Non esiste una frequenza corretta, esiste solo una conseguenza. L'intervallo fra due backup è esattamente quanto lavoro perderai nel caso peggiore. Decidi quanto può valere quel numero, e il calendario ne discende.

Ponila ad alta voce

Se tutto sparisse adesso e la copia più recente fosse di ieri notte, cosa sarebbe perduto? Per un sito vetrina: nulla. Per un negozio: gli ordini di oggi, cioè clienti che hanno pagato e di cui non resta traccia.

Punti di partenza ragionevoli

  • Sito vetrina, aggiornato una volta al mese — un backup completo settimanale è già generoso.
  • Blog o sito di notizie — ogni notte.
  • Negozio o sistema di prenotazioni — file ogni notte, database ogni ora.
  • Qualsiasi cosa incassi di continuo — file ogni notte, database ogni 15 minuti oppure invio continuo dei registri.

File e database non hanno bisogno dello stesso calendario

I file cambiano quando pubblichi. Le righe cambiano ogni minuto. Salvarli separatamente fa sì che il lavoro frequente e costoso sia quello piccolo.

# 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 prende un'istantanea coerente di InnoDB senza bloccare il sito. Senza, un negozio trafficato resta bloccato per tutta la durata del dump — vedi Esportare senza bloccare il sito.

E anche prima di ogni modifica

Un calendario non copre l'aggiornamento che stai per applicare. Prendine uno prima — vedi Un backup prima di ogni aggiornamento.

Più spesso è meglio solo fino al punto in cui nessuno controlla più che abbia funzionato. Un backup notturno verificato batte uno orario che fallisce in silenzio da marzo — vedi Leggere il registro di un backup fallito.