Bienvenue lecteurs de notre blog ! D'une certaine manière, nous nous connaissons déjà – mes articles en anglais ont été publiés ici grâce à la traduction de ma chère collègue . Cette fois, j'ai décidé de m'adresser directement à un public francophone.
Pour mes débuts, je souhaitais trouver un sujet intéressant pour le plus large public possible et nécessitant un examen approfondi. Daniel Defoe affirmait que la mort et les impôts attendent chacun. Pour ma part, je peux dire que les ingénieurs de support sont souvent confrontés à des questions sur les politiques de conservation des points de restauration (ou plus simplement – la rétention). Comment fonctionne la rétention, j'ai commencé à l'expliquer il y a 4 ans, en tant qu'ingénieur junior de premier niveau, et je continue à l'expliquer maintenant, en étant devenu chef d'équipe d'une équipe hispanophone et italophone. Je suis convaincu que mes collègues des niveaux deux et trois de support répondent également régulièrement aux mêmes questions.
Dans cette perspective, j'ai souhaité rédiger un article final, aussi détaillé que possible, auquel les utilisateurs francophones pourraient revenir encore et encore comme à un guide. Le moment est opportun – la récente sortie de la dixième version anniversaire a ajouté de nouvelles fonctionnalités à une base fonctionnelle qui n'a pas changé depuis des années. Mon article est principalement axé sur cette version — bien que la majeure partie de ce qui est écrit soit applicable aux versions antérieures, certaines des fonctionnalités décrites ne s'y trouveront tout simplement pas. Enfin, en regardant un peu vers l'avenir, je dirai que des changements sont attendus dans la prochaine version, mais nous en parlerons en temps voulu. Alors, commençons.

Tâches de sauvegarde (Backup job)
Pour commencer, examinons la partie qui n'a pas changé dans la version 10. La politique de rétention est définie par plusieurs paramètres. Ouvrons la fenêtre de création d'une nouvelle tâche et allons à l'onglet Stockage. Ici, nous verrons un paramètre qui définit le nombre souhaité de points de restauration :

Cependant, ce n'est qu'une partie de l'équation. Le nombre réel de points est également déterminé par le mode de sauvegarde défini pour la tâche. Pour sélectionner ce paramètre, il faut cliquer sur le bouton Avancé dans le même onglet. Cela ouvrira une nouvelle fenêtre avec de nombreuses options. Numérotant celles-ci, nous les examinerons une par une :

Si vous activez uniquement l'option 1, la tâche fonctionnera en mode « incrémental infini » (forever forward incremental). Il n'y a aucune difficulté ici : la tâche conservera le nombre défini de points de restauration allant de la sauvegarde complète (fichier avec l'extension VBK) jusqu'au dernier incrément (fichier avec l'extension VIB). Lorsque le nombre de points dépassera la valeur définie, le plus ancien incrément sera fusionné avec la sauvegarde complète. En d'autres termes, si la tâche est configurée pour conserver 3 points, alors immédiatement après la dernière session, il y aura 4 points dans le dépôt, après quoi la sauvegarde complète sera fusionnée avec le plus ancien incrément et le nombre total de points reviendra à 3.

La gestion des rétentions pour le mode « incrémental inversé » (reverse incremental) (option 2) est également très simple. Dans ce cas, le point le plus récent sera la sauvegarde complète, suivi d'une chaîne de ce que l'on appelle des rollbacks (fichiers avec l'extension VRB), donc pour appliquer la rétention, il suffit de supprimer le rollback le plus ancien. La situation sera la même : immédiatement après la session, le nombre de points dépassera la valeur définie de 1, puis reviendra à la valeur souhaitée.

Veuillez noter qu'avec le mode incrémental inversé, il est également possible d'inclure une sauvegarde complète périodique (option 4), mais cela ne changera rien à l'essentiel. Oui, des points de restauration complets apparaîtront dans la chaîne, mais nous continuerons simplement à supprimer les points les plus anciens un par un.
Enfin, nous arrivons à la partie intéressante. Si vous activez la sauvegarde incrémentale, mais en plus activez les options 3 ou 4 (vous pouvez également les activer toutes les deux), la tâche commencera à créer des sauvegardes complètes périodiques de manière « active » ou synthétique. La méthode utilisée pour créer la sauvegarde complète n'est pas importante - elle contiendra les mêmes données, et la chaîne incrémentale sera divisée en « sous-chaînes ». Cette méthode est appelée incrémental avant, et c'est elle qui soulève une grande partie des questions de nos clients.
La rétention est appliquée ici en supprimant la partie la plus ancienne de la chaîne (du sauvegarde complète jusqu'à l'incrément). Cependant, nous ne supprimerons pas uniquement la sauvegarde vide ou seulement une partie des incréments. L'ensemble de la « sous-chaîne » est complètement effacée en une fois. Le sens de la configuration du nombre de points change : alors que dans d'autres méthodes c'est un nombre maximum autorisé après lequel la rétention doit être appliquée, ici cette configuration définit le nombre minimum. En d'autres termes, après la suppression de la « sous-chaîne » la plus ancienne, le nombre de points dans la partie restante ne doit pas tomber en dessous de ce minimum.
Je vais essayer de représenter ce concept graphiquement. Supposons que la rétention est fixée sur 3 points, la tâche fonctionne chaque jour avec une sauvegarde complète le lundi. Dans ce cas, la rétention sera appliquée lorsque le nombre total de points atteindra 10 :

Pourquoi 10, alors qu'on a fixé 3 ? Un sauvegarde complète a été créée lundi. Du mardi au dimanche, la tâche a créé des incréments. Enfin, le lundi suivant, une sauvegarde complète est à nouveau créée et seulement après que 2 incréments aient été créés, toute l'ancienne partie de la chaîne peut être supprimée, car le nombre de points restants ne tombera pas en dessous des 3 établis.
Si l'idée est claire, je vous propose d'essayer de calculer la rétention vous-même. Prenons les conditions suivantes : la tâche s'exécute pour la première fois jeudi (évidemment, une sauvegarde complète sera faite). La tâche est configurée pour créer une sauvegarde complète le mercredi et le dimanche et conserver 8 points de restauration. Quand la rétention sera-t-elle appliquée pour la première fois ?
Pour répondre à cette question, je vous recommande de prendre une feuille de papier, de la diviser par jours de la semaine et d’écrire quel point est créé chaque jour. La réponse deviendra évidente.
Réponse

Explication : pour répondre, il suffit de se demander « quand la rétention sera-t-elle appliquée ? ». La réponse – quand nous pourrons supprimer les 3 premiers points (VBK, VIB, VIB) et que la chaîne restante ne tombe pas en dessous des 8 points requis. Il devient clair que nous pourrons le faire lorsque nous aurons un total de 11 points, c'est-à-dire le dimanche de la deuxième semaine.
Certains lecteurs pourraient objecter : « à quoi bon tout cela, s'il y a ?». Без сомнения, это очень полезный инструмент, и в некоторых случаях я бы применял именно его, но есть у него и ограничения. Прежде всего, он не позволяет указать начальные условия, а во многих случаях случаев вопрос звучит именно «у нас есть такая цепочка, что будет, если изменить такие-то настройки?». Во-вторых, инструменту все-таки несколько не хватает наглядности. Показывая страничку RPS клиентам, я не находил понимания, а вот расписав ее как в примере (даже используя тот же Paint), день за днем, все становилось ясно.
Enfin, nous n'avons pas abordé l'option « Transformer les chaînes de sauvegarde précédentes en rollbacks » (marquée par le chiffre 5). Cette option peut parfois dérouter les clients qui l'activent automatiquement, désireux d'inclure simplement une sauvegarde synthétique. Cependant, cette option active un mode de sauvegarde complètement spécifique. Sans entrer dans les détails, je dirai immédiatement qu'à ce stade du développement du produit, l'option « Transformer les chaînes de sauvegarde précédentes en rollbacks » est obsolète, et je ne peux imaginer aucun scénario où elle devrait être utilisée. Sa valeur est si douteuse que pendant un certain temps, Anton Gostev lui-même a lancé un appel sur le forum, demandant des exemples de son utilisation utile (si vous en avez, écrivez dans les commentaires, cela m'intéresse beaucoup). S'il n'y en a pas (je pense que ce sera le cas), cette option sera supprimée dans les prochaines versions.
La tâche créera des incréments (VIB) jusqu'au jour où une sauvegarde complète synthétique est prévue. Ce jour-là, un VBK sera effectivement créé, mais tous les points avant ce VBK seront transformés en rollbacks (VRB). Après cela, la tâche continuera à créer des incréments vers la sauvegarde complète jusqu'à la prochaine sauvegarde synthétique. Au final, la chaîne contiendra un mélange explosif de fichiers VBK, VBR et VIB. La rétention s'applique simplement – en supprimant le dernier VBR :

Problèmes
En plus de comprendre comment cela fonctionne, la plupart des problèmes rencontrés lors de l'utilisation du mode incrémental sont généralement liés à la sauvegarde complète. Une sauvegarde complète régulière est nécessaire pour ce mode, sinon le répertoire accumulera des points jusqu'à ce qu'il soit plein.
Par exemple, une sauvegarde complète peut être créée trop rarement. Disons que la tâche est configurée pour conserver 10 points, alors qu'une sauvegarde complète est réalisée une fois par mois. Il est évident que le nombre réel de points sera bien supérieur à celui spécifié. Ou bien la tâche est configurée pour fonctionner en mode incrémental infini et conserver 50 points. Ensuite, quelqu'un a accidentellement créé une sauvegarde complète. À partir de ce moment, la tâche attendra jusqu'à ce que le point complet accumule 49 incréments, après quoi elle appliquera la rétention et reviendra en mode complet infini.
Dans d'autres cas, une sauvegarde complète est censée être effectuée régulièrement, mais pour une raison quelconque, cela ne se produit pas. Voici la raison la plus courante. Certains clients préfèrent utiliser l'option de programmation “run after” et configurer les tâches pour qu'elles fonctionnent en chaîne. Prenons un exemple : il y a 3 tâches qui s'exécutent chaque jour et effectuent une sauvegarde complète le dimanche. La première tâche commence à 22h30, les autres s'exécutent en chaîne. La sauvegarde incrémentielle prend 10 minutes, donc à 23h00, toutes les tâches ont terminé. Cependant, la sauvegarde complète prend une heure, donc le dimanche, voici ce qui se passe : la première tâche fonctionne de 22h30 à 23h30. La suivante de 23h30 à 00h30. Et la troisième tâche ne commence que le lundi. La sauvegarde complète est programmée pour le dimanche, donc dans ce cas, elle n'existera tout simplement pas. La tâche attendra la sauvegarde complète pour appliquer la rétention. Donc, faites attention lorsque vous utilisez l'option “run after” ou ne l'utilisez pas du tout – configurez simplement les tâches pour qu'elles démarrent en même temps et laissez le planificateur de ressources faire son travail.
L'option complexe “Remove deleted items”
En consultant les paramètres de la tâche Stockage – Avancé – Maintenance, on peut tomber sur l'option “remove deleted items data after”, mesurée en jours.

Certains clients s'attendent à ce que cela corresponde à la rétention. En réalité, c'est une option complètement distincte, dont la mécompréhension peut entraîner des conséquences inattendues. Toutefois, tout d'abord, il est nécessaire d'expliquer comment B&R réagit aux situations où, au cours d'une session, seulement quelques machines sont sauvegardées avec succès.
Imaginons un tel scénario : une tâche d'incrémentation infinie, configurée pour conserver 6 points. La tâche comporte 2 machines, l'une est toujours sauvegardée avec succès, l'autre donne parfois des erreurs. En fin de compte, au septième point, la situation est la suivante :

Il est temps d'appliquer la rétention, mais une machine a 7 points, et l'autre seulement 4. La rétention sera-t-elle appliquée ici ? La réponse est oui, elle le sera. Si au moins un objet a été sauvegardé, B&R considère que le point a été créé.
Une situation similaire peut se produire si une machine n'a pas simplement été incluse dans la tâche pendant une certaine session. Cela arrive, par exemple, lorsque les machines sont ajoutées à la tâche non individuellement, mais en tant que conteneurs (dossiers, stockages) et qu'une machine migre temporairement dans un autre conteneur. La tâche sera alors considérée comme réussie, mais dans les statistiques, vous verrez un message vous invitant à prêter attention au fait qu'une certaine machine n'est plus traitée par la tâche.
![]()
Que se passera-t-il si on ignore cela ? Dans le cas de modes infiniment incrémentiels ou rétro-incrémentiels, le nombre de points de restauration de la machine « problématique » diminuera à chaque session, jusqu'à atteindre 1, sauvegardée dans le VBK. En d'autres termes, même si la machine n'est pas sauvegardée pendant longtemps, un point de restauration restera tout de même. La situation est différente lorsque des sauvegardes complètes périodiques sont activées. Si vous ignorez les signaux de B&R, la dernière point pourrait finalement être supprimée avec l'ancienne partie de la chaîne.
Après avoir compris ces détails, nous pouvons enfin examiner l'option « Remove deleted items data after ». Elle supprimera tous les points pour une certaine machine si cette machine n'est pas sauvegardée pendant X jours. Veuillez noter que cette configuration ne réagit pas aux erreurs (essayer – échouer). Il ne doit même pas y avoir de tentative de sauvegarde de la machine. À première vue, cette option semble utile et devrait toujours être activée. Si un administrateur a supprimé une machine de la tâche, il est logique de nettoyer erronément les données inutiles et la chaîne après un certain temps. Cependant, cette configuration nécessite discipline et attention.
Je vais donner un exemple pratique : plusieurs conteneurs ont été ajoutés à la tâche, dont la composition était assez dynamique. En raison d'un manque de RAM, le serveur B&R a rencontré des problèmes qui sont restés inaperçus. La tâche a été lancée et a tenté de sauvegarder les machines, à l'exception d'une qui n'était pas présente dans le conteneur à ce moment-là. Comme de nombreuses machines ont renvoyé des erreurs, par défaut, B&R doit effectuer 3 tentatives supplémentaires pour sauvegarder les machines 'problématiques'. En raison de problèmes constants de RAM, ces tentatives se sont étendues sur plusieurs jours. Il n'y a pas eu de nouvelle tentative de sauvegarde de la machine manquante (l'absence de la machine n'est pas une erreur). En fin de compte, lors d'une des tentatives supplémentaires, la condition “Remove deleted items” a été exécutée et tous les points de la machine ont été supprimés.
À ce sujet, je peux dire ce qui suit : si vous avez configuré des alertes concernant les résultats des tâches, et mieux encore, si vous utilisez l'intégration avec Veeam ONE, il est probable que cela ne vous arrive pas. Si vous consultez le serveur B&R une fois par semaine pour vérifier que tout fonctionne, il vaut mieux se passer des options qui pourraient potentiellement entraîner la suppression des sauvegardes.
Quoi de neuf dans la v.10
Ce dont nous avons parlé auparavant existait dans B&R depuis de nombreuses versions. Maintenant que nous avons compris ces principes de fonctionnement, examinons les nouveautés de la 'dixième' version anniversaire.
Rétention quotidienne
Nous avons précédemment examiné la politique de stockage « classique », basée sur le nombre de points. Une approche alternative consiste à afficher dans le même menu “days” au lieu de “restore points”.

L'idée est claire à partir du nom : la rétention conservera un nombre défini de jours, le nombre de points chaque jour n'a pas d'importance. Il faut cependant garder à l'esprit les points suivants :
- Le jour en cours n'est pas pris en compte dans le calcul de la rétention
- Les jours où la tâche n'a pas fonctionné du tout sont également comptés. Cela doit être gardé à l'esprit pour ne pas perdre accidentellement les points de celles qui fonctionnent de manière irrégulière.
- Un point de restauration est considéré à partir du jour où sa création a commencé (c'est-à-dire si la tâche a commencé à fonctionner un lundi et s'est terminée un mardi, alors ce point est celui de lundi)
En ce qui concerne l'application des principes de rétention aux tâches, ceux-ci sont toujours déterminés par la méthode de sauvegarde choisie. Essayons une autre tâche de calcul, en utilisant la même méthode incrémentale. Supposons que la rétention soit fixée à 8 jours, la tâche fonctionne toutes les 6 heures avec une sauvegarde complète le mercredi. De plus, la tâche ne fonctionne pas le dimanche. La tâche est lancée pour la première fois le lundi. Quand la rétention sera-t-elle appliquée ?
Réponse
Comme d'habitude, il est préférable de dessiner un tableau. Je vais simplifier la tâche et ne pas dessiner tous les points créés chaque jour, car le nombre de points par jour n'a pas d'importance ici. Ce qui compte, c'est que le premier lundi et les mercredis, le premier point sera une sauvegarde complète, tandis que pendant les autres jours, la tâche créera simplement 4 points incrémentaux.

Nous comprenons que la rétention sera appliquée en supprimant la sauvegarde complète de lundi et son incrément. Quand cela se produira-t-il ? Lorsque le reste de la chaîne contiendra 8 jours. Nous ne comptons pas le jour actuel, et nous comptons le dimanche. Donc, la réponse est : le jeudi de la deuxième semaine.
Archivage par méthode GFS pour les tâches ordinaires
Jusqu'à la version 10, la méthode de stockage Grandfather-Father-Son (GFS) n'était disponible que pour les tâches de création de copies de sauvegarde et les tâches de copie sur bande magnétique. Maintenant, elle est également disponible pour les sauvegardes ordinaires.
Bien que cela ne concerne pas le sujet actuel, je ne peux m'empêcher de dire que la nouvelle fonctionnalité ne signifie pas un abandon de la stratégie 3-2-1. La présence des points d'archive dans le référentiel principal n'affecte en rien sa fiabilité. Il est sous-entendu que GFS sera utilisé en conjonction avec un référentiel extensible (Scale-out), pour décharger ces points vers S3 et d'autres types de stockage similaires. Si vous ne les utilisez pas, il est préférable de continuer à stocker les points primaires et d'archive dans des référentiels différents.
Examinons maintenant les principes de création des points GFS. Dans les paramètres de la tâche, à l'étape de stockage, un bouton spécial a été ajouté, qui appelle le menu suivant :

L'essence de GFS peut être résumée en quelques points (notez que GFS fonctionne différemment dans d'autres types de tâches, mais nous en parlerons un peu plus tard) :
- La tâche ne crée pas une sauvegarde complète séparée pour le point GFS. Au lieu de cela, la sauvegarde complète la plus adéquate parmi les sauvegardes existantes sera utilisée. Ainsi, la tâche doit fonctionner en mode incrémental avec une sauvegarde complète périodique, ou la sauvegarde complète doit être créée manuellement par l'utilisateur.
- S'il n'y a qu'une seule période activée (par exemple, hebdomadaire), alors au début de la période GFS, la tâche commencera simplement à attendre une sauvegarde complète et marquera la première appropriée comme GFS.
Exemple : la tâche est configurée pour conserver un GFS hebdomadaire en utilisant une sauvegarde le mercredi. La tâche s'exécute chaque jour, mais la sauvegarde complète est programmée pour vendredi. Dans ce cas, la période GFS commencera mercredi et la tâche commencera à attendre le point approprié. Il apparaîtra vendredi et sera marqué du drapeau GFS.

- Si plusieurs périodes sont activées en même temps (par exemple, hebdomadaire et mensuelle), alors B&R appliquera une méthode permettant d'utiliser le même point comme GFS pour plusieurs intervalles (pour économiser de l'espace). Les drapeaux seront attribués successivement, en commençant par le plus jeune.
Exemple : le GFS hebdomadaire est fixé pour mercredi, et le mensuel pour la dernière semaine du mois. La tâche s'exécute chaque jour et crée des sauvegardes complètes le lundi et le vendredi.
Pour simplifier, commençons le décompte à partir de l'avant-dernière semaine du mois. Au cours de cette semaine, une sauvegarde complète sera créée le lundi, mais elle sera ignorée car l'intervalle GFS hebdomadaire commence mercredi. En revanche, la sauvegarde complète de vendredi convient parfaitement pour le point GFS. Ce système nous est déjà familier.

Considérons maintenant ce qui se passe lors de la dernière semaine du mois. L'intervalle GFS mensuel commencera le lundi, mais la sauvegarde du lundi ne sera pas marquée comme GFS, car la tâche cherche à marquer un VBK à la fois comme point GFS mensuel et hebdomadaire. La recherche commence précisément par le point hebdomadaire, car celui-ci peut par définition devenir aussi mensuel.

Ainsi, si uniquement les intervalles hebdomadaire et annuel sont activés, ils agiront indépendamment l'un de l'autre et peuvent marquer 2 VBK séparés comme correspondant aux intervalles GFS.
Tâches de création de copie de sauvegarde
Un autre type de tâches, souvent nécessitant des clarifications sur leur fonctionnement. Pour commencer, examinons la méthode « classique » de travail, sans les innovations de la v.10.
Méthode simple de rétention
Par défaut, ces tâches fonctionnent en mode incrémental infini. La création de points est déterminée par deux paramètres : l'intervalle de sauvegarde et le nombre souhaité de points de restauration (il n'y a pas de rétention par jour ici). L'intervalle de sauvegarde est défini dans le premier onglet Job lors de la création de la tâche :

Le nombre de points est déterminé un peu plus loin dans l'onglet Target

La tâche crée un nouveau point pour chaque intervalle (le nombre de points qui ont été créés pour la VM par les tâches initiales n'a pas d'importance). À la fin de l'intervalle, le nouveau point est finalisé et, si nécessaire, la rétention est appliquée en combinant le VBK avec le plus ancien incrément. Ce mécanisme nous est déjà familier.
Méthode de rétention utilisant GFS
BCJ peut également stocker des points d'archive. Cela se configure dans le même onglet Target, un peu plus bas que les réglages du nombre de points de restauration :

Les points GFS peuvent être créés de deux manières : de manière synthétique, en utilisant des données sur le dépôt secondaire, ou en imitant une sauvegarde complète et en lisant toutes les données du dépôt primaire (activé par l'option marquée du chiffre 3). La rétention dans les deux cas est très différente, examinons-les séparément.
GFS synthétique
Dans ce cas, le point GFS n'est pas créé exactement le jour prévu. Au lieu de cela, le point GFS sera créé lorsque le VIB de ce jour, pour lequel la création du point GFS était prévue, sera combiné avec la sauvegarde complète. Cela entraîne parfois des malentendus, car le temps passe et le point GFS n'est toujours pas là. Seul un puissant chamane du support technique peut prédire quel jour le point apparaîtra. En réalité, pas de magie requise – il suffit de regarder le nombre de points définis et l'intervalle de synchronisation (combien de points sont créés chaque jour). Essayez de calculer vous-même avec cet exemple : la tâche est configurée pour conserver 7 points, l'intervalle de synchronisation est de 12 heures (c'est-à-dire 2 points par jour). Actuellement, il y a déjà 7 points dans la chaîne, aujourd'hui c'est lundi, et la création du point GFS est prévue pour aujourd'hui. Quel jour sera-t-il créé ?
Réponse
Il vaut mieux décrire comment la chaîne va évoluer dynamiquement, au fil des jours :

Ainsi, lundi, le dernier incrément de la chaîne est marqué comme GFS, mais aucun autre changement visible ne se produit. Chaque jour, la tâche crée 2 nouveaux points, et la rétention pousse la chaîne vers l'avant implacablement. Enfin, jeudi arrive le moment d'appliquer la rétention à cet incrément. Cette session prendra plus de temps que d'habitude, car la tâche ‘extraire’ les blocs nécessaires de la chaîne et crée un nouveau point complet. À partir de ce moment, la chaîne comptera déjà 8 points – 7 dans la chaîne principale + GFS.
Création de points GFS avec l'option “Lire le point entier”
Plus haut, j'ai mentionné que BCJ fonctionne en mode incrémental infini. Maintenant, nous allons aborder la seule exception à cette règle. Lorsqu'on active l'option “Lire le point entier”, un point GFS sera créé exactement le jour prévu. La tâche elle-même fonctionnera en mode incrémental avec des sauvegardes complètes périodiques, comme nous l'avons discuté précédemment. La rétention sera également appliquée en supprimant la partie la plus ancienne de la chaîne. Cependant, dans ce cas, seuls les incréments seront supprimés, et la sauvegarde complète sera conservée en tant que point GFS. En conséquence, lors du calcul de la rétention, les points marqués par les drapeaux GFS ne sont pas pris en compte.
Supposons que la tâche soit configurée pour conserver 7 points et créer un point GFS hebdomadaire le lundi. Dans ce cas, chaque lundi, la tâche créera effectivement une sauvegarde complète et la marquera comme GFS. La rétention sera appliquée lorsque, après avoir supprimé les incréments de la partie la plus ancienne, le nombre d'incréments restants ne tombera pas en dessous de 7. Voici à quoi cela ressemble schématiquement :

Ainsi, à la fin de la deuxième semaine, la chaîne comptera au total 14 points. Au cours de la deuxième semaine, la tâche a créé 7 points. Si c'était une tâche simple, la rétention aurait déjà été appliquée. Mais c'est BCJ avec une rétention GFS, donc nous ne comptons pas les points GFS, ce qui signifie qu'il n'y en a que 6. Donc, nous ne pouvons pas encore appliquer la rétention. Au cours de la troisième semaine, nous créons une sauvegarde complète supplémentaire avec le drapeau GFS. 15 points, mais nous ne comptons encore pas celui-ci. Et enfin, mardi de la troisième semaine, nous créons un incrément. Maintenant, si nous supprimons les incréments de la chaîne de la première semaine, le nombre total d'incréments satisfera à la rétention établie.
Comme déjà mentionné, dans cette méthode, il est très important que les sauvegardes complètes soient créées régulièrement. Disons que si l'on fixe la rétention principale à 7 jours, mais seulement 1 point annuel, il n'est pas difficile d'imaginer que les incréments s'accumuleront beaucoup plus que 7. Dans de tels cas, il est préférable d'utiliser la méthode synthétique de création de GFS.
Et encore une fois, “Supprimer les éléments supprimés”
Cette option est également disponible pour BCJ :

La logique de cette option est la même que dans les tâches de sauvegarde ordinaires : si la machine n'est pas traitée pendant le nombre de jours spécifié, ses données sont supprimées de la chaîne. Cependant, pour BCJ, l'utilité de cette option est objectivement plus élevée, et voici pourquoi.
En mode normal, BCJ fonctionne en mode incrémental infini, donc si à un moment donné la machine est supprimée de la tâche, la rétention supprimera progressivement tous les points de restauration jusqu'à ce qu'il n'en reste qu'un – dans le VBK. Maintenant, imaginons que la tâche est encore configurée pour créer des points GFS synthétiques. Quand il sera temps, la tâche devra créer un GFS pour toutes les machines dans la chaîne. Si une machine n'a tout simplement aucun nouveau point – eh bien, il faudra utiliser celui qui existe. Et cela à chaque fois. Au final, une telle situation peut se présenter :

Notez la section Fichiers : nous avons le VBK principal et 2 points GFS hebdomadaires. Et maintenant, regardons la section Points de restauration – en fait, ces fichiers contiennent la même image de machine. Évidemment, il n'y a aucun sens à avoir de tels points GFS, ils ne font que prendre de la place.
Cette situation n'est possible qu'avec l'utilisation de GFS synthétique. Pour éviter cela, utilisez l'option “Supprimer les éléments supprimés”. N'oubliez pas de la configurer sur un nombre de jours adéquat. Le support technique a vu des cas où l'option était configurée sur un nombre de jours inférieur à l'intervalle de synchronisation – BCJ commençait à s'agiter et supprimait des points sans avoir eu le temps de les créer.
Prenez également en compte que cette option ne touche pas les points GFS déjà créés. Si vous souhaitez nettoyer les archives, vous devez le faire manuellement – en cliquant avec le bouton droit sur la machine et en sélectionnant “Supprimer du disque” (dans la fenêtre qui apparaît, n'oubliez pas de cocher la case “Supprimer la sauvegarde complète GFS”):

Nouvelle fonctionnalité v.10 – copie immédiate (immediate copy)
Après s'être familiarisé avec la fonctionnalité ‘classique’, passons au nouveau. Il n'y a qu'une seule nouveauté, mais elle est très importante. C'est un nouveau mode de fonctionnement.

Il n'existe pas de notion de « temps de synchronisation » ici, la tâche surveillera en permanence l'apparition de nouveaux points et les copiera tous, peu importe combien il y en a. Cependant, la tâche reste incrémentale, donc même si la tâche principale crée un VBK ou un VRB, ces points seront copiés en tant que VIB. En dehors de cela, il n'y a aucune surprise en mode standard ou GFS, qui fonctionnent selon les règles décrites ci-dessus (bien que seul GFS synthétique soit disponible ici).
Les disques tournent. Caractéristiques des dépôts avec rotation de disques.
La menace permanente des ransomwares a fait de la sauvegarde de données sur un support inaccessible pour le virus un standard de facto en matière de sécurité. Une des options est d'utiliser des dépôts avec rotation de disques, où les disques sont utilisés à tour de rôle : alors qu'un disque est branché et accessible pour l'écriture, les autres sont stockés en lieu sûr.
Pour apprendre à B&R à travailler avec de tels dépôts, il est nécessaire, dans les paramètres du dépôt, à l'étape Repository, de cliquer sur le bouton Advanced et de sélectionner l'option correspondante :

Après cela, VBR s'attendra à ce que la chaîne existante disparaisse périodiquement du dépôt, ce qui indique une rotation de disque. Selon le type de dépôt et du type de tâche, B&R se comportera différemment. On peut le représenter avec le tableau suivant :

Examinons chaque option.
Tâche ordinaire et dépôt Windows.
Donc, nous avons une tâche qui sauvegarde des chaînes sur le premier disque. Lors de la rotation, la chaîne créée disparaît effectivement, et la tâche doit trouver un moyen de survivre à cette perte. Elle trouve du réconfort dans la création d'une sauvegarde complète. Ainsi, chaque rotation signifie une sauvegarde complète. Mais que se passe-t-il avec les points sur le disque déconnecté ? Ils sont mémorisés et pris en compte lors du calcul de la rétention. Ainsi, le nombre de points indiqué dans la tâche est le nombre de points à conserver sur tous les disques. Prenons un exemple :
La tâche fonctionne en mode infiniment incrémental et est configurée pour conserver 3 points de restauration. Mais nous avons également un deuxième disque, et nous effectuons une rotation une fois par semaine (il peut y avoir plus de disques, cela ne change rien à l'essentiel).
Au cours de la première semaine, la tâche créera des points sur le premier disque et fusionnera les points superflus. Ainsi, le nombre total de points sera de trois :

Ensuite, nous connectons le deuxième disque. Lors du démarrage de B&R, il remarquera que le disque a changé. La chaîne sur le premier disque disparaîtra de l'interface, mais les informations à son sujet resteront dans la base. La tâche enregistrera maintenant 3 points sur le deuxième disque. La situation globale sera donc la suivante :

Enfin, nous reconnectons le premier disque. Avant de créer un nouveau point, la tâche vérifiera quel est l'état de la rétention. Et la rétention, je le rappelle, est configurée pour conserver 3 points. En attendant, nous avons 3 points sur le disque 2 (qui est déconnecté et stocké dans un endroit sûr, inaccessible pour B&R) et 3 points sur le disque 1 (celui-ci est connecté). Il est donc possible de supprimer 3 points du disque 1, car ils dépassent la rétention. Ensuite, la tâche crée de nouveau une sauvegarde complète, et notre chaîne commence à ressembler à ceci :

Si la rétention est configurée pour conserver des jours au lieu d'un nombre de points, la logique reste la même. De plus, la rétention GFS n'est pas prise en charge du tout lors de l'utilisation de dépôts avec rotation des disques.
Tâche standard et dépôt Linux stockage réseau
Cette option est également possible, mais généralement moins recommandée en raison des limitations imposées. Lors de la rotation du disque et de la disparition de la chaîne, la tâche réagira de la même manière – en créant une sauvegarde complète. La limitation est liée à un mécanisme de rétention tronqué.
Ici, lors de la rotation, toute la chaîne sur le disque déconnecté est simplement supprimée de la base de données B&R. Notez bien – de la base de données, les fichiers eux-mêmes restent sur le disque. Ils peuvent être importés et utilisés pour la restauration, mais il est facile de deviner que tôt ou tard, de telles chaînes oubliées rempliront tout le dépôt.
La solution consiste à ajouter DWORD ForceDeleteBackupFiles comme indiqué sur cette page : . Après cela, la tâche commencera simplement à supprimer tout le contenu du dossier de la tâche ou du dossier du dépôt (selon la valeur) à chaque rotation.
Cependant, ce n'est pas une rétention élégante, mais une suppression de tout le contenu. Malheureusement, le support technique a rencontré des cas où le dépôt était simplement le répertoire racine du disque, où en plus des sauvegardes, d'autres données se trouvaient. Tout cela a été détruit lors de la rotation.
De plus, lorsque vous activez ForceDeleteBackupFiles, cela fonctionne pour tous les types de dépôts, ce qui signifie même que les dépôts sur Windows arrêteront d'appliquer la rétention et commenceront à supprimer le contenu. En d'autres termes, un disque local sous Windows est le meilleur choix pour un tel système de stockage de sauvegardes.
Copie de sauvegarde et dépôt Windows
Avec BCJ, les choses deviennent encore plus intéressantes. Non seulement il y a une rétention complète ici, mais il n'est pas nécessaire de faire une sauvegarde complète à chaque changement de disque ! Cela fonctionne comme suit :
Tout d'abord, B&R commence à créer des points sur le premier disque. Disons que nous avons configuré la rétention sur 3 points. La tâche fonctionnera en mode incrémental infini et combinera tout ce qui est superflu (je rappelle que la rétention GFS n'est pas prise en charge dans ce cas).

Ensuite, nous connectons le deuxième disque. Comme il n'a pas encore de chaîne, nous créons une sauvegarde complète, après quoi nous avons une deuxième chaîne de trois points :

Enfin, il est temps de reconnecter le premier disque. Et c'est ici que la magie commence, car la tâche ne créera pas de sauvegarde complète, mais continuera simplement la chaîne incrémentale :

Après cela, il y aura en fait une chaîne indépendante sur chaque disque. Ainsi, la rétention ici signifie non pas le nombre de points sur tous les disques, mais le nombre de points sur chaque disque individuellement.
Copie de sauvegarde et dépôt Linux de stockage en réseau
Et encore une fois, toute l'élégance disparaît si le dépôt n'est pas sur un disque local Windows. Ce scénario fonctionne de manière similaire à celui considéré ci-dessus avec une simple tâche. À chaque rotation, BCJ créera une sauvegarde complète, et les points existants seront oubliés. Pour ne pas manquer d'espace libre, il est nécessaire d'utiliser DWORD ForceDeleteBackupFiles.
Conclusion
Ainsi, à la suite de ce long texte, nous avons examiné deux types de tâches. Bien sûr, il y a beaucoup plus de tâches, mais il n'est pas possible de les examiner toutes dans le cadre d'un seul article. Si vous avez des questions après la lecture, n'hésitez pas à les poser dans les commentaires, je serai ravi de répondre personnellement.
Source : habr.com
