Sicherung auf Debian Server mit rsync

[Noir]

Hallo,

ich habe eine Frage zu der Sicherung mit rsync.

Aktuell habe ich folgende Situation:

Daten sind auf dem PC gespeichert und werden regelmäßig mit einem WinSCP Script auf einen Debian Server gespeichert.

Was ich erreichen will:

Daten sind auf einem NAS4Free System gespeichert und werden von dort direkt über ssh / rsync auf einen Debian Server gespeichert.
ssh Verbindung zu dem Debian Server ist schon vorhanden (wird von WinSCP bereits genutzt).

Wichtig ist mir das wirklich die Daten kopiert werden. Ziel ist es das die Daten 2-mal vorhanden sind.

[Princo]

Ich würde die Aufgabenstellung zwar komplett anders lösen (vielmehr: ich habe sie anders gelöst), aber um näher an deiner Fragestellung zu bleiben:
Du kannst das ohne ssh lösen.
Dazu läßt du z.B. auf dem Debian-System einen rsync-Server laufen (aka rsync im Daemon-Modus).
Dann kannst du in der rsync-Sektion des N4F-Webgui ganz bequem die nötigen Einstellungen des Transfers konfigurieren.

Es sei denn, der Abgleich soll über ein unsicheres Netz stattfinden, dann bliebe nur ssh oder ein VPN.

Natürlich sind auch andere Lösungen möglich.

Grüße
Princo

[Noir]

Der Abgleich soll über ein unsicheres Netz erfolgen, daher auch die Verbindung über ssh.

Jetzt würde mich aber mal interessieren wie du diese Aufgabenstellung gelöst hast? Ich muss nicht zwingend rsync nutzen, es ist jedoch das erste was mir dazu eingefallen ist. Wichtig ist mit letztendlich nur das meine Daten auf 2 verschiedenen Rechnern liegen.

Grüße
Noir

[Princo]

Puuh, mal sehen, ob ich das schaffe:

Also, meine PCs werden täglich auf einem Backup-Server gesichert. Dazu verwende ich eine Kombination aus Image-Backup (per ntfsclone oder partclone) und File-by-File-Backup (per rsync). Der Backup-Server ist so konfiguriert, daß er die Stände der letzten sieben Tage aufbewahrt.

Meine wichtigen Daten (z.B. Bilderarchiv mit selbstgeschossenen Fotos) liegen auf einem reinen Daten-Server, und sind damit zentral verfügbar.

Mein Daten-Server wird alle paar Tage auf ein externes Array abgeglichen, dies kann aber auch ein eigenständiger Server sein.

Meinen Backup-Server für die PCs sichere ich nicht extra. Grund dafür ist, daß sein Inhalt ja bereits das Duplikat meiner PCs darstellt, und damit die Forderung nach einer doppelten Speicherung bereits erfüllt ist. Selbstverständlich ließe sich der Backup-Server auch auf ein anderes System abgleichen..

Wenn ich davon rede, daß ich Server miteinander abgleiche, dann meine ich damit, daß ich auf beiden Systemen ZFS einsetze, und dabei auch die speziellen Möglichkeiten von ZFS zur Datenreplikation nutze. Diese Vorgehensweise ist in einigen Punkten besser als der Einsatz von rsync.

rsync wird oft falsch eingesetzt, und dann werden nicht immer alle veränderten Daten auch tatsächlich übertragen. Liegt daran, daß der Parameter -c meistens nicht verwendet wird..

Bei rsync müssen Sender und Empfänger immer gleichzeitig miteinander verbunden sein, damit ein Abgleich stattfinden kann.

Bei ZFS bestehen diese Einschränkungen nicht, da das Filesystem selbst genau "weiß" welche Daten verändert wurden (rsync kann das nur durch Vergleich feststellen) und bei ZFS brauchen Sender und Empfänger nicht zwingend miteinander verbunden sein. In diesem Fall kann ein Datenabgleich ganz simpel mit einem Transportdatenträger durchgeführt werden. Das ist z.B. hilfreich, wenn die zu übertragende Datenmenge so groß ist, daß die Internetanbindung dafür zu lahm ist. Daß bei den ZFS Replikationsmechanismen auch nur die tatsächlich veränderten Daten behandelt werden, und daß man da die Übertragung auch verschlüsseln kann, dürfte klar sein.

Btw. auch bei ZFS/ZFS Abgleichen könnte man rsync einsetzen, aber das ist eine andere Baustelle.

Das ist eine Umsetzung, wie sie meinen Bedürfnissen entspricht. Das wird man evtl. nicht 1:1 bei dir umsetzen können, aber es soll zeigen, welche grundsätzlichen Möglichkeiten bestehen, wenn man mal etwas über den Tellerrand schaut.

Damit man demit etwas Praktikables umsetzen kann, bedarf es allerdings einer tieferen Bestandsaufnahme, bei der man genauer auf die Gesamtdatenmenge, die sich durchschnittlich ändernden Daten, sowie die Durchsatzrate der Verbindung zwischen den Servern schaut.

Je nachdem, was dabei rauskommt, kann man dann ein tragfähiges Konzept für den Abgleich erstellen, welches mit den vorhandenen Ressourcen maximale Effizienz erzielen kann.

Grüße
Princo

[crowi]

Hi Princo,
sorry für doe möglicherweise dumme Frage, aber

Liegt daran, daß der Parameter -c meistens nicht verwendet wird..

welche Vorteile bringt die -c Flag gegenüber Timestamp/Größe?
Verlangsamt das bilden der Checksummen nicht den ganzen Kopierprozess?

Gruß,
Crowi

[Noir]

Erst mal danke für deine ausführliche Beschreibung.

Hier mal meine aktuelle Situation:

Meine Backups und wichtige Daten waren auf einem Ubuntu Server mit RAID 5 gespeichert.
Meine Fotos und unwichtige Daten sind auf einer Netzwerkfestplatte gespeichert.
Die Fotos (aktuell rund 350 GB) werden regelmäßig auf einen root-Server im Internet gesichert. Upload Geschwindigkeit: 10,0 Mbit/s. Die Sicherung erfolgt aktuell noch unter Windows mit WinSCP ein Skript sorgt dafür das auf dem Server der gleiche Datenstand herrscht wie auf dem Netzwerkspeicher.

Zur Schätzung der Datenmenge habe ich jetzt einfach mal geschaut wie viel in diesem Jahr bis jetzt dazugekommen ist, das sind etwa 15 GB pro Monat. Kann aber immer schwanken.

Den Ubuntu Server habe ich jetzt aufgelöst und gegen ein NAS4Free System mit ZFS raidz1 getauscht. Die Fotos sollen nun auf das NAS System und von dort aus direkt auf den root-Server gesichert werden und nicht mehr über WinSCP.

Gruß
Noir

[Princo]

welche Vorteile bringt die -c Flag gegenüber Timestamp/Größe?
Verlangsamt das bilden der Checksummen nicht den ganzen Kopierprozess?

Der Vorteil ist, daß du hinterher auf beiden Systemen tatsächlich den gleichen Datenbestand hast.
Und irgendwie ist das ja auch der Sinn eines Backups

Im Ernst: Timestamp/Größe ist kein 100% sicheres Kriterium.
Das erste Mal ist mir das bei einem Truecrypt-Container aufgefallen.
In älteren Truecrypt-Versionen behielt der Container immer das gleiche Dateidatum, und die Größe bleibt bei TC-Containern immer gleich, d.h. der Container wurde nur ein einziges Mal gebackupped, wenn der Parameter -c bei rsync nicht gesetzt war.

In späteren TC-Versionen konnte man es dann konfigurieren, ob ein TC-Container nach dem Aushängen ein neues Dateidatum bekommen sollte.

Die Problematik kann aber z.B. auch bei Fotos auftreten. Hier setzt man gerne das Dateidatum auf das Aufnahmedatum des Bildes. Wenn man dann die EXIF oder IPTC Daten der Bilder verändert (Verschlagwortung), dann hat man hinterher eine Datei gleicher Größe und gleichen Datums, aber unterschiedlichem Inhalt. Auch für diverse Datenbanksysteme könnte diese Szenario zutreffen.

Das kann man zwar alles als Sonderfälle betrachten, aber meiner Erfahrung nach, können einem diese Sonderfälle echte Probleme bereiten, wenn man sie nicht beachtet. Besonders, wenn man Systemkopien anlegen möchte.

Es ist übrigens keine spezifische rsync-Macke, das Problem haben sämtliche Dateikopierprogramme (auch xcopy, robocopy und Konsorten).

Wenn ich große Datenbestände abgleichen möchte, mache ich idR einfach zwei rsync-Durchläufe. Einen ohne den -c Parameter, und einem mit diesem Parameter.

Natürlich dauert das dann insgesamt länger, aber das hängt auch davon ab, ob man die Features von rsync richtig nutzt.
Dabei ist von Belang, auf welches Medium man abgleicht.
Wenn ich z.B. auf eine lokale USB-Platte abgleiche, dann muß beim zweiten Durchlauf der Rechner tatsächlich beide Dateisysteme vollständig lesen und miteinander vergleichen. Dabei würde man aber auch fehlerhaft abgespeicherte Daten entdecken (meine Meinung zu USB-Festplatten dürfte bekannt sein). Dennoch ist die Methode besser, als alles komplett neu rüberzuschieben. Außerdem kann man so immer noch hocheffektive Backups mit Hardlinks durchführen.

Gleicht man aber gegen ein NAS ab, auf dem ein rsync-Server läuft, dann arbeiten beide Systeme Hand-in-Hand, und das geht erheblich schneller (weil beide Systeme den eigenen Bestand checken, und dann nur die Prüfsummen übers Netz gehen).

Mit der Methode (2xDurchlauf) nutze ich den Vorteil einen immens schnellen Abgleichs, der 99,9999% der Dateien betrifft, und habe mit dem 2. Durchlauf (den ich bei Bedarf auch einfach mal abbrechen kann) eine 100% Abdeckung. Damit brauche ich mir dann auch keine Gedanken darüber machen, ob irgendwelche Anwendungen auch immer der Dateidatum updaten.

Das ist natürlich auf ein Worst-Case Szenario ausgerichtet. Wenn man absolut exakt weiß, daß Timestamp/Größe als Kriterium ausreicht, dann geht das auch ohne den -c Parameter. Aber dafür muß man sich tatsächlich damit auseinandersetzen.

Hupps, das ist schon wieder etwas lang geworden, deswegen spare ich das Thema Datenreduzierung lieber mal aus

Grüße
Princo

[crowi]

Hallo Princo,

Wenn ich große Datenbestände abgleichen möchte, mache ich idR einfach zwei rsync-Durchläufe. Einen ohne den -c Parameter, und einem mit diesem Parameter.

thanks für die Erklärung, das ergibt jetzt wieder einen Sinn.
Ich hatte bisher mit Richcopy und Unison meine Daten 'manuell' rumgeschubst und werde mich demnächst mit rsync als Cronjob genauer beschäftigen. Deine Ausführungen helfen mir echt weiter.

Gruß,
Crowi

[Princo]

Hallo crowi,

geht es bei dir noch um das Backup-Thema (viewtopic.php?f=29&t=3824&start=75#p23242)?
Das ist nicht tot. Ganz im Gegenteil.

Grüße
Princo

[crowi]

Hallo Princo,

momentan habe ich eine Backuplösung mit der ich leben kann aber nicht ganz zufrieden bin.
Da ich aber momentan andere Baustellen habe, wurde das Optimieren des Backups immer wieder verschoben.

Das ist nicht tot. Ganz im Gegenteil.

Klingt gut !

Grüße,
Crowi

[shakky4711]

Hallo,

zu rsync möchte ich noch diesen Parameter anraten:

Code: Select all

 -W, --whole-file            copy files whole (w/o delta-xfer algorithm)

Mir ist es schon einige male passiert, dass sich md5 Prüfsummen von Dateien durch den Transfer mittels des delta algorythmus geändert haben.
Seitdem habe ich diesen Switch immer mit bei.


Gruß
Shakky

[Princo]

zu rsync möchte ich noch diesen Parameter anraten:

Code: Select all

 -W, --whole-file            copy files whole (w/o delta-xfer algorithm)

Mir ist es schon einige male passiert, dass sich md5 Prüfsummen von Dateien durch den Transfer mittels des delta algorythmus geändert haben.
Seitdem habe ich diesen Switch immer mit bei.

Bin in einem anderen Zusammenhang wieder auf diesen Thread gestoßen, und möchte noch etwas ergänzen.

Den Parameter -W verwende ich auch, aber interessanterweise aus einem völlig anderen Grund als shaky4711. Das mit den md5-Prüfsummen hatte ich dabei gar nicht auf dem Radar, sondern ich habe getestet, ob man ein Linux-System unter realistischen Bedingungen über eine normale DSL-Leitung backuppen kann (das geht übrigens). Dabei habe ich die rsync-Funktionen zur Kompression und zur partiellen Datenübertragung ausgetestet.
Als ich das Gleiche dann in meinem normalen Netz gemacht habe, konnte ich folgenden Effekt beobachten:
Bei weiteren Abgleichen (also nach dem Erstabgleich) wurden neue Dateien zuerst mit voller Geschwindigkeit übertragen.
Hatte das System dann eine partiell veränderte Datei am Wickel, ging die Geschwindigkeit runter, was durchaus logisch ist.
Kamen dann aber wieder neue Dateien zur Übertragung, blieb die Geschwindigkeit weiterhin niedrig.
Es war ungefähr so, als ob das System einfach "vergessen" hat, wieder auf die volle Geschwindigkeit zu gehen.

Gut, das ist es jetzt schon eine Weile her, und evtl. lag der Fehler bei der damals verwendeten rsync-Version, aber das ist der Grund dafür, daß ich bei rsync-Aktionen im internen Netz den Parameter -W verwende.

Um das Ganze abzurunden, ist hier jetzt exemplarisch der rsync-Optionsblock aufgeführt, den ich verwende, um File-by-File-Sicherungen von Linux- (und NTFS-Dateisystemen) auf mein NAS, oder auf eine externe Festplatte zu machen:

1. Durchlauf (und Erstabgleich):

Code: Select all

rsync -avSHhW --numeric-ids --progress --stats --delete $QUELLE $ZIEL

2. Durchlauf:

Code: Select all

rsync -avSHhWc --numeric-ids --progress --stats --delete $QUELLE $ZIEL

Erklärung zu den einzelnen Parametern: http://linux.die.net/man/1/rsync

Es ist übrigens keine gute Idee, diese Parameter einfach dumpf für alles Mögliche zu übernehmen. Es hat schon Gründe, weshalb ich -S, -H. --numeric-ids und --delete hier verwende.
Speziell der Parameter -S ist ein ziemlicher Performance-Killer, und man sollte seine Dateien sehr gut kennen, um entscheiden zu können, ob dieser Parameter wirklich eingesetzt werden sollte. Dabei geht es um das effektive Handling von sog. Sparse-Files. Weshalb das ein reales Problem darstellt, wird hier erklärt: http://de.wikipedia.org/wiki/Sparse-Dat ... Verwendung
Um es etwas abzukürzen: in den meisten Fällen kann man auf -S verzichten. Aber bei Systemen, auf denen tatsächlich große Sparse-Files vorhanden sind, können bei Nichtverwendung von -S die Backups riesig groß werden. Daher habe ich den Parameter vorsichtshalber mit aufgeführt.

Wer das mal ausprobieren möchte, kann anhand des verlinkten Wikipedia-Artikels einfach mal eine 10TB große Sparse-Datei auf seinem System anlegen (was tatsächlich möglich ist), und die dann auf das NAS kopieren. Viel Spaß dabei! Per rsync mit -S geht das natürlich.

Je nachdem, was man auf seinem System so veranstaltet, können übrigens auch Parameter wie -A oder -X wichtig werden, aber das müsst ihr schon selber herausfinden.

Fazit: rsync ist DAS Tool, um Dateien sicher zu transferieren. Allerdings gibt es Sonderfälle, welche man u.U. berücksichtigen muß.

Grüße
Princo