Raspberry-Pi-Backups auf ein UniFi-NAS automatisieren

Inhalt
Der Betrieb von Diensten, Hausautomation oder Webanwendungen auf einem Raspberry Pi stößt oft auf ein Problem: die microSD-Karte. Diese ist anfällig für Datenkorruption durch intensive Lese- und Schreibzyklen. Um eine resiliente Architektur zu schaffen, sollten Daten nicht ausschließlich auf dem Pi verbleiben, sondern auf eine redundante Speicherlösung ausgelagert werden. Diese Anleitung führt durch die Einrichtung einer vollautomatisierten täglichen Sicherung eines Raspberry Pi direkt auf ein Ubiquiti UNAS Pro, einschließlich Datenbank-Dumps und Dateikomprimierung.
Schritt 1: Vorbereitung des UNAS Pro
- Im UniFi OS-Konsole die Storage/NAS-Anwendung öffnen.
- Einen neuen freigegebenen Ordner (z. B.
Pi_Backups) erstellen. - Einen dedizierten lokalen Benutzer (z. B.
backup_user) mit einem sicheren Passwort anlegen. - Dem Benutzer Lese-/Schreibberechtigungen für den Ordner
Pi_Backupszuweisen. - Sicherstellen, dass SMB für diesen Share aktiviert ist.
Schritt 2: Einbinden des UNAS Pro auf dem Raspberry Pi
Die Einbindung erfolgt via cifs-utils, damit der NAS-Share als lokales Laufwerk erscheint.
- SSH-Zugriff auf den Raspberry Pi herstellen.
- Nötige Utilities installieren:
sudo apt updateundsudo apt install cifs-utils. - Lokalen Mount-Punkt erstellen:
sudo mkdir -p /mnt/unas_backup. - Eine versteckte Anmeldedatei unter
/etc/.unas_credsmit Benutzername, Passwort und Domain erstellen. Datei schützen:sudo chmod 600 /etc/.unas_creds. - Die
/etc/fstabeditieren und folgende Zeile ergänzen://192.168.1.XXX/Pi_Backups /mnt/unas_backup cifs credentials=/etc/.unas_creds,uid=1000,gid=1000,iocharset=utf8 0 0. - Mounten testen:
sudo mount -a.
Schritt 3: Sicherung der MySQL-Anmeldedaten
Um automatisierte Dumps ohne Passwortabfrage zu ermöglichen:
- Eine MySQL-Konfigurationsdatei erstellen:
nano ~/.my.cnf. - Datenbankdaten einfügen (
[client],user=...,password=...). - Datei schützen:
chmod 600 ~/.my.cnf.
Schritt 4: Backup-Skript erstellen
Ein Bash-Skript übernimmt den Export der Datenbanken, die Komprimierung von Ordnern und das Aufräumen alter Backups.
- Datei
~/pi_backup.sherstellen und den entsprechenden Code einfügen. - Ausführbarkeit gewähren:
chmod +x ~/pi_backup.sh.
#!/bin/bash
BACKUP_DATE=$(date +"%Y-%m-%d")
NAS_MOUNT="/mnt/unas_backup"
DEST_DIR="$NAS_MOUNT/$BACKUP_DATE"
TARGET_FOLDERS="/var/www/html /etc/nginx /home/pi/docker-data"
if ! mountpoint -q $NAS_MOUNT; then exit 1; fi
mkdir -p "$DEST_DIR"
mysqldump --all-databases | gzip > "$DEST_DIR/db_backup_$BACKUP_DATE.sql.gz"
tar -czf "$DEST_DIR/files_backup_$BACKUP_DATE.tar.gz" $TARGET_FOLDERS
find "$NAS_MOUNT" -mindepth 1 -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;Schritt 5: Automatisierung mit Cron
Zeitplan für die tägliche Ausführung um 2:00 Uhr morgens festlegen.
- Crontab öffnen:
crontab -e. - Zeile einfügen:
0 2 * * * $HOME/pi_backup.sh > $HOME/backup_log.txt 2>&1.
Das Ergebnis ist ein automatisierter Disaster-Recovery-Plan, der nächtlich Datenbanken exportiert, Konfigurationsdateien komprimiert und auf das UNAS Pro überträgt, wobei Archive älter als zwei Wochen automatisch gelöscht werden.
Fragen und Antworten
Was passiert beim Systemstart, wenn das NAS noch nicht erreichbar ist, etwa weil der Pi nach einem Stromausfall schneller hochfährt?
Ohne weitere Angaben bleibt der Start an der Einbindung hängen, bis eine Zeitüberschreitung greift, je nach Konfiguration eine lange Wartezeit, in der auch davon abhängige Dienste warten.
Zwei Optionen in der fstab lösen das: _netdev stellt die Einbindung hinter die Netzwerkbereitschaft, und nofail verhindert, dass ein Fehlschlag den Start blockiert. Der Pi kommt damit hoch, auch wenn das NAS noch aus ist.
Der zweite Teil steht schon im Skript und wird durch genau diesen Fall wertvoll: die Prüfung mit mountpoint -q vor dem Sichern. Ohne sie schreibt ein Lauf bei nicht eingebundenem Ziel in das leere lokale Verzeichnis, also auf die Karte, die das Backup schützen soll, im ungünstigen Fall, bis sie voll ist. Mit ihr bricht der Lauf ab, bevor etwas geschrieben wird. Von selbst holt das System eine beim Start gescheiterte Einbindung allerdings nicht nach: Bis die Freigabe eingebunden ist, etwa per sudo mount -a oder durch einen Neustart, enden auch die folgenden Läufe an dieser Prüfung.