[sciadzieda]

Napisany przez andy

To rozwiązanie jest mniej wydajne, bo za każdym razem wysyłasz wszystkie dane.

Sprawdźmy.

smok$ ssh leon@x
leon$ mkdir test && cd test
leon$ wget (jajko linuxa, brak 10 postów nie pozwala zamieścić linka)
leon$ tar xf linux-3.19.tar.xz
leon$ exit
smok$ mkdir testtar && cd testtar
smok$ time ssh leon@x 'cd ~/test/linux-3.19; tar cf - .' |  tar xf -
real	1m58.866s
user	0m13.801s
sys	0m5.804s
smok$ mkdir ../testrsync && cd ../testrsync
$smok time rsync -avz -q -e ssh leon@x:~/test/linux-3.19 .
real	1m26.136s
user	0m10.861s
sys	0m8.037s
$smok rm -Rf linux-3.19/samples/*
$smok time rsync -avz -q -e ssh leon@x:~/test/linux-3.19
real	0m15.260s
user	0m0.300s
sys	0m0.764s

Czyli rsync jest szybsze, choć używa więcej CPU.

Tyle że M@X za pomocą zwykłego kopiowania stworzył bardzo dobry system backupu serwera. Domyślam się, że posiada więcej niż jedną kopię, oznaczoną czasowo. Dzięki temu intuicyjnie dokona odtworzenia backupu z dowolnego dnia oraz będzie miał materiał dla analizy pozdarzeniowej.

Używając rsync musi zrozumieć, żeby nie synchronizować tego samego katalogu na maszynie backupowej - musi stworzyć strategię, logikę backupu. Strategią może być np. kopiowanie katalogu na localu i synchronizacja tejże kopii - aby mieć backup z kolejnych dni. Bo przecież np. włamanie i utrata plików nie musi być od razu zauważone.

Musiałby też M@X zautomatyzować kasowanie wybranych kopii itd itp

Wszystko zaczyna się komplikować, a skoro mielibyśmy zmuszać M@Xa do tworzenia nowego systemu backupu, to może lepiej niech użyje np.

rdiff-backup

który to jest już rozbudowanym narzędziem backupowym, synchronizującym wedle tego samego algorytmu co rsync i posiadającym też system logowania, o co M@X prosił na początku.

Podsumowując, rsync jest tylko narzędziem do synchronizacji plików, dzięki któremu można zbudować swoje narzędzie do backupu. Nie namawiałbym do tego M@Xa, bo posiada już swój backup i potrzebuje tylko metody wydajnego kopiowania.