Une sauvegarde protège de tout ce dont elle ne partage pas le sort. Sur le même disque, elle survit à un fichier supprimé mais pas à un disque en panne. Sur le même serveur, elle survit à un disque en panne mais pas à un compte compromis. La question est toujours : de quoi cette copie partage-t-elle le sort ?

Trois-deux-un, en clair

  • Trois copies — celle en service et deux sauvegardes.
  • Deux sortes de support — pas deux dossiers sur un même disque.
  • Une ailleurs — une autre machine, idéalement un autre prestataire.

« Ailleurs », classé selon ce que cela protège

  • Un autre disque du même serveur — un disque en panne, et rien d'autre.
  • Un autre serveur chez le même prestataire — un serveur en panne. Ni une suspension de compte, ni une erreur commise avec un accès couvrant tout le prestataire.
  • Un tout autre prestataire — tout ce qui précède, plus le jour où c'est le compte lui-même le problème.
Si la compromission de votre serveur peut aussi supprimer les sauvegardes, elles ne sont pas une défense contre une compromission. La destination des sauvegardes doit être en écriture seule depuis le serveur : il peut ajouter, il ne peut pas retirer.

L'écriture seule en pratique

# object storage with an append-only policy, or
# a pull model: the BACKUP server connects to the site and takes a copy,
# so the site never holds credentials that can delete anything

Le modèle où c'est le dépôt qui vient chercher est le plus solide et le moins employé : rien sur le serveur web n'atteint les sauvegardes, donc rien de ce qui s'y passe ne peut y toucher.

Chiffrez-la, et gardez la clé ailleurs

gpg --symmetric --cipher-algo AES256 backup.tar.gz
Une clé rangée uniquement sur le serveur qui est mort n'est pas une clé. Notez-la et gardez-la à un endroit qui n'a rien à voir avec le serveur.
Testez précisément la copie distante. La locale fonctionne d'ordinaire, et la distante est celle dont personne n'a jamais restauré.