Ob eine Sicherung taugt, zeigt sich erst, wenn ein Server ausfällt, eine Datenbank beschädigt ist oder ein Kunde versehentlich Teile seines Webverzeichnisses gelöscht hat. KeyHelp bringt dafür eine Backup-Funktion mit, die intern restic nutzt: verschlüsselt, dedupliziert und inkrementell. Diese Anleitung zeigt, wie Sie KeyHelp-Backups mit einem externen Ziel, passender Aufbewahrung und automatischem Zeitplan einrichten und den Restore bis zur kompletten Wiederherstellung auf einem neuen Server testen.

Warum die eingebaute Sicherung und was restic besser macht

Viele Admins schreiben für KeyHelp-Server eigene tar- oder rsync-Skripte. Das funktioniert, ignoriert aber die integrierte Lösung, die auf KeyHelp abgestimmt ist und restic nutzt. restic bringt drei Eigenschaften mit, die für Server-Backups entscheidend sind:

Inkrementell und dedupliziert: Nach dem ersten Vollbackup überträgt restic nur noch geänderte Datenblöcke. Das spart Speicher und macht tägliche Sicherungen schnell.
Verschlüsselt: restic verschlüsselt das Repository clientseitig. Auch beim Storage-Anbieter liegen Ihre Daten nicht im Klartext.
Snapshots: Jede Sicherung ist ein Snapshot, zu dem Sie gezielt zurückkehren können, etwa zum Stand von „vor drei Tagen“.

Sie verwalten alles im KeyHelp-Panel, können im Notfall aber auch direkt mit dem Befehl restic auf dasselbe Repository zugreifen, weil es ein Standard-Repository ist.

Was KeyHelp sichert

Eine KeyHelp-Sicherung umfasst die Bestandteile eines Hosting-Accounts:

die Webdaten der Domains (das komplette Verzeichnis des Benutzers),
die zugehörigen MySQL-/MariaDB-Datenbanken,
die E-Mail-Postfächer,
die Konto- und Konfigurationsdaten der Benutzer.

Sie können pro Benutzer oder für den ganzen Server sichern. Für den Wiederanlauf nach einem Totalausfall ist die serverweite Sicherung entscheidend.

Voraussetzungen

Eine laufende KeyHelp-Installation, Version 26.0 oder neuer (26.0 hat die zusätzlichen Rotationsoptionen eingeführt), siehe KeyHelp installieren und absichern.
Ein externer Speicher als Backup-Ziel, nicht derselbe Server: z. B. eine SFTP-fähige Storage Box (etwa bei Hetzner) oder ein rclone-Ziel (Cloud-Speicher).
Die Zugangsdaten für dieses Ziel (Host, Benutzer, Passwort oder SSH-Schlüssel) und Speicherplatz mindestens in Höhe der zu sichernden Daten plus Reserve für die Snapshot-Historie.
Root-Zugang per SSH für die Prüf- und Restore-Befehle mit restic.

Legen Sie das Backup-Ziel immer extern an. Ein Backup auf derselben Maschine geht bei Hardware-Ausfall, Verschlüsselungstrojaner oder versehentlichem Server-Reset zusammen mit dem Original verloren.

Schritt 1: Das richtige Backup-Ziel wählen

KeyHelp unterstützt mehrere Repository-Typen. Die Wahl bestimmt, wie gut Ihre Backups geschützt sind:

Ziel	Eignung	Hinweis
Lokal (gleicher Server)	nur als Zwischenspeicher	kein echter Schutz, fällt mit dem Server aus
SFTP (Storage Box)	Standard-Empfehlung für KMU	räumlich getrennt, einfach einzurichten
rclone-Ziel (Cloud)	für vorhandene Cloud-Speicher	flexibel, etwas mehr Konfiguration

Für die meisten Setups ist ein SFTP-Repository auf einer Storage Box die passende Wahl, weil es räumlich vom Server getrennt ist. Legen Sie beim Storage-Anbieter einen eigenen Unterordner und, wenn möglich, einen separaten Zugang nur für diesen Server an.

Verifizieren: Melden Sie sich vom KeyHelp-Server aus per sftp backupuser@u123456.your-storagebox.de am Ziel an und wechseln Sie mit cd keyhelp-backups in den Unterordner. Erwartetes Ergebnis: Anmeldung ohne Fehler, der Ordner ist leer.

Schritt 2: Das Backup-Repository in KeyHelp anlegen

Legen Sie im Backup-Bereich von KeyHelp ein neues Repository an und tragen Sie die Zugangsdaten des externen Ziels ein (Host, Pfad, Benutzer, Passwort bzw. SSH-Schlüssel). KeyHelp initialisiert das restic-Repository und vergibt ein Repository-Passwort. Bewahren Sie dieses Passwort getrennt vom Server auf (z. B. im Passwortmanager): Ohne es lässt sich nichts wiederherstellen.

Das Repository können Sie auch per Kommandozeile ansprechen, es ist ein normales restic-Repository:

# Snapshots im SFTP-Repository auflisten (Repository-Passwort aus KeyHelp)
export RESTIC_PASSWORD='ihr-repository-passwort'
restic -r sftp:backupuser@u123456.your-storagebox.de:/keyhelp-backups snapshots

Verifizieren: Der Befehl gibt eine Snapshot-Liste aus, bei einem frischen Repository eine leere Tabelle ohne Fehlermeldung. „wrong password or no key found“ bedeutet ein falsches Repository-Passwort.

Schritt 3: Aufbewahrung (Rotation) festlegen

Ohne Aufbewahrungsregeln wächst ein Repository unbegrenzt. Seit KeyHelp 26.0 steuern Sie genauer, wie viele der letzten täglichen, wöchentlichen, monatlichen und jährlichen Snapshots erhalten bleiben. Eine bewährte Ausgangsregel für KMU:

7 tägliche Snapshots,
4 wöchentliche,
6 monatliche,
optional 1–2 jährliche.

Damit haben Sie einen feinen Verlauf der letzten Woche und einen groben über Monate. KeyHelp räumt alte Snapshots nach diesen Regeln automatisch auf (restic forget und prune); laut Changelog läuft der Prune-Job seit 26.0 immer, sobald eine Rotation aktiv ist.

Verifizieren: Nach einigen Tagen Laufzeit zeigt restic -r … snapshots nicht mehr Snapshots, als die Regel zulässt (hier höchstens 7 tägliche plus die wöchentlichen und monatlichen Stände).

Schritt 4: Automatische Sicherung planen

Aktivieren Sie im Backup-Bereich einen automatischen Zeitplan, typischerweise eine tägliche Sicherung nachts bei geringer Last. Die erste Sicherung ist ein Vollbackup und dauert je nach Datenmenge deutlich länger; jede weitere ist dank Deduplizierung schnell. Planen Sie die Sicherung so, dass sie nicht mit anderen lastintensiven Jobs (große Importe, Updates) zusammenfällt, und aktivieren Sie die Benachrichtigung per E-Mail.

Verifizieren: Am Morgen nach dem ersten geplanten Lauf zeigt die Backup-Übersicht in KeyHelp einen erfolgreichen Lauf, und restic -r … snapshots listet einen neuen Snapshot mit dem Datum der Nacht.

Schritt 5: Restore testen: einzelne Dateien und ganze Accounts

Ein Backup ist erst dann eines, wenn Sie es zurückspielen können. Testen Sie beide Wege, bevor Sie sich darauf verlassen.

Einzelne Dateien brauchen Sie im Alltag am häufigsten (versehentlich gelöschte Datei, alte Version einer wp-config.php). Hängen Sie das Repository als Verzeichnis ein und kopieren Sie heraus, was Sie brauchen. restic mount läuft im Vordergrund; arbeiten Sie in einem zweiten Terminal:

mkdir -p /mnt/restic
restic -r sftp:backupuser@u123456.your-storagebox.de:/keyhelp-backups mount /mnt/restic
# Zweites Terminal: In /mnt/restic/snapshots/ liegen alle Stände als Ordner
# Datei heraussuchen und kopieren. Danach im ersten Terminal mit Strg+C aushängen.

Ganze Accounts stellen Sie über das KeyHelp-Panel wieder her: Snapshot auswählen, Benutzer bzw. Domain markieren und zurückspielen. Üben Sie das einmal mit einer Testdomain, damit Sie den Ablauf kennen, bevor es ernst wird.

Verifizieren: Die wiederhergestellte Datei ist mit dem erwarteten Inhalt im Zielverzeichnis vorhanden; die Testdomain liefert nach dem Account-Restore ihre Webseite aus, und die Datenbank ist in phpMyAdmin bzw. Adminer mit ihren Tabellen sichtbar.

Schritt 6: Komplette Wiederherstellung auf einem neuen Server

Im Ernstfall (Server defekt oder Umzug auf neue Hardware) gehen Sie so vor:

Den neuen Server mit einem sauberen System aufsetzen und KeyHelp frisch installieren.
Im Backup-Bereich das bestehende externe Repository einbinden, mit denselben Zugangsdaten und demselben Repository-Passwort wie zuvor. KeyHelp liest die vorhandenen Snapshots ein.
Den gewünschten Snapshot auswählen und die Wiederherstellung starten. KeyHelp legt Benutzer, Domains, Datenbanken und Postfächer wieder an.
DNS auf die neue Server-IP umstellen und die Funktion prüfen (Webseiten, Mail, SSL-Zertifikate neu ausstellen lassen).

Deshalb müssen Repository-Passwort und Backup-Ziel den Ausfall des Originalservers überstehen.

Verifizieren: Auf dem neuen Server sind alle Benutzer und Domains im Panel vorhanden, die Webseiten antworten nach der DNS-Umstellung mit gültigem Zertifikat, und ein Test-Postfach empfängt und sendet E-Mails.

Troubleshooting: häufige Backup-Fehler

Symptom	Ursache & Lösung
„config file already exists“ beim Anlegen	Im Zielpfad liegt bereits ein Repository. Anderen, leeren Unterordner verwenden oder das vorhandene Repository einbinden statt neu zu initialisieren.
Repository ist gesperrt / Restore hängt	Ein abgebrochener Lauf hat einen Lock hinterlassen. Mit `restic -r <repo> unlock` entsperren, dann erneut versuchen.
Verbindung zum SFTP-Ziel schlägt fehl	Host/Port/Pfad und SSH-Schlüssel prüfen; der Storage-Box-Zugang muss SFTP erlauben; Fingerprint einmal bestätigen.
Backup sehr langsam	Der Erstlauf ist immer ein Vollbackup. Bei dauerhaft langsamer Übertragung Verbindungslimit/Bandbreite des Ziels prüfen.
Wiederherstellung ohne Fortschritt	Großer Snapshot bzw. langsames Ziel: Bei großen Datenmengen dauert der Restore; vorab an einer kleinen Testdomain üben.

Fazit und Best Practices

Die restic-basierte Sicherung von KeyHelp deckt ab, was ein Hosting-Server braucht, wenn Sie sie richtig einrichten: externes Ziel, passende Aufbewahrung, automatischer Zeitplan und ein sicher verwahrtes Repository-Passwort. Machen Sie den Restore-Test zur Routine, etwa einmal pro Quartal, und halten Sie sich an die 3-2-1-Regel: drei Kopien, zwei Medien, eine außer Haus. Für zusätzlichen Schutz lagern Sie die Sicherung auf einen unveränderlichen (append-only) Speicher aus, den ein kompromittierter Server nicht löschen kann.

Weiterführend: restic-Grundlagen und Automatisierung per Cron, die 3-2-1-Backup-Strategie in der Praxis sowie für Ransomware-Schutz unveränderliche Backups mit restic und einer Hetzner Storage Box. Offizielle Quellen: KeyHelp-Dokumentation, KeyHelp-Changelog, restic-Dokumentation.