On range d'ordinaire les sauvegardes du côté de la fiabilité. Ce sont tout autant une mesure de sécurité, car la réponse à une compromission, à un rançongiciel et à un déploiement raté est la même : revenir à une copie dont on sait qu'elle est bonne. Ce qui décide si c'est possible, c'est où se trouve la copie et qui peut l'atteindre.
L'épreuve qui compte
Supposez qu'un attaquant détienne votre serveur et tous les identifiants qui s'y trouvent. Quelles copies survivent ? Si la réponse est aucune, vous n'avez pas de sauvegarde : vous avez une seconde copie du même risque.
Ce qui survit
- Hors site, chez un autre fournisseur — voir Une copie qui vit ailleurs.
- En écriture seule depuis le serveur. Le serveur peut ajouter une sauvegarde, mais ni en lister ni en supprimer.
- Versionnée ou immuable, pour qu'une écriture de données corrompues ne détruise pas la bonne copie.
- Conservée assez longtemps pour couvrir une compromission passée inaperçue pendant un mois.
# 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 DeleteObjectLa durée de conservation l'emporte sur la fréquence
Des sauvegardes horaires conservées deux jours ne servent à rien contre quelque chose qui a commencé il y a trois semaines. Gardez les quotidiennes un mois et les mensuelles un an — voir Conservation : combien de temps suffit.