KeyHelp-Backups mit Rotationsstrategien: täglich, wöchentlich, monatlich in einem Repository

Bis KeyHelp 25.3 kannte das Backup-System für alte Snapshots im Wesentlichen eine Regel: die Anzahl. Wer eine Woche fein und ein halbes Jahr grob sichern wollte, brauchte dafür mehrere Repositorys und zahlte doppelt Speicher. Mit KeyHelp 26.0 vom April 2026 hat Keyweb Rotationsstrategien eingeführt: Sie legen in einem einzigen Repository fest, wie viele tägliche, wöchentliche, monatliche und jährliche Snapshots bleiben. Diese Anleitung richtet sich an Administratoren kleiner Hosting-Server, Agenturen und KMU, die KeyHelp nach unserer Anleitung KeyHelp installieren und absichern betreiben. Sie zeigt, wie die Rotation in der Oberfläche heißt, welchen restic-Befehl KeyHelp daraus macht, wie sie sich mit echten Daten verhält und wo die Fallen liegen. Externe Ziele und den Restore behandelt unsere Anleitung KeyHelp-Backups richtig einrichten; die Inhalte wiederholen wir hier nicht.

Voraussetzungen

• KeyHelp ab 26.0, denn erst diese Version bringt die Rotation nach Zeitraum. Getestet haben wir 26.1.1 (Build 3698) auf Debian 12 mit restic 0.19.1.
• Ein Backup-Repository, am besten extern (SFTP, WebDAV, FTP(S), Dropbox, KeyDisc oder eine eigene rclone-Konfiguration unter „Benutzerdefiniert“). Für den Test genügt ein lokales.
• Das Repository-Passwort außerhalb des Servers, etwa im Passwortmanager. KeyHelp warnt selbst: Ohne Passwort gibt es keinen Zugriff mehr.
• Root per SSH für die Kontrolle mit restic, das KeyHelp unter /usr/local/bin/restic mitbringt.

Schritt 1: Die Rotation im Repository einstellen

Öffnen Sie „Backup“ → „Repository-Verwaltung“ und bearbeiten Sie ein Repository oder legen Sie mit „Repository hinzufügen“ ein neues an. Unter „Snapshot-Rotation“ erklärt KeyHelp: „Bei jedem Backup-Lauf wird ein Abbild Ihrer Daten (Snapshot) erstellt, was mit der Zeit viel Speicherplatz beanspruchen kann.“ Drei Modi stehen zur Wahl:

Modus	Felder	restic-Aufruf im Test
Deaktiviert	keine	Snapshots bleiben unbegrenzt
Nach Anzahl	„Maximale Anzahl von Snapshots“	forget --prune --keep-last 5
Nach Zeitraum	„Anzahl täglicher/wöchentlicher/monatlicher/jährlicher Snapshots“, jeweils einzeln aktivierbar	forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-yearly 1

Bei neuen Repositorys steht der Modus auf „Deaktiviert“. Wählen Sie „Nach Zeitraum“ und setzen Sie die Häkchen für jeden Zeitraum, den Sie aufbewahren wollen. Als Ausgangspunkt für KMU haben wir 7 täglich, 4 wöchentlich, 6 monatlich und 1 jährlich getestet. KeyHelp speichert das als Regel im eigenen Datenbankfeld rotation_policy:

by_time	{"keep_daily":7,"keep_weekly":4,"keep_monthly":6,"keep_yearly":1}

Kunden sehen dieselben drei Modi in ihrem eigenen Backup-Bereich, wenn Sie ihnen Repositorys erlauben (siehe Schritt 5).

Verifizieren: Die Repository-Übersicht zeigt in der Spalte „Snapshots“ den Ist-Stand und die Obergrenze. Direkt nach dem Anlegen mit 7/4/6/1 stand dort 0 / 18, also die Summe aller Zeiträume.

Schritt 2: Das erste Backup und den Ablauf verstehen

Starten Sie unter „Backup“ → „Backup erstellen“ eine Sicherung mit „Backup-Umfang“ „Vollständig“. Das umfasst laut Formular das Control Panel mit seinen Datenbanken, die Systemkonfiguration (/etc/, /root/, /var/spool/cron/) und alle Kundenkonten mit E-Mails, Datenbanken und Home-Verzeichnissen. Den Ablauf protokolliert KeyHelp unter /var/log/keyhelp/backup/backup-root.log:

INFO | Operation found: prune
INFO | Remove old snapshots
INFO | Operation found: backup
INFO | Backup created
INFO | Operation found: check
INFO | Integrity check
INFO | Operation found: prune
INFO | Remove old snapshots
INFO | Operation found: check
INFO | All finished, releasing lock.

Die Rotation läuft also nicht separat nachts, sondern an jedem Backup-Lauf zweimal: vor und nach der Sicherung, jeweils gefolgt von einer Integritätsprüfung (restic check). Der Vorgang startet nicht sofort; im Test lief er rund eine Minute nach dem Klick an, das gesamte Backup unseres kleinen Testservers dauerte etwa 30 Sekunden.

Verifizieren: Mit dem Repository-Passwort listet restic den Snapshot samt Beschreibung als Tag:

export RESTIC_PASSWORD='IHR-REPOSITORY-PASSWORT'
restic -r /backup/IHR-REPOSITORY snapshots

ID        Time                 Host            Tags               Paths            Size
e4b444b8  2026-10-01 08:24:09  kh.example.com  erstes-vollbackup  /etc             152.535 MiB
                                                                  /home/keyhelp
                                                                  /home/users/testkunde ...
1 snapshots

Bei einem SFTP- oder anderen Remote-Ziel spricht KeyHelp das Repository über rclone an (im Test: --repo rclone:rclone-storage:/backup/...); dann brauchen Sie für den direkten Zugriff die passende rclone-Konfiguration, siehe Anleitung zur externen Sicherung.

Schritt 3: Die Rotation mit echten Snapshots prüfen

Ob eine Aufbewahrungsregel tut, was sie soll, sehen Sie normalerweise erst nach Monaten. Wir haben deshalb mit restic backup --time 91 ältere Snapshots über 400 Tage zurückdatiert in das Testrepository geschrieben (täglich für 40 Tage, danach wöchentlich) und dann ein normales Backup über KeyHelp gestartet. Machen Sie das nur in einem Testrepository, nie im produktiven.

Ergebnis mit 7/4/6/1: Von 93 Snapshots blieben 13 übrig.

60a6702b  2026-05-28 03:00:00  simuliert       (monatlich)
48dbc125  2026-06-25 03:00:00  simuliert       (monatlich)
8eeba5b5  2026-07-30 03:00:00  simuliert       (monatlich)
dee23f24  2026-08-31 03:00:00  simuliert       (monatlich)
f7a2c6f7  2026-09-13 03:00:00  simuliert       (wöchentlich)
4b68f89d  2026-09-20 03:00:00  simuliert       (wöchentlich)
b718aabd  2026-09-25 03:00:00  simuliert       (täglich)
...
f9c7afc8  2026-09-30 03:00:00  simuliert       (täglich)
be301f7d  2026-10-01 08:31:03  zweites-backup  (täglich)
13 snapshots

Drei Dinge zeigt das Ergebnis, und sie sind wichtig für Ihre Planung:

• Die Regeln überlappen. Der neueste Snapshot einer Woche oder eines Monats zählt oft schon als täglicher. Deshalb blieben nicht 18, sondern 13 Snapshots. Die Anzeige „/ 18“ ist eine Obergrenze, kein Zielwert.
• Pro Tag bleibt nur der neueste. Unser erstes Vollbackup vom selben Vormittag verschwand, weil am selben Tag ein zweites lief. Wer mehrmals täglich sichert, behält bei „täglich“ trotzdem nur einen Stand pro Tag.
• Der jährliche Snapshot war hier schon durch den neuesten abgedeckt. Ein separater Jahresstand entsteht erst, wenn ein Jahreswechsel in der Historie liegt.

Verifizieren: Zählen Sie nach einem Lauf die Snapshots und vergleichen Sie mit Ihrer Regel:

restic -r /backup/IHR-REPOSITORY snapshots --compact | tail -1

13 snapshots

Schritt 4: Die Falle bei gemischten Sicherungen

KeyHelp ruft forget mit leerem --group-by auf. Laut restic-Dokumentation werden Snapshots dann nicht nach Host oder Pfaden getrennt, sondern gemeinsam rotiert. Im Test zeigte sich das deutlich: Unsere simulierten Snapshots enthielten nur eine einzige Datei, zählten für die Rotation aber genauso wie die Vollbackups. Die Tagesplätze der Woche belegten sie, nicht die vollständigen Sicherungen.

Für die Praxis heißt das: Sichern Sie in ein Repository mit Zeitraum-Rotation nur gleichartige Backups. Läuft nachts ein vollständiges Backup und mittags eine benutzerdefinierte Sicherung nur der Datenbanken in dasselbe Repository, ersetzt die Mittagssicherung als „neuester des Tages“ das Vollbackup. Legen Sie für abweichende Umfänge ein zweites Repository an.

Verifizieren: Prüfen Sie, welche Pfade die aufbewahrten Snapshots enthalten. Alle Tages-Snapshots sollten dieselbe Pfadliste zeigen:

restic -r /backup/IHR-REPOSITORY snapshots --json | python3 -c 'import json,sys;[print(s["time"][:10],len(s["paths"])) for s in json.load(sys.stdin)]'

Schritt 5: Zeitplan, Benachrichtigung und Kundenrepositorys

Die Rotation greift nur, wenn Backups laufen. Unter „Backup“ → „Regelmäßige Backups planen“ → „Backup-Zeitplan hinzufügen“ wählen Sie „Intervall wählen“ („Stündlich“, „Täglich“, „Wöchentlich“, „Monatlich“) und die Uhrzeit. KeyHelp weist auf die Zeitzone des Servers hin, im Test Etc/UTC; 02:30 Uhr dort ist im Sommer 04:30 Uhr in Deutschland. Tragen Sie unter „E-Mail-Adresse für Benachrichtigungen“ eine gelesene Adresse ein. Die Mail im Test hatte den Betreff „[ERFOLG] Backup auf Server kh.example.com“; seit 25.1 meldet KeyHelp laut Keyweb auch fehlgeschlagene Bereinigungen per E-Mail.

Stündliche Backups sind mit „täglich 7“ wenig sinnvoll, denn pro Tag bleibt nur der letzte. Wer Stundenstände behalten will, nutzt ein eigenes Repository mit „Nach Anzahl“, etwa 24.

Ob Kunden eigene lokale Repositorys anlegen dürfen, steuern Sie unter „Konfiguration“ → „Backup“ mit „Lokale Repositorys für Benutzerkonten aktivieren“. Deren Speicher wird vom Kontingent des Kunden abgezogen. Dort finden Sie auch „CPU-Kern-Limit“ für Backup-Prozesse.

Verifizieren: Die Zeitplan-Übersicht zeigt den Eintrag:

Backup erstellen | Aktiviert | Täglich ( 02:30 Uhr ) | lokal-rotation (Lokal) | nachts | —

Am Morgen nach dem ersten Lauf steht unter „Letzter Lauf“ ein Datum.

Schritt 6: Rotation umstellen

Sie können den Modus jederzeit ändern. Wir haben das Testrepository von „Nach Zeitraum“ auf „Nach Anzahl“ mit 5 umgestellt. Beim nächsten Backup lief forget --prune --keep-last 5, und von 13 Snapshots blieben die neuesten 5; die Monats- und Wochenstände waren damit unwiderruflich gelöscht. Das ist keine Fehlfunktion, sondern die neue Regel. Prüfen Sie vor dem Umstellen, ob Sie alte Stände noch brauchen, und sichern Sie diese bei Bedarf in ein anderes Repository.

Verifizieren:

by_count	{"keep_last":5}
5 snapshots

Typische Fehler

Repository wächst trotz Rotation

Prüfen Sie, ob der Modus wirklich gesetzt ist. Bei „Nach Zeitraum“ zählen nur Zeiträume mit Häkchen; ohne Häkchen lässt KeyHelp den Wert weg.

„repository is already locked“

Ein abgebrochener Lauf hat die Sperre hinterlassen. Unter „Backup“ → „Problembehandlung“ gibt es dafür „Repository entsperren“, außerdem „Ausstehende Operationen löschen“ und „Index reparieren“. KeyHelp mahnt, das Entsperren nur zu nutzen, wenn keine Operation mehr läuft.

Erstes Backup des Tages fehlt

Kein Fehler: Bei Rotation nach Zeitraum bleibt pro Tag nur der neueste Snapshot (Schritt 3).

Häufige Fragen

Spart die Rotation wirklich Speicher?

restic speichert unveränderte Daten nur einmal. Im Test belegten drei vollständige Sicherungen mit je rund 153 MiB zusammen 64 MB auf der Platte. Gelöschte Snapshots geben nur Daten frei, die kein anderer Snapshot mehr braucht.

Gilt die Rotation auch für Kundenrepositorys?

Ja, Kunden sehen in ihrem Backup-Bereich dieselben drei Modi. Die Regeln gelten pro Repository.

Wie stelle ich einen alten Stand wieder her?

Über „Backup wiederherstellen“ oder direkt mit restic. Das beschreibt Schritt 5 und 6 unserer Anleitung zur externen Sicherung und zum Restore.

Testumfang

Wir haben in KeyHelp 26.1.1 auf Debian 12 ein lokales Repository mit beiden Rotationsmodi, 91 zurückdatierten Snapshots, Zeitplan und Benachrichtigung geprüft und die restic-Aufrufe mitgeschnitten. Auffällig war, dass Teil- und Vollsicherungen gemeinsam rotiert werden. Nicht geprüft haben wir externe Ziele, einen echten Monatswechsel im Zeitplan und Kundenrepositorys im Betrieb. Kontrollieren Sie nach einigen Wochen die Snapshot-Liste Ihres Repositorys.

Fazit

Die Rotation nach Zeitraum ist die wichtigste Backup-Neuerung von KeyHelp 26: ein Repository, feine Stände für die letzte Woche und grobe für Monate, ohne Speicher doppelt zu belegen. Sie verhält sich exakt wie restic forget, mit allen Eigenheiten. Halten Sie Repositorys sortenrein, rechnen Sie mit einem Stand pro Tag und prüfen Sie nach Umstellungen die Snapshot-Liste. Für die 3-2-1-Regel dahinter lohnt ein Blick in unsere Anleitung zur 3-2-1-Backup-Strategie.

Weiterführende Anleitungen und Quellen

• KeyHelp-Backups richtig einrichten: externe Sicherung, Rotation und getesteter Restore
• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• Keyweb: KeyHelp 26.0 mit neuen Backup-Rotationsstrategien
• Keyweb: KeyHelp 25.1 mit neuen Backup-Funktionen
• restic-Dokumentation: Snapshots entfernen (forget und prune)