Warum ist ein inkrementelles Backup fast so groß wie ein vollständiges Backup?

Ein inkrementelles Backup kann fast so groß wie ein vollständiges Backup werden, wenn die Quelle tatsächlich viele Blöcke neu schreibt, die Backup-Engine ihre vorherige Änderungsbasislinie verliert, der geschützte Bereich sich ändert oder die gelesene Zahl das Repository-Wachstum und nicht die aktuelle inkrementelle Datenmenge darstellt. Diagnostizieren Sie diese Möglichkeiten separat, bevor Sie Wiederherstellungspunkte löschen, den Job zurücksetzen oder ein neues vollständiges Backup starten.

Identifizieren Sie zuerst, welche Zahl zu groß erscheint

„Das Inkrement ist voll groß“ kann vier verschiedene Messwerte beschreiben. Sie sind nicht austauschbar und weisen jeweils auf eine andere Ursache hin.

Notieren Sie alle vier Zahlen für einen Durchlauf. Ein Job, der 8 TB scannt, aber 12 GB überträgt, verhält sich ganz anders als einer, der 7 TB überträgt und schreibt.

Bestätigen Sie, ob sich die Arbeitslast wirklich so stark verändert hat

Backup-Software auf Volume-Ebene schützt geänderte Speicherblöcke, nicht die für den Benutzer sichtbare Größe bearbeiteter Dokumente. Eine kleine Änderung kann einen größeren Block verändern, und aktive Dienste modifizieren kontinuierlich Protokolle, Indizes, Datenbanken, Caches und Betriebssystemdateien. Eine aktuelle Administrator-Diskussion erklärt, warum ein einziges geändertes Byte den enthaltenen Sicherungsblock zum Teil des nächsten Inkrements machen kann.

Überprüfen Sie, ob der große Vorgang einem dieser Ereignisse folgte:

• Datenbankwartung, Kompaktierung, Neuindizierung oder Wachstum des Transaktionsprotokolls
• Updates von virtuellen Maschinen, Swap-Aktivität, Virenscans oder Gast-Defragmentierung
• Medien-Transkodierung, Neuindizierung der Fotobibliothek, Miniaturbild-Erneuerung oder Metadaten-Neuschreibungen
• Große Archiv-, verschlüsselte Container-, Postfach- oder Festplatten-Image-Dateien, die an Ort und Stelle neu geschrieben werden
• Dateisystem-Balance, Pool-Erweiterung, Blockverlagerung oder Snapshot-Konsolidierung

Vergleichen Sie das Sicherungsfenster mit Anwendungsprotokollen und Speicher-Schreibdiagrammen. Wenn die Quellenschreibvorgänge zur gleichen Zeit zunahmen, meldet die Sicherung möglicherweise eine echte Änderung und keinen Sicherungsfehler.

Überprüfen, ob die Änderungsverfolgung ihre Basislinie verloren hat

Block-Tracking-Systeme vergleichen den aktuellen Zustand mit einer bekannten vorherigen Änderungs-ID. Ein Snapshot-Rollback, Tracking-Reset, ungültige Änderungszuordnung, Host-Migration, fehlgeschlagene vorherige Sitzung oder Neuerstellung des Sicherungsjobs kann diese Beziehung unterbrechen. Der nächste Lauf kann dann die gesamte Quelle lesen oder schützen, um eine sichere Basislinie zu erstellen. Ein praktischer CBT-Wiederherstellungsleitfaden weist darauf hin, dass das Zurücksetzen des Änderungs-Trackings einen neuen aktiven Volllauf erfordern kann, bevor normale Inkremente fortgesetzt werden.

Suchen Sie nach Protokollbegriffen wie CBT zurückgesetzt, Änderungs-ID ungültig, Journal umgewickelt, Basislinie fehlt, neue Kette, oder Vollständiger Scan erforderlich. Setzen Sie das Tracking nicht wiederholt zurück, ohne die Protokolle zu sichern; wiederholte Resets können den ursprünglichen Auslöser verbergen und wiederholte vollständige Läufe verursachen.

Überprüfen Sie, ob der Sicherungsumfang und die Quellidentität sich nicht geändert haben

Ein Job kann weiterhin als inkrementell gekennzeichnet sein, während er eine andere Quelle als zuvor schützt. Ein neuer Mount unter einem eingeschlossenen Pfad, eine Größenänderung des Dateisystems, ein geänderter Geräte-Identifikator, ein anderer Hostname, ein neuer Freigabepfad oder eine erweiterte Einschlussregel können die Engine dazu bringen, neue interne Strukturen zu erstellen. Community-Fehlerbehebungen zeigen, dass zusätzliche Volumes und Mount-Punkte in einen scheinbar unveränderten Job einbezogen werden können.

Exportieren Sie die vorherigen und aktuellen Jobdefinitionen und vergleichen Sie sie:

• Geschützte Wurzeln, Mounts, Freigaben, Datensätze und virtuelle Laufwerke
• Host-, Volume- und Dateisystem-Identifikatoren
• Ein- und Ausschlussmuster
• Snapshot-Anbieter und Konsistenzmodus
• Verschlüsselungs-, Komprimierungs- und Deduplizierungseinstellungen

Wenn die Quelle absichtlich erweitert wurde, kann ein vollständiger Inkrementlauf erwartet werden. Wenn jeder spätere Lauf weiterhin groß bleibt, setzen Sie die Diagnose fort.

Bestimmen Sie, ob die Granularität der Sicherung zu den Dateien passt

Datei-, Block- und inhaltsspezifische Chunking-Engines reagieren unterschiedlich auf Bearbeitungen, Umbenennungen und Umschreibungen. Ein block-deduplizierendes System kann beim Verschieben eines Ordners nur Metadaten aufzeichnen; eine einfachere Datei-Ebene-Engine behandelt den verschobenen Pfad möglicherweise als gelöschte Datei plus eine neue Datei. In einem blockbasierten Beispiel ändert das Umbenennen eines Verzeichnisses die Pfadmetadaten, ohne alle unveränderten Datenblöcke neu hochzuladen.

Große veränderbare Dateien benötigen besondere Aufmerksamkeit. Eine Datenbank, VM-Image, verschlüsselter Tresor oder monolithisches Archiv kann vollständig gelesen werden, um kleine interne Änderungen zu erkennen, und die letztendlich gespeicherte Menge hängt von Chunk-Grenzen und Deduplizierung ab. Eine Diskussion über große Datenbanken beschreibt, wie eine mehrere Gigabyte große Datenbankdatei vollständig gelesen werden kann, auch wenn nur geänderte Chunks übertragen werden.

Wenn die Anwendung einen konsistenten Export, Transaktionsprotokoll-Backup oder anwendungsbewusstes Backup-Verfahren bietet, vergleichen Sie diesen Workflow mit dem Backup der live monolithischen Datei.

Trennen Sie ein großes Inkrement von synthetischem Vollbackup und Aufbewahrungsaktivität.

Ein synthetisches Vollbackup wird im Repository aus einem früheren Vollbackup plus späteren inkrementellen Backups zusammengesetzt. Es kann ein vollformatiges Wiederherstellungsobjekt erstellen, ohne die gesamte Quelle erneut zu lesen. Eine Übersicht der Backup-Typen erklärt, dass synthetische Vollbackups aus der bestehenden Voll- und Inkrementkette aufgebaut werden.

Das Repository-Wachstum kann auch hoch bleiben, wenn alte Wiederherstellungspunkte gesperrt sind, das Bereinigen nicht ausgeführt wurde, gelöschte Snapshots noch auf Chunks verweisen oder ein Merge vorübergehend Arbeitsbereich benötigt. Prüfen Sie die Job-Zeitleiste statt nur ein Verzeichnislisting:

Führen Sie einen Ein-Variablen-Test vor dem Wiederaufbau der Backup-Kette durch.

1. Speichern Sie die aktuelle Job-Konfiguration, detaillierte Protokolle, die Liste der Wiederherstellungspunkte und die Repository-Kapazität.
2. Wählen Sie ein ruhiges Testfenster und pausieren Sie bekannte Anwendungen mit hoher Schreiblast, wenn dies sicher ist.
3. Erstellen Sie eine kleine Testdatei, ändern Sie sie einmal und führen Sie denselben inkrementellen Job ohne Änderung der Einstellungen aus.
4. Erfassen Sie gescannte, übertragene, geschriebene, deduplizierte und beibehaltene Bytes.
5. Führen Sie einen zweiten inkrementellen Lauf ohne Quelländerungen durch.

Wenn beide kontrollierten Läufe vollformatig bleiben, konzentrieren Sie sich auf Tracking, Quellidentität oder Job-Chain-Konfiguration. Wenn sie klein werden, stellen Sie die normalen Arbeitslasten nacheinander wieder her, bis die Änderungsrate zurückkehrt. Dies trennt das Verhalten der Backup-Engine von der Anwendungsfluktuation.

Passen Sie die Lösung an die Ursache an

Berücksichtigen Sie bei der Dimensionierung des Ziels, dass Versionsverlauf und Aufbewahrung ein Repository größer als die aktive Quelle machen können. Dieselbe Unterscheidung wird im ZimaSpace-Leitfaden zur Planung der NAS-Kapazität für Versionen und Backup-Historie behandelt.

Stoppen und steigen Sie ein, wenn jeder Lauf eine neue Basislinie erstellt

Steigen Sie ein, bevor Sie die Kette löschen, wenn die Protokolle wiederholte Basislinien-Invalidierungen zeigen, Quell-IDs unerwartet wechseln, Wiederherstellungspunkte verschwinden, Repository-Metadaten Korruption melden oder ein No-Change-Test fast die gesamte Quelle schreibt. Behalten Sie die aktuellen Wiederherstellungspunkte, bis mindestens eine repräsentative Wiederherstellung getestet wurde. Das Neuerstellen des Jobs kann die Beweise verbergen und die einzige wiederherstellbare Historie entfernen.

Häufig gestellte Fragen

Kann das Verschieben oder Umbenennen eines großen Ordners ein vollgroßes inkrementelles Backup verursachen?

Das hängt von der Backup-Engine ab. Content- oder block-deduplizierende Tools können vorhandene Daten wiederverwenden und speichern meist nur Pfad-Metadaten, während Datei-Ebene-Tools verschobene Dateien als neue Objekte behandeln können. Testen Sie das genaue Produkt mit einem repräsentativen Ordner, bevor Sie einen großen Datensatz umorganisieren.

Bedeutet ein synthetisches Vollbackup, dass das NAS die gesamte Quelle erneut hochgeladen hat?

Nicht unbedingt. Ein synthetisches Vollbackup wird häufig aus bereits im Repository vorhandenen Daten zusammengesetzt. Vergleichen Sie die Zähler für Quell-Lese- und Netzwerk-Übertragungen mit den Repository-Schreibzählern, um zu sehen, wo die Arbeit stattgefunden hat.

Warum kann eine kleine Datenbankänderung ein großes inkrementelles Backup erzeugen?

Die Anwendung kann viele Speicherblöcke neu schreiben, die Datenbank komprimieren, Protokolle rotieren oder Chunk-Grenzen ändern, selbst wenn die sichtbare Datensatzänderung gering ist. Verwenden Sie ein anwendungs-konsistentes Backup oder einen Export und vergleichen Sie dessen Delta mit der Live-Datenbankdatei.