Offsite-Backup vom Synology-NAS mit Duplicity, Duply, Banana Pi und OneDrive

Vor einiger Zeit habe ich mir ein paar Gedanken gemacht, wie ich am besten ein Offsite-Backup von meinem NAS machen kann. Irgendwie wusste ich dann auch nicht so recht weiter, da es an allen Möglichkeiten einen Haken gab.

Microsoft bietet aktuell ein Angebot an, bei dem man, wenn man die Voraussetzung erfüllt, 1TB bei OneDrive für ein Jahr kostenlos erhält. Mir ging es primär um den Speicher, aber es gibt auch Office dazu.

Das ist die perfekte Gelegenheit gewesen, dass ich mich mal wieder mit dem Thema Offsite-Backup beschäftige.

Mit dem Paket Cloud Sync von Synology in DSM6 lassen sich Daten mit der Cloud synchronisieren und vorher auch verschlüsseln. Jedoch bleibt die Ordnerstruktur in der Cloud erhalten. Dies möchte ich gerne vermeiden. Es soll ein verschlüsseltes Offsite-Backup sein, bei dem wirklich alles verschlüsselt ist. Auch die Ordnerstruktur.

Für diese Lösung des Offsite-Backups sind Linux-Kenntnisse nötigt und es muss Software manuell nachinstalliert werden. Aber wenn man Spaß am Basteln hat, so wie ich, dann lassen sich die Hinternisse überwinden.

Der aktuelle Aufbau, um die Daten des NAS zu sichern, ist etwas speziell. Der Banana Pi mit Bananian liest die Daten über NFS ein, verschlüsselt sie und lädt sie zu OneDrive hoch. Dank VDSL100-Anbindung ist das Hochladen auch kein Problem.

Als Backup-Software kommt Duplicity mit Duply zum Einsatz. Duplicitiy ist die eigentliche Backup-Software und Duply macht die Bedienung von Duplicity einfacher und vereinigt alle Einstellungen in einer Konfigurationsdatei.

Wichtig ist, dass man die aktuelle Version von Duplicity und Duply einsetzt. Die Versionen, die man über apt-get unter Debian erhält, sind zu alt und enthalten vermutlich noch nicht die Unterstützung für OneDrive. Deshalb habe ich beides manuell installiert.

Duplicity kann man sich in der letzen Version herunterladen und auf dem Pi installieren. Eine Installationsanleitung ist in der README zu finden. Duply ist nur ein Skript, dass man in /usr/local/bin/ ablegt.

Neben der Installation von der aktuellen Version von Duplicity müssen zusätzliche Python-Module installiert werden. Für das OneDrive-Backend: python-requests und python-requests-oauthlib.[1]

Die genau Bedienung der Programme werde ich jetzt nicht erklären, dazu findet man einiges an Informationen, wenn man die Suchmaschine seines Vertrauens verwendet.

Für die erste Übersicht bekommt man mit duply usage alle Befehle, die Duply anbietet.

Duply speichert alle wichtigen Informationen unter ${HOME}/.duply/. In diesem Ordner befindet sich wieder ein Ordner mit dem Profil. Die wesentlichen Anpassungen der conf von Dupy sehen in meinem Fall wie folgt aus:

GPG_KEY='<ID der öffentlichen Schlüssels>'
GPG_PW='<Passphrase des privaten Schlüssels>'

TARGET='onedrive://backup'

SOURCE='/mnt/homes'

MAX_AGE=6M

MAX_FULL_BACKUPS=1

MAX_FULLBKP_AGE=2M
DUPL_PARAMS="$DUPL_PARAMS --full-if-older-than $MAX_FULLBKP_AGE "

VOLSIZE=250
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
VERBOSITY=5

DUPL_PARAMS="$DUPL_PARAMS --asynchronous-upload "

Für die Verschlüsselung kommt GPG zum Einsatz. Vor dem ersten Backup muss mit gpg --gen-key ein Schlüsselpaar erstellt werden.

Bei den Zeiten, wie lange ein Backup gespeichert wird, bin ich mir noch nicht so sicher, ob es so bleibt. Aber dazu mache ich mir dann noch mal Gedanken, wenn das Backup im Alltag aktiv läuft.

Die letzte Option ist noch experimentell, aber funktioniert bei mir schon sehr gut. Damit wird gleichzeitig verschlüsselt und hochgeladen. In den Standardeinstellung wird alles der Reihen nach gemacht. Damit kann das Backup um einiges beschleunigt werden.

Für das erste Backup gebe ich mir mit VERBOSITY=5 sehr viel mehr Information auf der Konsole aus. Im Alltag kann man den Wert auf 4 stellen, dann bekommt man nur noch Fehler angezeigt.

Oben habe ich schon angesprochen, dass die Daten via NFS eingelesen werden. Mit Duply lassen sich Pre- und Post-Skripte nutzen. Heißt bevor das Backup startet, soll das NAS via NFS gemountet werden und wenn das Backup abgeschlossen ist, dann soll das NAS wieder ausgehängt werden.

Pre-Skript:

sudo mount 192.168.42.120:/volume1/homes /mnt/homes

Mein NAS ist unter der Adresse 192.168.42.120 im Netzwerk erreichbar und es sollen alle Benutzer-Ordner gesichert werden. Der Banana Pi kann dann unter /mnt/homes auf das NAS zugreifen. Für den Zugriff über NFS ist das Paket nfs-common nötig. Auf dem Synology NAS muss der gemeinsame Ordner homes für den Zugriff freigegeben werden. Dabei muss die IP-Adresse des Pis eingegeben werden. Da der Pi nur Daten lesen muss, hat er auch nur Lesezugriff auf das NAS.

Post-Skript:

sudo umount /mnt/homes

Nach dem Backup wird der Ordner von dem NAS wieder ausgehängt.

Damit das erste Backup immer im Hintergrund läuft, habe ich es in einer tmux Session gestartet und lass mir dann noch gleich ein paar Systeminformationen anzeigen[2].

Es dauert sehr lange

750 GB zu verschlüsseln und hochzuladen dauert wirklich sehr lange. Als das Backup dann so lief, habe ich mit gut einer Woche gerechnet bis es fertig ist. Hat leider nicht ganz so geklappt, denn ab und zu hat sich das Backup aufgehangen und hat abgebrochen. Alles nur halb so schlimm. Duplicity ist so schlau und kann das Full-Backup wieder aufnehmen. Es scannt dann noch mal die Quelle und macht dann dort weiter wo er aufgehört hat. Kann man nur hoffen, dass es bei der Wiederherstellung der Daten keine Probleme gibt.

Irgendwann kam dann der Punkt, dass diese Meldung häufiger aufgetreten ist.

Attempt 1 failed. ConnectionError: ('Connection aborted.', error(104, 'Connection reset by peer'))

Oft hat es sich wieder gefangen, aber oft wurde dann auch nach 5 Versuchen komplett abgebrochen. An einigen Stellen muss man sich auch noch mal neu bei OneDrive authentifizieren. Man bekommt eine URL, die man im Browser einfügt und man wird dann auf eine leere Seite umgeleitet. Die URL fügt man dann wieder in die Shell ein.

Aber es ging dann gar nicht mehr weiter. Nach ein bisschen probieren habe ich die Vermutung gehabt, dass zu viele Dateien in dem Ordner bei OneDrive lagen. Das Backup wird nicht in eine große verschlüsselte Datei geschrieben, sondern in viele kleine Dateien aufgeteilt. Die Größe der einzelnen Dateien kann eingestellt werden. Im ersten Versuch waren die Dateien nur 50 MB groß. Der Ordner in OneDrive beinhaltete 6335 einzelne Dateien mit einer Größe von 309.68 GB. Mehr Dateien konnte Duplicity nicht mehr in den Ordner schreiben.

Nachdem ich die Größe der Dateien auf 250 MB gesetzt und den alten Ordner in OneDrive gelöscht habe, damit ein neuer angelegt wird, ging alles wieder. Alles ein bisschen merkwürdig. Ich habe auch den zeitlichen Überblick verloren wie lange das erste Backup dann effektiv gedauert hat.

Praxis

Der Plan ist, dass einmal am Tag das Backup läuft, jedoch gibt es da noch einen Haken. Für den Cronjob soll Duply wie folgt laufen:

/usr/bin/duply /home/lukas/.duply/homes backup_verify_purge --force

Es wird ein Backup erstellt, das Backup wird geprüft und alte Backups werden gelöscht. Jedoch dauert diese Aufgabe aktuell länger als ein Tag. Damit funktioniert es nicht, dass einmal am Tag ein Backup erstellt wird. Für den Cronjob empfiehlt es sich mit dem absoluten Pfad zu arbeiten.

Diese Aufgabe reicht auch schon, da in der Konfig-Datei steht, dass nach 2 Monaten ein neues Full-Backup erstellt werden soll.

Für das inkrementelle Backup hatte ich die Hoffnung, dass dies in ein paar Stunden durchläuft. Alle zwei Monate würde dann auch noch ein Full-Backup anstehen. Leider sind meine Tests noch nicht so weit fortgeschritten, dass ich berichten könnte wie sich das Erstellen des neuen Full-Backups verhält. Wenn wieder alles neu hochgeladen würde, fehlen Backups aus dieser Zeit.

Fazit

Auf der einen Seite läuft es aber auf der anderen Seite sehe ich da noch einige Schwierigkeiten im Alltag. Besonders das regelmäßige Erstellen der Backups sprengt den zeitlichen Rahmen. Wobei ich auch langsam die Vermutung habe, dass das NFS mit der Zeit immer langsamer wird. Zum Start wurde mit um die 20 MB/s Daten übertragen. Aktuell sind es nur noch 1,5 MB/s.

Am Ende muss ich das Thema Offsite-Backup wieder einmal verschieben, da es für den Alltag nicht praktikabel ist und es zu lange dauert.

Wenn es dann laufen würde, wäre auch noch der Restore der Daten zu prüfen. Denn was bringt das beste Backup, wenn es dann zu Problemen bei der Wiederherstellung der Daten kommt.

Vielleicht kann ich mich damit abfinden, dass die Ordnerstruktur in der Cloud sichtbar ist und ich dann auf den Cloud Sync von Synology setze.

Wenn du Tipps oder Verbesserungen zu dem Thema Offsite-Backup hast, immer her damit. Das Thema finde ich weiterhin sehr spannend.