Qu’est-ce qu’une sau­ve­garde in­cré­men­tielle ?

Les sau­ve­gardes in­cré­men­tielles per­met­tent un stockage en continu des ensembles de données modifiés ré­gu­liè­re­ment. Ceci réduit la con­fi­gu­ra­tion requise en termes de temps, de bande passante, et de stockage par rapport à des sau­ve­gardes complètes répétées. Les sau­ve­gardes in­cré­men­tielles com­men­cent par une sau­ve­garde complète, suivie par une chaîne de sau­ve­gardes in­cré­men­tielles plus petites, mais con­dui­sent à des processus de sau­ve­garde et de res­tau­ra­tion d’une plus grande com­plexité. Des logiciels spé­ci­fiques sont utilisés afin de faire face à cela.

Une sau­ve­garde in­cré­men­tielle (in­cre­men­tal backup en anglais) est une méthode de sau­ve­garde qui est souvent utilisée dans le cadre d’une stratégie de sau­ve­garde plus large. À la dif­fé­rence d’une sau­ve­garde complète, elle ne crée pas une copie complète du jeu de données à sau­ve­gar­der. Au lieu de cela, seuls les chan­ge­ments apportés aux fichiers à compter de la dernière sau­ve­garde sont sau­ve­gar­dés.

À la dif­fé­rence d’une sau­ve­garde dif­fé­ren­tielle, la ré­con­ci­lia­tion des mo­di­fi­ca­tions ne se fait pas né­ces­sai­re­ment par rapport à la dernière sau­ve­garde complète. Ce sont plutôt les mo­di­fi­ca­tions qui remontent à la dernière sau­ve­garde complète ou in­cré­men­tielle qui sont sau­ve­gar­dées.

Les approches de la pro­tec­tion des données in­cré­men­tielles sont en général re­grou­pées en deux grandes ca­té­go­ries :

1. La gra­nu­la­rité des chan­ge­ments
2. L’uti­li­sa­tion de la stratégie à employer

La plupart du temps, on a recours à des approches hybrides. Par exemple, le célèbre outil rsync crée des « sau­ve­gardes complètes syn­thé­tiques niveau bloc » en uti­li­sa­tion normale. Examinons plus en détail les dif­fé­rents types de sau­ve­gardes in­cré­men­tielles.

Les données stockées nu­mé­ri­que­ment sont cons­ti­tuées de chaînes presque infinies de 0 et de 1. Ces bits sont regroupés au sein d’unités logiques, dont les plus connues sont les fichiers. Cependant, en-dessous du niveau fichier, on trouve des « blocs » et des « bytes », qui cons­ti­tuent des grou­pe­ments logiques de bits in­di­vi­duels.

Pour comparer les mo­di­fi­ca­tions entre la dernière sau­ve­garde et l’état actuel du jeu de données, on peut se référer à ces dif­fé­rents niveaux. Plus la cor­res­pon­dance des chan­ge­ments est forte au niveau des bits in­di­vi­duels eux-mêmes, plus cela rend efficace la sau­ve­garde in­cré­men­tielle. Tandis que, d’un fichier à un autre, la taille varie, les blocs et les bytes ont des tailles définies et fixes. À titre d’exemple, un byte comprend huit bits con­sé­cu­tifs ; les blocs font gé­né­ra­le­ment de 512 à 4 096 bytes de longueur.

Une sau­ve­garde in­cré­men­tielle niveau fichier peut uni­que­ment dis­tin­guer si un fichier a été modifié. L’étendue du chan­ge­ment n’est pas prise en compte. Si un seul bit a été modifié, le fichier dans sa totalité est à nouveau sau­ve­gardé durant la sau­ve­garde in­cré­men­tielle. Pour illustrer ceci, imaginons que le manuscrit d’un long ouvrage est stocké sous la forme d’un fichier unique sur un support de données. Si une seule et unique lettre est modifiée, la totalité du manuscrit sera à nouveau copiée dans le cadre d’une sau­ve­garde in­cré­men­tielle niveau fichier.

Les sau­ve­gardes in­cré­men­tielles niveau fichier sont les plus faciles à mettre en place car les systèmes de fichiers ré­per­to­rient les dates de mo­di­fi­ca­tion des fichiers. Pour ré­con­ci­lier les chan­ge­ments, il suffit de comparer les ho­ro­da­tages de la dernière mo­di­fi­ca­tion d’un fichier sur les systèmes source et cible. Si l’ho­ro­da­tage sur le système source est plus récent, le fichier a été modifié et doit être copié à nouveau. Ainsi, les sau­ve­gardes in­cré­men­tielles sont inef­fi­caces pour les petits chan­ge­ments apportés à des fichiers vo­lu­mi­neux.

Le terme « bloc » provient du stockage de données. Les disques durs et les autres pé­ri­phé­riques de stockage de masse or­ga­ni­sent des sections de bytes con­sé­cu­tifs sous forme de zones logiques contiguës. Lorsque l’on crée la sau­ve­garde in­cré­men­tielle niveau bloc, seuls les blocs modifiés sont sau­ve­gar­dés. Cela présente l’avantage de réduire la taille des données à trans­fé­rer et à stocker. Ainsi, seules les sections modifiées des fichiers in­di­vi­duels sont sau­ve­gar­dées.

L’in­con­vé­nient majeur est qu’un mécanisme per­met­tant de créer des journaux de quels blocs ont été modifiés est né­ces­saire. Certaines tech­no­lo­gies de stockage ont la capacité de gérer cette in­for­ma­tion et peuvent dès lors im­plé­men­ter des sau­ve­gardes in­cré­men­tielles niveau bloc. Sinon, il faudrait comparer la sau­ve­garde complète niveau bloc à l’état actuel pour détecter tout chan­ge­ment.

Les sau­ve­gardes in­cré­men­tielles niveau byte cons­ti­tuent une version encore plus détaillée qu’une sau­ve­garde in­cré­men­tielle niveau bloc. Seuls les bytes modifiés d’un bloc sont sau­ve­gar­dés. En termes de temps né­ces­saire et d’espace de stockage requis, la sau­ve­garde in­cré­men­tielle niveau byte est as­su­ré­ment beaucoup plus efficace. Néanmoins, le processus est plus exigeant. Ceci est dû au fait qu’un journal des chan­ge­ments au niveau byte est né­ces­saire pour iden­ti­fier les bytes modifiés. L’effort sup­plé­men­taire pour les sau­ve­gardes in­cré­men­tielles niveau byte est justifié pour des chan­ge­ments localisés apportés à des fichiers très vo­lu­mi­neux.

Les sau­ve­gardes in­cré­men­tielles font partie d’une chaîne de sau­ve­gardes in­di­vi­duelles qui con­tien­nent les chan­ge­ments apportés à l’état antérieur. Au com­men­ce­ment de la chaîne, on retrouve toujours une sau­ve­garde complète. Il existe dif­fé­rentes méthodes de cons­truc­tion de cette chaîne et de création de nouvelles sau­ve­gardes complètes. Ceci offre des avantages en termes de com­plexité et de durée des processus de sau­ve­garde et de res­tau­ra­tion. Voici quelques stra­té­gies de création de sau­ve­gardes in­cré­men­tielles.

Une stratégie classique de sau­ve­garde in­cré­men­tielle nécessite des sau­ve­gardes complètes pé­rio­diques. Créer une sau­ve­garde complète est aussi lent que chro­no­phage. Avec les sau­ve­gardes complètes syn­thé­tiques, une nouvelle sau­ve­garde complète est créée. La sau­ve­garde complète d’origine et les sau­ve­gardes in­cré­men­tielles ul­té­rieures sont utilisées à cette fin. Ceci évite d’avoir à copier l’ensemble du jeu de données depuis le système source, qui, autrement, serait né­ces­saire lors de la création d’une sau­ve­garde complète. Ce processus est également appelé « sau­ve­garde in­cré­men­tielle directe ».

La sau­ve­garde toujours in­cré­men­tielle est optimisée pour copier des disques durs et des supports si­mi­laires. Au début, une sau­ve­garde complète est créée ; par la suite, seuls les blocs modifiés sont stockés dans une chaîne continue « infinie ». À la dif­fé­rence d’une sau­ve­garde complète syn­thé­tique ou in­cré­men­tielle inversée, aucune sau­ve­garde complète sup­plé­men­taire n’est créée après la toute première. Ceci permet d’éco­no­mi­ser de l’espace disque et réduit le volume de données transféré durant les opé­ra­tions de copie.

La sau­ve­garde in­cré­men­tielle inversée fonc­tionne de manière analogue à la sau­ve­garde complète syn­thé­tique. Après chaque sau­ve­garde in­cré­men­tielle, les mo­di­fi­ca­tions sont fu­sion­nées avec la dernière sau­ve­garde complète. Cela signifie qu’une sau­ve­garde complète existe au bout de la chaîne de sau­ve­garde. Il est vrai que créer une sau­ve­garde in­cré­men­tielle inversée prend plus de temps qu’une sau­ve­garde in­cré­men­tielle directe. Néanmoins, si né­ces­saire, le système source peut être restauré sans délai, dans la mesure où le dernier statut actuel est déjà dis­po­nible sous la forme d’une copie complète.

Une sau­ve­garde in­cré­men­tielle améliorée peut être de n’importe quel type. Ce qui la distingue est le fait qu’elle détecte les mo­di­fi­ca­tions apportées aux fichiers causées par le fait de les déplacer ou de les renommer. Dans le cas de fichiers vo­lu­mi­neux, cela permet de gagner en ef­fi­ca­cité.

L’atout majeur des sau­ve­gardes in­cré­men­tielles est le fait que chaque sau­ve­garde in­di­vi­duelle est petite. Étant donné que seules les dif­fé­rences par rapport à la dernière sau­ve­garde sont copiées, le processus de sau­ve­garde requiert re­la­ti­ve­ment peu de temps, de bande passante et d’espace de stockage. Le prérequis à cela est que la période entre chaque sau­ve­garde in­di­vi­duelle demeure courte. Sinon, de gros volumes de données s’ac­cu­mu­lent et doivent être trans­fé­rés.

L’avantage inhérent aux sau­ve­gardes in­cré­men­tielles est illustré de façon nette par le terme « fenêtre de sau­ve­garde ». Il s’agit de la période durant laquelle une sau­ve­garde peut être créée sans perturber le bon fonc­tion­ne­ment du système. Si la quantité de données est telle que le processus de copie prendrait plus de temps que la fenêtre de sau­ve­garde ne le permet, il devient im­pos­sible de créer une sau­ve­garde complète lorsque le système est utilisé. Dans ce cas, il est conseillé de créer de petites sau­ve­gardes in­cré­men­tielles à de courts in­ter­valles.

L’in­con­vé­nient immédiat des sau­ve­gardes in­cré­men­tielles est le fait qu’un logiciel spé­cia­lisé s’avère en général né­ces­saire. Planifier la stratégie de sau­ve­garde nécessite également plus d’efforts que de créer des sau­ve­gardes complètes. Il en va de même pour la res­tau­ra­tion de l’état d’origine à partir des sau­ve­gardes. Les données étant dis­sé­mi­nées sur plusieurs sau­ve­gardes, le processus est plus complexe. Il existe également un risque plus élevé de perte de données. Si une sau­ve­garde in­cré­men­tielle au sein d’une chaîne est en­dom­ma­gée, l’intégrité de toutes les sau­ve­gardes ul­té­rieures sera impactée.

Les sau­ve­gardes in­cré­men­tielles visent avant tout à réduire les besoins en termes de stockage et de temps né­ces­saires à la création d’une sau­ve­garde. Elles sont dès lors toujours utilisées lorsque la création répétée de sau­ve­gardes complètes serait une aber­ra­tion lo­gis­tique. Examinons quelques scénarios en détail.

Pour créer une sau­ve­garde sous Mac, le mieux est d’utiliser l’outil de sau­ve­garde préins­tallé sur macOS « Time Machine ». Cet outil copie les chan­ge­ments subis par le stockage de données interne de manière in­cré­men­tielle vers un disque dur externe. Comme à l’ac­cou­tu­mée avec les sau­ve­gardes in­cré­men­tielles, une sau­ve­garde complète initiale est créée lors de sa première exécution. Les mo­di­fi­ca­tions ul­té­rieures apportées au système de fichier sont ré­per­to­riées par des journaux et dis­po­nibles pour de futures sau­ve­gardes.

Time Machine vous permet de restaurer des fichiers in­di­vi­duels vers des points an­té­rieurs dans le temps. Par ailleurs, le système dans son entier peut être re­cons­ti­tué depuis la sau­ve­garde. C’est pratique si votre matériel bat de l’aile ou si vous souhaitez migrer votre système vers une nouvelle machine. Sa gestion facile du logiciel de sau­ve­garde est tout à fait im­pres­sion­nante. L’uti­li­sa­teur n’a qu’à connecter un disque dur externe et lancer le processus de sau­ve­garde ; le reste est au­to­ma­tique.

Les sau­ve­gardes in­cré­men­tielles sont également dis­po­nibles sous Windows. D’un côté, une sau­ve­garde peut être créée dans Windows 10 à l’aide de Windows Backup. D’un autre côté, vous pouvez utiliser l’outil de sau­ve­garde Robocopy dans la ligne de commande pour sau­ve­gar­der les contenus d’un ré­per­toire par in­cré­ments. Examinons un exemple :

L’option /MIR signifie « miroir ». La commande met en miroir le ré­per­toire source vers le chemin de des­ti­na­tion. Si un ré­per­toire portant le même nom existe déjà, une sau­ve­garde in­cré­men­tielle sera réalisée. Robocopy trans­fè­rera ensuite uni­que­ment les chan­ge­ments remontant à la dernière opération de sau­ve­garde.

Robocopy n’existe que sous Windows. Pour créer une sau­ve­garde de serveur avec Rsync sous Linux, on a recours à une sau­ve­garde in­cré­men­tielle. Pour commencer, une sau­ve­garde complète est créée. Lorsque la commande est ensuite appelée, Rsync transfère les chan­ge­ments apportés aux blocs à compter de la dernière sau­ve­garde seulement. Les données trans­fé­rées et le jeu de données existant sont fusionnés. Ainsi, il résulte de cette opération une sau­ve­garde complète syn­thé­tique. Voici un exemple d’un appel rsync cor­res­pon­dant :