Backups einrichten

Ein Backup, das auf demselben Server liegt, hilft nicht, wenn der Server weg ist oder du aus Versehen etwas gelöscht hast und es erst Tage später merkst. Diese Anleitung sichert deine Daten täglich auf ein anderes Ziel und zeigt, wie du prüfst, dass die Sicherung wirklich zurückspielbar ist.

Gilt für Debian 12 und 13, Ubuntu 22.04 und 24.04, AlmaLinux 9 und Rocky Linux 9. Alle Befehle laufen als root.

Was CitexNode schon sichert

Xeon-vServer sichern wir jede Nacht als Abbild der ganzen Platte und heben 7 Tage auf; zurückholen lässt sich ein Stand im Reiter Backups (siehe Backups). Das ist ein Komfort ohne Garantie und deckt keine einzelnen Dateien und keine Datenbanken im stimmigen Zustand ab.

Die Anleitung unten zeigt, wie du Dateien und Datenbanken zusätzlich regelmäßig auf ein Ziel außerhalb des Servers sicherst.

Was du sichern solltest

Nicht sichern musst du das System selbst (/usr, /var/lib/apt, …): das bekommst du per Neuinstallation zurück.

Datenbanken sicherst du als Dump, nicht als Dateien aus /var/lib/mysql. Kopierte Datenbankdateien eines laufenden Servers sind oft kaputt. Wie der Dump geht, steht in MariaDB einrichten.

Das Ziel

Du brauchst Platz außerhalb dieses vServers, z. B.:

• einen zweiten Server oder eine Storage-Box, die du per SFTP (SSH) erreichst,
• einen S3-kompatiblen Speicher bei einem Anbieter deiner Wahl.

Die Beispiele unten nutzen SFTP mit dem Ziel backup@backup.example.de. Leg auf dem vServer einen SSH-Schlüssel ohne Passphrase an, damit der Timer ohne dich läuft, und hinterleg ihn beim Ziel:

ssh-keygen -t ed25519 -f /root/.ssh/backup -N ''
ssh-copy-id -i /root/.ssh/backup.pub backup@backup.example.de

Und in /root/.ssh/config:

Host backup.example.de
    User backup
    IdentityFile /root/.ssh/backup

Weg A: restic (empfohlen)

restic verschlüsselt, legt nur Änderungen neu ab und hält viele Stände vor, ohne viel Platz zu brauchen.

Installieren

apt install -y restic                     # Debian und Ubuntu
dnf install -y epel-release && dnf install -y restic   # AlmaLinux und Rocky Linux

Repository anlegen

Leg ein Passwort an. Ohne dieses Passwort sind die Sicherungen nicht lesbar. Heb es zusätzlich außerhalb des Servers auf, z. B. im Passwortmanager.

openssl rand -base64 32 > /root/.restic-password
chmod 600 /root/.restic-password

Die Einstellungen in /root/.restic.env:

RESTIC_REPOSITORY=sftp:backup.example.de:/backups/vserver
RESTIC_PASSWORD_FILE=/root/.restic-password

Repository einmal anlegen:

set -a; . /root/.restic.env; set +a
restic init

Das Backup-Skript

/usr/local/bin/backup.sh:

#!/bin/bash
set -euo pipefail
set -a; . /root/.restic.env; set +a

# Datenbanken vorher als Dump ablegen (Zeile löschen, wenn du keine MariaDB hast)
mkdir -p /var/backups/mariadb
mariadb-dump --single-transaction --routines --triggers --all-databases | gzip > /var/backups/mariadb/alle.sql.gz

# Nur Ordner angeben, die es bei dir gibt, sonst endet der Lauf mit Fehler
restic backup /etc /var/www /var/backups /root /opt --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

chmod 700 /usr/local/bin/backup.sh
/usr/local/bin/backup.sh

Der erste Lauf dauert am längsten, die folgenden nur Sekunden bis Minuten.

Weg B: rsync

rsync spiegelt Ordner auf das Ziel. Einfach, aber ohne Verschlüsselung und ohne ältere Stände: Löschst du etwas und läuft danach das Backup, ist es auch auf dem Ziel weg (mit --delete) oder es sammeln sich alte Dateien (ohne).

apt install -y rsync   # Debian und Ubuntu
dnf install -y rsync   # AlmaLinux und Rocky Linux

/usr/local/bin/backup.sh mit rsync:

#!/bin/bash
set -euo pipefail
mkdir -p /var/backups/mariadb
mariadb-dump --single-transaction --routines --triggers --all-databases | gzip > /var/backups/mariadb/alle.sql.gz
# Nur Ordner angeben, die es bei dir gibt, sonst endet der Lauf mit Fehler
rsync -aR --delete /etc /var/www /var/backups /root /opt backup.example.de:/backups/vserver/

Auf dem Ziel muss ebenfalls rsync installiert sein.

Täglich automatisch: systemd-Timer

/etc/systemd/system/backup.service:

[Unit]
Description=Tägliches Backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

/etc/systemd/system/backup.timer:

[Unit]
Description=Tägliches Backup um 3 Uhr

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Einschalten:

systemctl daemon-reload
systemctl enable --now backup.timer
systemctl list-timers backup.timer

Persistent=true holt einen verpassten Lauf nach, wenn der Server um 3 Uhr aus war. Lieber Cron? Siehe Cronjobs und Timer.

Prüfen, ob es geklappt hat

Letzter Lauf ohne Fehler?

systemctl status backup.service
journalctl -u backup.service -n 50 --no-pager

Bei restic die vorhandenen Stände und eine Prüfung des Repositorys:

set -a; . /root/.restic.env; set +a
restic snapshots
restic check

Probe-Wiederherstellung

Ein Backup ist erst etwas wert, wenn du es zurückspielen kannst. Mach das einmal jetzt und danach ab und zu, z. B. jeden Monat.

Mit restic den letzten Stand in einen Testordner holen:

set -a; . /root/.restic.env; set +a
restic restore latest --target /tmp/restore-test --include /etc/hostname --include /var/backups
ls -l /tmp/restore-test/etc/hostname /tmp/restore-test/var/backups/mariadb/

Prüfen, ob der Datenbank-Dump vollständig ist. Die letzte Zeile eines fertigen Dumps beginnt mit -- Dump completed:

gunzip -t /tmp/restore-test/var/backups/mariadb/alle.sql.gz
gunzip -c /tmp/restore-test/var/backups/mariadb/alle.sql.gz | tail -n 1
rm -rf /tmp/restore-test

Ein Dump mit --all-databases legt die Datenbanken beim Einspielen unter ihren alten Namen an und überschreibt sie. Für einen echten Test spiel ihn deshalb auf einem zweiten Server oder einer Testmaschine ein, nicht auf dem laufenden.

Mit rsync holst du Dateien vom Ziel zurück, z. B. rsync -a backup.example.de:/backups/vserver/etc/hostname /tmp/.

Häufige Fehler

• Fatal: unable to open config file bei restic. Das Repository wurde noch nicht mit restic init angelegt, oder der Pfad in RESTIC_REPOSITORY stimmt nicht.
• Fatal: wrong password or no key found. Das Passwort in /root/.restic-password passt nicht zum Repository. Ohne das richtige Passwort kommst du nicht mehr an die Daten.
• Der Timer läuft, aber SSH fragt nach einem Passwort. Der Schlüssel liegt nicht beim Ziel oder /root/.ssh/config fehlt. Teste mit ssh backup.example.de.
• unable to create lock. Ein früherer Lauf ist abgebrochen. Prüf, dass kein restic mehr läuft, dann restic unlock.
• Die Platte des vServers läuft voll. Alte Dumps in /var/backups sammeln sich. Das Skript oben überschreibt den Dump jedes Mal, die älteren Stände liegen in restic.

Wie es weitergeht

• Sieh dir nach ein paar Tagen restic snapshots an. Stimmen Anzahl und Uhrzeiten, läuft alles.
• Fehlschläge siehst du nur im Journal. Prüf es regelmäßig oder lass dir von einer Überwachung Bescheid geben.

Kommst du nicht weiter, schreib uns ein Ticket.