Pourquoi une politique de conservation GFS supprime-t-elle plus de points de restauration que ne le suggèrent les nombres de conservation ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Une politique de rétention GFS peut supprimer plus de points de restauration que prévu, car les nombres à conserver correspondent à des périodes, et non à une simple addition de sauvegardes indépendantes.

Les règles telles que conserver les dernières sauvegardes, conserver des sauvegardes quotidiennes, hebdomadaires, mensuelles et annuelles sélectionnent généralement des points de restauration représentatifs de périodes qui se chevauchent. Une même sauvegarde peut satisfaire plusieurs niveaux de période, tandis qu’une autre peut ne correspondre à aucune période en raison de son horodatage, de son groupe source, de l’héritage de la politique ou d’une modification récente de celle-ci. Certains outils traitent les règles dans un ordre défini ou excluent des niveaux suivants les sauvegardes déjà sélectionnées. Prévisualisez le calendrier exact avant d’exécuter le nettoyage ou la compaction.

Répertoriez chaque point de restauration avec son groupe de politiques et son horodatage

Exportez les identifiants des instantanés ou des archives, l’hôte source, le chemin, les balises, l’état d’achèvement, l’heure locale, l’heure UTC et la politique appliquée à chaque groupe. Ne comptez pas toutes les sources ou tous les dépôts ensemble.

Restic applique les politiques de rétention à des groupes d’instantanés en fonction de l’hôte, des chemins et des balises, sauf si le regroupement est modifié. Ainsi, deux points de restauration visuellement similaires peuvent être évalués selon des politiques différentes.

Si les suppressions inattendues ne concernent qu’un hôte, un chemin ou un groupe de balises, corrigez ce groupe ou ce sélecteur plutôt que de modifier la rétention à l’échelle du dépôt.

N’additionnez pas les nombres quotidiens, hebdomadaires et mensuels

Associez chaque point de restauration à la période qu’il représente. Indiquez si la même sauvegarde est sélectionnée comme candidate quotidienne, hebdomadaire et mensuelle.

Le simulateur de nettoyage de Proxmox affiche les périodes de rétention qui se chevauchent, notamment les cas où une candidate hebdomadaire couvre une période et où les règles suivantes ne conservent pas une autre sauvegarde du même intervalle.

Le total attendu n’est donc pas toujours égal à la somme des valeurs quotidiennes, hebdomadaires et mensuelles à conserver. Comptez les identifiants de sauvegarde uniques conservés après l’application de toutes les règles.

Vérifiez l’ordre des règles et la candidate choisie pour chaque période

Déterminez si la sauvegarde la plus récente, la plus ancienne, la première ou la dernière sauvegarde réussie de chaque période est sélectionnée. Comparez ce choix avec l’heure réelle d’exécution de la tâche.

Borg décrit ses règles de nettoyage de type GFS et précise que le traitement des limites de calendrier peut affecter les archives proches de l’heure limite.

Une tâche exécutée juste avant et juste après minuit peut créer deux sauvegardes qui semblent correspondre à des dates locales différentes, mais qui se trouvent dans une seule fenêtre de politique après conversion du fuseau horaire ou du planificateur.

Examinez les politiques héritées au niveau du dépôt, de l’utilisateur et de la source

Exportez la politique effective au lieu de consulter uniquement les valeurs par défaut globales. Vérifiez les remplacements par source, les valeurs héritées, les balises, les dossiers et les préréglages de l’interface.

La commande de politique de Kopia prend en charge les valeurs de rétention héritées par source, ce qui peut rendre la règle active différente du paramètre affiché au niveau du dépôt ailleurs.

Une valeur locale de conservation égale à zéro ou une modification de la limite d’héritage peut supprimer des points de restauration, même si la politique parente semble correcte. Enregistrez la politique résolue avec l’audit.

Examinez les réductions récentes de la politique et le calendrier du nettoyage

Comparez les valeurs de rétention actuelles avec les versions précédentes de la politique et avec la date du dernier nettoyage. Déterminez si les points plus anciens ont été immédiatement marqués comme arrivant à expiration.

Microsoft indique que la réduction de la rétention affecte les points de récupération existants lors d’une tâche de nettoyage ultérieure, et pas uniquement les futures sauvegardes.

Un nettoyage différé peut donner l’impression que de nombreuses suppressions se produisent simultanément. Conservez l’historique de la modification de la politique ainsi que la liste des points marqués avant d’autoriser une nouvelle exécution.

Vérifiez les indicateurs GFS, la rétention à court terme et la conversion de la politique

Vérifiez que les indicateurs hebdomadaires, mensuels et annuels sont toujours associés et que la chaîne à court terme peut encore prendre en charge les points sélectionnés. Examinez les mises à niveau logicielles et les conversions de politiques.

Veeam avertit que la modification des paramètres GFS peut entraîner la perte du statut GFS de candidates existantes, qui deviennent alors éligibles à une suppression ordinaire à court terme.

Ne supposez pas que l’ancien nom de fichier d’un point de restauration ou son rôle de sauvegarde complète garantit sa rétention actuelle à long terme. Vérifiez son indicateur de politique actif.

Exécutez un mode dry-run ou un simulateur avant le nettoyage et la compaction

Gelez les modifications de politique, exportez la liste actuelle des points de restauration, exécutez le mode dry-run ou le simulateur de la plateforme, puis comparez les identifiants conservés et supprimés avec un échantillon vérifié manuellement.

L’article de ZimaSpace consacré aux historiques volumineux d’instantanés fournit le contexte de récupération associé. Cet article se concentre sur les raisons pour lesquelles le calcul de la rétention diffère d’un simple décompte.

Le problème est résolu lorsque le simulateur, la politique effective et les identifiants uniques conservés concordent sur au moins deux limites de calendrier, et qu’aucune fenêtre de récupération requise ne dépend d’un point marqué pour suppression.

Foire aux questions

Les nombres de sauvegardes quotidiennes et hebdomadaires à conserver sont-ils cumulatifs ?

Pas nécessairement. Le même point de restauration peut représenter les deux périodes, ou le moteur de rétention peut exclure des candidates déjà couvertes par les règles suivantes.

La réduction de la rétention peut-elle supprimer des points de restauration existants ?

Oui. De nombreux systèmes appliquent la nouvelle politique aux points existants lors du prochain nettoyage, et pas uniquement aux futures sauvegardes.

Le nettoyage libère-t-il immédiatement de l’espace dans le dépôt ?

Cela dépend de l’outil. Certains systèmes marquent d’abord les instantanés ou les archives, puis récupèrent les données partagées lors d’une étape distincte de compaction ou de collecte des données inutilisées.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.