rsync full/incremental Backup

[heisenberg]

Ich habe das schon alles verstanden, aber um's nochmal einfach zusammenzufassen:

1. rsync kann auch nur Differenzen über das Netzwerk senden statt ganzer Dateien. Das ist gerade einer der zentralen Leistungsmerkmale von rsync so etwas zu können.
2. Die Methode die rsync dabei anwendet, ist sehr aufwändig. Es muss sowohl Quelle, als auch Ziel komplett lesen, was sehr hohe Platten-I/O verursacht.
3. CoW-Dateisysteme(zfs,btrfs) zeichnen Änderungen direkt als Teil des Betriebes auf und müssen Änderungen an Dateisytemen nicht extra ermitteln, sind also wesentlich schneller.
4. Der rsync Algorithmus hat dort den Vorteil, wo nur sehr geringe Netzwerkbandbreiten verfügbar sind.
5. Der Unterschied ist, das CoW-Dateisystem auf Dateisytemebene arbeiten und rsync auf Dateiebene.

[MSfree]

1. Die Methode die rsync dabei anwendet, ist sehr aufwändig. Es muss sowohl Quelle, als auch Ziel komplett lesen, was sehr hohe Platten-I/O verursacht.

Richtig. Das lohnt sich nur für sehr langsame Netzwerkverbindungen. Man muß rsync dazu die Parameter -c -B Blockgröße mitgeben. Dann werden vom Server Dateien in Datenblöcke der Größe Blockgröße unterteilt und für jeden Datenblock eine Prüfsumme berechnet und übertragen. Der Client kann dann seine Kopie ebenfalls in Teilblöcken lesen, Prüfsummen berechnen und mit der übermittelten vergleichen. Das verursacht dann aber neben IO auch noch CPU-Last wegen der Prüfsummenberechnung. Mein bevorzugt genutzter Debianmirror hat daher die Prüfsummenberechnung serverseitig abgeschaltet.

• CoW-Dateisysteme(zfs,btrfs) zeichnen Änderungen direkt als Teil des Betriebes auf und müssen Änderungen an Dateisytemen nicht extra ermitteln, sind also wesentlich schneller.

Wobei ich nicht genau weiß, ob man btrfs dazu noch speziell konfigurieren muß. Zumindest die Prüfsummenberechnung im btrfs ist noch per Default aktiv. Die ist zwar für Snapshots nicht unbedingt nötig, hilft aber, um Festplattenfehler aufzudecken.

• Der Unterschied ist, das CoW-Dateisystem auf Dateisytemebene arbeiten und rsync auf Dateiebene.

Damit hast du den wichtigsten Nagel au den Kopf getroffen.

[heisenberg]

Der Vorteil vom senden inkrementeller Snapshots ist also die Backup-Geschwindigkeit und die Resourcensparsamkeit.

Der Vorteil von rsync ist der Zugriff auf einzelne Dateien des Backups, den man mit den Snapshots so überhaupt nicht hat. (Es sei denn man spielt alle full+incr. Snapshots auf einem Ersatzsystem ein und stellt damit dann wieder einzelne Dateien her).

[Lord_Carlos]

Der Vorteil von rsync ist der Zugriff auf einzelne Dateien des Backups, den man mit den Snapshots so überhaupt nicht hat.

Doch, ich glaube in falle von ZFS schon.
Bei Lokalen Snapshots hast du immer Lesezugriff auf alle Snapshot Daten. Die liegen einfach in .zfs/snapshot/<name des snapshots>
Und wenn ich alles richtig verstanden habe sind remote snapshots genau so.

Auch nett: Daten sind schon Komprimiert (Wenn moeglich) und ggf verschluesselt (Meta Daten ausgenommen)

Mein / root ist auch noch altes ext4 und deswegen sind meine /etc backups auch noch alt modisch als <datum>.tar.gz verpackt. Aber ich glaube wenn ich mal Zeit habe werde ich es um machen. Einfach rsync des etc Ordners auf eine ZFS platte und da snapshot erstellen. Beim naechsten mal einfach die Daten ueberschreiben und neues snapshot machen. Fertig.

[Tintom]

Der Vorteil von rsync ist der Zugriff auf einzelne Dateien des Backups, den man mit den Snapshots so überhaupt nicht hat. (Es sei denn man spielt alle full+incr. Snapshots auf einem Ersatzsystem ein und stellt damit dann wieder einzelne Dateien her).

Der eigentliche Vorteil ist, dass es als eigenständiges Programm völlig unabhängig vom darunterliegenden Dateisystem ist. Die Option --inplace ist ein Versuch das beste aus beiden Welten miteinander zu verknüpfen, aber ich muss gestehen, ausprobiert habe ich sie noch nicht.

[heisenberg]

--inplace heisst nur, dass die Datei direkt geschrieben wird und nicht eine temporäre Datei vorab, die dann umbenannt wird.

[joe2017]

Schönen guten Morgen und... was ist denn hier passiert?
Ein Tag nicht dazu gekommen und schon ist das Thema explodiert. Aber ich finde eure Ansätze alle sehr interessant.

Ich werde das Ganze jetzt erst einmal mir rsync angehen, da ich immer auf einzelne Backup Files zugreifen muss.
Zudem ist das alles ziemlich simple einzurichten.

Jedoch ist mir aufgefallen, dass wenn ich das Ganze über ssh (key) durchführe, dauert das Inrementelle Backup sehr lange.
Ich habe aktuell nur 4 Dateien (3 txt Datein und eine 4GB Datei) auf dem zu sichernden Ordner liegen, und mit --compare-dest oder --link-dest dauert das Backup über 1 Minute.

Ich habe das wie folgt eingerichtet:

Code: Alles auswählen

ssh-keygen -t ecdsa -b 384

Den Key auf meinen zu sichernden Server übertragen und den ersten Login getestet. Das funktioniert soweit.

Code: Alles auswählen

ssh serverIP -i /path/to/id_ecdsa

Anbei meine rsync Befehle:
Full Backup

Code: Alles auswählen

rsync -avre 'ssh -i /path/to/id_ecdsa' admin@serverIP:/backup/source/path /backup/target/path/fullbackup

Incremental Backup

Code: Alles auswählen

rsync -avre 'ssh -i /path/to/id_ecdsa' --compare-dest=/backup/target/path/fullbackup admin@serverIP:/backup/source/path /backup/target/path/incrbackup
oder
rsync -avre 'ssh -i /path/to/id_ecdsa' --link-dest=/backup/target/path/fullbackup admin@serverIP:/backup/source/path /backup/target/path/incrbackup

Hat jemand eine Idee woran das liegen könnte?
Wenn nur Links erstellt werden, dürfte das doch nicht so lange dauern oder? Ich gehe mal davon aus, dass die Links auf das Full Backup zeigen.

[MSfree]

Ich habe aktuell nur 4 Dateien (3 txt Datein und eine 4GB Datei) auf dem zu sichernden Ordner liegen, und mit --compare-dest oder --link-dest dauert das Backup über 1 Minute.

Eine Minute für ein paar Dateien hört sich erstmal zu lange an. Spontan weiß ich natürlich nicht, was da bremst.

Wie lange hat das originale Fullbackup über SSH gedauert?
Wann fängt die Ausgabe im Terminal an zu laufen, wenn du rsync in einem Terminal startest?

Ja, SSH bremst ein wenig, was unter anderem an der Verschlüsselung liegt. Bei nur 4 (hoffentlich kleinen) Dateien sollte es aber praktisch keinen Unterschied zwischen unverschlüsseltem rsync und rsync über SSH geben.

Mein Backup läuft allerdings unverschlüsselt direkt über den rsync-Port (873). Dazu muß aber ein rsync-Server auf der Quellmaschine laufen. Diesen kann man auch read-only einrichten, damit man die Dateien der Quellmaschine nicht (versehentlich) über das rsync-Protokoll manipuliert.

[Lord_Carlos]

Hat sich die 4GB Datei geaendert, oder dessen Timestamp?

[joe2017]

Ich habe gerade herausgefunden, weshalb mein rsync so lange dauert. Als erstes hatte ich die externe Festplatte in verdacht.

Jedoch habe ich gerade von meinem source Server via scp eine Datei auf meinen Backup Server kopiert. Hier bekomme ich eine Übertragung von ca. 12MB/s angezeigt.

Mein Source Server ist eine VM und läuft unter einem Microsoft Hyper-V Server. Vielleicht wird die Netzwerkkarte nicht richtig angesprochen?
Muss hierfür evtl. etwas nachinstalliert werden?

[joe2017]

Schönen guten Morgen zusammen,

ich wollte euch nur kurz informieren, dass es nicht an meiner VM lag, sondern an meinem Backup Server (keine VM).
Hier wird die Onboard Netzwerkkarte nicht unterstützt. Nach Einbau einer Netzwerkkarte, werden meine Dateien mit der erwarteten Netzwerkgeschwindigkeit kopiert.

Mein Full Backup wird mit ca. 4GB in ca. 30 Sek erstellt.
Mein Incrementelles Backup dauert jedoch ca 75 Sek. Egal ob ich --link-dest oder --compare-dest verwende.

Code: Alles auswählen

sudo rsync -avre "ssh -i /path/to/key" --link-dest=/path/to/full/backup user@ServerIP:/path /path/to/incremental/backup

Hat hierzu noch jemand eine Idee?
Gibt es nicht die Möglichkeit nur die Files zu sichern welche nicht verändert wurden? Ohne Hardlinks zu erzeugen.
Vielleichet ändert das etwas?

[MSfree]

Hier wird die Onboard Netzwerkkarte nicht unterstützt.

Was ist denn das für ein Exot? Oder fehlt da nur Firmware?

Mein Full Backup wird mit ca. 4GB in ca. 30 Sek erstellt.

Was sit das für ein Netzwerk?
Wie viele Dateien sind das?
4GB in 30s ist über GBit-Ethernet unmögiich. Das müßtest du also noch präzisieren.

[joe2017]

Eigentlich ist das eine normale Realtek Karte. Jedoch ist der PC ein ziemlich neues Model. Wahrscheinlich wird die Karte nicht unterstützt.
Hab auch versucht diverse Debian Firmware zu installieren. Leider ohne Erfolg.

Ich habe lediglich eine 4GB ISO Datei (gerade überprüft ca. 3,4GB) als Test abgelegt. Diese wird auf meinem BackupServer auf eine externe Festplatte geschrieben.
Das wäre jetzt auch nicht das Problem. Das Problem ist, dass mein Incrementerlles Backup so viel länger dauert als mein Full Backup.

Gibt es nicht eine Möglichkeit, ohne Hardlinks zu arbeiten. Einfach nur die neuen Files zu übertragen?
Oder ist das Problem nicht bei den Hardlinks zu suchen, sondern ehr bei der Überprüfung welche Files verändert wurden.

Ich kenne das aktuell nur aus der Microsoft Welt mit robocopy. Hier wird ein Flac gesetzt sobald eine Datei bearbeitet wurde. Somit weiß Robocopy welche Files geschrieben werden müssen.
Ich habe bei rsync schon die Option --backup-dir versucht. Jedoch funktioniert das irgendwie überhaupt nicht.

Mit SCP gibt es ja leider keine Möglichkeit Inrementelle Files zu schreiben.

[MSfree]

Eigentlich ist das eine normale Realtek Karte. Jedoch ist der PC ein ziemlich neues Model. Wahrscheinlich wird die Karte nicht unterstützt.
Hab auch versucht diverse Debian Firmware zu installieren. Leider ohne Erfolg.

Das glaube ich nicht so recht. Realteks gehören zu den verbreitetsten NICs überhaupt und ich hatte bisher keine, die nicht funktioniert hätte.
Was geben

Code: Alles auswählen

lspci

und

Code: Alles auswählen

ip a

aus?

Ich habe lediglich eine 4GB ISO Datei (gerade überprüft ca. 3,4GB) als Test abgelegt. Diese wird auf meinem BackupServer auf eine externe Festplatte geschrieben.

OK, 3.4GB in 30s für nur eine Datei hört sich schon realistischer an.

Das wäre jetzt auch nicht das Problem. Das Problem ist, dass mein Incrementerlles Backup so viel länger dauert als mein Full Backup.

Was sind denn die genauen Optionen, die du rsync mitgibts?

Gibt es nicht eine Möglichkeit, ohne Hardlinks zu arbeiten. Einfach nur die neuen Files zu übertragen?

Das ist der Default. Du verlierst aber damit die Möglichkeit, das Backup eines ganz speziellen Tages herstellen zu können.Wenn du einen Emotet-Vorfall hast, willst du nicht die bereits verschlüsselten Dateien aus dem Backup kopieren sondern die Dateien, die noch intakt sind. Daher ist es sinnvoll, immer eine gewisse Backuphistory mitzuschleppen und das geht eben mit Hardlinks.

[joe2017]

Ich glaube ich habe den Fehler gefunden. Bin mir aber nicht sicher.

Ich verwende folgenden Befehl:
Full Backup

Code: Alles auswählen

sudo rsync -avre "ssh -i /path/to/key" user@ServerIP:"/source" "/destination/full-backup"

Soweit so gut. Das Script wird auf meinem Backup Server gestartet. Dieser verbindet sich mit dem ssh key zu meinem Samba Server und kopiert die Lokalen Daten aus "/source" auf meinen Backup Server "/destination/full-backup"

Incremental Backup

Code: Alles auswählen

sudo rsync -avre "ssh -i /path/to/key" --compare-dest="/destination/full-backup" user@ServerIP:"/source" "/destination/incr-backup"

Hier ist glaube ich der Fehler. Das Script wird wieder auf dem Backup Server ausgeführt. Dieser verbindet sich mit dem ssh key zu meinem Samba Server und kopiert die Lokalen Daten aus "/source" auf meinen Backup Server "/destination/full-backup". Zusätzlich sollten die Daten mit dem Verzeichnis auf dem Backup Server "/destination/full-backup" verglichen werden.

Ich denke das hier der Fehler liegt. Wenn ich das ohne ssh teste funktioniert der --compare-dest Befehl

Code: Alles auswählen

sudo rsync -avr --compare-dest="/destination/full-backup" "/source" "/destination/incr-backup"

Ich befürchte, dass in meinem obigen Befehl das --compare-dest Verzeichnis nicht überprüft werden kann?

Ich habe das auch schon umgestellt. Dann wird jedoch wieder alles kopiert.

Code: Alles auswählen

sudo rsync -avr --compare-dest="/destination/full-backup" -e "ssh -i /path/to/key" user@ServerIP:"/source" "/destination/incr-backup"

[joe2017]

Ich habe gerade einen interessanten Artikel gefunden.
https://www.linuxforen.de/forums/showth ... -erreichba
Hier wird mehr oder weniger die selbe Problematik beschrieben. Hier wird gesagt, dass während des Backups von einem Remote Server auf den Backup Server die Rechte auf dem Backup Server geändert werden. Somit würden sich die Dateien anschließend immer von dem Quell Server unterscheiden. Aus diesem Grund würde wieder alles kopiert werden.

Das muss aber doch zu lösen sein.
Mit Snapshots kann ich leider nicht arbeiten, da ich immer auf die einzelnen Folder/Files zugreifen muss.

[MSfree]

Welchen Benutzer nutzt du, um den SSH-Tunnel zu starten?
Hast du es auch mal als root versucht?

[Lord_Carlos]

Das muss aber doch zu lösen sein.

Ich bin leider nicht so der rsync experte. Aber ich stelle mal ein Paar dumme Fragen. Vielleicht hilft es. Alternativ einfach ignorieren.

Hast du es mal mit trailing slashes versucht?

Code: Alles auswählen

rsync -avre 'ssh -i /path/to/id_ecdsa' --link-dest=/backup/target/path/fullbackup/ admin@serverIP:/backup/source/path/ /backup/target/path/incrbackup/

Was passiert dann? Wird einfach alles nochmal uebertragen, und dann links erstellt? Oder werden gar keine links erstellt?
Eigentlich sollte das funktionieren: https://unix.stackexchange.com/question ... ot-linking

Mit Snapshots kann ich leider nicht arbeiten, da ich immer auf die einzelnen Folder/Files zugreifen muss.

Ich weis nicht wie es bei btrfs oder LVM ist, aber bei ZFS geht das ohne Probleme.
Ob ZFS bei dir jetzt alles besser macht kann ich aber auch nicht einschaetzen. Wahrscheinlich eher etwas was man sich in der Zukunft mal angucken kann.