Cybee > Restic en entreprise
Restic, référence open source

Restic en entreprise : forces, limites et industrialisation de la sauvegarde open source

Restic, un moteur de sauvegarde open source sous licence BSD-2-Clause, est renommé pour sa capacité de déduplication à la source, son chiffrement de bout en bout et son intégration native du stockage objet S3.

Fondé en 2014 et actuellement adopté par des très nombreux grands départements informatiques à travers le monde (dont le CERN), il est devenu la référence open source en matière de sauvegarde moderne.

 

Cependant, un moteur de sauvegarde, aussi performant soit-il, ne constitue pas une solution globale pour l’entreprise. Restic ne propose ni interface centralisée, ni planificateur, ni rapport de conformité : des caractéristiques essentielles lorsqu’il s’agit de sauvegarder des dizaines ou centaines de serveurs soumis à des obligations légales (RGPD, NIS2, DORA).

Les fondamentaux techniques de Restic

Restic est un programme de sauvegarde en ligne de commande, écrit en Go et distribué sous forme d’un binaire unique, sans dépendance, disponible pour Linux, Windows, macOS et BSD. Son développement est piloté par une communauté active : la version 0.19.1 est sortie en juillet 2026, un mois après la 0.19.0 qui a apporté de nouveaux modes de compression zstd et une réduction significative de la consommation mémoire sur les gros dépôts. La documentation officielle, exhaustive, est maintenue sur restic.readthedocs.io.

Architecture Restic

Restic ne copie pas des fichiers : il découpe les données en blocs de taille variable (content-defined chunking), identifie chaque bloc par son empreinte cryptographique SHA-256, et ne stocke chaque bloc qu’une seule fois dans un dépôt appelé dépot. Chaque sauvegarde est un cliché: une vue cohérente et horodatée de l’arborescence, qui ne référence que des blocs.

Deux conséquences majeures pour l’entreprise :

  • Chaque cliché est une sauvegarde complète logique. Il n’existe pas de chaîne « full + incrémentales » fragile à reconstruire : restaurer le snapshot de mardi ne dépend d’aucune restauration préalable.
  • Le format du dépôt est un standard public et documenté. Le projet applique le versionnement sémantique à son format de données : toute sauvegarde reste restaurable par les versions futures du moteur. C’est une garantie de réversibilité qu’aucun format propriétaire n’offre.

Les limites de Restic seul en production

Restic est un moteur de sauvegarde, pas une plateforme.

 

Le projet l’assume : il fait une chose, sauvegarder et restaurer,  et la fait très bien. Tout le reste est laissé à la charge de l’exploitant. À l’échelle de quelques serveurs,  c’est un non-sujet. À l’échelle d’un parc d’entreprise, quatre manques deviennent bloquants.

Pas de console centralisée ni de supervision Restic s’exécute localement, serveur par serveur. Il n’existe ni tableau de bord consolidé, ni vue du parc, ni alerte native en cas d’échec. Superviser 50 serveurs signifie agréger soi-même 50 sorties de commandes, via des scripts, un Prometheus ou des solutions maison qu’il faudra maintenir.

Une sauvegarde qui échoue silencieusement pendant une semaine est le scénario classique que ce manque génère.
Pas de gestion des dépôts à l'échelle Un dépôt Restic est identifié par l’URL de son stockage : il n’existe ni nom logique, ni étiquette, ni commande de renommage natif.

Réorganiser des dizaines de dépôts (par OS, par site, par criticité), migrer un dépôt vers une autre classe de stockage, ou simplement maintenir un inventaire fiable des serveurs sauvegardés et des plans liés, relève entièrement de la discipline de l’équipe — ou d’un outillage au-dessus du moteur.
Ordonnancement, rétention, bande passante : tout est à scripter Restic n’embarque pas de planificateur. Les sauvegardes sont déclenchées par cron ou systemd-timer ; les politiques de rétention doivent être orchestrées avec soin — un élagage mal placé peut entrer en conflit avec une sauvegarde en cours ; la gestion des fenêtres de sauvegarde et de la bande passante est manuelle.

Chaque équipe réécrit les mêmes scripts, avec les mêmes limites.
Ni reporting de conformité, ni preuve d'exploitation NIS2 impose de démontrer la résilience des sauvegardes ; DORA exige des tests de restauration documentés ; le RGPD demande la maîtrise de la localisation des données.

Restic ne produit aucun rapport d’exploitation, aucun historique consolidé des jobs, aucune preuve de test de restauration. Or, en audit, ce qui n’est pas documenté n’a que peu de valeur.

Industrialiser Restic : l’approche orchestrateur

La réponse à ces limites n’est pas d’abandonner Restic pour une boîte noire propriétaire : c’est de le compléter. Le schéma  est donc  un moteur open source éprouvé + une couche d’orchestration qui apporte l’échelle, la supervision et la gouvernance.

C’est l’architecture de Cybee, solution européenne de sauvegarde Cloud cyber-résiliente construite sur le moteur Restic.

Console centralisée déploiement, planification et supervision de l’ensemble du parc (Windows et Linux) depuis une interface unique, avec alerting en cas d’anomalie.
Gestion multi-dépots les dépôts Restic reçoivent une identité logique et s’organisent selon la stratégie de l’entreprise (par périmètre, par criticité), afin d’optimiser les facteurs de déduplication.
Optimisation des classes de stockage S3 répartition entre stockage chaud, tiède pour maîtriser les coûts sans sacrifier les délais de restauration.
Ordonnancement intelligent gestion en temps réel de la bande passante et des priorités pour respecter les fenêtres de sauvegarde.
Hébergement européen et conformité native données chiffrées à la source, stockées en Europe, avec les rapports d’exploitation attendus par les auditeurs.
Immuabilité anti-ransomware des sauvegardes qu’un attaquant ayant compromis la production ne peut ni chiffrer ni supprimer? C’est la parade au scénario désormais standard où les ransomwares ciblent d’abord les sauvegardes.