VPS Backup mit dem Synology DS416play

Datensicherungen sind wichtig! Aus diesem Grund hatte ich mir auch letztes Jahr ein neues NAS gekauft, auf das die Backups unserer Laptops laufen.

Später habe ich mir dann einen VPS (Virtual Private Server) für meine Webseiten und meine private Cloud (NextCloud, Gitea) gegönnt. Leider bisher ohne ein wirkliches Backup-Konzept.

Zugegeben, für meine publikumsträchtigsten Seiten hatte ich das Wordpress-Plugin BackWPup eingerichtet, was mir einmal pro Woche einen Abzug der Dateien und Datenbanken in meine Dropbox legt. Aber damit waren auch nur meine beiden Musikmagazine in einer Sicherung.

Als ich dann mal all meine Dienste auf dem VPS dokumentiert hatte, viel mir relativ schnell auf, dass zu viel ohne Sicherung war. Blog und Webdesign-Portfolio sind vielleicht eher unwichtig. Das sind statische Seiten aus Hugo, die ich jederzeit schnell und unkompliziert wieder einspielen kann. Leider liegen die Quellen, aus denen ich automatisch die Webseite generieren lasse, im Gitea auf dem gleichen VPS.

Synology “Active Backup For Server” - und seine Unzulänglichkeiten

Also musste ein ordentliches Backup-Konzept für den Server her. Synology bietet hierfür theoretisch sogar eine sehr nette App: “Active Backup For Server”. Man gibt Server und Credentials an, schon kann man über eine nette Oberfläche die Pfade festlegen, die per rsync periodisch gesichert werden. Klappt auch wunderbar. Nur habe ich meinen VPS abgesichert und lasse keinen Login per Passwort zu. Nur mit SSH-Key. Das unterstützt das “Active Backup For Server” leider nicht. Ob das noch kommt? Ich hoffe es mal.

Backup mit rsync und mysqldump

Also blieb mir nur die Möglichkeit ein eigenes Script zu schreiben. Auch wenn es in der Realität etwas komplexer ist, ist die Blaupause eigentlich eher simpel:

#!/bin/bash
USER="myuser"
KEY="/home/user/.ssh/mykey"
PORT="22"
SERVER="domain.tld"
SOURCE="/home/service/"
TARGET="/home/user/backup/data"
LOG="/home/user/backup/$current_date.log"

rsync -avz -L --progress -e "ssh -i ${KEY} -p $PORT" $USER@$SERVER:$SOURCE $TARGET >> $LOG 2>&1

Bei mir musste ich für jeden Webservice-User ein eigenes Script anlegen, weil ich sonst wegen Berechtigungen nicht auf die Daten zugreifen kann. Da Gitea den direkten SSH-Zugriff abblockt, habe ich die wichtigen Verzeichnisse für die Repositories per Symlink einem anderen Benutzer zugänglich gemacht. das -L im rsync-Aufruf folgt diesen Links zu den eigentlichen Daten.

Die Datenbanken sichere ich über ein separates Script:

#!/bin/bash
USER="myuser"
KEY="/home/user/.ssh/mykey"
PORT="22"
SERVER="domain.tld"
TARGET="/home/user/backup/database"
DB_USER="user"
DB_PASSWORD="geheim"
DATABASE="datenbank"
ssh -p ${PORT} -i ${KEY} ${USER}@${SERVER} "mysqldump -u ${DB_USER} -p${DB_PASSWORD} ${DATABASE}" > "${TARGET}/${DATABASE}.sql"

Die Aufrufe aller Scripte, also für jede Datenbank und die Daten jedes Services, habe ich in einem Script zusammengefasst. Dann alles per SSH auf das NAS gepumpt und dort abermals getestet, Pfade korrigiert und so weiter. Nachem alles so lief, wie es sollte, sollte das Backup nun automatisiert ausgeführt werden.

Dazu ging ich als Admin in die DSM-Oberfläche des NAS. Unter Systemsteuerung, Aufgabenplaner konnte ich dann eine neue Aufgabe erstellen, Zeitplan und den Pfad zum Script angeben. Nachdem die Aufgabe erstellt war, habe ich sie abermals manuell ausgeführt, um eventuelle Fehler auszuschließen.

Synology NAS und seine Unzulänglichkeiten - Teil 2

Mein rsync-Script verbindet sich nun mit SSH-Key zu meinem Server und sichert die Daten. Das ist schon mal schöner, als mit Username/Password. Leider hat das Synology-NAS keinen SSH-Agent, der für mich die Freischaltung des Schlüssels übernehmen könnte.

Das ist für mich ebenso unverständlich, wie die fehlende Option einen SSH-Key beim “Active Backup For Server” zu hinterlegen.