Alle Produkte 
VPS-Backups: Strategien und Werkzeuge
Auf einem VPS sind Backups Ihre Sache, auch wenn im Tarif „Backups inklusive“ steht. Hier lesen Sie, was genau gesichert werden muss, warum ein Snapshot beim Hoster nicht reicht, wie Sie restic oder BorgBackup in einer halben Stunde einrichten und wie Sie sicherstellen, dass sich aus dem Backup tatsächlich wiederherstellen lässt.
An ein Backup denkt man meist erst, wenn man es braucht: Ein Update hat die Datenbank beschädigt, jemand hat den Ordner der Website gelöscht, beim Hoster ist eine Festplatte ausgefallen oder der Server wurde gehackt. In jedem dieser Fälle rettet Sie nicht irgendein Backup, sondern eines, das an einem anderen Ort liegt, aktuell ist und aus dem Sie schon mindestens einmal wiederhergestellt haben. Im Folgenden erfahren Sie, wie Sie ein solches Backup auf einem gewöhnlichen Linux-Server einrichten.
Ein Snapshot beim Hoster ist noch keine Strategie
Viele Hoster bieten im Panel Festplatten-Snapshots und automatische Sicherungen an. Das ist nützlich, doch eine solche Sicherung hat drei Schwachstellen.
- Sie liegt beim selben Hoster. Ein Zahlungsproblem, die Schließung des Kontos, ein Ausfall im Rechenzentrum oder ein gestohlenes Passwort zum Kundenkonto nehmen den Server und alle seine Snapshots auf einmal mit.
- Es gibt wenige Sicherungen, und sie sind selten. Oft sind es ein oder zwei letzte Sicherungen, einmal täglich oder wöchentlich. Fällt ein Schaden erst nach einigen Tagen auf, ist womöglich keine intakte Version mehr übrig.
- Die Datenbank im Snapshot ist nicht immer intakt. Ein Snapshot hält die Festplatte zu einem beliebigen Zeitpunkt fest, als wäre der Server plötzlich ausgeschaltet worden. InnoDB und PostgreSQL erholen sich davon meist, eine Garantie gibt es aber nicht, und MyISAM-Tabellen können beschädigt sein.
Ein Snapshot ist praktisch als schneller Rückfallpunkt vor einem Update. Die eigentlichen Backups sollten Sie mit eigenen Mitteln erstellen und getrennt aufbewahren.
Die 3-2-1-Regel
Das klassische Schema lautet: drei Kopien der Daten, auf zwei verschiedenen Datenträgern oder Systemen, eine davon an einem anderen Ort. Für einen VPS sieht das meist so aus:
- Die Arbeitsdaten auf dem Server selbst.
- Eine Kopie auf einem anderen Server oder in einem S3-Objektspeicher bei einem anderen Hoster oder zumindest in einem anderen Rechenzentrum.
- Eine weitere Kopie: Snapshots im Panel des Hosters, ein zweiter Backup-Server oder eine Sicherung auf einen Speicher zu Hause.
Dazu kommt eine Regel: Mindestens eine Kopie darf sich vom Produktivserver aus nicht löschen lassen. Hat ein Angreifer root-Rechte erlangt, sieht er auch die Zugangsdaten zum Backup-Speicher. Wie Sie das umsetzen, steht weiter unten im Abschnitt über den Schutz vor dem Löschen.
Was gesichert werden muss
Das gesamte System zu sichern, ist meist nicht nötig: Ein sauberer Server ist aus einer Vorlage in Minuten aufgesetzt. Wertvoll sind Daten und Einstellungen.
| Was | Wo es meist liegt | Wie sichern |
|---|---|---|
| Dateien der Websites und Uploads der Nutzer | /var/www, /home | Als Dateien |
| Datenbanken | /var/lib/mysql, /var/lib/postgresql | Nur als Dump, nicht als Dateien |
| System- und Diensteinstellungen | /etc | Als Dateien, zusammen mit den Zertifikaten aus /etc/letsencrypt |
| Geplante Aufgaben | /etc/cron.d, crontab -l der Benutzer | Als Dateien oder als Textexport |
| Containerdaten | Docker-Volumes, meist /var/lib/docker/volumes | Als Dateien bei gestopptem Container oder als Datenbank-Dump daraus |
Schließen Sie Caches, temporäre Dateien, Logs und node_modules aus: Sie blähen das Backup auf und entstehen von selbst neu.
Datenbanken: nur als Dump
Die Datenbankdateien eines laufenden Servers dürfen Sie nicht einfach kopieren: Sie ändern sich während des Kopierens, und die Kopie wird inkonsistent. Der richtige Weg ist ein Dump. Für MySQL und MariaDB:
mysqldump --single-transaction --routines --triggers shop | gzip > /var/backups/shop-$(date +%F).sql.gzDer Schalter --single-transaction erzeugt einen konsistenten Dump der InnoDB-Tabellen, ohne Schreibvorgänge anzuhalten. MyISAM-Tabellen schützt dieser Schalter nicht: Gibt es welche, stellen Sie sie auf InnoDB um oder erstellen den Dump mit --lock-all-tables. Unter Debian und Ubuntu meldet sich root über den Socket ohne Passwort bei MariaDB an, der Befehl funktioniert als root also unverändert; für einen anderen Benutzer legen Sie Login und Passwort in ~/.my.cnf mit den Rechten 600 ab.
Für PostgreSQL:
sudo -u postgres pg_dump -Fc shop > /var/backups/shop-$(date +%F).dump
sudo -u postgres pg_dumpall --globals-only > /var/backups/pg-globals.sqlDie zweite Datei sichert Rollen und Rechte, die im Dump einer einzelnen Datenbank fehlen. Wiederhergestellt wird ein solcher Dump mit pg_restore -d shop datei.dump. Ist die Datenbank Dutzende Gigabyte groß und dauert der Dump zu lange, sehen Sie sich physische Sicherungen an: mariabackup oder Percona XtraBackup für MySQL, pgBackRest für PostgreSQL.
Legen Sie die Dumps in einem Ordner ab, etwa /var/backups, und nehmen Sie ihn in die Dateisicherung auf – dann landet alles mit einem einzigen Befehl im Speicher.
Werkzeuge: rsync, restic, BorgBackup
| rsync | restic | BorgBackup | |
|---|---|---|---|
| Versionen | Nur manuell über --link-dest | Ja, Snapshots | Ja, Archive |
| Verschlüsselung | Nein, nur bei der Übertragung per SSH | Immer, auf dem Quellserver | Ja, wählbar beim Anlegen des Repositorys |
| Deduplizierung | Nein | Ja | Ja, plus Komprimierung |
| Speicherziel | Festplatte, SSH | Festplatte, SFTP, S3, eigener REST-Server | Festplatte, SSH mit borg auf der Gegenseite |
| Modus „nur hinzufügen“ | Nein | Über rest-server | Über borg serve --append-only |
rsync: ein Spiegel, kein Backup
rsync synchronisiert Ordner schnell, ist für sich genommen aber kein Backup: Eine auf dem Server gelöschte oder beschädigte Datei wird beim nächsten Lauf auch im Spiegel gelöscht oder beschädigt. Versionen erhalten Sie mit dem Schalter --link-dest: Jeder Lauf legt einen neuen Ordner an, und unveränderte Dateien darin sind Hardlinks auf den vorherigen, sodass nur Änderungen Platz verbrauchen. Bequemer ist es, das auf dem Backup-Server laufen zu lassen, der die Daten selbst vom Produktivserver abholt:
rsync -a --delete --link-dest=/backup/web/2026-10-30 root@web.example.com:/var/www/ /backup/web/2026-10-31/Für eine einzelne Website reicht das, doch Verschlüsselung und Integritätsprüfung bietet rsync nicht.
restic
restic ist ein einzelnes Programm ohne Abhängigkeiten. Es verschlüsselt die Daten vor dem Versand, speichert nur neue Dateiteile und kann auf SFTP, in einen S3-kompatiblen Speicher oder auf einen eigenen rest-server schreiben. Das Repository wird einmal angelegt, danach entsteht ein Backup mit einem einzigen Befehl:
export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /var/www /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic checkDer Befehl forget behält 7 tägliche, 4 wöchentliche und 6 monatliche Snapshots, und --prune gibt den Platz der übrigen frei. Ohne das Passwort aus /root/.restic-pass lässt sich das Repository auf keinen Fall entschlüsseln, bewahren Sie also eine Kopie davon außerhalb des Servers auf, etwa in einem Passwortmanager.
BorgBackup
Borg ähnelt restic, komprimiert aber meist besser und arbeitet schneller mit vielen kleinen Dateien. Das Repository liegt auf einer Festplatte oder auf einem anderen Server per SSH, wo ebenfalls borg installiert sein muss; S3 unterstützt es nicht direkt. Der stabile Zweig ist 2026 die 1.4, Version 2.0 ist noch in der Betaphase und für produktive Backups nicht empfohlen. Die Befehle für 1.4:
export BORG_REPO=ssh://backup@storage.example.com/./web1
export BORG_PASSCOMMAND="cat /root/.borg-pass"
borg init --encryption=repokey-blake2
borg create --stats --compression zstd ::'{hostname}-{now}' /etc /var/www /var/backups
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compactSeit 1.2 wird der Platz nach prune erst mit dem Befehl compact freigegeben. Im Modus repokey liegt der Schlüssel passwortgeschützt im Repository selbst; exportieren Sie ihn sicherheitshalber mit borg key export und bewahren Sie ihn außerhalb des Servers auf.
Ist auf dem Server ein Control Panel installiert, sehen Sie sich dessen eingebaute Backups an: In ISPmanager, FASTPANEL und aaPanel werden sie in der Oberfläche eingerichtet und können Archive an einen externen Speicher senden. Tarifauswahlen mit Panels: ISPmanager, FASTPANEL, aaPanel.
Wo Sie Backups aufbewahren
- Ein separater VPS bei einem anderen Hoster. Für Backups brauchen Sie keinen schnellen Prozessor, sondern eine große Festplatte. Solche Tarife finden Sie in den Auswahlen VPS für Datenspeicherung, VPS mit HDD und VPS für Backups.
- S3-Objektspeicher. Sie zahlen für belegte Gigabyte, und restic schreibt direkt dorthin. Unterstützt der Speicher Objektversionen oder eine befristete Löschsperre, ist das zugleich ein Schutz vor dem Löschen.
- Ein Speicher zu Hause oder im Büro. Gut als dritte Kopie: Der Backup-Server holt die Daten selbst per SSH ab, und von außen kann sich niemand mit ihm verbinden.
Enthält die Datenbank personenbezogene Daten russischer Bürger, beachten Sie das russische Gesetz 152-FZ: Auch die Backups bewahren Sie dann besser auf Servern in Russland auf, Auswahl: VPS für 152-FZ.
Schutz vor dem Löschen
Am unangenehmsten ist es, wenn ein Angreifer oder ein fehlerhaftes Skript sowohl die Daten als auch die Backups löscht. Es gibt drei Wege, das zu verhindern.
- Abholen statt senden. Der Backup-Server verbindet sich selbst mit dem Produktivserver und holt die Daten ab. Der Produktivserver hat keinerlei Zugriff auf die Backups.
- Modus „nur hinzufügen“. Für borg wird auf dem Backup-Server in
authorized_keysdem Schlüssel des Produktivservers ein Befehl zugewiesen:command="borg serve --append-only --restrict-to-path /srv/borg/web1",restrict ssh-ed25519 AAAA…. Neue Archive lassen sich hinzufügen, alte nicht löschen. Bei restic übernimmt das ein rest-server, der mit dem Schalter--append-onlygestartet wird. Das Aufräumen alter Backups starten Sie in diesem Fall von einem vertrauenswürdigen Rechner mit einem anderen Schlüssel. - Versionen und Löschsperre in S3. Der Speicher bewahrt frühere Objektversionen selbst für einen festgelegten Zeitraum auf.
Zeitplan und wie oft Sie sichern sollten
Die Häufigkeit hängt davon ab, wie viele Daten Sie zu verlieren bereit sind. Für einen Blog reicht ein Backup pro Tag. Bei einem Shop, in dem den ganzen Tag Bestellungen eingehen, sollten Sie den Datenbank-Dump stündlich erstellen und die Dateien einmal täglich sichern. Starten Sie das Backup nachts per cron oder systemd-Timer, etwa mit einer Datei /etc/cron.d/backup mit der Zeile 30 3 * * * root /usr/local/bin/backup.sh.
Ein Backup, das unbemerkt nicht mehr läuft, ist schlimmer als gar keines: Sie glauben, geschützt zu sein. Senden Sie am Ende des Skripts ein Signal an ein externes Monitoring (ein einfaches curl auf die Prüfadresse), und bleibt das Signal aus, meldet sich das Monitoring bei Ihnen.
Prüfen Sie die Wiederherstellung
Stellen Sie einmal im Monat ein Backup auf einem sauberen Server wieder her und prüfen Sie, dass die Website lädt und die Daten vollständig sind. Praktisch dafür ist die stundenweise Abrechnung: Der Testserver kostet nur für die Stunden, in denen er läuft.
restic restore latest --target /tmp/restore --include /var/www/site
restic check --read-data-subset=10%
borg extract ::web1-2026-10-31T03:30:00 var/www/site # Archivname aus borg list
borg check --verify-dataDer zweite und der vierte Befehl lesen die eigentlichen Daten im Repository, nicht nur sein Inhaltsverzeichnis, und finden beschädigte Teile. Schreiben Sie den Ablauf der Wiederherstellung in eine eigene Datei außerhalb des Servers: Bei einem Ausfall haben Sie keine Zeit, sich an Befehle zu erinnern. Wie Sie den neuen Server vorbereiten, auf dem Sie wiederherstellen, beschreibt der Artikel Die ersten 10 Schritte nach dem VPS-Kauf: Sicherheit, den Umzug einer kompletten Website der Artikel So ziehen Sie eine Website vom Shared Hosting auf einen VPS um.