Restic

Restic est un outil de sauvegarde qui prend le problème par le bon bout : il envoie vos données chiffrées vers un dépôt distant (stockage objet, SFTP, disque externe), ne transfère que ce qui a changé, et garde chaque sauvegarde comme un instantané daté dans lequel on peut aller rechercher un seul fichier. Pour une PME, l'enjeu n'est pas d'avoir une sauvegarde : presque tout le monde en a une. L'enjeu est de savoir combien de temps il faut pour remettre le service debout à partir d'elle, et si quelqu'un l'a vérifié.

• →Borg / BorgmaticMême philosophie, dépôt en SSH plutôt qu'en stockage objet : excellent quand la destination est une machine que vous possédez
• →Instantanés de l'hébergeurImmédiats et sans installation, mais hébergés dans le même compte que la production
• →PostgreSQL en PITRPour une base critique, la réplication et la restauration à un instant donné complètent la sauvegarde de fichiersVoir la page
• →AnsiblePour déployer et tenir la même configuration de sauvegarde sur tout un parcVoir la page

1. 01

   Règle 3-2-1 : trois copies, deux supports, une hors site — et hors du compte qui héberge la production

2. 02

   Dépôt chiffré côté client, clé conservée ailleurs que sur la machine sauvegardée

3. 03

   Dump applicatif cohérent avant l'instantané, jamais une copie à chaud des fichiers d'une base en cours d'écriture

4. 04

   Rétention déclarée et purgée automatiquement, vérification d'intégrité du dépôt planifiée

5. 05

   Restauration testée et chronométrée, avec la procédure écrite pour quelqu'un qui n'a pas construit le système

• Qu'est-ce que Restic apporte face à une simple copie de fichiers ?

  Trois choses qu'une copie ne donne pas. La déduplication : seuls les blocs modifiés partent, donc trente sauvegardes quotidiennes ne pèsent pas trente fois la même donnée. L'instantané daté : on restaure l'état d'un jour précis, pas le dernier état connu qui a peut-être déjà écrasé la donnée perdue. Le chiffrement avant transfert : l'hébergeur du stockage détient des blocs illisibles.
• Les instantanés de mon hébergeur ne suffisent-ils pas ?

  Ils sont utiles et instantanés, mais ils vivent dans la même main que ce qu'ils protègent : un compte compromis, une erreur de facturation ou une suppression de projet emporte les deux d'un coup. Ils couvrent la panne matérielle et l'erreur de manipulation. Ils ne couvrent ni le rançongiciel qui remonte les partages, ni la perte du compte. Une copie hors du fournisseur reste nécessaire.
• Où sont stockées les sauvegardes, et combien coûte ce stockage ?

  Dans un stockage objet compatible S3 (OVH, Scaleway, Backblaze B2, Wasabi), en SFTP, ou sur un disque distant. C'est un coût de fonctionnement, facturé au volume conservé : de l'ordre de quelques euros par mois pour quelques centaines de gigaoctets, auxquels s'ajoutent parfois des frais de sortie au moment d'une restauration massive — un point à vérifier avant de choisir le fournisseur, pas le jour de l'incident.
• Combien coûte la mise en place d'une stratégie de sauvegarde ?

  Ce n'est pas l'outil qui commande le prix, c'est ce qu'il faut protéger et à quelle vitesse il faut le rendre : le nombre de serveurs et de bases, la volumétrie, la rétention à tenir, l'existence ou non d'une supervision, et le niveau de restauration à garantir — un fichier, une base, ou l'ensemble du service. Le montant se fixe au devis, après un cadrage initial gratuit qui écrit le périmètre avant tout engagement.
• À quelle fréquence faut-il tester une restauration ?

  À chaque changement significatif de l'infrastructure, et au moins deux fois par an en dehors de tout changement. Un test de restauration n'est pas une case à cocher : il mesure une durée, révèle les dépendances oubliées (certificats, variables d'environnement, droits) et vérifie que la procédure est exécutable par quelqu'un d'autre que celui qui l'a écrite.