Ein Hosting-Panel ist schnell installiert – der wahre Test kommt erst, wenn ein Server ausfällt, eine Datenbank zerschossen ist oder ein Kunde versehentlich sein halbes Webverzeichnis gelöscht hat. Genau dann entscheidet sich, ob deine Sicherung mehr ist als ein gutes Gefühl. KeyHelp bringt dafür eine vollwertige Backup-Funktion mit, die unter der Haube auf restic setzt: verschlüsselt, dedupliziert und inkrementell. Diese Anleitung zeigt, wie du KeyHelp-Backups richtig einrichtest – mit einem externen Ziel, sinnvoller Aufbewahrung, automatischem Zeitplan und, am wichtigsten, einem getesteten Restore bis hin zur kompletten Wiederherstellung auf einem neuen Server.

Kurzfassung: KeyHelp sichert Webdaten, Datenbanken, Mails und Konteneinstellungen über restic. Lege ein externes Repository an (SFTP, z. B. eine Storage Box, oder ein rclone-Ziel), definiere die Aufbewahrung (täglich/wöchentlich/monatlich) und einen automatischen Zeitplan. Entscheidend ist der Restore-Test: einzelne Dateien per restic mount, ganze Accounts über das Panel und im Ernstfall die komplette Wiederherstellung auf einer frischen KeyHelp-Installation. Ein ungetestetes Backup ist kein Backup.

Warum die eingebaute Sicherung – und was restic besser macht

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

Inkrementell und dedupliziert: Nach dem ersten Vollbackup werden nur noch geänderte Datenblöcke übertragen. Das spart Speicher und macht tägliche Sicherungen schnell.
Verschlüsselt: Das Repository ist Ende-zu-Ende verschlüsselt. Selbst auf einem fremden Storage-Anbieter liegen deine Daten nicht im Klartext.
Snapshots: Jede Sicherung ist ein Snapshot, auf den du gezielt zurückgehen kannst – ideal, um einen Stand von „vor drei Tagen“ wiederherzustellen.

Der praktische Vorteil: Du verwaltest das alles im KeyHelp-Panel, kannst im Notfall aber auch direkt mit dem restic-Kommando an dasselbe Repository, weil es ein Standard-Format ist.

Was KeyHelp sichert

Eine KeyHelp-Sicherung umfasst die Bestandteile, die einen Hosting-Account ausmachen:

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

Du kannst Sicherungen pro Benutzer oder für den ganzen Server fahren. Für den Wiederanlauf nach einem Totalausfall ist die serverweite Sicherung der entscheidende Baustein.

Voraussetzungen

Eine laufende KeyHelp-Installation (Version 26 bringt die erweiterten Aufbewahrungs-/Rotationsstrategien mit).
Ein externer Speicher als Backup-Ziel – nicht derselbe Server. Bewährt im DACH-Raum: eine SFTP-fähige Storage Box (z. B. bei Hetzner) oder Netcup-Speicher; alternativ ein rclone-Ziel (Cloud-Speicher).
Die Zugangsdaten für dieses Ziel (Host, Benutzer, Passwort oder SSH-Key) und ausreichend Speicherplatz.

Lege das Backup-Ziel immer extern an. Ein Backup, das auf derselben Maschine liegt wie die Originaldaten, ist bei Hardware-Ausfall, Verschlüsselungs-Trojaner oder versehentlichem Server-Reset genauso weg wie das Original.

Schritt 1: Das richtige Backup-Ziel wählen

KeyHelp unterstützt mehrere Repository-Typen. Die Wahl bestimmt, wie sicher und wie schnell deine Backups 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	günstig, offsite, schnell; ideal Hetzner/Netcup
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 beste Wahl: räumlich getrennt vom Server, kostengünstig und ohne Traffic-Limit. Lege beim Storage-Anbieter zunächst einen eigenen Unterordner und – wenn möglich – einen separaten Zugang nur für diesen Server an.

Schritt 2: Das Backup-Repository in KeyHelp anlegen

Im KeyHelp-Backup-Bereich legst du ein neues Repository an und trägst die Zugangsdaten des externen Ziels ein (Host, Pfad, Benutzer, Passwort bzw. SSH-Key). KeyHelp initialisiert daraufhin das restic-Repository und vergibt ein Repository-Passwort – notiere dieses Passwort sicher, denn ohne es lässt sich später nichts wiederherstellen.

Wer den Zustand lieber direkt prüfen möchte, kann das Repository auch per Kommandozeile ansprechen – es ist ein normales restic-Repository:

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

Erscheint eine Liste mit Snapshots (oder bei einem frischen Repository eine leere, aber gültige Ausgabe), steht die Verbindung.

Schritt 3: Aufbewahrung (Rotation) festlegen

Ohne Aufbewahrungsregeln wächst ein Repository endlos. Seit KeyHelp 26 steuerst du getrennt, wie viele der jeweils 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 hast du einen feinen Verlauf der letzten Woche und einen groben über Monate, ohne dass der Speicher explodiert. KeyHelp räumt alte Snapshots nach diesen Regeln automatisch auf (restic forget plus prune im Hintergrund).

Schritt 4: Automatische Sicherung planen

Aktiviere im Backup-Bereich einen automatischen Zeitplan – typischerweise eine tägliche Sicherung nachts, wenn wenig Last anliegt. Wichtig sind zwei Dinge: Die erste Sicherung ist ein Vollbackup und dauert je nach Datenmenge deutlich länger; jede weitere ist dank Deduplizierung schnell. Und: Plane die Sicherung so, dass sie nicht mit anderen ressourcenhungrigen Jobs (große Imports, Updates) kollidiert.

Schritt 5: Restore testen – einzelne Dateien und ganze Accounts

Ein Backup ist erst dann eines, wenn du es zurückspielen kannst. Teste beide Wege, bevor du dich darauf verlässt:

Einzelne Dateien brauchst du im Alltag am häufigsten (versehentlich gelöschte Datei, alte Version einer wp-config.php). Am elegantesten geht das, indem du das Repository als Verzeichnis einhängst und einfach herauskopierst, was du brauchst:

mkdir -p /mnt/restic
restic -r sftp:backupuser@u123456.your-storagebox.de:/keyhelp-backups mount /mnt/restic
# In /mnt/restic/snapshots/ liegen alle Stände als durchsuchbare Ordner
# Datei heraussuchen, kopieren, danach aushängen:
umount /mnt/restic

Ganze Accounts stellst du über das KeyHelp-Panel wieder her: Snapshot auswählen, Benutzer/Domain markieren und zurückspielen. Mach das einmal bewusst mit einer Testdomain, damit du den Ablauf kennst, bevor es ernst wird.

Schritt 6: Komplette Wiederherstellung auf einem neuen Server

Der eigentliche Ernstfall – Server defekt oder Umzug auf neue Hardware – läuft so ab:

Den neuen Server mit einem sauberen System aufsetzen und KeyHelp frisch installieren (siehe die Installations-Anleitung).
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.
Anschließend DNS auf die neue Server-IP umstellen und die Funktion prüfen (Webseiten, Mail, SSL-Zertifikate neu ausstellen lassen).

Genau dieser Ablauf ist der Grund, warum das Repository-Passwort so wichtig ist und warum das Ziel extern liegen muss: Beides muss den Ausfall des Originalservers überleben.

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-Key prüfen; Storage-Box-Zugang muss SFTP erlauben; Fingerprint einmal bestätigen.
Backup sehr langsam	Erstlauf ist immer ein Vollbackup. Bei dauerhaft langsamer Übertragung Verbindungslimit/Bandbreite des Ziels prüfen.
Wiederherstellung ohne Fortschritt	Großer Snapshot bzw. langsames Ziel – Geduld bei großen Datenmengen; vorab an einer kleinen Testdomain üben.

Fazit und Best Practices

KeyHelp liefert mit seiner restic-basierten Sicherung alles, was ein Hosting-Server braucht – vorausgesetzt, du richtest sie richtig ein: externes Ziel, sinnvolle Aufbewahrung, ein automatischer Zeitplan und ein sicher verwahrtes Repository-Passwort. Mach den Restore-Test zur festen Routine – am besten quartalsweise einmal eine Testwiederherstellung – und halte dich an die 3-2-1-Regel: drei Kopien, zwei Medien, eine außer Haus. Wer es noch sicherer will, lagert die Sicherung zusätzlich auf einen unveränderlichen (append-only) Speicher aus, den ein kompromittierter Server nicht löschen kann.

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