🚀 go-pugleaf

2022-11-15 o 02:35 GMT, Marcin Debowski napisał:
> Właśnie się zacząłem zaznajamiac z borgiem i podoba mi się coraz 
> bardziej, tyle tylko, że preferuję robienie backupów w trybie pull, a 
> borg chyba wyłącznie przewiduje tryb push? Tj. że na remote host
> sprawę załatwia klient. Nie podoba mi się to ze względów
> bezpieczeństwa bo raz, że muszę mieć wystawiony port dla borga lub
> kombinować z tunelami, dwa, że nie lubię aby stado maszyn miało
> dostęp do archiwum, nawet tych dedykowanych konkretnej maszynie.

Z tego co wiem to BORG jest backupem "pull" i należy się z tym
pogodzić. :)

BORG korzysta z ssh, więc nie ma potrzeby wystawiania portu specjalnie
dla BORG, a ssh pewno i tak masz na serwerze backupowym.

Stado maszyn dążących do jednego repo może być problemem z czterech
powodów:
- nie chcesz, by klient A mógł wykasować backupy (swoje lub nie)
- nie chcesz, by klient A miał dostęp do danych klienta B
- masz na tyle częste backupy, że klienci muszą walczyć o write lock
- chcesz wiedzieć, kiedy backup dla któregoś klienta się z jakiegoś
  powodu przestanie wykonywać

Pierwszy problem jest łatwy w rozwiązaniu: wystarczy dodać BORGowi
flagę --append-only, tzn. zezwolić klientowi na wywoływanie go tylko z
tą flagą (via authorized_keys).

Drugi problem można rozwiązać poprzez stosowanie osobnego repozytorium
dla każdego klienta. Zalety: każdy klient ma swój unikalny klucz oraz
pełna izolacja danych. Wada: tracisz deduplikację danych między
klientami.
Przy takiej konfiguracji trzeba oczywiście dodać odpowiedni parametr
--restrict-to-repository w authorized_keys, by każdemu klientowi
ograniczyć dostęp li tylko do swojego repo. Alternatywnie: ograniczyć
dostępy uprawnieniami na poziomie FS-a.

Trzeci problem można rozwiązać albo osobnymi repo dla klientów, albo
ścisłym harmonogramem (np. klient A ma okienko backupowe w dni parzyste
między 10:00 a 10:15, klient B między 10:15 a 10:30, itd). Backupy BORG
wykonują się bardzo szybko, więc w praktyce nie jest to jakiś duży
problem, chyba że masz naprawdę dużo klientów.

Czwarty problem załatwiam krótkim skryptem, który okresowo zagląda do
mojego repo i sprawdza datę ostatniego backupy dla każdego klienta.
Jeśli jest dalsza niż tydzień to wysyła mi maila.

Mam świadomość, że to wszystko nie odpowiada na Twoje pytanie. Staram
się tu tylko zasugerować, że być może "pull" jednak nie taki straszny.

> Czy, jeśli faktycznie tylko push, da się to jakoś elegancko zrobić
> bez dodatkowych zabiegów w stylu sshfs?

Pomysł z sshfs wydaje mi się słaby, bo jeśli dobrze rozumiem co masz na
myśli, to serwer musiałby zaciągnąć pełne dane od klienta, a to
może potrwać... Jedną z b. fajnych zalet BORGa jest niesamowita
szybkość backupów dzięki temu, że klient wysyła serwerowi tylko
zmienione bloki. Montując zdalny FS tracisz tę zaletę.


Mateusz

2022-11-15 o 02:35 GMT, Marcin Debowski napisał:
> Właśnie się zacząłem zaznajamiac z borgiem i podoba mi się coraz 
> bardziej, tyle tylko, że preferuję robienie backupów w trybie pull, a 
> borg chyba wyłącznie przewiduje tryb push? Tj. że na remote host
> sprawę załatwia klient. Nie podoba mi się to ze względów
> bezpieczeństwa bo raz, że muszę mieć wystawiony port dla borga lub
> kombinować z tunelami, dwa, że nie lubię aby stado maszyn miało
> dostęp do archiwum, nawet tych dedykowanych konkretnej maszynie.

Z tego co wiem to BORG jest backupem "push" i należy się z tym
pogodzić. :)

BORG korzysta z ssh, więc nie ma potrzeby wystawiania portu specjalnie
dla BORG, a ssh pewno i tak masz na serwerze backupowym.

Stado maszyn dążących do jednego repo może być problemem z czterech
powodów:
- nie chcesz, by klient A mógł wykasować backupy (swoje lub nie)
- nie chcesz, by klient A miał dostęp do danych klienta B
- masz na tyle częste backupy, że klienci muszą walczyć o write lock
- chcesz wiedzieć, kiedy backup dla któregoś klienta się z jakiegoś
  powodu przestanie wykonywać

Pierwszy problem jest łatwy w rozwiązaniu: wystarczy dodać BORGowi
flagę --append-only, tzn. zezwolić klientowi na wywoływanie go tylko z
tą flagą (via authorized_keys).

Drugi problem można rozwiązać poprzez stosowanie osobnego repozytorium
dla każdego klienta. Zalety: każdy klient ma swój unikalny klucz oraz
pełna izolacja danych. Wada: tracisz deduplikację danych między
klientami.
Przy takiej konfiguracji trzeba oczywiście dodać odpowiedni parametr
--restrict-to-repository w authorized_keys, by każdemu klientowi
ograniczyć dostęp li tylko do swojego repo. Alternatywnie: ograniczyć
dostępy uprawnieniami na poziomie FS-a.

Trzeci problem można rozwiązać albo osobnymi repo dla klientów, albo
ścisłym harmonogramem (np. klient A ma okienko backupowe w dni parzyste
między 10:00 a 10:15, klient B między 10:15 a 10:30, itd). Backupy BORG
wykonują się bardzo szybko, więc w praktyce nie jest to jakiś duży
problem, chyba że masz naprawdę dużo klientów.

Czwarty problem załatwiam krótkim skryptem, który okresowo zagląda do
mojego repo i sprawdza datę ostatniego backupy dla każdego klienta.
Jeśli jest dalsza niż tydzień to wysyła mi maila.

Mam świadomość, że to wszystko nie odpowiada na Twoje pytanie. Staram
się tu tylko zasugerować, że być może "pull" jednak nie taki straszny.

> Czy, jeśli faktycznie tylko push, da się to jakoś elegancko zrobić
> bez dodatkowych zabiegów w stylu sshfs?

Pomysł z sshfs wydaje mi się słaby, bo jeśli dobrze rozumiem co masz na
myśli, to serwer musiałby zaciągnąć pełne dane od klienta, a to
może potrwać... Jedną z b. fajnych zalet BORGa jest niesamowita
szybkość backupów dzięki temu, że klient wysyła serwerowi tylko
zmienione bloki. Montując zdalny FS tracisz tę zaletę.


Mateusz

On 2022-11-15, Mateusz Viste <mateusz@xyz.invalid> wrote:
> 2022-11-15 o 02:35 GMT, Marcin Debowski napisał:
>> Właśnie się zacząłem zaznajamiac z borgiem i podoba mi się coraz 
>> bardziej, tyle tylko, że preferuję robienie backupów w trybie pull, a 
>> borg chyba wyłącznie przewiduje tryb push? Tj. że na remote host
>> sprawę załatwia klient. Nie podoba mi się to ze względów
>> bezpieczeństwa bo raz, że muszę mieć wystawiony port dla borga lub
>> kombinować z tunelami, dwa, że nie lubię aby stado maszyn miało
>> dostęp do archiwum, nawet tych dedykowanych konkretnej maszynie.
>
> Z tego co wiem to BORG jest backupem "pull" i należy się z tym
> pogodzić. :)

E, jest push? :) A potrzeba "pull" wydaje się bardzo realna bo walneli 
cały rozdział w dokumentacji jak to obejść: 
https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html 
Trochę zastanawia dlaczego nie zaimplementować czegoś w kliencie (który 
w tym momencie robiłby za lokalny serwer), skoro najwyraźniej widzą, że 
jest pewien problem.

> BORG korzysta z ssh, więc nie ma potrzeby wystawiania portu specjalnie
> dla BORG, a ssh pewno i tak masz na serwerze backupowym.

Tak, ale nie jest wystawiony. Jest wyłącznie dostępny w sieci lokalnej.

> Stado maszyn dążących do jednego repo może być problemem z czterech
> powodów:
> - nie chcesz, by klient A mógł wykasować backupy (swoje lub nie)

To jest głowna przyczyna dla której ogólnie nie podoba mi się koncept, 
że to klient rządzi.

> - nie chcesz, by klient A miał dostęp do danych klienta B
> - masz na tyle częste backupy, że klienci muszą walczyć o write lock
> - chcesz wiedzieć, kiedy backup dla któregoś klienta się z jakiegoś
>   powodu przestanie wykonywać
>
> Pierwszy problem jest łatwy w rozwiązaniu: wystarczy dodać BORGowi
> flagę --append-only, tzn. zezwolić klientowi na wywoływanie go tylko z
> tą flagą (via authorized_keys).

Dzięki, muszę trochę jeszcze poczytać.

> Drugi problem można rozwiązać poprzez stosowanie osobnego repozytorium
> dla każdego klienta. Zalety: każdy klient ma swój unikalny klucz oraz
> pełna izolacja danych. Wada: tracisz deduplikację danych między
> klientami.

Tak właśnie zamierzam. Myślę, że przeżyje bez tej międzymaszynowej 
deduplikacji.

> Przy takiej konfiguracji trzeba oczywiście dodać odpowiedni parametr
> --restrict-to-repository w authorized_keys, by każdemu klientowi
> ograniczyć dostęp li tylko do swojego repo. Alternatywnie: ograniczyć
> dostępy uprawnieniami na poziomie FS-a.
>
> Trzeci problem można rozwiązać albo osobnymi repo dla klientów, albo
> ścisłym harmonogramem (np. klient A ma okienko backupowe w dni parzyste
> między 10:00 a 10:15, klient B między 10:15 a 10:30, itd). Backupy BORG
> wykonują się bardzo szybko, więc w praktyce nie jest to jakiś duży
> problem, chyba że masz naprawdę dużo klientów.
>
> Czwarty problem załatwiam krótkim skryptem, który okresowo zagląda do
> mojego repo i sprawdza datę ostatniego backupy dla każdego klienta.
> Jeśli jest dalsza niż tydzień to wysyła mi maila.
>
> Mam świadomość, że to wszystko nie odpowiada na Twoje pytanie. Staram
> się tu tylko zasugerować, że być może "pull" jednak nie taki straszny.

Pomyślałem, że zrobię to w ten sposób, że serwer będzie łączył się z 
klientem, tworzył do siebie tunel i odpalał na kliencie backup ze 
wskazaniem tego forwardującego, lokalnego portu na maszynie klienta. W 
połączeniu z --append-only powinno załatwić większość wspomnianych 
wcześniej problemów. Teraz tylko się zastanawiam jak zrobić z 
autoryzacją, ale w sumie jedyne czym tu się chyba ryzykuje, to że 
ktoś (w razie utraty klienta) zapcha repozytorium, więc w sumie ryyzko 
nieduże. Dodatkowo widzę można też poustawiać quoty.

>> Czy, jeśli faktycznie tylko push, da się to jakoś elegancko zrobić
>> bez dodatkowych zabiegów w stylu sshfs?
>
> Pomysł z sshfs wydaje mi się słaby, bo jeśli dobrze rozumiem co masz na
> myśli, to serwer musiałby zaciągnąć pełne dane od klienta, a to
> może potrwać... Jedną z b. fajnych zalet BORGa jest niesamowita
> szybkość backupów dzięki temu, że klient wysyła serwerowi tylko
> zmienione bloki. Montując zdalny FS tracisz tę zaletę.

Zerknij pod ww. linkiem. Próbowałem nawet to zrobić ale coś mi nie chce 
bindować. Poza tym bardzo nie podoba mi się część z chrootowaniem. Nie 
wiem jak szybko to działa w praktyce, ale zwykłe podmontowanie sshfs i 
praca nad tym jak na zasobie lokalnym działa faktycznie koszmarnie 
wolno.

-- 
Marcin

Kontynuując wątek...

Wystawiam tunel na porcie, tu 15222, do serwera z borgiem. Jak łaczę się 
z terminala to klarownie następuje zakończona sukcesem negocjacja po 
kluczach:

root@mmlinux:~# ssh -p 15222 backups@localhost PTY allocation request 
failed on channel 0 

(w authorized_keys jest command="borg serve --append-only 
--restrict-to-repo ...etc)

Ale jak robie borga, np.: 
borg create -s --progress backups@localhost:15222/itakdalej dostaję 
backups@localhost's password: i nawet jak podam, to dostaję Repository 
backups@localhost:15222/itakdalej does not exist.

Zgaduję, że mu się serwer z repo nie zgadza choć nie do końca rozumiem 
braku negocjacji po kluczu. Pytanie jak zrobić aby się łączył po 
przeforwardowanym porcie?

-- 
Marcin

On 2022-11-20, Marcin Debowski <agatek@INVALID.zoho.com> wrote:
> Kontynuując wątek...
>
> Wystawiam tunel na porcie, tu 15222, do serwera z borgiem. Jak łaczę się 
> z terminala to klarownie następuje zakończona sukcesem negocjacja po 
> kluczach:
>
> root@mmlinux:~# ssh -p 15222 backups@localhost PTY allocation request 
> failed on channel 0 
>
> (w authorized_keys jest command="borg serve --append-only 
> --restrict-to-repo ...etc)
>
> Ale jak robie borga, np.: 
> borg create -s --progress backups@localhost:15222/itakdalej dostaję 
> backups@localhost's password: i nawet jak podam, to dostaję Repository 
> backups@localhost:15222/itakdalej does not exist.
>
> Zgaduję, że mu się serwer z repo nie zgadza choć nie do końca rozumiem 
> braku negocjacji po kluczu. Pytanie jak zrobić aby się łączył po 
> przeforwardowanym porcie?

Tak właśnie przeglądam internety w poszukiwaniu rozwiązania i widzę, że 
w cytowanym wcześniej linku o sposobach "pull" jest rozwiązanie oparte 
na socketach.

borg-server:~$ ssh \
   -R /run/borg/reponame.sock:/run/borg/reponame.sock \
   borgc@borg-client \
   borg create \
   --rsh "sh -c 'exec socat STDIO UNIX-CONNECT:/run/borg/reponame.sock'" \
   ssh://borg-server/path/to/repo::archive /path_to_backup \
   ';' rm /run/borg/reponame.sock

Być może więc nie da się jakoś "normalnie".

-- 
Marcin