Il backup segnala che è andato bene: come fai a sapere che è vero?
In breve
Un rapporto di backup dice che un lavoro è stato eseguito, non che i dati siano utilizzabili. I backup si fermano in silenzio e il rapporto resta verde, oppure smette di arrivare e nessuno se ne accorge. Due controlli risolvono quasi tutto: il lavoro si annuncia quando finisce, e tu sorvegli l'età dell'ultimo backup buono.
Quasi tutte le aziende hanno i backup. Molte meno hanno una copia che le rimetterebbe in piedi domani mattina. La differenza raramente sta nel programma di backup: sta nel fatto che un backup che smette di funzionare lo fa in silenzio, e il silenzio sembra normalità.
Che cosa dimostra davvero un rapporto «andato bene»?
Un rapporto andato bene dimostra che un lavoro è stato eseguito, e nulla di più. Non dimostra che i file siano completi, che la destinazione avesse spazio, che la chiave di cifratura sia disponibile, né che qualcuno riuscirebbe a ripristinare da lì.
Fra i professionisti informatici le storie sono quasi intercambiabili, e a fare male sono i tempi: un mese senza un backup buono perché gli avvisi andavano alla casella di posta di una persona che se n’era andata; una serie di backup scoperti corrotti da circa quattro mesi, trovati al momento del ripristino; nastri vuoti perché il lavoro non era in realtà mai stato impostato per partire.
Nessuno di quei sistemi stava chiedendo aiuto a gran voce. Ognuno sembrava normale finché qualcuno non ha avuto bisogno dei dati.
Quali due controlli scoprono quasi tutto?
Sono due: il lavoro che si annuncia quando finisce, e un numero che dica quanto è vecchio l’ultimo backup buono.
Primo: fai parlare il lavoro. In fondo al tuo script di backup, fagli chiamare un URL. Se la chiamata non arriva entro la finestra prevista, ricevi un avviso. Questo solo cambiamento ribalta il problema: non dipendi più dal fatto che il guasto venga segnalato, ti accorgi del silenzio. Prende il lavoro che non è mai partito, la macchina che era spenta, il servizio andato in crash, lo script morto a metà strada.
Secondo: sorveglia un numero. Fai stampare a un piccolo comando qualcosa che ti interessa — le ore dall’ultimo backup riuscito, oppure la dimensione del file più recente — e tratta quel numero come un valore sorvegliato con una soglia. Un lavoro può concludersi e non scrivere nulla; un numero se ne accorge, un rapporto verde no.
Funzionano tutti e due su qualunque sistema che sappia eseguire un comando o fare una chiamata HTTP, cioè praticamente ogni prodotto di backup, script o pianificatore che già usi.
Perché il NAS non ti salva qui?
Perché un NAS non sa avvisarti di propria iniziativa: può soltanto essere interrogato da fuori, e dei lavori di backup non dice nulla. La guida MIB di Synology afferma che DSM non supporta i trap SNMP: il dispositivo non può mandare un avviso di propria iniziativa. Gli si può chiedere — stato di salute dei dischi, stato RAID compresi degradato e in crash, spazio libero — ma solo da qualcosa che sta fuori e che lo interroga.
E l’esito dei lavori di backup stessi non è esposto affatto. Quindi “me lo dirà il NAS” ha due problemi: te lo dice solo se glielo chiedi, e del lavoro non ti dice mai nulla.
Che cosa fare questa settimana
- Aggiungi la riga dell’annuncio in fondo al lavoro di backup, e imposta la finestra prevista.
- Stampa un numero — le ore dall’ultimo backup buono — e sorveglialo.
- Sorveglia la destinazione: spazio libero e stato di salute dei dischi, così vieni a sapere che un volume è pieno prima che il lavoro fallisca.
- Fissa una prova di ripristino. Mettila in calendario con un nome, non con “qualcuno dovrebbe”.
Un backup che non hai mai ripristinato è una speranza. Un backup che ogni mattina ti dice che è ancora lì, e quanto è vecchio, è un sistema.
Cosa non possiamo dirti
- Non possiamo leggere l'esito di un lavoro di backup dentro un NAS: i programmi NAS più diffusi, di casa e d'azienda, non lo espongono in rete, e non fingeremo il contrario.
- Non possiamo dirti che un backup è ripristinabile: solo una prova di ripristino lo dimostra.
- Possiamo vedere soltanto quello che il tuo sistema ci dice: un lavoro che si annuncia, un numero che il tuo script stampa, o un dispositivo che risponde.
Le domande che fanno davvero
Perché i backup si guastano in silenzio invece di segnalare un errore?
Perché la parte che dovrebbe segnalare l'errore è spesso proprio quella che si è fermata. Un lavoro pianificato che non parte mai non manda nulla. Un servizio andato in crash non manda nulla. Una casella di posta che rifiuta l'avviso se lo inghiotte. Il silenzio è identico al successo, ed è per questo che tanti guasti vanno avanti per mesi.
Qual è il controllo più semplice che funziona davvero?
Fai in modo che il lavoro di backup si annunci quando finisce, e fatti avvisare quando l'annuncio non arriva in tempo. Ribalta la logica: invece di aspettare una cattiva notizia che forse non verrà mai mandata, ti accorgi del silenzio. Basta una riga in fondo allo script che hai già.
Che cosa devo sorvegliare oltre al lavoro stesso?
L'età dell'ultimo backup buono, come numero: le ore dall'ultima esecuzione riuscita, oppure la dimensione del file di backup più recente. Un lavoro può finire e produrre un file vuoto. Un numero che guardi ogni giorno se ne accorge; un rapporto verde no.
Ogni quanto va provato un ripristino?
Almeno due volte l'anno, su una macchina che non è quella di produzione, con il cronometro in mano. Impari due cose che nessun rapporto ti dirà: se i dati tornano, e per quanto tempo l'azienda resterebbe ferma. Scrivi tutte e due.