KeyHelp: Kunden eigene Backups und Wiederherstellungen erlauben
So erlauben Sie Kunden in KeyHelp eigene Backups, lassen sie ein Repository anlegen und gelöschte Dateien oder Datenbanken selbst wiederherstellen, mit den Fallen aus unserem Test.
Geprüft am 01.10.2026 · für KeyHelp 26.1.1
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu
Ein Kunde löscht versehentlich eine Datei oder leert eine Tabelle, und das Support-Ticket landet bei Ihnen. KeyHelp kann Kunden die Sicherung und Wiederherstellung selbst überlassen: Jedes Kundenkonto hat einen eigenen Backup-Bereich, der auf restic aufsetzt. Diese Anleitung zeigt, welche zwei Schalter der Administrator dafür setzt, wie der Kunde ein Repository anlegt, ein Backup erstellt und eine einzelne Datei und eine Datenbank zurückholt, und welche Fallen wir dabei gefunden haben. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Die Server-Sicherung als Administrator beschreibt KeyHelp-Backups extern einrichten, die Rotation alter Stände Backup-Rotation in KeyHelp. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.
Voraussetzungen
- Ein KeyHelp-Server, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15.
- Ein Kundenkonto, im Beispiel kunde1 mit der Domain kunde1.example.de, einem Postfach und der Datenbank kunde1_db.
- Administratorzugang zum Panel. Für die Prüfung auf dem Server zusätzlich SSH als root.
Schritt 1: Berechtigung für den Kunden setzen
Öffnen Sie „Benutzerverwaltung“, beim Kunden das Bearbeiten-Symbol und den Reiter „Berechtigungen“. Dort steht zwischen „SSH“ und „Datei-Manager“ der Haken „Backup-Verwaltung“. In unserem Grundzustand war er beim Testkunden bereits gesetzt.
Entfernt man den Haken, meldet KeyHelp nach „Speichern“ „Der Benutzer kunde1 wurde aktualisiert.“ Beim Kunden fehlt dann der Menüpunkt „Backup“. Auch der direkte Aufruf der Wiederherstellungsseite über die Adresse ?page=backup_restore&action=select landete im Test auf dem Kunden-Dashboard.
Verifizieren: Melden Sie sich als Kunde an, zum Beispiel als root mit keyhelp login kunde1. Unter „Einstellungen“ erscheint „Backup“ nur mit gesetzter Berechtigung.
Schritt 2: Lokale Kunden-Repositorys erlauben
Der zweite Schalter liegt unter „Konfiguration“ > „Backup“: „Lokale Repositorys für Benutzerkonten aktivieren“, im Grundzustand aktiviert. KeyHelp erklärt dazu: „Die lokalen Repositorys der Kunden befinden sich im Home-Verzeichnis des jeweiligen Kunden. Der für ein Repository benötigte Speicherplatz wird vom gesamten dem Kunden zugewiesenen Speicherplatz abgezogen.“ und „Wenn deaktiviert, können Kunden keine lokalen Repositorys einrichten. Administratorkonten sind von dieser Einstellung nicht betroffen.“
Ohne diesen Schalter bietet KeyHelp dem Kunden als „Speicher-Typ“ nur noch „FTP(S)“, „SFTP“, „WebDAV“, „KeyDisc“, „Dropbox“ und „Benutzerdefiniert“ an. Ein lokales Repository liegt auf demselben Server und hilft bei versehentlich gelöschten Daten, nicht bei einem Serverausfall. Für den Ernstfall bleibt Ihre eigene Server-Sicherung nötig.
Verifizieren: Im Formular „Repository hinzufügen“ des Kunden muss bei „Speicher-Typ“ der Eintrag „Lokal“ erscheinen.
Schritt 3: Repository als Kunde anlegen
Der Kunde öffnet „Einstellungen“ > „Backup“. Die Seite hat die Bereiche „Backup erstellen“, „Backup wiederherstellen“, „Repository-Verwaltung“ und „Problembehandlung“. Zuerst braucht er unter „Repository-Verwaltung“ > „Repository hinzufügen“ ein Ziel. Pflichtfelder sind „Name“ und „Passwort“ samt „Passwort bestätigen“, „Generieren“ schlägt ein Passwort vor. Beim Speicher-Typ „Lokal“ ist das „Verzeichnis“ laut Formular „Ein Pfad innerhalb des /files/ Ordners in Ihrem Home-Verzeichnis“. Im Test lag das Repository unter /backup/repository-3q5ht/. Die „Snapshot-Rotation“ steht auf „Deaktiviert“, die Alternativen erklärt die Anleitung zur Rotation.
Das Passwort verschlüsselt das Repository. KeyHelp weist darauf hin, es sicher aufzubewahren, „da Sie sonst möglicherweise nicht mehr auf das Repository zugreifen können“. Im Test brauchten wir es, um ein Repository erneut einzubinden (siehe Typische Fehler).
Verifizieren: Nach „Speichern“ meldet KeyHelp „Das Backup-Repository Kunden-Backup lokal wurde hinzugefügt.“ Auf dem Server liegt danach ein restic-Repository im Home-Verzeichnis des Kunden:
ls /home/users/kunde1/files/backup/*/config
data
index
keys
locks
snapshotsSchritt 4: Backup erstellen
Unter „Backup erstellen“ wählt der Kunde den „Backup-Umfang“. „Vollständig“ „Erstellt ein Backup Ihres Home-Verzeichnisses, Ihrer Datenbanken und E-Mails.“ Ausgenommen sind laut Formular /tmp/ und das lokale Backup-Verzeichnis /files/backup/. Alternativ gibt es „Benutzerdefiniert“. Dazu kommen „Repository“, eine „Beschreibung“ und eine „E-Mail-Adresse für Benachrichtigungen“. Wiederkehrende Sicherungen plant der Kunde unter „Regelmäßige Backups planen“.
Für den Test haben wir vorher die Datei www/wichtig.txt und in kunde1_db eine Tabelle kontakte mit zwei Zeilen angelegt. Nach „Speichern“ zeigt KeyHelp „Backup-Vorgang erstellt.“ Der Vorgang lief nicht sofort, sondern laut Log zu Beginn der folgenden Minute. KeyHelp protokolliert ihn in /var/log/keyhelp/backup/backup-kunde1.log:
[2026-10-01 20:48:02] INFO | Operation found: backup
[2026-10-01 20:48:02] INFO | Prepare backup...
[2026-10-01 20:48:07] INFO | Backup created
[2026-10-01 20:48:14] INFO | Size 'raw': 37.24 KiB
[2026-10-01 20:48:14] INFO | Size 'restore': 178.62 KiB
[2026-10-01 20:48:15] INFO | All finished, releasing lock.Verifizieren: Mit dem Repository-Passwort (hier in der Datei /root/.repopw) lässt sich der Inhalt als root direkt mit restic ansehen. Die Datenbank liegt als SQL-Dump, das Postfach als Archiv im Snapshot:
export RESTIC_PASSWORD_FILE=/root/.repopw
restic -r /home/users/kunde1/files/backup/repository-3q5ht ls latest/__databases__/kunde1_db.sql
/__email_accounts__/info@kunde1.example.de.tar.gz
/home/users/kunde1/www/index.html
/home/users/kunde1/www/wichtig.txtSchritt 5: Datei und Datenbank wiederherstellen
Nun der Ernstfall: Wir haben wichtig.txt gelöscht und in der Tabelle die Zeile mit Erika Musterfrau entfernt. Der Kunde öffnet „Backup wiederherstellen“. Unter „Repository wählen“ listet KeyHelp die Snapshots mit „Erstellt am“, „Beschreibung“ und „Größe nach Wiederherstellung“, im Test „01. Okt. 2026, 20:48:02“ mit unserer Beschreibung und „178,62 KiB“. Ein Klick auf das Datum öffnet die Auswahl.
Die Seite gliedert sich in „E-Mail-Konten“, „Datenbanken“ und „Dateien und Verzeichnisse“. Für eine einzelne Datei setzen Sie „Wiederherstellen einer einzelnen Datei oder eines Unterverzeichnisses“ und tragen den Pfad relativ zum Home-Verzeichnis ein, hier www/wichtig.txt. Unter „Wiederherstellungsort“ stehen „Ursprünglicher Pfad“ und „Alternativer Pfad“ zur Wahl.
Nach „Speichern“ meldet KeyHelp „Backup-Wiederherstellungsvorgang erstellt.“ Im Log folgt kurz darauf:
[2026-10-01 20:51:02] INFO | Operation found: restore
[2026-10-01 20:51:02] INFO | Restore databases...
[2026-10-01 20:51:07] INFO | Import database: kunde1_db
[2026-10-01 20:51:07] INFO | Restore paths...
[2026-10-01 20:51:13] INFO | All finished, releasing lock.Verifizieren: Datei und Datenzeile sind zurück:
cat /home/users/kunde1/www/wichtig.txt; mysql kunde1_db -e "select * from kontakte"Wichtige Kundendaten Stand 1
id name
1 Erika Musterfrau
2 Max MustermannTypische Fehler
Neuere Daten in der Datenbank sind nach dem Restore weg
Die Datenbank wurde im Test nicht ergänzt, sondern aus dem Dump neu eingespielt („Import database: kunde1_db“ im Log). Im Test haben wir nach dem Backup die Zeile „Neu nach Backup“ eingefügt und danach die Datenbank erneut wiederhergestellt. Anschließend enthielt kontakte wieder nur die zwei Zeilen aus dem Backup. Wer nur einzelne Daten zurückholen will, setzt „Wiederherstellen von Datenbanken als .sql Datei“. Dann legt KeyHelp laut Formular einen Dump an einem anderen Ort ab, statt die Datenbank zu überschreiben. Diesen Weg haben wir nicht getestet.
„Das von Ihnen eingegebene Passwort stimmt nicht mit der Passwortbestätigung überein.“
Diese Meldung zeigt „Repository hinzufügen“, wenn die beiden Passwortfelder abweichen. Übernehmen Sie einen generierten Vorschlag in beide Felder.
Repository nach Abschalten der lokalen Repositorys verschwunden
Als wir „Lokale Repositorys für Benutzerkonten aktivieren“ abgeschaltet haben, war das Repository des Kunden aus seiner „Repository-Verwaltung“ verschwunden („- Keine Einträge vorhanden -“), auch der Eintrag in der KeyHelp-Datenbank war gelöscht. Die Seite „Backup erstellen“ meldete „Sie müssen zunächst mindestens ein Repository einrichten, bevor Sie diese Funktion nutzen können.“ Die Dateien blieben aber im Home-Verzeichnis liegen, die Belegung des Ordners lag bei 92K, und restic meldete weiterhin „1 snapshots“. Nach dem Wiedereinschalten blieb die Liste leer. Erst als der Kunde ein Repository mit demselben Pfad /backup/repository-3q5ht/ und dem alten Passwort neu anlegte, erkannte KeyHelp den alten Snapshot wieder („Size 'restore': 178.62 KiB“ im Log). Ohne das Passwort haben wir das nicht versucht. Laut KeyHelp-Hinweis ist der Zugriff dann möglicherweise nicht mehr möglich.
Anleitung der Wissensdatenbank passt nicht zum Formular
Der Artikel „Backup erstellen“ im Benutzer-Bereich der KeyHelp-Wissensdatenbank wurde zuletzt im März 2018 aktualisiert. Er nennt im Formular die Felder „Backup Inhalt“, „Ziel Repository“ und einen „Passwortschutz“ direkt beim Backup. In KeyHelp 26.1.1 heißt das Feld „Backup-Umfang“ mit „Vollständig“ und „Benutzerdefiniert“, das Ziel „Repository“, und ein Passwort gibt es im Backup-Formular nicht mehr. Es wird beim Anlegen des Repositorys vergeben. Richten Sie sich nach dem Formular, nicht nach dem alten Artikel.
Häufige Fragen
Zählen Kunden-Backups zum Speicherplatz des Kunden?
Laut Hinweis unter „Konfiguration“ > „Backup“ ja, der Platz wird vom zugewiesenen Speicher abgezogen. Wie sich ein volles Kontingent auf laufende Backups auswirkt, haben wir nicht getestet.
Werden Backups im Backup mitgesichert?
Nein. Das lokale Backup-Verzeichnis /files/backup/ ist laut Formular bei „Vollständig“ ausgenommen.
Kann der Kunde das ganze Konto zurücksetzen?
Das Formular erlaubt E-Mail-Konten, Datenbanken und das gesamte Home-Verzeichnis. Laut Hinweis müssen die Elemente aber vorhanden sein: „Nicht vorhandene Elemente müssen zunächst erstellt werden, bevor ihr Inhalt wiederhergestellt werden kann.“ Eine gelöschte Datenbank muss der Kunde also erst neu anlegen. Komplette Konten haben wir nicht wiederhergestellt.
Wie lange dauert ein Kunden-Backup?
Bei unserem kleinen Testkonto mit 178,62 KiB lagen zwischen „Operation found: backup“ und „All finished“ 13 Sekunden, der Restore dauerte 11 Sekunden. Für große Webspaces sagt das nichts aus. Beide Vorgänge begannen im Test laut Log erst zur nächsten vollen Minute, nicht sofort nach dem Klick.
Testumfang
Wir haben Berechtigung, lokales Kunden-Repository, ein vollständiges Backup und die Wiederherstellung einer Datei und einer Datenbank mit KeyHelp 26.1.1 durchgespielt. Auffällig: Abschalten der lokalen Repositorys entfernt das Repository aus dem Panel, die Daten bleiben liegen. Externe Speicherziele, geplante Backups, Postfach-Restore und die SQL-Datei-Option haben wir nicht geprüft. Testen Sie einen Restore, bevor Kunden ihn brauchen.
Fazit
Mit „Backup-Verwaltung“ und lokalen Repositorys holen Kunden versehentlich gelöschte Dateien selbst zurück, ohne Ticket. Weisen Sie Ihre Kunden auf zwei Dinge hin: Das Repository-Passwort gehört in einen Passwortmanager, und beim Restore wird die Datenbank auf den Stand des Backups zurückgesetzt, im Test gingen neuere Einträge verloren. Ein lokales Kunden-Repository ersetzt nicht Ihre externe Server-Sicherung, es ergänzt sie.
