elginux.

Article · 19 septembre 2026 · 18 min de lecture

Sauvegardes incrémentales pour une TPE ou une PME : méthodes, outils, coûts et restauration

Une méthode générale pour choisir, chiffrer, contrôler et restaurer les sauvegardes dont votre activité dépend.

Une sauvegarde n'est utile que si l'entreprise peut récupérer les données dont elle dépend, avec les secrets et les procédures nécessaires, dans le délai prévu.[4] La présence d'un fichier sur un disque ou d'un dépôt distant ne prouve ni son intégrité ni la capacité à remettre une application en service.[6] L'ANSSI recommande de définir une stratégie adaptée au contexte, de protéger les serveurs de sauvegarde et de tester régulièrement les restaurations.[4]

Ce guide propose une méthode générale pour les fichiers, les applications et les bases de données.[4] Il compare plusieurs familles d'outils — synchronisation, dépôts à snapshots et sauvegardes incrémentales chiffrées — avant de présenter un exemple facultatif pour un administrateur Linux avec Restic. Aucun outil n'est la solution universelle : le choix dépend notamment du RPO, du RTO, du stockage cible, de l'historique souhaité, des compétences disponibles et des mesures d'isolement.[4]

Pourquoi plusieurs outils sont possibles

Restic est utilisé dans certains exemples parce qu'il réunit snapshots, déduplication, chiffrement du dépôt, vérification et plusieurs types de stockage dans un outil relativement simple à déployer.[1] Cela en fait un exemple pratique, pas une recommandation automatique ni une obligation technique.

Rsync, que l'on utilisait déjà largement dans les années 2000, reste un outil de synchronisation efficace : son algorithme de transfert delta réduit les données envoyées en ne transmettant que les différences entre la source et la destination.[9] Il convient notamment à un miroir vers un autre serveur ou un NAS. Utilisé seul, il faut toutefois concevoir séparément l'historique, la rétention, le chiffrement, l'isolement et la protection contre une suppression propagée ou un compte compromis.[9]

BorgBackup crée des dépôts dédupliqués et prend en charge, selon sa configuration, la compression et le chiffrement authentifié.[10] Il convient surtout à une organisation qui accepte de gérer un dépôt Borg et dispose d'un environnement compatible.

Kopia propose des snapshots, la compression, la déduplication et le chiffrement, avec une approche multiplateforme et plusieurs emplacements de stockage possibles.[11] Il peut être intéressant lorsqu'une interface ou une gestion multiplateforme compte dans le choix.

Duplicity réalise des sauvegardes incrémentales chiffrées et utilise l'algorithme de type rsync pour réduire les transferts et l'espace nécessaires.[12] Il s'inscrit dans une approche différente des dépôts à snapshots modernes et doit être évalué avec sa procédure de restauration et sa chaîne de dépendances.

Le choix doit être fait après un test représentatif, pas seulement sur le nom de l'outil : vérifiez la restauration d'un fichier, d'une application et, si nécessaire, d'un environnement complet. Dans tous les cas, la cohérence des bases actives, l'isolement anti-ransomware, la gestion des secrets et le test de reprise restent des responsabilités de l'architecture globale.[4]

1. Partir des besoins de l'entreprise

Avant de choisir un logiciel ou un fournisseur, inventoriez les données qui permettent à l'activité de fonctionner :

Recommandation de méthode : classez ces éléments par criticité et par fréquence de changement.[4] Les données reproductibles, comme un logiciel réinstallable, ne se conservent pas forcément comme les données métier ; sa configuration, ses licences, ses secrets et ses données, eux, doivent être traités selon leur rôle dans la reprise.[4]

Le cas particulier des bases de données

Copier les fichiers d'une base pendant qu'elle écrit ne garantit pas un état cohérent et restaurable.[4] Selon le moteur, utilisez plutôt une sauvegarde native, un export logique, un mécanisme de sauvegarde à chaud ou un arrêt contrôlé du service.[4] La procédure dépend du moteur et de l'objectif de reprise ; Restic peut sauvegarder le fichier d'export produit, mais ne remplace pas les garanties de cohérence, de journalisation et de restauration du moteur.[1]

Si l'export est envoyé à Restic par un tube ou produit par une commande externe, contrôlez séparément le code de sortie de cette commande.[8] Un export échoué ou incomplet ne doit pas être présenté comme une sauvegarde valide.[1]

2. Fixer le RPO et le RTO avant la fréquence

Deux objectifs dimensionnent le dispositif.[4]

Ces objectifs doivent être fixés avec les responsables de l'activité.[4] L'ANSSI les rapproche de la perte de données maximale admissible (PDMA) et de la durée maximale d'interruption admissible (DMIA), qui doivent être définies pour les applications et les données métier.[4]

Le RPO détermine notamment la fréquence des sauvegardes et peut montrer qu'une sauvegarde seule ne suffit pas : pour une perte maximale de quatre heures, une sauvegarde quotidienne ne rend pas ce résultat réaliste.[4] L'ANSSI signale notamment que certains besoins de perte de données inférieure à 24 heures peuvent appeler une solution de réplication plutôt qu'une simple sauvegarde.[4]

Le RTO inclut davantage que la durée de restic restore : accès au dépôt, récupération du secret, téléchargement, préparation de la machine, restauration, réinstallation ou reconfiguration des services et validation par le métier.[4][6] Une restauration de quelques fichiers et la reconstruction d'un serveur complet ne demandent donc pas le même dispositif.[4]

3. Comprendre l'incrémental, les snapshots et la déduplication

Au sens courant, une sauvegarde incrémentale ne retransfère pas toutes les données à chaque exécution.[1] Elle traite les éléments nouveaux ou modifiés depuis un point de référence. La quantité réellement ajoutée dépend toutefois des changements, de la rétention et du contenu déjà présent ; l'incrémental ne signifie ni « zéro lecture » ni « zéro coût ».[1][2]

Avec Restic, le contenu d'un répertoire à un instant donné est enregistré dans un snapshot (instantané).[1] Les blocs déjà présents dans le dépôt peuvent être réutilisés par déduplication de contenu entre plusieurs snapshots.[1] Chaque snapshot décrit un état logique restaurable ; il ne s'agit pas forcément d'un fichier différentiel autonome.[1]

Restic doit parcourir les sources.[1] Sa détection des changements peut s'appuyer sur les métadonnées afin d'éviter de relire certains fichiers estimés inchangés, mais un renommage, un déplacement de répertoire ou un changement de métadonnées peut entraîner un nouveau parcours.[1] La quantité transférée peut donc être inférieure ou supérieure à la quantité simplement « modifiée » telle qu'affichée pendant le scan.[1]

La déduplication réduit le volume ajouté, mais le dépôt continue à consommer de l'espace.[1] L'estimation dépend au moins du volume initial, des blocs réellement nouveaux, de la fréquence des modifications, des métadonnées, de la compression éventuelle, du nombre de snapshots conservés et du backend avec ses frais d'opérations, de transfert ou de récupération.[1][5]

La taille initiale des données ne suffit pas pour prévoir le volume futur.[1][5] Recommandation de méthode : mesurez le dépôt après plusieurs cycles représentatifs, puis réévaluez l'estimation lorsque le périmètre, la rétention ou les habitudes de modification changent.[5]

4. Distinguer chiffrement du dépôt et sécurité du transport

Restic chiffre et authentifie le contenu et les métadonnées de son dépôt avant leur stockage.[3] Il permet aussi de gérer plusieurs clés ou mots de passe d'accès à un même dépôt.[3] La perte de toutes les clés utilisables ou du mot de passe rend toutefois la restauration impossible.[3]

Le chiffrement du dépôt et la sécurité du transport sont deux sujets différents.[2] Le premier protège les données dans le dépôt ; le second concerne la liaison entre la machine sauvegardée et le backend : protocole réellement utilisé, authentification, vérification des certificats et protection contre l'interception ou la modification.[5] Pour un transport TLS, ne désactivez pas la vérification des certificats pour contourner une erreur de configuration.[2] La documentation Restic expose notamment une option permettant de l'ignorer, mais la qualifie d'insecure ; elle ne doit pas être traitée comme une solution normale.

Recommandation de méthode : documentez, pour chaque backend, le protocole, les identifiants, les droits, la vérification TLS ou l'équivalent, ainsi que le chemin de récupération en cas d'indisponibilité du poste principal.[2][4] Ne déduisez pas la sécurité du transport de la seule présence d'un dépôt Restic chiffré.[2]

Protéger les secrets

Le mot de passe ou la clé du dépôt est une dépendance de reprise.[3] Ne placez pas un secret réel dans cet article, dans un script versionné, dans une commande conservée dans l'historique ou dans un ticket.[4] Restic documente notamment RESTIC_PASSWORD_FILE et RESTIC_PASSWORD_COMMAND pour fournir le mot de passe sans l'inscrire directement dans la ligne de commande.[8]

Un exemple générique peut ressembler à ceci :

export RESTIC_REPOSITORY="s3:https://stockage-exemple.invalid/entreprise"
export RESTIC_PASSWORD_COMMAND="/usr/local/sbin/obtenir-mot-de-passe-restic"
restic snapshots

Le mécanisme appelé doit récupérer le secret depuis un coffre ou un support protégé, avec des permissions minimales.[4] Si un fichier de mot de passe est utilisé, protégez-le contre la lecture par les comptes non autorisés.[8] Gardez au moins une possibilité de récupération indépendante du dépôt et de l'environnement de production, et testez-la.[4]

La procédure doit préciser où se trouve le dépôt, qui peut sauvegarder ou restaurer, comment récupérer le secret, comment remplacer ou révoquer un accès et comment importer les clés après un sinistre.[4][8] Après un incident de sécurité, restaurez de manière progressive et contrôlée : des sauvegardes peuvent contenir des éléments compromis, et l'ANSSI recommande de tenir compte de ce risque lors de la reconstruction.[4]

5. Mettre en place 3-2-1 avec une copie hors ligne ou immuable

La règle 3-2-1 est un cadre de résilience, pas une fonction automatique de Restic.[4]

L'ANSSI recommande cette architecture et précise qu'une sauvegarde hors ligne, ou à défaut une sauvegarde hors site en ligne sous certaines conditions, doit être envisagée selon le contexte.[4]

Pour limiter l'impact d'un rançongiciel, ajoutez une copie hors ligne ou immuable, selon les possibilités du dispositif et le risque accepté :[4]

Une copie distante chiffrée mais supprimable avec le même compte compromis ne constitue pas, à elle seule, une copie indépendante suffisante. Recommandation de méthode : testez aussi le scénario où le dépôt principal, le compte cloud ou le serveur d'administration est compromis.[4]

6. Estimer le coût sans inventer de tarif

Il n'existe pas un prix mensuel universel pour une sauvegarde.[1] Restic est un logiciel ; le tarif dépend du backend, du fournisseur, de la région, des classes de stockage, du volume, de la rétention, des opérations, des transferts et du temps d'exploitation.[5][7]

Formule d'estimation à adapter à la grille du fournisseur :

coût mensuel total estimé
= coût du stockage facturé
+ coût des opérations facturées
+ coût des transferts facturés
+ coût du support ou du matériel local
+ coût de l'administration et des tests

Par exemple :

coût du stockage    = volume facturé moyen × tarif applicable
coût des opérations = nombre d'opérations facturées × tarif applicable
coût des transferts = volume transféré facturé × tarif applicable
coût d'exploitation = temps prévu × taux interne retenu, si l'entreprise le comptabilise

Cette formule est un modèle de calcul, pas une citation de prix. Mesurez le volume initial, les ajouts par période, la déduplication observée et l'effet de la rétention sur plusieurs cycles.[1] Séparez aussi les restaurations prévues, car une sortie de données peut être facturée par le fournisseur.[5] Demandez sa grille tarifaire et ses conditions de récupération, de suppression définitive et d'immutabilité avant de comparer des offres.[7]

7. Contrôler les sauvegardes et déclencher des alertes

Une tâche qui affiche « terminé » n'est pas une preuve suffisante.[1][8] Recommandation de méthode : faites remonter vers un canal surveillé les événements suivants :

Le superviseur doit journaliser au minimum la commande ou le job, la date, la durée, le snapshot créé, les avertissements, la version de Restic et le code de sortie.[1][8] Les alertes doivent arriver ailleurs que sur le seul serveur sauvegardé et la chaîne d'escalade doit être vérifiée périodiquement.[4]

Pour les scripts, la documentation Restic indique que le code 0 signale une commande réussie, que 1 signale une erreur et que 3 peut signaler des données source illisibles ; les codes inconnus doivent être traités comme des échecs.[8] Pour backup, le code 3 peut correspondre à un snapshot incomplet malgré des erreurs de lecture, tandis que le code 1 correspond à une erreur fatale sans snapshot créé.[1]

Surveillez séparément le code de sortie d'un export de base de données et celui de Restic.[8] Un code favorable décrit le résultat de la commande concernée ; il ne remplace ni check ni un test de restauration métier.[5][6] Évitez les pipelines qui masquent l'échec d'une première commande et testez le comportement des alertes avec un échec contrôlé.

8. Vérifier le dépôt : check et check --read-data

restic check vérifie la structure et la cohérence du dépôt, notamment les index, les arbres et les références. Par défaut, il ne relit pas nécessairement le contenu de chaque pack de données.[5]

restic check --read-data ajoute la lecture et la vérification de l'intégrité des données des packs.[5] Cette opération est plus longue et peut télécharger l'ensemble des packs, donc consommer davantage de bande passante qu'un contrôle structurel ordinaire. Si le volume ne permet pas une lecture complète dans une seule fenêtre, --read-data-subset=... peut répartir le contrôle.[5] Un sous-ensemble ponctuel ne prouve pas que tous les packs ont été vérifiés.[5]

Recommandation de méthode : définissez une fréquence et une couverture réalistes, documentées selon le risque et la taille du dépôt.[5] Un contrôle de structure réussi ne dispense pas d'une restauration de fichier et d'un test applicatif.[5][6]

9. Choisir un snapshot avec prudence

Le mot latest sélectionne le dernier snapshot correspondant aux filtres fournis.[6] Dans un dépôt qui regroupe plusieurs hôtes, chemins ou jeux de données, latest sans filtre peut donc désigner le mauvais instantané.[6]

Pour une restauration opérationnelle :

  1. listez les snapshots avec restic snapshots ;[6]
  2. vérifiez l'ID, l'hôte, le chemin, les tags, la date et, si nécessaire, la cohérence applicative ;[6]
  3. sélectionnez explicitement l'ID voulu ;[6]
  4. restaurez vers une cible séparée et conservez la trace du choix.[6]

Exemple générique :

# Remplacer SNAPSHOT_ID par un ID relevé après vérification.
restic -r "$RESTIC_REPOSITORY" restore SNAPSHOT_ID \
  --target /tmp/restauration-test

# Si latest est retenu, borner explicitement la sélection.
# restic -r "$RESTIC_REPOSITORY" restore latest \
#   --host SERVEUR_EXEMPLE --path /srv/donnees \
#   --target /tmp/restauration-test

Restic documente l'emploi de latest avec des filtres d'hôte et de chemin, mais la sélection doit correspondre au jeu de sauvegarde recherché.[6] Recommandation de méthode : dans un script de reprise, refusez de continuer si plusieurs snapshots répondent au besoin sans sélection explicite.[6]

10. Gérer la rétention avec forget, prune et --dry-run

La durée de conservation doit découler du besoin de retour en arrière, des obligations identifiées et du RPO, plutôt que d'un nombre choisi au hasard.[4] Dans Restic, forget retire les snapshots sélectionnés par une politique, mais les données physiques devenues inutilisées ne sont pas nécessairement supprimées immédiatement ; prune les retire ensuite.[7] L'option --prune de forget enchaîne ces opérations lorsqu'un snapshot a effectivement été supprimé.[7]

Commencez par une simulation avec --dry-run.[7]

# Exemple de politique : à adapter, ne pas appliquer sans revue.
restic -r "$RESTIC_REPOSITORY" forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 \
  --tag fichiers --dry-run

Après vérification des hôtes, chemins, tags, périodes protégées et obligations de conservation, appliquez la politique.[7]

restic -r "$RESTIC_REPOSITORY" forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 \
  --tag fichiers --prune

Les valeurs sont un exemple, pas une recommandation universelle.[7] Ne supprimez pas la seule copie protégée ni un snapshot nécessaire à une investigation.[4] prune peut être long, verrouiller le dépôt et empêcher une sauvegarde de s'achever pendant son exécution ; planifiez cette opération en conséquence.[7]

11. Tester trois niveaux de restauration

Recommandation de méthode : ne testez pas seulement l'existence d'un dépôt ; testez ce que l'entreprise doit réellement récupérer.

Test fichier

À intervalles définis, choisissez un snapshot par son ID après vérification de ses attributs, restaurez un échantillon vers un répertoire ou une machine isolée, puis contrôlez les chemins, les tailles, les permissions, les propriétaires et les attributs pertinents. Ouvrez des fichiers représentatifs et comparez des sommes de contrôle lorsque c'est pertinent. Mesurez la durée, relevez les erreurs et la version de l'outil.

Test applicatif

Pour une base, importez un export cohérent ou ouvrez une base restaurée avec le moteur approprié dans un environnement de test. Vérifiez qu'elle répond aux requêtes attendues et que les objets importants sont présents. Pour une application, restaurez sa configuration et ses dépendances, puis contrôlez un démarrage maîtrisé et un parcours métier représentatif. La présence de fichiers ne prouve pas que le service fonctionnera.

Test de reprise

Lorsque le RTO l'exige, exercez dans un environnement isolé la séquence complète : accès au dépôt depuis une machine de secours, récupération du secret, préparation ou réinstallation du système, création des volumes, installation des paquets, restauration de la configuration et des données, redémarrage des services et validation par un responsable métier. Chronométrez les étapes qui ne relèvent pas de Restic.

Restic sait restaurer des données vers une cible, mais ce n'est pas une solution d'image disque complète ni une procédure automatique de bare metal recovery. Sauvegarder / ne reconstitue pas à lui seul la table de partitions, le chargeur d'amorçage, les volumes chiffrés ou la configuration matérielle. Pour un objectif bare metal strict, complétez Restic par une image système ou un outil adapté, ou documentez et testez une reconstruction manuelle.[6]

Un contrôle technique ou un test de restauration échoué est un incident de sauvegarde, même si la tâche automatique est marquée réussie. Vérifiez l'erreur, l'accès au backend, le secret, l'espace local, l'intégrité du dépôt, la version, les permissions et les exclusions ; corrigez puis rejouez le test. Après un incident de sécurité, réinstallez les systèmes depuis des sources de confiance et restaurez progressivement les données nécessaires, plutôt que de remettre aveuglément toute l'image en service.[4]

12. Conserver une fiche d'exploitation

Recommandation de méthode : pour chaque dispositif, conservez une fiche accessible même si le poste d'administration habituel est indisponible. Elle devrait indiquer :

Encadré facultatif — Exemple pour administrateur Linux avec Restic

Restic est ici un exemple d'outil de sauvegarde de fichiers et de répertoires. Il crée des snapshots, réutilise les blocs déjà présents lorsque la déduplication s'applique et chiffre son dépôt ; il n'est pas obligatoire pour mettre en œuvre la méthode de cet article.[1][3]

Adaptez le backend, les chemins, les droits, la version et la méthode de fourniture du secret. Initialisez un dépôt une seule fois, puis utilisez-le pour les sauvegardes suivantes :

# RESTIC_REPOSITORY et RESTIC_PASSWORD_FILE sont fournis
# par un mécanisme de secrets protégé, hors de ce script.
export RESTIC_REPOSITORY="..."
export RESTIC_PASSWORD_FILE="..."

# À exécuter une seule fois pour un nouveau dépôt.
restic -r "$RESTIC_REPOSITORY" init

restic -r "$RESTIC_REPOSITORY" backup /srv/donnees --tag fichiers
restic -r "$RESTIC_REPOSITORY" snapshots
restic -r "$RESTIC_REPOSITORY" check
# À planifier selon le risque et la fenêtre disponible :
restic -r "$RESTIC_REPOSITORY" check --read-data

Ne lancez pas une restauration de production avec latest sans vérifier la sélection. Listez les snapshots, relevez l'ID voulu, puis restaurez vers une cible séparée :

restic -r "$RESTIC_REPOSITORY" restore SNAPSHOT_ID \
  --target /tmp/restauration-test

Après la restauration, ouvrez réellement des fichiers et, pour une base, appliquez la procédure cohérente du moteur concerné. Ces commandes ne remplacent ni la copie hors ligne ou immuable, ni les alertes, ni les contrôles du code de sortie, ni les tests métier.

Conclusion

Une sauvegarde incrémentale chiffrée peut réduire les données transférées et conserver plusieurs points de restauration. Elle ne garantit pas, à elle seule, la cohérence d'une base active, la protection contre un compte compromis, la récupération du secret, une reprise bare metal ou la restauration d'une application.

La méthode fiable consiste à identifier les données et le RPO/RTO, choisir une méthode cohérente pour chaque type de donnée, chiffrer le dépôt et sécuriser séparément le transport, protéger les secrets, conserver plusieurs copies dont une hors site et une hors ligne ou immuable, surveiller les codes de sortie, gérer la rétention avec une simulation et prouver régulièrement la restauration d'un fichier, d'une application et d'un environnement de reprise.

Le bon indicateur n'est donc pas seulement « la sauvegarde s'est terminée sans erreur », mais « l'entreprise sait quel snapshot choisir et peut restaurer les données dont elle dépend, avec le secret, les outils et le temps réellement disponibles ».

Sources

[1] https://restic.readthedocs.io/en/stable/040_backup.html — Restic — Backing up [2] https://restic.readthedocs.io/en/stable/manual_rest.html — Restic — Manual [3] https://restic.readthedocs.io/en/stable/070_encryption.html — Restic — Encryption [4] https://messervices.cyber.gouv.fr/documents-guides/anssi_fondamentaux_sauvegarde_systemes_dinformation_v1.1.pdf — ANSSI — Sauvegarde des systèmes d’information : les fondamentaux [5] https://restic.readthedocs.io/en/stable/045_working_with_repos.html — Restic — Working with repositories [6] https://restic.readthedocs.io/en/stable/050_restore.html — Restic — Restoring from backup [7] https://restic.readthedocs.io/en/stable/060_forget.html — Restic — Removing backup snapshots [8] https://restic.readthedocs.io/en/stable/075_scripting.html — Restic — Scripting [9] https://rsync.samba.org/ftp/rsync/rsync.html [10] https://borgbackup.readthedocs.io/en/stable/introduction.html [11] https://kopia.io/docs/features [12] https://duplicity.us/features.html