Es gibt keine richtige Häufigkeit, nur eine Folge. Der Abstand zwischen zwei Sicherungen ist genau die Menge Arbeit, die Sie im schlimmsten Fall verlieren. Legen Sie fest, wie groß diese Zahl sein darf, und der Zeitplan ergibt sich daraus.

Stellen Sie die Frage laut

Wenn jetzt alles verschwände und die letzte Kopie von gestern Nacht wäre — was ist weg? Bei einer Visitenkarten-Website: nichts. Bei einem Shop: die heutigen Bestellungen, also Kunden, die bezahlt haben und dafür keinen Beleg mehr haben.

Vernünftige Ausgangspunkte

  • Visitenkarten-Website, monatlich geändert — eine wöchentliche Vollsicherung ist großzügig.
  • Blog oder Nachrichtenseite — nächtlich.
  • Shop oder Buchungssystem — Dateien nächtlich, Datenbank stündlich.
  • Alles, was laufend Zahlungen annimmt — Dateien nächtlich, Datenbank alle 15 Minuten oder fortlaufender Log-Versand.

Dateien und Datenbank brauchen nicht denselben Rhythmus

Dateien ändern sich beim Ausrollen. Zeilen ändern sich jede Minute. Sie getrennt zu sichern heißt, dass der teure häufige Lauf der kleine ist.

# hourly, database only
15 * * * * /usr/bin/mysqldump --single-transaction --quick shop \
  | gzip > /srv/backup/db-$(date +\%H).sql.gz

# nightly, everything
30 2 * * * /usr/local/bin/restic backup /var/www /srv/backup
--single-transaction nimmt einen konsistenten InnoDB-Snapshot, ohne die Website zu sperren. Ohne das ist ein gut besuchter Shop für die Dauer des Dumps gesperrt — siehe Exportieren, ohne die Website zu sperren.

Und vor jeder Änderung

Ein Zeitplan deckt das Update nicht ab, das Sie gleich einspielen. Ziehen Sie vorher eine Sicherung — siehe Vor jedem Update sichern.

Häufiger ist nur bis zu dem Punkt besser, an dem niemand mehr prüft, ob es geklappt hat. Eine geprüfte nächtliche Sicherung schlägt eine stündliche, die seit März lautlos scheitert — siehe Ein fehlgeschlagenes Sicherungs-Log lesen.