VPS-Backups: was wir sichern und wie Sie eigene erstellen

Die VPS-Backups verwalten wir, und im Kundenbereich können Sie daraus die gesamte Festplatte wiederherstellen. Für einzelne Dateien, Datenbanken und eine Kopie außerhalb unserer Infrastruktur richten Sie eigene Backups ein. Wir zeigen beides.

Automatische StormHost-Backups#

Wir erstellen VPS-Backups automatisch. Sie finden sie im Kundenbereich: Meine Dienste › Ihr VPS › Registerkarte Backups.

• Für jedes Backup zeigt die Liste Erstellt (Datum und Uhrzeit), Größe und den Speicher, auf dem es liegt.
• Ein Backup können Sie aus dem Kundenbereich nicht manuell erstellen. Erstellen Sie vor einer riskanten Änderung (System-Upgrade, große Konfigurationsänderung) ein eigenes Backup, wie im Rest dieser Anleitung beschrieben.
• Wenn Sie „Einer der Backup-Speicher antwortet gerade nicht — die Liste ist möglicherweise unvollständig“ sehen, sind manche Backups vorübergehend nicht verfügbar. Versuchen Sie es später erneut oder kontaktieren Sie uns.
• Ein Mitglied eines geteilten Dienstes sieht Backups nur mit der Berechtigung Backups und Wiederherstellung.

Den gesamten VPS wiederherstellen#

1. Suchen Sie in der Registerkarte Backups das Backup anhand seines Datums in der Spalte Erstellt.
2. Klicken Sie auf Wiederherstellen.
3. Lesen Sie die Warnung und bestätigen Sie sie durch Verschieben des Schiebereglers („Zum Wiederherstellen schieben“).
4. Warten Sie, bis es abgeschlossen ist. Während der Wiederherstellung ist der VPS heruntergefahren und gesperrt, und die Konsole verbindet sich nicht.
5. Starten Sie den VPS nach der Wiederherstellung (falls er nicht von selbst startet) und prüfen Sie Ihre Dienste.

Vollständige Wiederherstellung oder einzelne Dateien?#

Die 3-⁠2-⁠1-⁠Regel#

Eine bewährte Regel für Backups: 3 Kopien Ihrer Daten, an 2 verschiedenen Orten oder Speicherarten, davon 1 außerhalb der Hauptinfrastruktur.

Für einen VPS bedeutet das:

1. Die Daten auf dem VPS (die Originalkopie).
2. Unsere automatischen Backups (die zweite Kopie, außerhalb Ihres VPS).
3. Ihr eigenes Backup woanders: ein NAS zu Hause, ein anderer Server, Cloud-Speicher (die dritte Kopie, außerhalb unserer Infrastruktur).

Die dritte Kopie schützt Sie auch dann, wenn eine Wiederherstellung im Kundenbereich nicht hilft: Sie brauchen einen älteren Stand, eine einzelne Datei, oder Sie möchten umziehen.

Was sichern#

Backup-Skript#

Jeden Tag exportiert das Skript alle Datenbanken, archiviert die wichtigen Verzeichnisse und löscht Backups, die älter als 7 Tage sind.

1. Erstellen Sie die Skriptdatei:

   nano /usr/local/sbin/zaloha.sh

2. Fügen Sie den Inhalt ein:

   #!/bin/bash
   set -euo pipefail
   umask 077
   
   CIL=/var/backups/vps
   DNES=$(date +%F)
   UCHOVAT_DNI=7
   
   mkdir -p "$CIL"
   
   # 1) Datenbanken (nur wenn MariaDB/MySQL installiert ist)
   if command -v mariadb-dump >/dev/null 2>&1; then
     mariadb-dump --single-transaction --routines --events --all-databases | gzip > "$CIL/db-$DNES.sql.gz"
   fi
   
   # 2) Dateien
   tar -czf "$CIL/soubory-$DNES.tar.gz" --ignore-failed-read /etc /home /root /var/www /opt /srv || [ $? -eq 1 ]
   
   # 3) alte Backups loeschen
   find "$CIL" -type f -name '*.gz' -mtime +"$UCHOVAT_DNI" -delete
   
   echo "$(date '+%F %T') Backup fertig"

3. Speichern Sie (Strg+O, Eingabe), schließen Sie (Strg+X) und machen Sie es ausführbar:

   chmod 700 /usr/local/sbin/zaloha.sh

   • chmod 700 – nur root kann das Skript lesen und ausführen.

Was das Skript tut:

4. Probieren Sie das Skript von Hand:

   /usr/local/sbin/zaloha.sh
   ls -lh /var/backups/vps

   Sie sehen Backup fertig und die Dateien db-….sql.gz und soubory-….tar.gz. Die Meldung tar: Removing leading '/' from member names ist normal: Pfade werden im Archiv ohne den führenden Schrägstrich gespeichert.

Automatische Ausführung mit cron#

1. Stellen Sie sicher, dass cron installiert ist (ist es das bereits, passiert nichts):

   apt -y install cron

2. Öffnen Sie die Crontab von root:

   crontab -e

   Wählen Sie beim ersten Lauf den Editor nano.

3. Fügen Sie am Ende diese Zeile hinzu:

   30 3 * * * /usr/local/sbin/zaloha.sh >> /var/log/zaloha.log 2>&1

4. Speichern und schließen Sie den Editor. Sie sehen crontab: installing new crontab.

Eine Crontab-Zeile hat fünf Zeitfelder und einen Befehl:

Weitere Zeitbeispiele:

Die Zeiten richten sich nach der Zeitzone des VPS (timedatectl). Planen Sie Backups für die Zeit, in der der Server am wenigsten Verkehr hat.

Kopieren vom VPS weg#

SSH-Zugang zum Zielserver einrichten#

Senden Sie die Backups an einen anderen Server (ein NAS zu Hause mit SSH, einen anderen VPS). In den Beispielen hat der Zielserver die IP-Adresse 198.51.100.25; verwenden Sie stattdessen die Adresse Ihres eigenen Servers.

Legen Sie auf dem Zielserver (Ubuntu oder Debian, als root angemeldet) einen Benutzer und ein Verzeichnis an, in das er schreiben kann:

adduser zaloha
mkdir -p /srv/zalohy
chown zaloha:zaloha /srv/zalohy
chmod 700 /srv/zalohy

• adduser zaloha – legt den Benutzer zaloha an. Er fragt nach einem Passwort (Sie brauchen es in Schritt 2 unten) und nach optionalen Angaben, die Sie mit Eingabe überspringen können.
• mkdir -p /srv/zalohy – das Backup-Verzeichnis.
• chown zaloha:zaloha – das Verzeichnis gehört dem Benutzer zaloha, damit er hineinschreiben kann. Ohne dies scheitern sowohl rsync als auch restic mit Permission denied.
• chmod 700 – niemand sonst kann auf das Verzeichnis zugreifen.

Auf dem Zielserver muss die Passwortanmeldung mindestens erlaubt sein, bis Sie den Schlüssel hochgeladen haben (Schritt 2). Bei einem NAS folgen Sie dessen eigener Anleitung (Benutzer, freigegebener Ordner, SSH aktiviert).

Dann auf dem zu sichernden VPS:

1. Erstellen Sie einen SSH-Schlüssel ohne Passwort, der nur für Backups verwendet wird:

   ssh-keygen -t ed25519 -f /root/.ssh/zaloha -N "" -C "zaloha-vps"

   • -t ed25519 – ein moderner Schlüsseltyp.
   • -f /root/.ssh/zaloha – wo der Schlüssel gespeichert wird (erstellt zaloha und zaloha.pub).
   • -N "" – keine Schlüssel-Passphrase, damit cron ihn ohne Sie verwenden kann.
   • -C "zaloha-vps" – eine Schlüsselkennung.

2. Laden Sie den öffentlichen Schlüssel auf den Zielserver hoch (Sie geben das Passwort des Benutzers zaloha auf dem Zielserver ein):

   ssh-copy-id -i /root/.ssh/zaloha.pub [email protected]

   Bei der ersten Verbindung fragt SSH Are you sure you want to continue connecting (yes/no/[fingerprint])?. Tippen Sie yes: Der Fingerabdruck des Zielservers wird in /root/.ssh/known_hosts gespeichert, und cron wird nicht erneut gefragt.

3. Erstellen Sie ein Verbindungskürzel. Öffnen Sie nano /root/.ssh/config und fügen Sie hinzu:

   Host zalohy
       HostName 198.51.100.25
       User zaloha
       IdentityFile /root/.ssh/zaloha

   • Host zalohy – das Kürzel, das Sie statt der Adresse verwenden.
   • HostName – die IP-Adresse oder Domain des Zielservers.
   • User – der Benutzer auf dem Zielserver.
   • IdentityFile – der Schlüssel für die Anmeldung.

4. Testen Sie die Verbindung: ssh zalohy muss ohne Passwort anmelden. Melden Sie sich mit exit ab.

Die Arbeit mit Schlüsseln im Detail: SSH-Schlüssel.

rsync#

rsync kopiert nur geänderte Dateien und ist daher auch bei großen Backups schnell. Es muss auf beiden Seiten installiert sein (apt -y install rsync).

rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/

• -a – Archivmodus: kopiert rekursiv und erhält Berechtigungen, Zeiten und Links.
• -z – komprimiert die Daten während der Übertragung.
• /var/backups/vps/ – was kopiert wird. Der Schrägstrich am Ende bedeutet „den Inhalt des Verzeichnisses“, nicht das Verzeichnis selbst.
• zalohy:/srv/zalohy/vps1/ – das Ziel: das Kürzel aus ~/.ssh/config und das Verzeichnis auf dem Zielserver.

Fügen Sie die Übertragung als letzte Zeile von zaloha.sh hinzu oder in die Crontab eine Stunde nach dem Backup:

30 4 * * * rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/ >> /var/log/zaloha.log 2>&1

restic (fortgeschritten)#

restic speichert Backups verschlüsselt und mit Deduplizierung: Wiederholte Daten werden nur einmal gespeichert, sodass Sie Dutzende Tagesversionen mit wenig Platz behalten können. Es kann sowohl auf einen SFTP-Server als auch in Cloud-Speicher sichern.

1. Installieren Sie restic: apt -y install restic.

2. Erstellen Sie eine Datei mit dem Repository-Passwort und beschränken Sie ihre Berechtigungen:

   nano /root/.restic-heslo
   chmod 600 /root/.restic-heslo

   Legen Sie ein langes zufälliges Passwort in die Datei (Passwortgenerator).

3. Erstellen Sie ein Repository auf dem Zielserver:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo init

   • -r sftp:zalohy:/srv/zalohy/restic-vps1 – ein Repository über SFTP; zalohy ist das Kürzel aus ~/.ssh/config.
   • --password-file – die Passwortdatei, damit restic nicht fragt (für cron erforderlich).
   • init – legt ein neues leeres Repository an. Sie sehen created restic repository ….

4. Sichern Sie (diesen Befehl können Sie im Skript statt des tar-Archivs verwenden; behalten Sie den Datenbankexport):

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo backup /etc /home /root /var/www /opt /srv /var/backups/vps

5. Löschen Sie alte Versionen nach einer Richtlinie:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

   • forget – entfernt Versionen (Snapshots), die die Richtlinie nicht behält.
   • --keep-daily 7 – behält die neueste Version jedes der letzten 7 Tage, die ein Backup haben.
   • --keep-weekly 4, --keep-monthly 6 – zusätzlich eine Version pro Woche für 4 Wochen und eine pro Monat für 6 Monate.
   • --prune – löscht sofort Daten, auf die keine Version mehr verweist (gibt Platz frei).

Nützliche Befehle:

Eine Alternative zu restic ist BorgBackup (Dokumentation (öffnet sich in einem neuen Fenster)), das nach einem ähnlichen Prinzip arbeitet.

Wiederherstellung testen#

Ein Backup, dessen Wiederherstellung Sie nie geprobt haben, ist nur Hoffnung. Testen Sie es ab und zu:

1. Listen Sie den Archivinhalt auf: tar -tzf /var/backups/vps/soubory-2026-10-01.tar.gz | head.

2. Entpacken Sie eine einzelne Datei in ein temporäres Verzeichnis:

   mkdir -p /tmp/obnova
   tar -xzf /var/backups/vps/soubory-2026-10-01.tar.gz -C /tmp/obnova etc/nginx/nginx.conf

   • -x – entpacken, -z – gzip-Format, -f – aus einer Datei.
   • -C /tmp/obnova – wohin entpackt wird (damit die Live-Datei nicht überschrieben wird).
   • etc/nginx/nginx.conf – was entpackt wird (Pfad ohne führenden Schrägstrich).

3. Prüfen Sie den Datenbankexport: zcat /var/backups/vps/db-2026-10-01.sql.gz | head -n 20 muss den Anfang eines SQL-Exports zeigen.

4. Machen Sie einen vollständigen Test (Datenbank wiederherstellen, App starten) auf einem separaten Test-VPS, nicht auf Ihrem Produktivsystem.

Überprüfung#

• Am Morgen nach der ersten Nacht: tail /var/log/zaloha.log enthält die Zeile Backup fertig.
• ls -lh /var/backups/vps zeigt neue Dateien mit dem heutigen Datum und einer sinnvollen Größe (nicht 0 Bytes).
• Der Zielserver hat dieselben Dateien (rsync), oder restic snapshots zeigt die heutige Version.

Fehlerbehebung#

Cron hat das Skript nicht ausgeführt#

Prüfen Sie, dass cron läuft und was es ins Log geschrieben hat:

systemctl status cron
journalctl -u cron -n 50

Häufige Ursachen: In der Crontab fehlt der vollständige Pfad zum Skript, das Skript ist nicht ausführbar (chmod 700), oder Sie haben die Crontab eines anderen Benutzers als root bearbeitet (crontab -l gibt sie aus).

mariadb-dump: Got error: 1045: "Access denied for user …"#

Das Skript läuft nicht als root, oder der Datenbank-root verwendet ein Passwort statt des Unix-Sockets. Führen Sie das Skript aus der Crontab von root aus. Hat root ein Datenbankpasswort, speichern Sie es in /root/.my.cnf, wo mariadb-dump es automatisch liest:

[client]
user=root
password=<DB_ROOT_PASSWORT>

• [client] – die Optionsgruppe für alle MariaDB-Client-Programme (mariadb, mariadb-dump).
• user, password – die Zugangsdaten. Ersetzen Sie <DB_ROOT_PASSWORT> durch das Passwort des Datenbankbenutzers root (ohne die spitzen Klammern).

Sichern Sie die Datei mit chmod 600 /root/.my.cnf, damit niemand sonst das Passwort lesen kann.

Das Backup hat 0 Bytes oder ist verdächtig klein#

Das Skript ist mittendrin fehlgeschlagen. Führen Sie es von Hand aus und lesen Sie den Fehler. Dank set -euo pipefail bleibt ein Exportfehler nicht unbemerkt.

Permission denied (publickey) bei rsync oder restic#

Der Zielserver hat den Schlüssel nicht akzeptiert. Testen Sie ssh zalohy. Fragt es nach einem Passwort oder scheitert es, laden Sie den Schlüssel erneut hoch (ssh-copy-id) und prüfen Sie, dass IdentityFile in /root/.ssh/config auf die richtige Datei zeigt.

restic: Fatal: wrong password or no key found#

Das Passwort in /root/.restic-heslo passt nicht zum Repository. Prüfen Sie, dass die Datei kein zusätzliches Leerzeichen oder ein anderes Passwort enthält.

restic: Fatal: unable to open config file … Is there a repository at the following location?#

Unter dem angegebenen Pfad gibt es kein Repository (ein Tippfehler im Pfad, oder Sie haben init nicht ausgeführt).

Die Festplatte füllt sich#

Backups werden nicht gelöscht oder sind zu groß. Prüfen Sie, dass der Schritt find … -delete läuft, verringern Sie UCHOVAT_DNI und lassen Sie Verzeichnisse mit großen Daten weg, die Sie anders sichern.

Weiterführende Links#

• restic: Dokumentation (öffnet sich in einem neuen Fenster)
• BorgBackup: Dokumentation (öffnet sich in einem neuen Fenster)
• rsync: Handbuchseite (öffnet sich in einem neuen Fenster)
• crontab(5): Crontab-Format (öffnet sich in einem neuen Fenster)
• MariaDB: mariadb-dump (öffnet sich in einem neuen Fenster)