Sauvegarder, et surtout restaurer
Ce qu'il faut sauvegarder, où le mettre, et pourquoi une sauvegarde jamais restaurée ne compte pas.
Les images de machine proposées dans votre espace client couvrent le gros incident : une machine perdue, une mise à jour ratée. Elles ne couvrent pas le cas le plus fréquent, qui est la suppression discrète d'un fichier repérée trois semaines plus tard. Pour ça, il faut un historique.
Ce qui mérite d'être sauvegardé
- Les données produites par vos utilisateurs : fichiers déposés, mondes de jeu, boîtes mail.
- Les bases de données, exportées proprement — copier les fichiers d'une base en cours d'écriture donne une sauvegarde inutilisable.
- Vos fichiers de configuration : /etc, les vhosts, les unités systemd.
- Pas le système lui-même : il se réinstalle en dix minutes.
Exporter une base de données
mysqldump --single-transaction --quick maBase | gzip > maBase-$(date +%F).sql.gz--single-transaction prend un instantané cohérent sans bloquer les écritures pendant l'export. Pour PostgreSQL, l'équivalent est pg_dump -Fc.
Un historique, hors de la machine
restic chiffre, déduplique et garde plusieurs versions. Le dépôt doit vivre ailleurs que sur le serveur sauvegardé — une sauvegarde sur le disque de la machine disparaît avec elle.
restic -r sftp:[email protected]:/depot init
restic -r sftp:[email protected]:/depot backup /var/www /etc
restic -r sftp:[email protected]:/depot forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneTestez la restauration
Une sauvegarde qu'on n'a jamais restaurée est une hypothèse, pas une sécurité. Une fois par trimestre, restaurez un fichier au hasard dans un dossier temporaire et ouvrez-le. C'est cinq minutes, et c'est la seule preuve que la chaîne fonctionne de bout en bout.
restic -r sftp:[email protected]:/depot restore latest --target /tmp/testBloqué malgré tout ? Ouvrez un ticket : on répond en français, et on regarde votre machine si besoin.
Ouvrir un ticket