So testen Sie, ob Time Machine den Backup-Verlauf fortsetzt oder neu erstellt

Sie können die Kontinuität überprüfen, indem Sie die Identität des Ziels, den geerbten Sicherungsverlauf, die Liste der letzten Snapshots und die Frage prüfen, ob der erste neue Lauf wie eine inkrementelle oder vollständige Übertragung funktioniert.

Die Entscheidung ist relevant, wenn ein Mac nach einer Migration, der Umbenennung einer Freigabe, einer Änderung der Anmeldedaten oder der Reparatur eines Sparsebundles wieder eine Verbindung zu einem NAS herstellt. Die beiden konkurrierenden Zustände sind, dass der bestehende Verlauf übernommen und erweitert wird oder dass neben dem alten ein neuer Sicherungssatz erstellt wird. Beginnen Sie mit einer gespeicherten Konfiguration und nicht kritischen Daten, beobachten Sie jeweils nur einen Zweig und brechen Sie ab, wenn der Test das Risiko von Datenverlust, Berechtigungs- oder Verfügbarkeitsproblemen erhöht.

Definieren Sie die Bedingungen für die Entscheidung zur Kontinuität des Time-Machine-Verlaufs

Dokumentieren Sie die Umgebung, bevor Sie etwas ändern: Software- und Firmwareversionen, Geräteidentitäten, Einhänge- oder Netzwerkpfad, freien Speicherplatz, Berechtigungen und das beobachtete Symptom. Die Ausgangsbasis muss genügend Details bewahren, um eine erneute Verbindung eines Mac mit einem NAS nach einer Migration, der Umbenennung einer Freigabe, einer Änderung der Anmeldedaten oder der Reparatur eines Sparsebundles reproduzieren zu können.

Der erste mögliche Zustand ist, dass der bestehende Verlauf übernommen und erweitert wird. Der zweite ist, dass neben dem alten ein neuer Sicherungssatz erstellt wird. Die aktuelle Dokumentation zu tmutil-Zielprüfungen definiert den im Test verwendeten Mechanismus oder Befehlsbereich; sie ersetzt nicht die Beobachtung auf diesem konkreten Heimserver.

Legen Sie die Akzeptanz- und Abbruchbedingung fest, bevor Sie den Unterscheidungstest ausführen. Ein erfolgreicher Test muss die von einem Zweig vorhergesagten Belege verändern, während nicht verwandte Dienste unverändert bleiben; bei einem Fehlschlag muss das System in den gespeicherten Zustand zurückversetzt werden, statt eine Kette spekulativer Fehlerbehebungen auszulösen.

Überprüfen Sie die Annahme, ohne die ursprüngliche Anforderung zu senken

Verwenden Sie diesen Unterscheidungstest: Prüfen Sie die Ziel- und Snapshot-Historie von tmutil und starten Sie anschließend eine kontrollierte Sicherung, während Sie die übertragene Größe und das Ziel-Bundle überwachen. Halten Sie Arbeitslast, Client, Pfad, Dateisatz und Zeitplanung konstant, damit das Ergebnis der veränderten Variable zugeschrieben werden kann.

Verwenden Sie Time-Machine-Ziele, um das Feld auszuwählen, das die beiden Zweige tatsächlich voneinander unterscheiden kann, und erfassen Sie dessen Zeitstempel, Exit-Status, Fehlermeldung, Geräte- oder Snapshot-Identität, Latenz, übertragene Bytes, Berechtigungen und Wiederherstellungsstatus. Ein sauberer Befehlsabschluss reicht nicht aus, wenn Identität, Haltbarkeit oder Anwendungsstatus die zu prüfende Behauptung betreffen.

Wiederholen Sie den Test nach einem Neustart, einer erneuten Verbindung, einem erneuten Einhängen oder einem Kaltstart des Caches, wenn dieses Ereignis Teil der ursprünglichen Bedingung ist. Wenn der erste Lauf destruktiv ist oder die Umgebung nicht wiederhergestellt werden kann, brechen Sie ab und reproduzieren Sie den Vorgang stattdessen mit einer nicht kritischen Kopie.

tmutil destinationinfo
tmutil listbackups
tmutil status

Interpretieren Sie erfolgreiche, fehlgeschlagene und Ausnahmeergebnisse

ERFOLG: Neue lokale Snapshots werden mit dem erwarteten Ziel verknüpft, und der Lauf überträgt nur geänderte Daten. Notieren Sie die genaue Version, Identität und Arbeitslast, mit denen der Test erfolgreich war, damit die Schlussfolgerung bedingt bleibt und nicht zu einer universellen Aussage wird.

FEHLSCHLAG: Ein neues Sparsebundle wird angezeigt, der Verlauf fehlt oder die übertragene Größe nähert sich einer vollständigen Ausgangssicherung. Ein Fehlschlag beweist nicht automatisch den gegenteiligen Zweig, wenn Netzwerk, Arbeitsspeicher, Berechtigungen oder die Konsistenz der Quelle beide beeinflussen können; isolieren Sie diese gemeinsamen Abhängigkeiten, bevor Sie weitere Schritte einleiten.

AUSNAHME ODER MEHRDEUTIGES ERGEBNIS: Stoppen Sie den Lauf, bevor beide Verläufe das Kontingent aufbrauchen, und stellen Sie die vorherige Zielidentität wieder her. Bewahren Sie die Protokolle auf und führen Sie keine Befehle zum Reparieren, Bereinigen, Löschen, Partitionieren oder zur rekursiven Besitzänderung aus, bevor keine wiederherstellbare Kopie vorhanden ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Bestätigen Sie die Entscheidung unter der ursprünglichen Arbeitslast

Wenden Sie die zum beobachteten Zweig passende Maßnahme an und wiederholen Sie anschließend die ursprüngliche Bedingung statt eines vereinfachten Ersatzes. Die Entscheidung gilt nur dann, wenn neue lokale Snapshots über zwei Zyklen oder über den relevanten Neustart, Ruhezustand, die Unterbrechung oder den Lastwechsel hinweg mit dem erwarteten Ziel verknüpft werden und der Lauf nur geänderte Daten überträgt.

Verwenden Sie die Time-Machine-Kontingente, um den nächstgelegenen abhängigen Arbeitsablauf zu prüfen, lassen Sie den ursprünglichen Auslöser jedoch unverändert. Nicht verwandte Datensätze, Freigaben, Container, Benutzer und Wiederherstellungspunkte müssen ihren bisherigen Zugriff und ihr bisheriges Zeitverhalten beibehalten.

Die Abbruchgrenze ist eindeutig: Wenn ein neues Sparsebundle erscheint, der Verlauf fehlt oder sich die übertragene Größe einer vollständigen Ausgangssicherung nähert, kehren Sie zur zuletzt verifizierten Konfiguration zurück, bewahren Sie die Belege auf und leiten Sie nur dann einen umfassenderen Plattform- oder Hardwaretest ein, wenn der Zweig wiederholbar ist.

Nachdem das Zielergebnis erreicht wurde, vergleichen Sie es mit der Wiederherstellungsprüfung, damit die Behebung das Risiko nicht in einen benachbarten Dienst verlagert. Ein erfolgreicher Zieltest mit einer neuen Sicherung, Identitäts-, Timeout- oder Verfügbarkeitsstörung ist weiterhin eine fehlgeschlagene Änderung.

FAQ

Bei der Kontinuität des Time-Machine-Verlaufs geht es bei den verbleibenden Fragen meist darum, ob ein großer erster Lauf immer bedeutet, dass der Verlauf verloren ging, ob zwei Sparsebundles ähnliche Namen haben können und ob das alte Bundle gelöscht werden sollte, nachdem eine neue Sicherung begonnen hat. Die folgenden Antworten halten diese Sonderfälle von der primären Entscheidung getrennt.

Die Akzeptanzgrenze verschiebt sich nicht: Neue lokale Snapshots werden mit dem erwarteten Ziel verknüpft und der Lauf überträgt nur geänderte Daten. Wenn eine nachfolgende Bedingung das Dateisystem, die Identität, den Netzwerkpfad oder die Anwendungsversion ändert, wiederholen Sie nur den von dieser Änderung betroffenen Unterscheidungstest.

Erweitern Sie das Experiment nicht weiter, wenn ein neues Sparsebundle erscheint, der Verlauf fehlt oder sich die übertragene Größe einer vollständigen Ausgangssicherung nähert. Stoppen Sie den Lauf an diesem Punkt, bevor beide Verläufe das Kontingent aufbrauchen, und stellen Sie die vorherige Zielidentität wieder her; bewahren Sie die Belege auf, bevor Sie den Plattform-, Speicher- oder Hardwareverantwortlichen einschalten.

Bedeutet ein großer erster Lauf immer, dass der Verlauf verloren ging?

Nein. Betriebssystem-Upgrades, Ausschlüsse, Änderungen am Dateisystem oder lange Unterbrechungen können große inkrementelle Übertragungen verursachen; prüfen Sie die Zielidentität und die Snapshot-Abstammung.

Können zwei Sparsebundles ähnliche Namen haben?

Ja. Verwenden Sie die Rechneridentität und Zielmetadaten, nicht nur den Dateinamen.

Sollte das alte Bundle gelöscht werden, nachdem eine neue Sicherung begonnen hat?

Nicht, bevor die Kontinuität nachgewiesen wurde oder der neue vollständige Verlauf einen Wiederherstellungstest bestanden hat.

Bei der Kontinuität des Time-Machine-Verlaufs bleibt die praktische Antwort bedingt: Neue lokale Snapshots werden mit dem erwarteten Ziel verknüpft und der Lauf überträgt nur geänderte Daten. Wenn ein neues Sparsebundle erscheint, der Verlauf fehlt oder sich die übertragene Größe einer vollständigen Ausgangssicherung nähert, stoppen Sie den Lauf, bevor beide Verläufe das Kontingent aufbrauchen, und stellen Sie die vorherige Zielidentität wieder her; ein Teilerfolg, der die ursprüngliche Arbeitslast nicht übersteht, ist keine Kompatibilität.