Eine praktische VPS-Backup-Strategie (3-2-1-Regel)

Geschrieben vom ApexVPS-Team • Zuletzt aktualisiert: Juli 2026 • 7 Min. Lesezeit

Eine zuverlässige VPS-Backup-Strategie ist der Unterschied zwischen einer Fünf-Minuten-Wiederherstellung und einer sehr schlechten Woche. Server fallen aus, Festplatten korrumpieren, Deploys gehen schief, und ein einziger Tippfehler kann ein Verzeichnis löschen. Das Cloudflare Learning Center und die meisten Infrastruktur-Teams verweisen auf dieselbe einfache Disziplin: die 3-2-1-Regel. Dieser Leitfaden zeigt, wie Sie sie auf einen echten virtuellen Server anwenden, welche Tools Sie verwenden und wie Sie alles planen und testen, damit eine Wiederherstellung tatsächlich funktioniert, wenn Sie sie brauchen.

Was die 3-2-1-Regel bedeutet

Die 3-2-1-Regel ist ein jahrzehntealtes Backup-Prinzip, das gilt, egal wo Ihr Server lebt:

Auf einem VPS bedeutet das in der Regel Ihren laufenden Server, ein lokales Backup-Repository und eine verschlüsselte Kopie, die auf einen externen Speicher an einem anderen Standort übertragen wird. Der Punkt ist Redundanz ohne einen gemeinsamen Single Point of Failure.

Was Sie auf einem VPS sichern sollten

Die gesamte Festplatte Block für Block zu sichern, ist verschwenderisch und langsam. Ein gutes Backup-Konzept zielt auf die drei Dinge ab, die wirklich schwer neu zu erstellen sind.

Anwendungsdaten und Dateien

Hochgeladene Dateien, Website-Roots, Container-Volumes und alles, was Benutzer generieren. Typische Pfade sind /var/www, /srv, /home und Ihr Docker-Volume-Verzeichnis. Wenn Sie selbst gehostete Apps wie einen Dateiserver oder ein Wiki betreiben, ist dies der Ort, an dem Ihre unersetzlichen Inhalte leben – finden Sie in unserem Leitfaden zu VPS für Self-Hosting, wie diese Verzeichnisse normalerweise aufgebaut sind.

Datenbanken

Kopieren Sie niemals Live-Datenbankdateien, während der Dienst läuft – Sie könnten einen halb geschriebenen, beschädigten Zustand erfassen. Exportieren Sie stattdessen einen konsistenten Dump. Für MySQL oder MariaDB:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

Das --single-transaction-Flag erzeugt einen konsistenten Snapshot von InnoDB-Tabellen, ohne sie zu sperren. Verwenden Sie für PostgreSQL stattdessen pg_dump:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

System- und Dienstkonfiguration

Die Dateien, die Ihren Server zu Ihrem machen: /etc (nginx, systemd-Units, cron, SSH-Konfiguration), Paketlisten, TLS-Zertifikate und Firewall-Regeln. Diese nach einem Ausfall aus dem Gedächtnis neu aufzubauen, ist genau die mühsame Arbeit, die Backups vermeiden sollen.

Die Wahl Ihrer Backup-Werkzeuge

Drei Tools decken fast alle VPS-Fälle ab. Entscheiden Sie basierend darauf, wie wichtig Ihnen Deduplizierung und Verschlüsselung sind.

restic – verschlüsselte, deduplizierte Snapshots

restic ist ein modernes Backup-Tool mit einer einzigen Binärdatei, das standardmäßig verschlüsselt und dedupliziert. Initialisieren Sie einmal ein Repository und führen Sie dann Backups dagegen aus:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup – deduplizierende Archive

BorgBackup bietet ähnliche Deduplizierung und Komprimierung mit einem etwas anderen Workflow:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync – einfache Dateispielgelung

Wenn Sie einfach nur eine schnelle Spiegelung von Dateien auf einen anderen Host benötigen, ist rsync über SSH kaum zu schlagen:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

Die -aAX-Flags erhalten Berechtigungen, ACLs und erweiterte Attribute; --delete hält den Spiegel auf dem neuesten Stand der Quelle. rsync allein erstellt keine Versionsverläufe, weshalb viele Teams es mit restic oder Borg kombinieren.

Automatisieren Sie den Zeitplan mit cron

Ein Backup, an das Sie sich erinnern müssen, ist ein Backup, das nicht stattfinden wird. Legen Sie Ihre Schritte in einem Skript ab, machen Sie es ausführbar und planen Sie es mit cron. Bearbeiten Sie Ihre Crontab mit:

crontab -e

Fügen Sie dann Zeilen wie diese hinzu:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

Protokollieren Sie die Ausgabe und lassen Sie das Skript bei Fehlern mit einem Nicht-Null-Status beenden, damit Sie es in die Überwachungs- und Alarmierungsfunktionen einbinden können, die mit Ihrem Plan enthalten sind. Ein stiller Backup-Fehler ist schlimmer als kein Backup, weil er sich sicher anfühlt.

Behalten Sie eine echte externe Kopie

Die "1" in 3-2-1 ist der Teil, den die meisten überspringen. Ein Backup, das auf demselben Server sitzt, den es schützt, verschwindet mit diesem Server. Übertragen Sie eine verschlüsselte Kopie an einen unabhängigen Ort – Objektspeicher, eine remote SFTP-Box oder einen anderen Anbieter. restic und Borg schreiben beide direkt auf entfernte Repositorys, z.B. über SFTP:

restic -r sftp:[email protected]:/backups/restic backup /var/www

Da restic und Borg verschlüsseln, bevor die Daten Ihren VPS verlassen, sieht der entfernte Host niemals Ihren Klartext. Reduzieren Sie alte Snapshots nach einer Richtlinie, damit der Speicher nicht endlos wächst:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Testen Sie Ihre Wiederherstellungen – jedes Mal

Ein ungetestetes Backup ist ein Gerücht. Planen Sie eine periodische Wiederherstellung an einem Wegwerfort und bestätigen Sie, dass die Dateien und Datenbanken intakt zurückkommen:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

Wenn die Wiederherstellung erfolgreich ist und die Daten übereinstimmen, haben Sie einen Plan. Wenn nicht, haben Sie das an einem Dienstagnachmittag gelernt und nicht während eines echten Ausfalls.

Snapshots sind nur eine Ebene, nicht die ganze Strategie

Jeder ApexVPS-Tarif enthält automatisierte Backups – tägliche Snapshots bei Starter Pro und stündliche Snapshots bei Business – und sie sind wirklich nützlich für schnelle Rollbacks nach einem fehlerhaften Deployment oder versehentlichem Löschen. Aber seien Sie ehrlich, was sie sind: eine bequeme erste Ebene, die auf unserer Plattform liegt. Sie ersetzen keine externe, unabhängig verifizierte Kopie, die die 3-2-1-Regel verlangt. Behandeln Sie Plattform-Snapshots als Ihren schnellen lokalen Wiederherstellungspunkt und führen Sie einen eigenen restic- oder borg-Job aus, um die Teile der Regel zu erfüllen, die Offsite und getestete Wiederherstellung betreffen. Dieser mehrschichtige Ansatz unterscheidet ein hoffnungsvolles Setup von einem widerstandsfähigen, ob Sie nun Apps wie Nextcloud selbst hosten oder eine Produktionsdatenbank betreiben.

Ihre VPS-Backup-Strategie-Checkliste

Wenn man alles zusammenfügt, sieht eine vollständige Backup-Strategie für einen virtuellen Server so aus. Arbeiten Sie sie einmal durch, scripten Sie sie und lassen Sie cron sie weiterführen:

Wenn Sie diese sechs Dinge tun, hört die 3-2-1-Regel auf, Theorie zu sein, und wird zur Gewohnheit, auf die sich Ihre Infrastruktur verlassen kann. Die anfängliche Stunde für die Einrichtung ist trivial im Vergleich zu den Kosten, wenn Sie mitten im Vorfall entdecken, dass Ihre einzige Kopie auf der Festplatte lag, die gerade gestorben ist.

Brauchen Sie einen Server, den Sie vollständig kontrollieren, um dies auszuführen? ApexVPS gibt Ihnen vollen Root-Zugriff, NVMe-Speicher und dedizierte Ressourcen in 39 Rechenzentren – mit Krypto-only-Zahlung, ohne Karte und ohne KYC. Vergleichen Sie dedizierte VPS-Pläne →

Häufig gestellte Fragen

Zählen Anbieter-Snapshots als Backup-Strategie?

Snapshots sind eine nützliche Ebene, aber keine vollständige Strategie. Unsere täglichen und stündlichen Snapshots schützen vor den meisten kurzfristigen Fehlern, aber sie liegen auf derselben Plattform wie Ihr Server. Eine vollständige 3-2-1-Backup-Strategie benötigt immer noch eine unabhängige, externe Kopie, die Sie kontrollieren, und Wiederherstellungen, die Sie tatsächlich getestet haben.

Wie oft sollte ich einen VPS sichern?

Passen Sie die Häufigkeit an, wie viele Daten Sie sich leisten können zu verlieren. Statische Dateien und Konfigurationen können täglich gesichert werden, während aktive Datenbanken oft stündliche Dumps rechtfertigen. Verwenden Sie cron, um den Zeitplan zu automatisieren, damit Backups nie vom Erinnern abhängen.

Was ist das beste Werkzeug für VPS-Backups?

restic und BorgBackup sind beide ausgezeichnet: Sie deduplizieren, komprimieren und verschlüsseln Backups und unterstützen externe Repositories. rsync ist für einfache Dateispiegelung gut, und mysqldump oder pg_dump übernehmen den Datenbank-Export. Viele Setups kombinieren einen Datenbank-Dump mit einem restic- oder borg-Lauf.

Woher weiß ich, dass meine Backups tatsächlich funktionieren?

Testen Sie Wiederherstellungen nach einem Zeitplan. Stellen Sie in ein temporäres Verzeichnis wieder her, überprüfen Sie Dateiinhalte und Prüfsummen, und importieren Sie einen Datenbank-Dump in eine Testdatenbank. Ein Backup, das Sie nie wiederhergestellt haben, ist nur eine hoffnungsvolle Vermutung, kein Wiederherstellungsplan.