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
déploiement, planification et supervision de l’ensemble du parc (Windows et Linux) depuis une interface unique, avec alerting en cas d’anomalie.
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.
répartition entre stockage chaud, tiède pour maîtriser les coûts sans sacrifier les délais de restauration.
gestion en temps réel de la bande passante et des priorités pour respecter les fenêtres de sauvegarde.
données chiffrées à la source, stockées en Europe, avec les rapports d’exploitation attendus par les auditeurs.
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.