Come verificare se Time Machine sta continuando o ricreando la cronologia dei backup

Puoi verificare la continuità controllando l’identità della destinazione, la cronologia dei backup ereditata, l’elenco degli snapshot recenti e se la prima nuova esecuzione si comporta come un trasferimento incrementale o completo.

La decisione è importante quando un Mac si riconnette a un NAS dopo una migrazione, la ridenominazione di una condivisione, una modifica delle credenziali o una riparazione di sparsebundle. I due stati contrapposti sono: la cronologia esistente viene ereditata e ampliata, oppure viene creato un nuovo set di backup accanto a quello precedente. Inizia con una configurazione salvata e dati eliminabili, osserva un ramo alla volta e interrompi il test se aumenta il rischio di perdita di dati, problemi di autorizzazioni o indisponibilità.

Definisci le condizioni alla base della decisione sulla continuità della cronologia di Time Machine

Registra l’ambiente prima di modificare qualsiasi cosa: versioni del software e del firmware, identità dei dispositivi, percorso di montaggio o di rete, spazio libero, autorizzazioni e sintomo osservabile. La baseline deve conservare dettagli sufficienti per riprodurre la riconnessione di un Mac a un NAS dopo una migrazione, la ridenominazione di una condivisione, una modifica delle credenziali o una riparazione di sparsebundle.

La prima ipotesi è che la cronologia esistente venga ereditata e ampliata. La seconda è che venga creato un nuovo set di backup accanto a quello precedente. L’attuale verifica della destinazione tmutil definisce il meccanismo o il confine del comando utilizzato nel test; non sostituisce l’osservazione da questo specifico home server.

Definisci la condizione di accettazione e quella di arresto prima di eseguire il discriminatore. Un superamento deve modificare gli elementi che una delle ipotesi predice, lasciando invariati i servizi non correlati; un fallimento deve riportare il sistema allo stato salvato invece di avviare una serie di correzioni speculative.

Verifica l’ipotesi senza ridurre il requisito originale

Usa questo discriminatore: controlla la destinazione di tmutil e la cronologia degli snapshot, poi avvia un backup controllato monitorando la quantità trasferita e il bundle di destinazione. Mantieni costanti carico di lavoro, client, percorso, set di file e tempistiche, in modo che il risultato sia attribuibile alla variabile modificata.

Usa le destinazioni di Time Machine per selezionare il campo che può effettivamente distinguere i due rami, quindi acquisisci timestamp, stato di uscita, testo dell’errore, identità del dispositivo o dello snapshot, latenza, byte trasferiti, autorizzazioni e stato di ripristino. Un’uscita corretta del comando non è sufficiente quando l’ipotesi riguarda identità, durabilità o stato dell’applicazione.

Ripeti il test una volta dopo un riavvio, una riconnessione, un nuovo montaggio o una cache fredda quando tale evento fa parte della condizione originale. Se la prima esecuzione è distruttiva o l’ambiente non può essere ripristinato, interrompi e riproduci il test su una copia eliminabile.

tmutil destinationinfo
tmutil listbackups
tmutil status

Interpreta i risultati superati, falliti e anomali

SUPERATO: i nuovi snapshot locali si collegano alla destinazione prevista e l’esecuzione trasferisce solo i dati modificati. Registra la versione esatta, l’identità e il carico di lavoro che hanno superato il test, così la conclusione rimane condizionale invece di diventare un’affermazione universale.

FALLITO: compare un nuovo sparsebundle, la cronologia è assente oppure la quantità trasferita si avvicina a una baseline completa. Un fallimento non dimostra automaticamente il ramo opposto quando rete, memoria, autorizzazioni o coerenza dell’origine possono influenzare entrambi; isola queste dipendenze condivise prima di procedere.

RISULTATO ANOMALO O AMBIGUO: interrompi l’esecuzione prima che entrambe le cronologie consumino la quota e ripristina l’identità della destinazione precedente. Conserva i log e non eseguire comandi di riparazione, eliminazione, distruzione, ripartizionamento o modifica ricorsiva della proprietà finché non esiste una copia recuperabile.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Conferma la decisione con il carico di lavoro originale

Applica l’azione corrispondente al ramo osservato, quindi ripeti la condizione originale invece di usare una versione ridotta. La decisione è valida solo quando i nuovi snapshot locali si collegano alla destinazione prevista e l’esecuzione trasferisce solo i dati modificati per due cicli oppure durante il riavvio, la sospensione, l’interruzione o la variazione di carico pertinente.

Usa le quote di Time Machine per controllare il flusso di lavoro dipendente più vicino, ma mantieni invariato il fattore scatenante originale. Dataset, condivisioni, container, utenti e punti di ripristino non correlati devono conservare l’accesso e le tempistiche precedenti.

Il limite di arresto è esplicito: se compare un nuovo sparsebundle, la cronologia è assente oppure la quantità trasferita si avvicina a una baseline completa, torna all’ultima configurazione verificata, conserva le prove e procedi a un test più approfondito della piattaforma o dell’hardware solo quando il ramo è riproducibile.

Dopo aver ottenuto il risultato previsto, confrontalo con la verifica del ripristino, così la correzione non sposta il rischio verso un servizio vicino. Un test previsto superato con un nuovo backup, un problema di identità, un timeout o un errore di disponibilità rimane comunque una modifica fallita.

Domande frequenti

Per la continuità della cronologia di Time Machine, le ricerche rimanenti riguardano di solito se una prima esecuzione di grandi dimensioni significhi sempre che la cronologia è andata persa, se due sparsebundle possano avere nomi simili e se il vecchio bundle debba essere eliminato dopo l’avvio di un nuovo backup. Le risposte seguenti mantengono separati questi casi limite dalla decisione principale.

Il limite di accettazione non cambia: i nuovi snapshot locali si collegano alla destinazione prevista e l’esecuzione trasferisce solo i dati modificati. Se una condizione successiva modifica il filesystem, l’identità, il percorso di rete o la versione dell’applicazione, ripeti solo il discriminatore interessato da tale modifica.

Smetti di ampliare l’esperimento quando compare un nuovo sparsebundle, la cronologia è assente o la quantità trasferita si avvicina a una baseline completa. A quel punto, interrompi l’esecuzione prima che entrambe le cronologie consumino la quota e ripristina l’identità della destinazione precedente; conserva le prove prima di procedere con il responsabile della piattaforma, dello storage o dell’hardware.

Una prima esecuzione di grandi dimensioni significa sempre che la cronologia è andata persa?

No. Gli aggiornamenti del sistema operativo, le esclusioni, le modifiche al filesystem o intervalli lunghi possono generare incrementali di grandi dimensioni; controlla l’identità della destinazione e la derivazione degli snapshot.

Due sparsebundle possono avere nomi simili?

Sì. Usa l’identità della macchina e i metadati della destinazione, non solo il nome del file.

Il vecchio bundle deve essere eliminato dopo l’avvio di un nuovo backup?

Non prima di aver dimostrato la continuità o di aver superato un test di ripristino con la nuova cronologia completa.

Per la continuità della cronologia di Time Machine, la risposta pratica rimane condizionale: i nuovi snapshot locali si collegano alla destinazione prevista e l’esecuzione trasferisce solo i dati modificati. Quando compare un nuovo sparsebundle, la cronologia è assente o la quantità trasferita si avvicina a una baseline completa, interrompi l’esecuzione prima che entrambe le cronologie consumino la quota e ripristina l’identità della destinazione precedente; un successo parziale che non resiste al carico di lavoro originale non è compatibilità.