Backups für den vServer einrichtenAutomatisch, verschlüsselt und außerhalb des Servers

Wie das Backup bei uns geregelt ist

Wir legen keine automatischen Sicherungen deines vServers an. Das ist eine bewusste Entscheidung und hat zwei Seiten: Du zahlst nichts für einen Dienst, den viele ohnehin nicht nutzen - und du trägst dafür die Verantwortung selbst.

Was auf unserer Seite dagegen gegeben ist: Der NVMe-Speicher läuft im RAID 1, die Daten liegen also gespiegelt auf zwei Datenträgern. Das schützt vor dem Ausfall einer einzelnen SSD - mehr aber nicht. Gegen ein versehentliches rm -rf, eine kaputte Datenbank-Migration, Ransomware oder ein missglücktes Update hilft RAID überhaupt nicht. Dafür brauchst du ein Backup.

Eine gute Faustregel bleibt die 3-2-1-Regel: drei Kopien der Daten, auf zwei verschiedenen Medien, eine davon außerhalb des Standorts. Für einen einzelnen vServer heißt das übersetzt: die Live-Daten, eine lokale Sicherung für den schnellen Zugriff, eine externe Sicherung für den Ernstfall.

Schritt 1: Klären, was überhaupt gesichert werden muss

Ein vollständiges Abbild des Systems ist selten nötig. Das Betriebssystem installierst du im Webinterface in wenigen Minuten neu - unersetzlich sind nur deine eigenen Daten. Die typische Liste:

• Webseiten und Anwendungen: meist unter /var/www/
• Datenbanken: nicht die Dateien kopieren, sondern einen Dump erzeugen - dazu gleich mehr
• Konfigurationen: /etc/nginx/, /etc/php/, systemd-Units unter /etc/systemd/system/
• Docker: die Compose-Dateien und die Inhalte der benannten Volumes
• Gameserver: Weltordner und Konfigurationsdateien
• Zertifikate: /etc/letsencrypt/ - lässt sich zwar neu beantragen, spart aber Zeit

Schreib dir diese Liste einmal auf. Das häufigste Backup-Problem ist nicht die fehlende Sicherung, sondern die unvollständige.

Schritt 2: Datenbanken richtig sichern

Der klassische Fehler: das Verzeichnis /var/lib/mysql mitkopieren, während die Datenbank läuft. Das Ergebnis ist im Zweifel ein inkonsistenter Zustand, der sich nicht mehr einspielen lässt. Erzeuge stattdessen einen Dump:

sudo mkdir -p /var/backups/db
sudo mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alle-$(date +%F).sql.gz

Der Parameter --single-transaction ist entscheidend: Er sorgt für einen konsistenten Stand, ohne die Datenbank während des Dumps zu sperren. Bei PostgreSQL lautet das Gegenstück pg_dumpall.

Damit im Skript kein Passwort im Klartext steht, legst du eine geschützte Zugangsdatei an:

sudo nano /root/.my.cnf

[client]
user=root
password=dein-datenbank-passwort

sudo chmod 600 /root/.my.cnf

Bei Datenbanken im Docker-Container läuft der Dump über den Container hinweg:

docker compose exec -T db mariadb-dump --single-transaction -u root -pPASSWORT --all-databases | gzip > db-$(date +%F).sql.gz

Schritt 3: Variante einfach - rsync auf ein externes Ziel

Wenn du ein zweites System hast - einen weiteren vServer, ein NAS zu Hause, einen Rechner mit SSH-Zugang -, ist rsync der schnellste Weg. Es überträgt nur die Änderungen und ist damit auch für größere Datenmengen tauglich.

Zuerst einen SSH-Schlüssel ohne Passphrase für den automatisierten Lauf erzeugen und hinterlegen:

sudo ssh-keygen -t ed25519 -f /root/.ssh/backup_key -N ""
sudo ssh-copy-id -i /root/.ssh/backup_key.pub backup@ZIEL-SERVER

Dann das Backup-Skript:

sudo nano /root/backup.sh

#!/bin/bash
set -euo pipefail

DATUM=$(date +%F)
ZIEL="backup@ZIEL-SERVER:/backups/vserver/"
KEY="/root/.ssh/backup_key"

# 1. Datenbank-Dump
mkdir -p /var/backups/db
mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alle-$DATUM.sql.gz

# 2. Alte Dumps aufraeumen (aelter als 14 Tage)
find /var/backups/db -name "*.sql.gz" -mtime +14 -delete

# 3. Uebertragen
rsync -az --delete -e "ssh -i $KEY" \
  /var/www/ /etc/nginx/ /etc/letsencrypt/ /var/backups/db/ \
  "$ZIEL"

echo "Backup $DATUM abgeschlossen"

sudo chmod 700 /root/backup.sh

Die Zeile set -euo pipefail ist wichtiger, als sie aussieht: Sie bricht das Skript bei jedem Fehler ab, statt stillschweigend weiterzumachen und ein unvollständiges Backup als Erfolg zu melden.

Vorsicht mit --delete: Der Parameter spiegelt exakt und entfernt am Ziel, was auf der Quelle fehlt. Bei einem versehentlich gelöschten Verzeichnis löscht der nächste Lauf also auch die Sicherung. Wer das vermeiden will, nimmt Borg.

Schritt 4: Variante empfohlen - BorgBackup

BorgBackup löst genau dieses Problem: Es legt versionierte Sicherungspunkte an, dedupliziert über alle Läufe hinweg und verschlüsselt am Quellsystem. Selbst wenn jemand Zugriff auf das Backup-Ziel bekommt, sind deine Daten dort nicht lesbar.

sudo apt install borgbackup -y
sudo borg init --encryption=repokey-blake2 backup@ZIEL-SERVER:/backups/borg-vserver

Sichere die Passphrase und die Repository-Schlüsseldatei außerhalb des Servers. Ohne sie ist das Backup wertlos - das ist der Punkt, an dem eine an sich gute Strategie im Ernstfall scheitert.

Das Skript dazu:

#!/bin/bash
set -euo pipefail

export BORG_PASSPHRASE='deine-lange-passphrase'
export BORG_RSH="ssh -i /root/.ssh/backup_key"
REPO="backup@ZIEL-SERVER:/backups/borg-vserver"

mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alle.sql.gz

borg create --stats --compression zstd \
  "$REPO::{hostname}-{now:%Y-%m-%d_%H%M}" \
  /var/www /etc/nginx /etc/letsencrypt /var/backups/db

borg prune -v "$REPO" \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6

borg compact "$REPO"

Die prune-Zeile hält den Speicherbedarf im Rahmen: sieben tägliche, vier wöchentliche und sechs monatliche Sicherungspunkte. Dank Deduplizierung kostet das deutlich weniger Platz, als die Anzahl vermuten lässt.

Schritt 5: Automatisieren per Cron

Ein Backup, das du von Hand anstoßen musst, wird irgendwann vergessen. Trage es in den Cron ein:

sudo crontab -e
30 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1

Das führt das Skript täglich um 3:30 Uhr aus und schreibt die Ausgabe samt Fehlermeldungen in eine Logdatei. Prüfe nach dem ersten Lauf, ob alles durchgelaufen ist:

tail -n 30 /var/log/backup.log

Wer nicht regelmäßig ins Log schauen möchte, hängt einen Benachrichtigungsdienst an oder lässt sich bei Fehlern eine Mail schicken. Ein stillschweigend seit Wochen kaputtes Backup ist gefährlicher als gar keines, weil man sich darauf verlässt.

Schritt 6: Die Wiederherstellung testen

Das ist der Schritt, den fast alle überspringen - und der im Ernstfall den Unterschied macht. Ein Backup, das noch nie zurückgespielt wurde, ist bestenfalls eine Vermutung.

Bei Borg schaust du dir zuerst an, was überhaupt da ist:

borg list "$REPO"
borg list "$REPO::ARCHIVNAME" | head

Eine einzelne Datei holst du so zurück:

cd /tmp && borg extract "$REPO::ARCHIVNAME" var/www/meineseite/index.php

Eine Datenbank spielst du so ein:

gunzip < alle-2026-08-01.sql.gz | sudo mariadb

Setz dir eine Erinnerung, das einmal im Quartal zu machen. Und denke an den Extremfall: Wenn dein vServer komplett neu aufgesetzt werden muss, brauchst du auch Zugang zum Backup-Ziel, die Borg-Passphrase und den privaten SSH-Schlüssel. Liegt all das ausschließlich auf dem verlorenen Server, hilft dir die beste Sicherung nicht weiter.

Kurze Checkliste

• Liste erstellt, welche Verzeichnisse und Datenbanken unersetzlich sind
• Datenbanken per Dump gesichert, nicht als Dateikopie
• Ziel liegt außerhalb des vServers
• Backup verschlüsselt, Passphrase separat gesichert
• Cronjob eingerichtet, erster Lauf im Log geprüft
• Aufbewahrung begrenzt, damit das Ziel nicht vollläuft
• Wiederherstellung mindestens einmal getestet

Häufige Fragen