Il n'existe pas de bonne fréquence, seulement une conséquence. L'intervalle entre deux sauvegardes, c'est exactement la quantité de travail que vous perdrez au pire. Décidez de ce que ce chiffre a le droit d'être, et le calendrier en découle.

Posez la question à voix haute

Si tout disparaissait maintenant et que la copie la plus récente datait de cette nuit, qu'aurait-on perdu ? Pour un site vitrine : rien. Pour une boutique : les commandes du jour, c'est-à-dire des clients qui ont payé et dont il ne reste aucune trace.

Des points de départ raisonnables

  • Site vitrine, modifié une fois par mois — une complète hebdomadaire est déjà généreuse.
  • Blog ou site d'actualité — chaque nuit.
  • Boutique ou système de réservation — fichiers chaque nuit, base chaque heure.
  • Tout ce qui encaisse en continu — fichiers chaque nuit, base toutes les 15 minutes ou envoi continu des journaux.

Fichiers et base n'ont pas besoin du même rythme

Les fichiers changent quand vous déployez. Les lignes changent chaque minute. Les sauvegarder séparément, c'est faire en sorte que la tâche fréquente et coûteuse soit la petite.

# 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 prend un instantané cohérent d'InnoDB sans verrouiller le site. Sans elle, une boutique fréquentée reste verrouillée pendant toute la sauvegarde — voir Exporter sans verrouiller le site.

Et avant chaque modification

Un calendrier ne couvre pas la mise à jour que vous allez appliquer. Faites-en une d'abord — voir Sauvegarder avant chaque mise à jour.

Plus souvent n'est meilleur que jusqu'au point où plus personne ne vérifie que cela a marché. Une sauvegarde nocturne vérifiée vaut mieux qu'une sauvegarde horaire qui échoue en silence depuis mars — voir Lire un journal de sauvegarde en échec.