Come forzare un deep traversal di Time Machine?

11

Dopo un po 'di panico del kernel e una accidentale disconnessione accidentale del mio disco Firewire Time Machine, mi piacerebbe assicurarmi che la mia Time Machine corrisponda esattamente al mio Macintosh HD, proprio come rsync -a . C'è un modo per forzare Time Machine a fare un deep traversal per verificare che il backup corrisponda?

Sarebbe utile sapere come farlo su Leopard, Snow Leopard e Lion.

    
posta Blair Zajac 14.03.2012 - 06:54
fonte

2 risposte

7

Impostare la destinazione Time Machine su nulla e quindi reimpostarla nella stessa posizione di prima per forzare un deep traversal per me. Potresti provare a riavviare tra il cambio della destinazione e il re-aggiungerlo per aumentare la possibilità che venga attivato un deep traversal.

Nel peggiore dei casi, potremmo fare a meno della modalità utente singolo per distruggere la directory fseventsd in un momento sicuro quando il sistema non conta su di esso per essere corretto, quindi hai forzato un nuovo database che non corrisponderà. Potresti presumibilmente eliminarlo dal lato TM, ma rimuoverò la copia di avvio come marginalmente più sicura e meno incline a distruggere i dati di cui hai bisogno o rovinare il backup.

Se sei incline ad usare la riga di comando / terminale, inizierei con tmutil compare prima ancora di forzare un deep traversal. Confronta in modo esplicito le cose così come esistono ora con l'ultima istantanea e puoi forzare le cose specificando uno snapshot esterno specifico se sei preoccupato di confrontare uno snapshot locale.

    
risposta data 29.05.2012 - 19:28
fonte
1

L'avvio in modalità utente singolo può causare un attraversamento profondo. Ha fatto per me una volta, ma non in tempi successivi. Cancellare /.fseventsd lo farà sicuramente. Dovrebbe essere sicuro farlo in modalità utente singolo. L'eliminazione di /.fseventd sul volume backup non ha attivato per me un deep traversal. (Il mio sistema è continuato come normale e non lo ha mai nemmeno ricreato.)

tmutil compare è solo un po 'accurato. Sembrava identificare accuratamente i file che non erano stati sottoposti a backup all'inizio. Ho attivato un deep traversal per correggere questo problema, ma Time Machine non esegue ancora il backup di molti file. Eppure tmutil compare ora afferma che non c'è un problema. Mi fiderei:

rsync --dry-run --itemize-changes --checksum --protect-args -aNHAXx --protect-decmpfs --fileflags --force-change --delete path/to/source_dir/ path/to/destination_dir/

Utilizza /Volumes/<your time machine volume>/Backups.backupdb/<your machine name>/Latest/ come percorso di origine o di destinazione. --itemize-changes ci permette di vedere cosa è diverso; '--checksum' dice a rsync di confrontare effettivamente il contenuto del file, piuttosto che solo i tempi di modifica e le dimensioni del file; e --dry-run dice a rsync di non effettuare il backup (quindi ci dice solo cosa farebbe). Il resto degli argomenti sono flag che indicano che rsync rende la destinazione identica alla sorgente in ogni modo, inclusi i metadati e lo stato di compressione HFS. Credo che Time Machine aggiunga metadati di contabilità che rimuove durante il ripristino, quindi rsync potrebbe trovare spurie modifiche ai metadati.

    
risposta data 29.01.2015 - 03:26
fonte

Leggi altre domande sui tag