In breve: controlla la data del file più recente nel backup, non la data della cartella. La data di una cartella cambia per motivi che non hanno nulla a che fare con la fine di un backup.
Se il file più recente al suo interno è più vecchio di ieri, il backup non sta girando, qualunque cosa dica lo strumento.
La maggior parte dei consigli sui backup riguarda il disastro sbagliato. Ne immagina uno drammatico: un disco che muore, un portatile rubato, un'alluvione. Sono rari e tutti li capiscono.
Il caso comune è noioso. L'unità è stata scollegata per fare spazio a qualcos'altro e non è più stata ricollegata. Il NAS si è riavviato dopo un'interruzione di corrente e la condivisione non si è rimontata. Il portatile era chiuso al momento in cui l'operazione doveva partire, ogni notte, per un mese. Uno script è uscito con un errore che nessuno ha letto, perché nessuno legge un log che va bene da un anno.
In ognuno di questi casi niente è rotto. Nessun errore compare dove una persona guarda. La cartella di backup è ancora lì, ancora piena di file, ancora della dimensione giusta. L'unica cosa cambiata è che ha smesso di aggiornarsi, e niente nel sistema lo ritiene degno di nota.
Puntalo sulla destinazione del backup. Trova il file modificato più di recente in qualsiasi punto al suo interno e ne stampa la data:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5La prima colonna è un timestamp Unix. Per leggerlo direttamente:
find /Volumes/Backup -type f -newermt '-2 days' | headSe non stampa nulla, in due giorni non è stato scritto niente. È questa la risposta, ed è più affidabile di qualsiasi schermata di stato, perché è una proprietà dei file stessi.
Per Time Machine nello specifico:
tmutil latestbackupche stampa il percorso dell'istantanea più recente, con la data nel nome, oppure un errore se non ce n'è.
L'istinto è guardare la cartella di backup nel Finder e leggere la colonna Data di modifica. Quel numero non è ciò che pensi.
La data di modifica di una cartella cambia quando le si aggiunge o toglie qualcosa, e non quando cambia il contenuto di un file al suo interno. L'indicizzazione di Spotlight, un .DS_Store riscritto, un antivirus, un client cloud che tocca i propri metadati: ognuna di queste cose può far sembrare che una cartella di backup ferma sia stata scritta stamattina.
I file al suo interno sono la prova. La cartella no.
launchd con StartCalendarInterval non parte mentre il Mac è in stop, e non recupera dopo a meno che tu non l'abbia chiesto. Un portatile chiuso a mezzanotte ha un backup di mezzanotte che non è mai avvenuto nemmeno una volta.launchd scrive la sua lamentela in un file, e quel file è l'unico a saperlo.Se lo fai da te, la soluzione è un dispositivo a uomo morto: qualcosa che si lamenta quando un backup non è avvenuto. È un evento diverso da un backup che fallisce, e solo il primo copre i casi qui sopra.
La versione più semplice è un'operazione che controlla l'età del file più recente e lancia l'allarme se è troppo vecchio:
if [ -z "$(find /Volumes/Backup -type f -newermt '-2 days' 2>/dev/null | head -1)" ]; then
osascript -e 'display notification "No backup in two days" with title "Backup"'
fiEseguilo con una sua pianificazione, separata dal backup, così una pianificazione di backup guasta non guasta anche ciò che la sorveglia. È quest'ultimo il punto su cui si sbaglia: un controllo che gira dentro l'operazione di backup non può segnalare che l'operazione di backup non è partita.
Ciò che vuoi davvero è che l'assenza sia l'allarme, e che lo strumento nomini la cosa che manca.
Copy Shelter è costruito su questo. Tiene traccia di quando ogni destinazione è stata scritta e controllata l'ultima volta, e si fa sentire dopo sette giorni senza un backup riuscito. Nomina la posizione, quindi ricevi "l'unità nel cassetto non si vede dal 14 agosto". E poiché rilegge il backup e controlla ogni pezzo con l'hash con cui è stato salvato, intercetta anche un backup che gira ma produce dati illeggibili, che è il guasto un passo oltre questa pagina.
Il punteggio che mostra conta solo ciò che è stato verificato di recente. Un backup che non è partito non è un backup che hai, e il numero lo dice.
Non dovresti doverlo fare. È questo il senso della pagina: un controllo che fai a mano è un controllo che smetterai di fare, di solito circa tre settimane dopo averlo impostato. Automatizza l'allarme per l'assenza, e lascia che il controllo a mano sia ciò che fai quando te lo dice.
Aiuta, ma ha dei limiti. Time Machine avvisa dopo dieci giorni senza un backup completato, e la notifica è facile da ignorare e da smettere di notare. Inoltre non può dirti che il backup completato è illeggibile, perché su un disco locale non controlla.
È il caso dei permessi, ed è più subdolo perché ogni indicatore di stato dice che è tutto a posto. Confronta il numero di file nella destinazione con quello nell'origine. Se un backup che dovrebbe contenere decine di migliaia di file ne contiene quaranta, macOS sta negando l'accesso alle cartelle e l'operazione non ne viene informata.
In modo diverso, ma sì. I client di sincronizzazione si disconnettono, esauriscono la quota e si mettono in pausa da soli, e il simbolo che te lo direbbe è una piccola icona in una barra dei menu che non stai guardando. I file inoltre restano esattamente dov'erano, quindi niente sembra sbagliato.
In gran parte sì. Due destinazioni che si guastano per motivi diversi, controllate separatamente, valgono più di qualsiasi monitoraggio su una sola. Il monitoraggio ti dice che la copia non c'è più; la seconda copia fa sì che non importi. Vedi la regola 3-2-1.
Vedi anche: verificare che un backup sia davvero leggibile e la regola 3-2-1.