rsync full/incremental Backup

[joe2017]

Schönen guten Morgen zusammen,

ich weiß, dass dieses Thema schon ausreichend behandelt wurde. Ich hätte eine kleine Frage und finde den passenden Schalter nicht. Ich bin mir sicher, dass jemand von euch das Problem schon mal hatte.

Ich möchte ein Full Backup in den Folder BackupFull und ein incrementelles Backup in den Ordner BackupIncremental erstellen.
Soweit so gut.

Code: Alles auswählen

source=/path/to/folder
target=/path/to/folder

rsync -avr "${source}" "${target}/BackupFull" 
rsync -avr --compare-dest="${target}/BackupFull" "${source}" "${target}/BackupIncremental"

Jetzt meine Frage. mit dem rsync Befehl für die incrementellen Backups wird jedoch die gesamte Ordnerstruktur angelegt. Auch wenn keine Dateien verändert und somit nicht gebackupt werden. Kann man das verhindern? Es sollten nur Ordner erstellt werden, wenn auch Dateien erstellt werden.

Wahrscheinlich ist das nur ein einziger Schalter und ich seh den Wald vor lauter Bäumen nicht.

Danke.

[bullgard]

Ich empfehle Dir als sehr gute Alternative rsnapshot.
Gruß
bullgard

[Tintom]

Auch wenn keine Dateien verändert und somit nicht gebackupt werden. Kann man das verhindern?

Ich vermute du suchst den Parameter --link-dest.
Mit dem Schalter kannst du ein Referenzbackup vergleichen. Bei Sicherung nimmt rsync die Daten in dem Referenzbackup als Vergleich und setzt Hardlinks zu den Dateien, die sich nicht verändert haben. Es sieht auf Dateiebene so aus als wenn ein Komplettbackup gefahren wird, faktisch werden aber nur die neu hinzugekommenen Daten gesichert.

[joe2017]

Hi Tintom,

wenn ich das jetzt richtig mit dem --link-dest verstanden habe, sieht dies in meinem Backup immer so aus, als ob es ein volles Backup wäre. Es werden alle Dateien in dem incrementellen Backup angezeigt. Jedoch werden Hardlinks von den bestehenden Files welche nicht bearbeitet wurden angelegt und lediglich die neuen Files in den neuen Folder geschrieben.

Wie macht sich das anlegen der Hardlinks bei hunderttausenden Files bemerkbar?
Wird dies eine enorme Zeit in anspruch nehmen? Der benötigte Speicherplatz sollte sich ja in Grenzen halten, das es sich nur um Links handelt.

Ich werde mir das mal anschauen.

Danke schon mal für den Tipp. Falls das nicht hilft, werde ich mir die Alernative rsnapshot ansehen.
Ich wollte das Ganze als Fileserver Backup verwenden. Ich muss einmal die Woche ein volles Backup erstellen, und täglich bzw. mehrmals täglich ein incrementelles Backup.

[MSfree]

Wie macht sich das anlegen der Hardlinks bei hunderttausenden Files bemerkbar?

Jeder Hardlink beansprucht einen Verzeichniseintrag, kostet also immer auch Platz. Das macht aber bei einer Million Dateien "nur" 20-30 MByte aus.

Wird dies eine enorme Zeit in anspruch nehmen?

Leider ja. Bei mir wird täglich ein Dateisystem auf die Art gesichert. Dabei sind 870000 Dateien und Verzeichnisse zu sichern, was im Moment etwa 1,5h braucht, inklusive der Übertragung der Dateien, die sich wirklich geändert haben (etwa. 12GB).

Falls das nicht hilft, werde ich mir die Alernative rsnapshot ansehen.

rsnapshot hatte ich vor vielen Jahren mal im Einsatz. Das funktioniert aber sehr ähnlich wie rsync --link-dest, es ist sogar so, daß rsnapshot rsync vewendet. Daher ist der Zeit- und Speicherbedarf hier nicht besser.

[Tintom]

Wird dies eine enorme Zeit in anspruch nehmen?

Leider ja. Bei mir wird täglich ein Dateisystem auf die Art gesichert. Dabei sind 870000 Dateien und Verzeichnisse zu sichern, was im Moment etwa 1,5h braucht, inklusive der Übertragung der Dateien, die sich wirklich geändert haben (etwa. 12GB).

Interessant wäre der Zeitaufwand, wenn sich keine Datei geändert hat (im einfachsten Fall: Du führst das Kommando 2x hintereinander aus). Hast du dafür Zahlen? Ich kann mir nicht so recht vorstellen, dass es dann zeitaufwendig ist.

[Lord_Carlos]

Ich habe mal was gelesen das wenn zu viele hard links auf die selbe Datei zeigen das dann irgendwann schluss ist. Und es ggf sogar ein stiller Fehler ist der nicht sofort auffaellt.
Leider habe ich das nur einmal gelesen und selbst mehrmaliges suchen hat nichts ergeben. Scheint also kein weit verbreitetes Problem zu sein? Weis einer mehr?

Interessant wäre der Zeitaufwand, wenn sich keine Datei geändert hat (im einfachsten Fall: Du führst das Kommando 2x hintereinander aus). Hast du dafür Zahlen? Ich kann mir nicht so recht vorstellen, dass es dann zeitaufwendig ist.

Wenn es fix sein soll, kann ich dir nur empfehlen ein Datensystem zu benutzten was Snapshots kan. Diese Snapshots koennen auf andere Datentraeger gesichert werden. Das syncronizieren, also backup zum zweiten mal Ausfuehren dauert dann keine 10 Sekunde mehr. Auch remote.
Scroll hier mal runter zu Replication und guck dir die Graphen an: https://arstechnica.com/information-tec ... ormance/3/
rsync --inplace = 10 minuten
ZFS send|receive = 4 sekunden bei einer 40GB datei.

Muss jetzt nicht ZFS sein, gibt ja auch andere.
Snapshots macht das leben so einfach. z.B. ohne grossen Aufwand kannst du einstellen das deine Platte jede stunde ein snapshot erstellte wird, und die letzten 24 behaelt. Dazu auch noch Woechentliche, 10 davon. Und die werden immer auf ein remote host uebertragen. Alles in einer konfig, leserlich.

[heisenberg]

Das ist die eine Hardlinkproblematik, die ich kenne:

viewtopic.php?f=32&t=176750

Ansonsten würde ich schätzen, dass Probleme mit Hardlinks bei Zahlen von <1M Dateien da noch weit entfernt sind.

[MSfree]

Interessant wäre der Zeitaufwand, wenn sich keine Datei geändert hat (im einfachsten Fall: Du führst das Kommando 2x hintereinander aus). Hast du dafür Zahlen? Ich kann mir nicht so recht vorstellen, dass es dann zeitaufwendig ist.

Bei mir werden um die 10-13GB pro Backup übertragen. Das geht über GBit-Lan in 2 Minuten. Das Übertragen der Dateilisten und das dabei auf jeder Seite nötige Auflisten aller Dateien dauert sicher auch ein wenig. Im Prinzip passiert dabei das gleiche wie bei einem find, was bis zu 2 Minuten bei der Dateimenge dauern kann (wenn die Verzeichnisstruktur noch im Cache ist, dauert es 1-2 Sekunden). Das Anlegen der Links dauert also bei mir fast 90 Minunten. Das ist mit der Zeit auch immer langsamer geworden, anfangs ging das noch in 60 Minuten.

Das Quelldateisystem ist ein ext4, des Zieldateisystem ist btrfs, die Backupkiste ist eine Synology DS218.

Ich kann damit aber leben. Das Backup findet statt, wenn ich nicht aktiv an den Systemen arbeite. Zeit spielt bei mir also keine Rolle.

[MSfree]

ZFS send|receive = 4 sekunden bei einer 40GB datei.

Naja, das ist aber nur die halbe Wahrheit. Natürlich dauert die Übertagung von 40GB auch bei ZFS deutlich länger als 4s, es sei denn, du hast 100GBit Ethernet und Storagesysteme, die diese Geschwindigkeit liefern.

Die 4s beziehen sich halt nur auf die wirklich veränderten Daten. Wenn du in einer 40GB Datenbank nur 5 Datensätze zu 4kB änderst, sind auch nur 20kB verändert worden und die Übertragung geht mit ZFS entsprechend schnell.

Bei rsync müßte man die kompletten 40GB übertragen, weil rsync keine Deltas in Dateien suchen und übertragen kann. Bei ZFS fallen diese Deltas als "Abfallprodukt" direkt aus dem Dateisystem heraus. Dafür ist ZFS aber lizenztechnisch problematisch und im Moment auch nicht im Kernel enthalten. Wenn ich nicht unbedingt die Vorteile brauche, die ZFS bietet, würde ich die Finger davon lassen.

[Tintom]

@MSfree: Danke für die Erläuterung!

@Lord_Carlos: Bei neuen Systemen achte ich auf ein snapshotfähiges Dateisystem (meist btrfs), alles andere ist heutzutage schon fast fahrlässig

Wenn uns @joe2017 noch sein(e) Dateisystem(e) verrät, von/auf denen synchronisiert werden soll, wäre die hier diskutierte Variante mit rsync vielleicht obsolet.

[Lord_Carlos]

Naja, das ist aber nur die halbe Wahrheit.
Die 4s beziehen sich halt nur auf die wirklich veränderten Daten.

Ich schrieb doch, keine neuen Daten. Das war ja auch das was gefragt wurde:

Interessant wäre der Zeitaufwand, wenn sich keine Datei geändert hat

Und im Artikel:

ZFS asynchronous incremental replication is an enormous improvement over earlier, non-snapshot-based techniques like rsync. In both cases, only the changed data needs to get sent over the wire—but rsync must first read all the data from disk, on both sides, in order to checksum and compare it. By contrast, ZFS replication doesn't need to read anything but the pointer trees—and any blocks that pointer tree contains which weren't already present in the common snapshot.

Dafür ist ZFS aber lizenztechnisch problematisch und im Moment auch nicht im Kernel enthalten. Wenn ich nicht unbedingt die Vorteile brauche, die ZFS bietet, würde ich die Finger davon lassen.

Deswegen habe ich ja extra geschrieben:

Muss jetzt nicht ZFS sein, gibt ja auch andere.

(Andere Datensysteme die Snapshots koennen)

[heisenberg]

Bei rsync müßte man die kompletten 40GB übertragen, weil rsync keine Deltas in Dateien suchen und übertragen kann.

Das verwirrt mich jetzt aber. Kann das sein, dass Du gerade etwas anderes gemeint hast? (man rsync -> "It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination."). Das es aber wesentlich aufwändiger ist, klar(wie Carlos schrieb).

[Tintom]

Bei rsync müßte man die kompletten 40GB übertragen, weil rsync keine Deltas in Dateien suchen und übertragen kann.

Das verwirrt mich jetzt aber. Kann das sein, dass Du gerade etwas anderes gemeint hast? (man rsync -> "It is famous for its delta-transfer algorithm, which reduces the amount of data sent over the network by sending only the differences between the source files and the existing files in the destination."). Das es aber wesentlich aufwändiger ist, klar(wie Carlos schrieb).

Er meint die Deltas innerhalb der Datei, sprich die Veränderten Blöcke auf Dateisystemebene. So tief kann rsync nicht schauen, es vergleicht nur, ob sich die Datei geändert hat und überträgt im Zweifel die kompletten 40GB einer anstatt der nur geänderten 10kB.

[MSfree]

Das verwirrt mich jetzt aber. Kann das sein, dass Du gerade etwas anderes gemeint hast?

Rsync übertägt eigentlich immer vollständige Dateien.

Hast du 1000 Dateien, von denen sich eine Datei geändert hat, wird die gänderte Datei übertragen.

Hast du nur eine sehr große Dateie, in der sich nur ein paar kByte geändert haben, was typisch für Datenbaken ist, wird rsync trotzdem die komplette Datei übertragen. Das Suchen nach Deltas innerhalb von Dateien ist viel zu aufwendig. Man muß ja trotzdem die komplette Datei auf Quell- und Zielsystem durchlesen und nach Veränderungen durchsuchen. Da kann man auch gleich die komplette Datei übertragen.

Snapshotfähige Dateisystem merken sich die veränderten Datenblöcke, und da eine Datei aus vielen Datenblöcken bestehen kann, kann man damit auch Änderungen innerhalb von Dateien verfolgen.

[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?