2022-10-15 o 00:31 GMT, Marcin Debowski napisał:
> > A kiedy będziesz potrzebował któregoś z tych obrazów dd, to albo
> > wyciągasz go BORGiem na serwerze (a dalej tradycyjnie, na dyskietce
> > czy co tam używasz), albo montujesz BORGa FUSE-em i eksportujesz
> > zasób NFSem lub inną Sambą.
>
> A ta kompresja to jest na poziomie bloków jakiegoś wewnętrznego
> systemu plików, skoro, jak napisałeś gdzieindziej, zmiana w dużym
> pliku nie oznacza jego nowej, pełnej kopii?

Nie tyle w wewnętrznym "systemie plików", co w sposobie, w jaki BORG
trzyma dane (tj. formacie swojej bazy danych). Przy czym sama kompresja
tak naprawdę niewiele daje. Dużo bardziej interesująca jest
deduplikacja. Kiedy masz dwa pliki, których zawartość pokrywa się np. w
90%, to BORG potrafi to wykryć i zapisuje 90% ich zawartości tylko raz.

Masz natomiast rację w tym, że jest to podejście blokowe, poniekąd
podobne zresztą do tego, które znamy z torrentów. Deduplikacja działa
tak, że BORG każdy plik dzieli na bloki. Dla każdego bloku oblicza hash
i taką parę HASH=BLOK sobie zapisuje w swojej bazie. Jeśli widzi, że
hash o takiej wartości już wcześniej wystąpił, to nie zapisuje go
kolejny raz, tylko trzyma odnośnik do niego. Co istotne: nieważne, czy
blok pochodzi z tego samego pliku, czy z dwóch różnych, czy nawet z
różnych źródeł lub różnych okresów backupu: BORG trzyma go tylko raz.

Czyli jeśli mam gigabajtowy plik wideo, który sobie skopiuję na dysk
pod inną nazwą, potem wyślę na laptop żony, i dodatkowo zapiszę na
domowym NASie, to po backupach tych trzech komputerów w bazie BORGa
plik nadal będzie zapisany tylko raz, a nie 4x jak to miałoby miejsce
przy konwencjonalnym podejściu.

Do tego deduplikacja zachodzi już na kliencie, czyli zamiast wysyłać
całość danych do serwera backupowego, klient BORGa wysyła mu listę
znalezionych plików, i dla każdego pliku listę bloków (hashy), z
których się składa. Serwer wówczas pyta tylko o te bloki, których
jeszcze nie zna, dzięki czemu wysyłamy relatywnie mało danych (dużo
mniej, niż wysłałby rsync).

BORG daje też fajny podgląd na to, jak skuteczny jest każdy z etapów.
Tutaj przykład obecnego stanu mojego repo:

----------------------------------------------------
--------------
Original size Compressed size Deduplicated size
All archives: 2.32 TB 1.87 TB 110.30 GB

Unique chunks Total chunks
Chunk index: 575'596 12'846'752
----------------------------------------------------
--------------

Takie repo można zamontować (read-only) borgfs-em, wówczas użytkownik
widzi normalną strukturę katalogów, a borgfs zajmuje się w tle
odpowiednim mapowaniem danych.


Mateusz