Bereits vor einigen Wochen begann ich mit der Umsetzung des von mir favorisierten Backupkonzeptes. Neben der täglichen Sicherung meiner ownCloud-Instanz auf eine im lokalen Netz vorhandene Synology Diskstation, schwebte mir ein Backup auf einen Rechner außerhalb meines lokalen Netzwerkes vor. Die Tests mit dem Backup von der Synology auf einen „rsync-kompatiblen Server“ waren allerdings in Bezug auf Geschwindigkeit und Datendurchsatz niederschmetternd. Allein die Erstsicherung der ca. 2,4 GB großen Backupdatei von ownCloud dauerte über das VPN mehrere Stunden. Nach einigem Suchen fand ich eine mögliche Erklärung für diese schlechte Performance: standardmäßig verwendet rsync ssh zur Verschlüsselung seiner Kommunikation. Die ssh-Verschlüsselung wird an der Datenquelle realisiert, also der Diskstation von Synology. Nun glänzt die in meinem Netz vorhandene DS 211+ nicht gerade mit überragender Hardware, ein Umstand den sie mit den kleinen Home-NAS von Synology und auch anderen Herstellern durchaus gemeinsam hat …
Da in meiner Umgebung die Verbindung zum Remoteserver per VPN (LAN-LAN-Kopplung zweier Fritz!Boxen) hergestellt wird, ist eine zusätzliche SSH-Verschlüsselung nicht unbedingt erforderlich um die Sicherheit der Übertragung zu gewährleisten. Um die Performance zu steigern sollte die Übertragung der Dateien also unverschlüsselt erfolgen. Meines Wissens nach ist es über die Webschnittstelle der Diskstation aber nicht möglich, die Verschlüsselung zu umgehen. War also wieder Konsolenarbeit angesagt …
Nach einiger Recherche und Tests nach dem Prinzip „try and error“ fand ich schließlich die meiner Zielstellung entsprechende Lösung. Inzwischen wurde dieser Ansatz in 2 Umgebungen zur Zufriedenheit getestet, so dass ich sie für praktikabel halte. Wie immer ist eine Garantie für die Funktionalität natürlich ausgeschlossen 😉 …
1. Debianserver als rsync-Server (daemon) einrichten
Im wesentlichen konnte ich hier auf die Erkenntnisse aus meinem Artikel Backup von Synology DS auf Debian Teil I zurückgreifen. Der Ansatz auf dem Zielrechner unserer Datensicherung rsync als Daemon einzurichten, war erst einmal richtig. Allerdings hat sich der Inhalt der /etc/rsyncd.conf doch ein wenig verändert:
Entscheidend als Änderung gegenüber des o.a. Artikels ist die Definition des Ports, die Beschränkung der erlaubten IP-Adressen und das Wegfallen der Option „auth users„. Die anderen Schritte (Erstellen der der rsyncd.scrt usw.) einschließlich der Rechtevergabe auf das Verzeichnis rsyncbackup sollten genau so wie im o.a. Artikel durchgeführt werden.
Durch /etc/init.d/rsyncd restart wird der Daemon von rsync neu gestartet (um die geänderten Konfigurationen zu übernehmen).
2. Datensicherung auf der Quelle starten
Das war im Prinzip bereits der schwierige Teil 🙂 . In dieser frühen Phase meiner Tests behelfen wir uns erst einmal mit der manuellen Eingabe des entsprechenden rsync-Befehls zur Datensicherung. Auf der Konsole der Datenquelle als root anmelden und mit
rsync -aP /Pfad/des/zu/sichernden/Verzeichnisses rsync://rsync@IP_des_Backupservers/backup
die Datensicherung starten. Diese Erstsynchronisation wird in Abhängigkeit von der Bandbreite und der zu sichernden Datenmenge entsprechend viel Zeit benötigen, jede nachfolgende Sicherung schreibt dagegen lediglich die Änderungen auf den Backupserver, was eine deutliche Beschleunigung mit sich bringt.
rsync ist ein mächtiges Werkzeug zur Dateisynchronisation, dass zudem über Optionen sehr gut gesteuert werden kann. Die von mir verwendeten Optionen (-aP) bedeuten einfach nur, das die Archivbits mit auf die Sicherung geschrieben (a) werden bzw. das rsync auch nach einer Unterbrechung der Verbindung (P) fortgesetzt wird.
Im nächsten Schritt steht die Automatisierung des Vorgangs über ein zeitgesteuertes Skript im Fokus. In meiner Umgebung wird eine wöchentliche Auslagerung des Backups ausreichend sein …
Hallo Karsten,
Danke an dieser Stelle nochmal. Hat mich echt gefreut. Ich denke die zweite Umgebung ist auf mich gemünzt… 🙂
Hab einen Updateauftrag in der Syno definiert. Nochmal das Shared-Verzeichnis.
Diesmal scheint es ohne „Permissions Denied“ durchzulaufen. Mit dieser Konfiguration ist es möglich auch direkt auf der Syno Aufträge zu definieren und zu einem Zeitplan ausführen zu lassen.
Viele Grüße Markus