2022-10-12 o 07:43 +0200, Marek napisał:
> On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszy
> > stko,
> > i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty
> > zysk.
>
> ?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez
> Internet (nie lokalnie)

Oczywiście, jeśli masz wąskie gardło między źródłem a celem, to
podejście przyrostowe jest istotnie szybsze. Wcześniej nic nie pisałeś
o backupach przez internet więc odniosłem się do sytuacji stricte
lokalnej. Ale i tu BORG jest lepszy od rsync, bo dodatkowo deduplikuje
i kompresuje.

> Nie ma nic lepszego niż rsync, reszta to protezy.

Z tym nie będę polemizował, bo wkraczamy już w obszar religii.

> Ale tworzenie obrazu to długa operacja

Zależy od nośnika i stanu FSa. Przy magnetycznych talerzach, taki
sekwencyjny dd potrafi być znacząco szybszy od kopiowania milionów
porozrzucanych plików.

> poza tym tworzenie obrazu dd
> jest bez sensu gdy fs jest np. w 1% zajęty lub ma pliki z dziurami.
> Dd tego nie zoptymalizuje.

Ano, dlatego pisałem, że samo dd ogólnie słabe jest, jeśli o backupy
chodzi. Można natomiast połączyć dd z BORGiem, wtedy wychodzi nam bardzo
eleganckie rozwiązanie. Albo użyć BORGa bez dd, jeśli sama struktura
FSa nas nie interesuje.

> Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe.

Niezupełnie. compare-dest kopiuje po prostu pliki, które
uległy zmianie, kopiując je w całości, czyli mają plik gigabajtowy, w
którym zmienił się tylko jeden bajt, w kopii przyrostowej rsync-a
pojawi się cały gigabajt.

> Świat się dzieli tylko na tych co używają rsync i tych, którzy będą
> go używać w przyszłości. Żadne inne protezy.

Przez parę lat używałem rsynca, ale świat idzie do przodu i obecnie
istnieją dużo fajniejsze rozwiązania. Najpierw z rsynca przeskoczyłem
na rdiff-backup, a później z rdiff-backup na BORG. Przy czym poniekąd
masz rację, bo w obu tych rozwiązaniach rsync jest zaszyty.

Mateusz