Comment empêcher la réplication des instantanés de saturer le pool de destination
La réplication des instantanés remplit un pool de destination lorsque les instantanés conservés et les blocs modifiés s’accumulent plus vite que la politique de nettoyage de la destination ne peut les libérer.
La solution préventive consiste à concevoir la conservation à la source, la conservation à la destination, la cadence de réplication et les alertes d’espace libre comme une seule politique. Une réplique peut légitimement conserver davantage d’historique que la source, mais ce choix doit être encadré. Suivez les instantanés nécessaires comme bases incrémentielles, la quantité de données uniques immobilisées par les anciens instantanés, la possibilité de remplacer certains instantanés locaux de la source par des signets, ainsi que la marge restante avant l’arrivée du prochain important ensemble de modifications.
Définissez explicitement une politique de conservation à la destination
Décidez combien de points de restauration horaires, quotidiens, hebdomadaires et mensuels la destination doit conserver, et documentez pourquoi cet historique diffère de celui de la source. Ne supposez pas que le logiciel de réplication supprimera automatiquement tous les anciens instantanés de destination lorsque la source les supprime.
Une présentation de la réplication ZFS explique que la réplication nécessite une politique d’instantanés, car les instantanés sont à la fois des points de récupération et des limites de transfert incrémentiel.
Appliquez la conservation la plus courte aux jeux de données très modifiés, sauf si un historique plus long présente une valeur concrète pour la récupération. Conservez les archives peu modifiées selon un calendrier différent afin qu’une politique globale ne gaspille pas d’espace là où des points de restauration fréquents apportent peu de valeur.
Estimez la quantité de modifications immobilisées par les anciens instantanés
Mesurez la valeur USED des instantanés, les données écrites entre les instantanés et l’espace libre du pool de destination avant et après d’importantes suppressions, déplacements, remplacements de médias ou réécritures de machines virtuelles. Un instantané peut conserver d’anciens blocs actifs même après la disparition des données actives.
Une note de TrueNAS sur la réplication avertit que le foisonnement des instantanés conserve les anciens blocs, même lorsque le jeu de données actif actuel devient plus petit.
Utilisez ce taux de modification pour dimensionner la conservation. Une destination conservant 30 jours d’images de machines virtuelles qui changent rapidement peut nécessiter bien plus de capacité qu’un autre jeu de données de même taille active, mais composé principalement de photos familiales auxquelles on ajoute des éléments sans les réécrire.
Réservez une marge dans le pool pour la prochaine réplication
Définissez un seuil opérationnel d’espace libre qui tient compte de l’incrément le plus important susceptible d’arriver, de la croissance des instantanés locaux et des frais généraux normaux du système de fichiers. Déclenchez une alerte avant d’atteindre ce seuil, et non lorsque le pool est déjà presque plein.
La discussion d’Oracle sur la conservation des instantanés souligne que la conservation contrôle la croissance des instantanés, au lieu de considérer les instantanés comme gratuits parce que leur création est initialement peu coûteuse.
Mettez en pause la conservation non critique ou raccourcissez-la avant que la destination n’atteigne une situation d’urgence. Une cible de réplication a besoin d’espace pour recevoir et valider de nouveaux blocs ; ne laisser que l’espace nécessaire au jeu de données actif d’aujourd’hui n’est donc pas une stratégie de capacité sûre.
Utilisez des signets lorsqu’ils préservent l’historique incrémentiel
Lorsque votre version de ZFS et vos outils de réplication prennent en charge les signets, vérifiez si un signet peut préserver la référence d’envoi incrémentiel après qu’un ancien instantané source n’est plus nécessaire comme point de restauration local complet.
Une conception de sauvegarde hors site montre comment les signets préservent les bases incrémentielles tout en permettant de gérer séparément la conservation des instantanés.
Ne remplacez pas tous les instantanés par des signets. L’historique de restauration de la destination nécessite toujours de véritables instantanés, et les outils de réplication diffèrent dans leur gestion des bases communes. Utilisez les signets uniquement lorsqu’ils simplifient la gestion côté source sans compromettre l’objectif de récupération de la destination.
Protégez uniquement les instantanés encore nécessaires à la réplication
Identifiez l’instantané commun le plus récent partagé par la source et la destination avant toute purge. Lorsque les outils utilisent des verrous ou des protections équivalentes, vérifiez que les tâches de nettoyage les respectent et que les verrous obsolètes sont finalement libérés.
Le manuel ZFS de FreeBSD explique que les verrous protègent les instantanés partagés jusqu’à leur libération explicite.
Ne conservez pas tous les instantanés historiques simplement parce qu’une seule base commune est nécessaire. Protégez le petit ensemble réellement requis par la réplication, puis laissez la politique de conservation de la destination gérer les anciens points de récupération indépendants.
Auditez séparément les instantanés de réplication et l’historique des sauvegardes
Certains outils créent leurs propres instantanés de synchronisation en plus de vos instantanés horaires ou quotidiens planifiés. Répertoriez ces deux catégories sur la destination et assurez-vous que l’ensemble généré par l’outil ne peut pas croître sans règle de nettoyage.
Une discussion sur Sanoid et Syncoid explique que les instantanés de synchronisation servent de garde-fous, plutôt que chaque instantané de réplication soit destiné à constituer un historique de sauvegarde à long terme.
Examinez la destination chaque mois ou après tout déplacement important de jeu de données. La politique est saine lorsque les points de restauration attendus sont conservés, que le prochain incrément dispose d’une base commune valide et que l’espace libre du pool reste supérieur au seuil défini. L’article ZimaSpace associé sur le diagnostic de l’espace occupé par les instantanés constitue la procédure de récupération lorsque la destination est déjà pleine de manière inattendue.
Foire aux questions
La destination doit-elle conserver exactement les mêmes instantanés que la source ?
Pas nécessairement. Une cible de sauvegarde peut conserver un historique plus long, mais la différence doit être intentionnelle, testée en fonction de la capacité et régie par sa propre politique de conservation.
La suppression de fichiers sur la source libère-t-elle immédiatement de l’espace sur la destination ?
Non. Les instantanés répliqués peuvent continuer à référencer d’anciens blocs après la disparition du fichier actif. L’espace n’est libéré que lorsqu’aucun instantané conservé ni aucune autre référence n’a encore besoin de ces blocs.
La suppression de l’instantané le plus ancien libère-t-elle toujours le plus d’espace ?
Non. L’espace des instantanés est partagé entre les points de récupération. Estimez ou mesurez l’espace référencé de manière unique et protégez tout instantané commun encore nécessaire à la réplication incrémentielle.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
