Welches ist besser für Website-Backup - Rsync oder Git Push

Ich betreibe zwei LAMP-Webserver bei verschiedenen Anbietern für Disaster Recovery-Zwecke - einen leistungsstarken Live-Server und einen leistungsschwachen Backup-Server.

Derzeit synchronisiere ich alle 4 Stunden alle Daten vom Live-Server auf den Backup-Server.

Dies funktioniert einwandfrei, aber das System wird geladen, während rsync feststellt, welche Dateien geändert wurden.

Da sich alle Websites auch in Git-Repositories befinden, frage ich mich, ob ein Git-Push eine bessere Sicherungstechnik wäre.

Ich müsste den Ordner für Live-Uploads in das Git-Repo aufnehmen. und dann wäre der Sicherungsvorgang:

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

und dann einen Post-Commit-Hook auf dem Sicherungsserver zum Auschecken bei jedem Push.

Jede Website ist zwischen 50 und 2 GB groß. Am Ende hätte ich ungefähr 50 separate Git-Repos.

Ist das eine "bessere" Lösung als rsync?

• Kann git besser berechnen, welche Dateien geändert wurden?
• Ist Git Push effizienter als Rsync?
• Was habe ich vergessen

Vielen Dank!

---- Daten einiger Vergleichstests ------

1) 52 MB Ordner, dann Hinzufügen eines neuen 500 KB Ordners (hauptsächlich Textdateien)

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) 1.4G-Ordner, dann Hinzufügen eines neuen 18M-Ordners (hauptsächlich Bilder)

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) 52M Ordner, dann Hinzufügen eines neuen 18M Ordners (hauptsächlich Bilder)

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) 1.4G Ordner, dann Hinzufügen eines neuen 500k Ordners (hauptsächlich Text)

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) 1.4G Ordner - keine Änderung

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) 52M Ordner - keine Änderung

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

Eigentlich würde ich vorschlagen, eine ausgewogene Mischung aus beiden zu verwenden. Ihre Hauptsicherung sollte (mindestens) jede Nacht auf Git übertragen werden. Synchronisieren Sie es ein- oder zweimal pro Woche mit einer anderen Maschine, die mit rsync weit entfernt von der Produktionsbox ist.

Git hilft Ihnen bei der sofortigen Wiederherstellung und erleichtert die Analyse von Daten, da Ihr Backup versioniert ist und ein Änderungsprotokoll enthält. Nach jeder größeren Änderung an den Daten können Sie ein Commit durchführen und manuell auf git klicken und den Grund in das Changelog eintragen. Wenn git kaputt geht, hilft rsync, aber denken Sie daran, dass Sie immer noch Daten verlieren, abhängig von der Häufigkeit von rsync.

Faustregel: Wenn es um Backups und Disaster Recovery geht, kann Ihnen nichts 100% ige Wiederherstellung garantieren.

Rsync ist ein wunderbares Sync - Tool, aber Sie viel mehr Flexibilität erhalten , wenn Git (s) auf dem Server ausgeführt wird , und pushing oder pulling Updates.

Ich muss benutzergenerierte Inhalte auf unserem Server verfolgen und sichern. Der productionServer hat eine Kopie des Git-Repos und fügt jede Nacht automatisch alle neuen Dateien über cron hinzu und schreibt sie fest. Diese werden pushan unseren Gitolite-Server gesendet, der dann Hooks verwendet, um den Rest der Server zu synchronisieren.

Da die Server Kopien des Repos an Bord haben, erhalten Sie nicht nur einen Schnappschuss, sondern detaillierte Verlaufsinformationen, die Sie leicht retten können, wenn etwas mit Ihrem Server passiert.

Ich denke, Sie haben so ziemlich ein gutes Verständnis für das, was beide bieten. Ich würde einfach Ihre Denkweise ändern, von Servern, die die Codebasis auschecken / exportieren, bis hin zu ihren eigenen Repos. Ein weiterer Gedanke ist, dass Sie Ihre Mediendateien rsynchen könnten (Sie sagten 2 GB für einige dieser Sites, weshalb ich denke, dass es viele Mediendateitypen gibt?) Und sie nicht in Git verfolgen könnten.