Skip to content
VDS · Backups und Festplatte

Was genau kopiert werden sollte

Eine Liste dessen, was auf einem VPS tatsächlich gesichert werden muss, was sinnlos zu kopieren ist und wie Sie Datenbanken exportieren, damit die Kopie wirklich funktioniert.

Aktualisiert am 23. August 2026

Wir erstellen keine automatischen Backups Ihrer Maschine: Auch im Panel gibt es keine Zustands-Snapshots, und eine Neuinstallation des Betriebssystems löscht die Festplatte vollständig. Das bedeutet, dass Backups vollständig in Ihrer Verantwortung liegen – und Sie müssen am ersten Tag damit beginnen, nicht erst nach einem Verlust.

Was Sie sichern müssen

  • Anwendungsdaten — Docker-Volumes, Website-Verzeichnisse, von Nutzern hochgeladene Dateien.
  • Datenbank-Dumps — ausdrücklich Dumps, keine laufenden Datenbankdateien (mehr dazu unten).
  • Konfiguration — /etc/nginx, /etc/caddy, systemd-Units, compose.yaml und .env-Dateien, Firewall-Regeln.
  • Zertifikate und Schlüssel — /etc/letsencrypt, Anwendungsschlüssel, DKIM-Schlüssel des Mailservers.
  • Geplante Aufgaben — crontab -l > /root/crontab.txt vor dem Backup, sonst stellen Sie alles außer dem Zeitplan wieder her.
  • Liste der installierten Pakete — dpkg --get-selections > /root/packages.txt. Kostet Kilobytes, spart Stunden.

Was Sie nicht sichern müssen

Das Betriebssystem, Pakete und Docker-Images werden durch Neuinstallation und das Ausführen von Befehlen wiederhergestellt – sie sind den Speicherplatz und die Zeit nicht wert. Sichern Sie nicht /proc, /sys, /dev, /var/lib/docker vollständig, Cache-Verzeichnisse oder Swap-Dateien.

Eine vernünftige Faustregel: Ein Backup sollte alles enthalten, was nicht im Internet steht und was Sie nicht anhand von Anleitungen neu erstellen können.

Datenbanken

Sie können die Dateien einer laufenden Datenbank nicht kopieren: Sie erhalten einen Snapshot, der mitten im Schreibvorgang erstellt wurde und sich möglicherweise nicht öffnen lässt. Der richtige Weg ist ein Dump mit den eigenen Werkzeugen der Datenbank.

docker compose exec -T db pg_dump -U postgres app | gzip > /backup/app-$(date +%F).sql.gz
docker compose exec -T db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction app | gzip > /backup/app-$(date +%F).sql.gz
sqlite3 /data/app.db ".backup '/backup/app-$(date +%F).db'"

Bei PostgreSQL und MySQL müssen Sie den Dienst nicht stoppen. Bei SQLite verwenden Sie .backup, nicht cp: Das Kopieren der Datei im laufenden Betrieb erzeugt eine beschädigte Datenbank.

Ein Backup, aus dem Sie noch nie wiederhergestellt haben, zählt nicht als Backup. Testen Sie es auf einer leeren Maschine oder in einem separaten Container – siehe Wiederherstellungsübung.

Beispiel eines vollständigen Sets

#!/bin/bash
set -euo pipefail
DEST=/backup/$(date +%F)
mkdir -p "$DEST"

docker compose -f /opt/myapp/compose.yaml exec -T db pg_dump -U postgres app | gzip > "$DEST/db.sql.gz"
tar czf "$DEST/etc.tar.gz" /etc/nginx /etc/letsencrypt /opt/myapp/compose.yaml /opt/myapp/.env
tar czf "$DEST/uploads.tar.gz" /var/www/uploads
crontab -l > "$DEST/crontab.txt"
dpkg --get-selections > "$DEST/packages.txt"

Legen Sie das Skript in /usr/local/bin/backup.sh ab, geben Sie ihm chmod 700-Rechte und fügen Sie es zum Zeitplan hinzu. Danach müssen Sie das Backup an einen anderen Ort senden – eine Datei neben Ihren Daten schützt Sie vor nichts.

Wie lange aufbewahren

Die „3-2-1“-Regel in vereinfachter Form: mindestens zwei Kopien, mindestens eine außerhalb dieser Maschine. Für die Aufbewahrung reichen sieben tägliche, vier wöchentliche und drei monatliche – das genügt, um auf einen Zustand vor einem stillen Fehler zurückzurollen, den Sie nicht sofort bemerkt haben.

Planen Sie Ihren Speicherplatz im Voraus: VDS-1 hat eine 40 GB Festplatte, und darauf ist schlicht kein Platz für die Backup-Historie – siehe Speicherplatz.

Häufige Fehler

  • Das Backup liegt auf derselben Maschine. Eine Neuinstallation, Verlust des Zugangs, ein rm -rf-Fehler – und das Backup ist zusammen mit den Daten weg.
  • Sie haben .env vergessen. Sie haben die Daten, aber die Passwörter und Schlüssel dafür sind verloren.
  • Das Kopieren des Datenbank-Volumes im laufenden Betrieb. Die Wiederherstellung scheitert an einer beschädigten Datei. Nur Dumps.
  • Niemand weiß, dass das Backup nicht mehr erstellt wird. Richten Sie eine Push-Prüfung in Uptime Kuma ein: Das Skript pingt nach Erfolg eine Adresse an, und ein Tag Stille löst einen Alarm aus.