I backup si archiviano di solito sotto la voce affidabilità. Sono altrettanto una misura di sicurezza, perché la risposta a una violazione, a un riscatto e a un rilascio andato male è la stessa: tornare a una copia che sai buona. A decidere se ciò sia possibile sono due cose — dove sta quella copia e chi riesce a raggiungerla.

La prova che conta

Immagina che un attaccante abbia il tuo server e ogni credenziale che vi si trova. Quali copie sopravvivono? Se la risposta è nessuna, non hai un backup: hai una seconda copia dello stesso rischio.

Che cosa sopravvive

  • Fuori sede, presso un altro fornitore — vedi Una copia che sta altrove.
  • Sola scrittura dal server. Il server può aggiungere un backup e non può elencarne né cancellarne.
  • Con versioni o immutabile, così che sovrascrivere con dati corrotti non distrugga la copia buona.
  • Conservato abbastanza a lungo da coprire una violazione che per un mese non hai notato.
# a push-only key: the server can write, and nothing else
restic -r s3:s3.example.com/backups backup /var/www /var/lib/mysql
# the credential used here has PutObject and no DeleteObject

La conservazione batte la frequenza

Backup ogni ora conservati due giorni non servono a nulla contro qualcosa cominciato tre settimane fa. Tieni i giornalieri per un mese e i mensili per un anno — vedi Conservazione: quanto a lungo è abbastanza.

Ripristinare un sito violato non è un ripristino

Se il backup è stato preso dopo l'intrusione, ripristinarlo rimette dentro l'attaccante. Scopri dai log quando è cominciata, ripristina da prima di quel momento e chiudi la via d'ingresso prima che il sito torni pubblico.
Un backup mai provato è una convinzione, non una misura. Ripristinane uno, su una macchina diversa, con regolarità — vedi Verificare che un backup si ripristini.