Pourquoi une sauvegarde incrémentielle est-elle presque aussi volumineuse qu'une sauvegarde complète ?

Une sauvegarde incrémentielle peut devenir presque aussi volumineuse qu’une sauvegarde complète lorsque la source réécrit réellement de nombreux blocs, que le moteur de sauvegarde perd sa référence de changement précédente, que la portée protégée change, ou que le chiffre que vous lisez correspond à la croissance du dépôt plutôt qu’à la charge utile incrémentielle actuelle. Diagnostiquez ces possibilités séparément avant de supprimer des points de restauration, réinitialiser le travail ou lancer une nouvelle sauvegarde complète.

Identifiez d’abord quel chiffre semble trop élevé

« L’incrémentiel est de taille complète » peut décrire quatre mesures différentes. Elles ne sont pas interchangeables et chacune indique une cause différente.

Enregistrez les quatre chiffres pour une exécution. Un travail qui scanne 8 To mais transfère 12 Go se comporte très différemment d’un autre qui transfère et écrit 7 To.

Confirmez si la charge de travail a vraiment autant changé

Le logiciel de sauvegarde au niveau du volume protège les blocs de stockage modifiés, pas la taille visible par l’utilisateur des documents édités. Une petite modification peut altérer un bloc plus grand, et les services actifs modifient continuellement les journaux, index, bases de données, caches et fichiers système. Une discussion récente d’administrateurs explique pourquoi un octet modifié peut faire qu’un bloc de sauvegarde contenant fasse partie de l’incrément suivant.

Vérifiez si la grande opération a suivi l’un de ces événements :

• Maintenance de base de données, compactage, réindexation ou croissance du journal des transactions
• Mises à jour de machines virtuelles, activité de swap, analyses antivirus ou défragmentation invité
• Transcodage média, réindexation de bibliothèque photo, régénération de vignettes ou réécritures de métadonnées
• Fichiers volumineux d'archives, de conteneurs chiffrés, de boîtes aux lettres ou d'images disque réécrits sur place
• Équilibrage du système de fichiers, expansion du pool, relocalisation de blocs ou consolidation de snapshots

Comparez la fenêtre de sauvegarde avec les journaux d'application et les graphiques d'écriture de stockage. Si les écritures source ont augmenté en même temps, la sauvegarde peut signaler un delta réel plutôt qu'une erreur de sauvegarde.

Vérifiez si le suivi des modifications a perdu sa référence

Les systèmes de suivi par blocs comparent l'état actuel avec un ID de changement précédent connu. Un retour à un snapshot, une réinitialisation du suivi, une carte de changement invalide, une migration d'hôte, une session antérieure échouée ou la recréation d'une tâche de sauvegarde peuvent rompre cette relation. L'exécution suivante peut alors lire ou protéger l'ensemble de la source pour établir une base sûre. Un guide pratique de récupération CBT note que la réinitialisation du suivi des changements peut nécessiter un nouveau plein actif avant que les incrémentiels normaux ne reprennent.

Recherchez des termes dans les journaux tels que CBT réinitialisé, ID de changement invalide, journal bouclé, base de référence manquante, nouvelle chaîne, ou analyse complète requise. Ne réinitialisez pas le suivi de manière répétée sans conserver les journaux ; des réinitialisations répétées peuvent masquer le déclencheur initial et produire des exécutions complètes répétées.

Vérifiez que la portée de la sauvegarde et l'identité de la source n'ont pas changé

Une tâche peut encore être étiquetée incrémentielle tout en protégeant une source différente de celle d'avant. Un nouveau montage sous un chemin inclus, un redimensionnement du système de fichiers, un identifiant de périphérique modifié, un nom d'hôte différent, un nouveau chemin de partage ou une règle d'inclusion étendue peuvent amener le moteur à construire de nouvelles structures internes. Le dépannage communautaire montre que des volumes et points de montage supplémentaires peuvent être intégrés dans une tâche qui semble inchangée.

Exportez les définitions des tâches précédente et actuelle et comparez-les :

• Racines protégées, montages, partages, ensembles de données et disques virtuels
• Identifiants d'hôte, de volume et de système de fichiers
• Modèles d'inclusion et d'exclusion
• Fournisseur de snapshot et mode de cohérence
• Paramètres de chiffrement, compression et déduplication

Si la source a été intentionnellement étendue, un incrément complet peut être attendu. Si chaque exécution ultérieure reste volumineuse, poursuivez le diagnostic.

Déterminez si la granularité de la sauvegarde correspond aux fichiers

Les moteurs de découpage au niveau des fichiers, des blocs et définis par le contenu réagissent différemment aux modifications, renommages et réécritures. Un système de déduplication par blocs peut n'enregistrer que les métadonnées lorsqu'un dossier est déplacé ; un moteur plus simple au niveau des fichiers peut traiter le chemin déplacé comme un fichier supprimé plus un nouveau fichier. Dans un exemple basé sur les blocs, renommer un répertoire modifie les métadonnées du chemin sans re-télécharger tous les blocs de données inchangés.

Les gros fichiers modifiables nécessitent une attention particulière. Une base de données, une image VM, un coffre-fort chiffré ou une archive monolithique peut être entièrement lue pour détecter de petits changements internes, et la quantité finalement stockée dépend des limites des morceaux et de la déduplication. Une discussion sur les grandes bases de données décrit comment un fichier de base de données de plusieurs gigaoctets peut être lu en entier même lorsque seuls les morceaux modifiés sont transférés.

Si l'application fournit une exportation cohérente, une sauvegarde de journal de transactions ou une méthode de sauvegarde consciente de l'application, comparez ce flux de travail avec la sauvegarde du fichier monolithique en direct.

Séparez un grand incrément de l'activité de sauvegarde complète synthétique et de rétention.

Une sauvegarde complète synthétique est assemblée dans le dépôt à partir d'une sauvegarde complète antérieure plus des incrémentaux ultérieurs. Elle peut créer un objet de récupération de taille complète sans relire toute la source. Un aperçu des types de sauvegarde explique que les sauvegardes complètes synthétiques sont construites à partir de la chaîne complète et incrémentale existante.

La croissance du dépôt peut aussi rester élevée lorsque les anciens points de restauration restent verrouillés, que l'élagage n'a pas été effectué, que des instantanés supprimés référencent encore des morceaux, ou qu'une fusion nécessite temporairement de l'espace de travail. Vérifiez la chronologie de la tâche plutôt que de juger à partir d'une seule liste de répertoires :

Effectuez un test à variable unique avant de reconstruire la chaîne de sauvegarde.

1. Sauvegardez la configuration actuelle de la tâche, les journaux détaillés, la liste des points de restauration et la capacité du dépôt.
2. Choisissez une période de test calme et mettez en pause les applications à forte écriture si cela est sûr.
3. Créez un petit fichier test, modifiez-le une fois, puis lancez la même tâche incrémentale sans changer les paramètres.
4. Enregistrez les octets scannés, transférés, écrits, dédupliqués et conservés.
5. Exécutez un deuxième incrémental sans modification de la source.

Si les deux exécutions contrôlées restent de taille normale, concentrez-vous sur le suivi, l'identité de la source ou la configuration de la chaîne de tâches. Si elles deviennent petites, restaurez les charges de travail normales une par une jusqu'à ce que le taux de changement revienne. Cela permet de distinguer le comportement du moteur de sauvegarde du renouvellement des applications.

Adaptez la correction à la cause

Lors de la dimension du stockage de destination, rappelez-vous que l’historique des versions et la rétention peuvent rendre un dépôt plus volumineux que la source active. La même distinction est abordée dans le guide ZimaSpace sur la planification de capacité NAS pour les versions et l’historique des sauvegardes.

Arrêtez et escaladez lorsque chaque exécution crée une nouvelle base

Escaladez avant de supprimer la chaîne lorsque les journaux montrent une invalidation répétée de la base, des changements inattendus d’identifiants source, la disparition de points de restauration, des métadonnées du dépôt signalant une corruption, ou qu’un test sans changement écrit encore presque toute la source. Conservez les points de restauration actuels jusqu’à ce qu’au moins une restauration représentative ait été testée. Recréer la tâche peut masquer les preuves et supprimer le seul historique récupérable.

Questions fréquemment posées

Le déplacement ou le renommage d’un grand dossier peut-il provoquer un incrément de taille complète ?

Cela dépend du moteur de sauvegarde. Les outils de déduplication de contenu ou de blocs peuvent réutiliser les données existantes et stocker principalement les métadonnées de chemin, tandis que les outils au niveau fichier peuvent traiter les fichiers déplacés comme de nouveaux objets. Testez le produit exact avec un dossier représentatif avant de réorganiser un grand ensemble de données.

Un complet synthétique signifie-t-il que le NAS a téléchargé à nouveau toute la source ?

Pas nécessairement. Un complet synthétique est souvent assemblé à partir des données déjà présentes dans le dépôt. Comparez les compteurs de lecture source et de transfert réseau avec les compteurs d’écriture dans le dépôt pour voir où le travail a eu lieu.

Pourquoi une petite modification de base de données peut-elle créer un incrément important ?

L'application peut réécrire de nombreux blocs de stockage, compacter la base de données, faire pivoter les journaux ou modifier les limites des segments même lorsque le changement visible dans l'enregistrement est minime. Utilisez une sauvegarde ou une exportation cohérente avec l'application et comparez son delta avec le fichier de base de données en direct.