Co jest lepsze do tworzenia kopii zapasowych witryn - rsync lub git push

Prowadzę 2 serwery sieciowe LAMP u różnych dostawców w celu odzyskiwania po awarii - serwer na żywo o wysokiej mocy i serwer zapasowy o niskiej mocy.

Obecnie synchronizuję wszystkie dane z serwera na żywo z serwerem zapasowym co 4 godziny.

Działa to dobrze, ale przyspiesza ładowanie systemu, podczas gdy rsync sprawdza, które pliki się zmieniły.

Ponieważ wszystkie strony internetowe również działają w repozytoriach git, zastanawiam się, czy push git byłby lepszą techniką tworzenia kopii zapasowych.

Musiałbym dołączyć folder przesyłania na żywo do repozytorium git; a następnie proces tworzenia kopii zapasowej byłby:

live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git push backup live_branch

a następnie mieć haczyk po zatwierdzeniu na serwerze zapasowym, aby kasować przy każdym wypychaniu.

Każda witryna ma rozmiar od 50 M do 2 GB. Skończyłem z około 50 osobnymi repozytoriami git.

Czy to jest „lepsze” rozwiązanie niż rsync?

• Czy git lepiej oblicza, które pliki uległy zmianie?
• Czy git push jest bardziej wydajny niż rsync
• O czym zapomniałem

Dzięki!

---- Dane z niektórych testów porównawczych ------

1) Folder 52 MB, a następnie dodany nowy folder 500k (głównie pliki tekstowe)

rsync

sent 1.47K bytes  received 285.91K bytes  
total size is 44.03M  speedup is 153.22

real    0m0.718s    user    0m0.044s    sys     0m0.084s

git

Counting objects: 38, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (37/37), 118.47 KiB, done.
Total 37 (delta 3), reused 0 (delta 0)

real    0m0.074s     user   0m0.029s    sys     0m0.045s

2) Folder 1,4G, a następnie dodanie nowego folderu 18M (głównie obrazy)

rsync

sent 3.65K bytes  received 18.90M bytes
total size is 1.42G  speedup is 75.17

real    0m5.311s    user    0m0.784s    sys     0m0.328s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.21 MiB/s, done.
Total 107 (delta 0), reused 0 (delta 0)

real    0m15.334s    user   0m5.202s    sys     0m1.040s

3) Folder 52 mln, a następnie dodany nowy folder 18 mln (głównie obrazy)

rsync

sent 2.46K bytes  received 18.27M bytes  4.06M bytes/sec
total size is 62.38M  speedup is 3.41

real    0m4.124s    user    0m0.640s    sys     0m0.188s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.43 MiB/s, done.
Total 107 (delta 1), reused 0 (delta 0)

real    0m6.990s    user    0m4.868s    sys     0m0.573s

4) Folder 1,4G, a następnie dodanie nowego folderu 500k (głównie tekst)

rsync

sent 2.66K bytes  received 916.04K bytes  612.47K bytes/sec
total size is 1.42G  speedup is 1547.14

real    0m1.191s    user    0m0.180s    sys     0m0.268s

git

Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (48/48), 177.90 KiB, done.
Total 48 (delta 3), reused 0 (delta 0)

real    0m1.776s    user    0m0.390s    sys     0m0.497s

5) Folder 1,4G - bez zmian

rsync

sent 1.72K bytes  received 716.44K bytes  287.26K bytes/sec
total size is 1.42G  speedup is 1979.18

real    0m1.092s    user    0m0.168s    sys     0m0.272s

git

nothing to commit (working directory clean)

real    0m0.636s    user    0m0.268s    sys     0m0.348s

5) Folder 52M - bez zmian

rsync

sent 528 bytes  received 88.40K bytes  59.29K bytes/sec
total size is 62.38M  speedup is 701.41

real    0m0.779s    user    0m0.044s    sys     0m0.144s

git

nothing to commit (working directory clean)

real    0m0.156s    user    0m0.057s    sys     0m0.097s

Właściwie sugerowałbym użycie zrównoważonej kombinacji obu. Twoja główna kopia zapasowa powinna być przydzielana (przynajmniej) co noc do git. Zsynchronizuj go raz lub dwa razy w tygodniu z innym komputerem, który znajduje się daleko od skrzynki produkcyjnej za pomocą rsync.

Git pomoże Ci w natychmiastowym odzyskaniu, a także ułatwi analizę danych, ponieważ twoja kopia zapasowa jest w wersji i ma dziennik zmian. Po każdej poważnej zmianie danych możesz wykonać zatwierdzenie i nacisnąć przycisk git ręcznie i podać przyczynę w dzienniku zmian. W przypadku, gdy git pójdzie źle, rsync przyjdzie na ratunek, ale pamiętaj, że nadal stracisz dane w zależności od częstotliwości rsync.

Ogólna zasada: jeśli chodzi o tworzenie kopii zapasowych i odzyskiwanie po awarii, nic nie może zagwarantować 100% odzyskania.

Rsync jest wspaniałym narzędziem do synchronizacji, ale zyskujesz znacznie większą wszechstronność, gdy uruchamiasz Git na serwerze (serwerach), a także aktualizujesz pushlub pullaktualizujesz.

Muszę śledzić i tworzyć kopie zapasowe treści generowanych przez użytkowników na naszym serwerze. productionSerwer posiada kopię repo git, a każda noc to automatycznie dodaje i zobowiązuje wszystkich nowych plików poprzez crona. Są one pushedytowane na naszym serwerze gitolite, który następnie używa haczyków do synchronizacji pozostałych serwerów.

Ponieważ serwery mają kopie repozytorium na pokładzie, otrzymujesz nie tylko migawkę, ale szczegółową historię, która może łatwo cię uratować, gdyby coś się stało z twoim serwerem.

Myślę, że właściwie dobrze rozumiesz, co oferują obie, po prostu zmienię twój sposób myślenia z serwerów sprawdzających / eksportujących bazę kodów na posiadanie własnych repozytoriów. Inną myślą jest to, że możesz zsynchronizować pliki multimedialne (powiedziałeś 2 GB dla niektórych z tych witryn, co sprawia, że ​​myślę, że istnieje wiele plików multimedialnych?) I nie śledzić ich w Git.