Raspberry-Pi-Backups auf ein UniFi-NAS automatisieren

Eine tägliche Kopie auf einem UniFi UNAS Pro ergänzt die Anwendungsdaten des Raspberry Pi um einen zweiten Speicherort. Das Beispiel sichert ausgewählte Verzeichnisse und MySQL-Datenbanken über SMB, ein Protokoll für Netzwerkfreigaben. Für einen belastbaren Wiederherstellungsplan fehlen anschließend noch Rücksicherungstests und eine getrennte Offline- oder Außer-Haus-Kopie.

Voraussetzungen und Umfang

Das Beispiel verwendet das Linux-Konto pi, das Heimatverzeichnis /home/pi, Bash und einen passenden MySQL-Dump-Client. Kontoname, numerische Benutzer- und Gruppenkennung, Datenbanken und Quellverzeichnisse müssen zur Installation passen. Das Sicherungskonto benötigt Leserechte auf alle Quellen. Ein laufendes Docker-Datenbankverzeichnis lässt sich durch bloßes Hinzufügen zu tar nicht konsistent sichern.

1. NAS vorbereiten

In UniFi Drive dient eine Freigabe namens Pi_Backups als Ziel. Ein eigenes Sicherungskonto benötigt Schreibrechte auf diese Freigabe sowie Dateidienst-Zugangsdaten für SMB. Das Passwort für die UniFi-Konsole ist nicht zwangsläufig das SMB-Passwort. Der SMB-Dienst muss aktiviert sein; genaue Bezeichnungen hängen von der installierten Drive-Version ab.

2. SMB-Freigabe einbinden

Das Paket cifs-utils stellt das Hilfsprogramm zum Einbinden der SMB-Freigabe bereit. Die folgenden Einrichtungsschritte benötigen Administratorrechte:

sudo apt update
sudo apt install cifs-utils
sudo mkdir -p /mnt/unas_backup

Die mit sudo nano /etc/.unas_creds angelegte Datei enthält zwei Zeilen:

username=backup_user
password=REPLACE_WITH_SMB_PASSWORD

Das Passwort bleibt in dieser Datei im Klartext gespeichert. Dateirechte beschränken den Zugriff; ein Punkt am Dateianfang verschlüsselt nichts. Eigentümer muss root sein:

sudo chown root:root /etc/.unas_creds
sudo chmod 600 /etc/.unas_creds

Der folgende Eintrag gehört in /etc/fstab. Adresse und Freigabename sind Beispiele. UID und GID 1000 müssen zum Sicherungskonto passen; id pi zeigt die tatsächlichen Werte. Zusätzlich gelten weiterhin die Zugriffsrechte auf dem NAS.

//192.168.1.XXX/Pi_Backups /mnt/unas_backup cifs credentials=/etc/.unas_creds,uid=1000,gid=1000,iocharset=utf8,_netdev,nofail 0 0

sudo mount /mnt/unas_backup prüft genau diese Einbindung. Mit nofail kann der Systemstart ohne NAS weiterlaufen. Eine fehlende Einbindung verhindert trotzdem die Sicherung; nach Rückkehr des NAS ist ein erneutes Einbinden erforderlich. SMB bedeutet nicht automatisch verschlüsselte Übertragung. Verschlüsselungsanforderungen benötigen eine eigene Konfiguration und Prüfung.

3. Datenbankzugang einrichten

Die Datei /home/pi/.my.cnf gehört dem ausführenden Konto und enthält die unten angegebenen Datenbank-Zugangsdaten. chmod 600 /home/pi/.my.cnf beschränkt den Zugriff. Das separate Datenbankkonto benötigt die für die gewählten Dump-Optionen dokumentierten Rechte, einschließlich Routinen und Ereignissen.

[client]
user=backup_user
password=REPLACE_WITH_DATABASE_PASSWORD

4. Sicherungsskript speichern

Das folgende Skript gehört nach /home/pi/pi_backup.sh. Vor dem Einsatz sind app1 app2 und TARGET_FOLDERS durch die tatsächlichen Datenbanken und Verzeichnisse zu ersetzen. Für MariaDB sind der installierte Client mariadb-dump und dessen unterstützte Optionen gesondert zu prüfen.

#!/bin/bash
set -euo pipefail
umask 077
PATH=/usr/local/bin:/usr/bin:/bin
NAS_MOUNT="/mnt/unas_backup"
TARGET_FOLDERS=(/var/www/html /etc/nginx)
DATABASES=(app1 app2)
exec 9>/home/pi/.pi-backup.lock
flock -n 9 || { echo "Backup already running" >&2; exit 1; }
mountpoint -q "$NAS_MOUNT" || { echo "NAS is not mounted" >&2; exit 1; }
[[ $(findmnt -n -o FSTYPE --target "$NAS_MOUNT") == cifs ]] || exit 1
BACKUP_ID=$(date +%Y-%m-%d_%H-%M-%S)
WORK_DIR="$NAS_MOUNT/.partial-$BACKUP_ID"
DEST_DIR="$NAS_MOUNT/$BACKUP_ID"
mkdir -- "$WORK_DIR"
trap 'echo "Backup failed; incomplete directory: $WORK_DIR" >&2' ERR
mysqldump --defaults-extra-file=/home/pi/.my.cnf   --single-transaction --routines --events --triggers   --databases "${DATABASES[@]}" | gzip > "$WORK_DIR/databases.sql.gz"
gzip -t "$WORK_DIR/databases.sql.gz"
tar -czf "$WORK_DIR/files.tar.gz" -- "${TARGET_FOLDERS[@]}"
tar -tzf "$WORK_DIR/files.tar.gz" > /dev/null
printf '%s\n' "$BACKUP_ID" > "$WORK_DIR/COMPLETE"
mv -- "$WORK_DIR" "$DEST_DIR"
echo "Backup written: $DEST_DIR"

pipefail macht Dump-Fehler sichtbar, die ein erfolgreiches gzip sonst verdeckt. Bei einem fehlgeschlagenen Dump oder Dateiarchiv bricht dieser geradlinige Ablauf ab. Unvollständige Läufe behalten ein Verzeichnis mit .partial-; der endgültige Ordner entsteht erst nach beiden Archivprüfungen. Diese Prüfungen erkennen beschädigte Archive, belegen aber weder logische Vollständigkeit noch Wiederherstellbarkeit.

--single-transaction liefert für transaktionale Tabellen wie InnoDB einen konsistenten Datenstand. Nichttransaktionale Tabellen und gleichzeitige Schemaänderungen erfordern eine andere Sicherungsstrategie. Die anschließend kopierten Dateien gehören nicht automatisch zum selben Zeitpunkt wie der Datenbankstand. Anwendungen mit zusammengehörigen Uploads und Datenbankeinträgen benötigen ein abgestimmtes Wartungsfenster oder ein geeignetes Snapshot-Verfahren.

5. Zeitplan und Kontrolle

Nach chmod +x /home/pi/pi_backup.sh muss ein manueller Lauf unter demselben Konto erfolgreich sein. Der folgende Eintrag in crontab -e des Kontos pi startet die Sicherung um 02:00 Uhr in der lokalen Zeitzone des Cron-Dienstes:

0 2 * * * /home/pi/pi_backup.sh >> /home/pi/backup_log.txt 2>&1

Das Protokoll wächst durch Anhängen und benötigt deshalb eine Rotation. Eine Überwachung muss fehlgeschlagene Läufe und ausbleibende aktuelle Sicherungen erkennen. Das Skript löscht bewusst keine alten Kopien. Vor dem Löschen braucht es eine Aufbewahrungsregel, die freien Platz, unvollständige Läufe und den letzten geprüften Wiederherstellungspunkt berücksichtigt.