On 2022-10-15, Mateusz Viste <m...@x...invalid> wrote:
> 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.

Dzięki za objaśnienia. Chyba się faktycznie skuszę, bo w końcu to może
funkcjonować równolegle do innych rodzajów archiwizacji, a ja mam to de
facto już w tej chwili zorganizowane jako struktura na serwerze typu
klient-serwer.

A sam pomysł kompresji ciekawy. Tak mi się trochę kojarzy z kompresją
międzyramkową wideo, gdzie kolejne bloki pierwotnego (oryginalnego)
pliku, przy jego kolejnych kopiach, byłyby porównywane i kompresowane na
zasadzie I-frame i P-frames.

--
Marcin