Un job di backup che esce verde è un’affermazione. L’affermazione è che, in una mattina futura, quei file diventeranno un sito che funziona. Non ci credo finché non ho fatto quella mattina apposta, su una macchina di prova, mentre nessuno aspetta. Un backup non provato è una storia che ti racconti. Un ripristino che hai eseguito è un backup.
Ripristinare sul vuoto, a calendario
L’ambiente di prova non è la produzione e non è lo staging che usano chi modifica. Parte vuoto. Il backup è l’unico modo per entrare. Lo alzo, entro e percorro un percorso che conterebbe durante un incidente: una pagina d’ordine, un invio di modulo ancora nel database, un file media che deve stare nell’archivio e non solo sul disco vecchio. Poi butto la copia di prova.
Se fallisce, preferisco scoprirlo un martedì che durante il disservizio per cui c’era il backup. I fallimenti soliti sono noiosi. Il dump del database è più nuovo degli uploads. Una tabella del plugin punta a un file che era escluso. L’archivio presume una versione di PHP che la macchina di prova non ha. Niente di questo compare nella spunta verde del plugin di backup.
Gli aggiornamenti hanno bisogno di un ritorno
Applicare un aggiornamento è facile. Applicarlo con un modo per tornare indietro è il servizio. Un’istantanea prima, un breve test di fumo dopo, e un ritorno scritto se il test fallisce. Dire che il backup si può ripristinare non è un ritorno se il ripristino non ha una durata che hai misurato. Voglio quella durata dalla prova sulla macchina di scorta, non dal dépliant del plugin.
Cosa apro davvero sulla copia vuota
Entra come utente reale, non come l’amministratore dell’installazione, se il backup include utenti. Apri un ordine che abbia uno stato, un totale e almeno una nota. Apri una pagina che contenga un’immagine e conferma che l’immagine è il file dell’archivio, non un collegamento caldo verso la produzione. Non inviare nulla. Sto verificando che il passato sia tornato, non creando un presente nuovo su un host usa e getta.
Scrivo la durata accanto alla data. “Ultimo ripristino, 18 minuti, fallito sull’archivio uploads, corretta l’esclusione, rilanciato.” Quella nota è più utile di un badge di monitoraggio. Quando qualcuno chiede se il piano include i backup, posso rispondere con una data. Un piano che non sa rispondere con una data è un cron con una fattura.
Un tempo di risposta in un piano di assistenza non significa nulla il primo giorno se non ho ancora ripristinato niente. L’orologio che sono disposto a scrivere parte dopo la linea di base, l’accesso e un ripristino riuscito. Prima di allora sto ancora imparando come è messo insieme il sito. Promettere una risposta lo stesso giorno in quella nebbia è il modo in cui i piani di assistenza diventano scuse.
Chiedi quando è stato fatto l’ultimo ripristino di prova. La pausa prima della risposta è la risposta.
La cura non è una scheda aperta per funzioni nuove
Un piano che promette monitoraggio, aggiornamenti, ripristini e anche qualunque cosa ti venga in mente dopo è prezzato per una fantasia, oppure sarà rinegoziato la prima volta che la fantasia arriva. Pagine nuove, un rifacimento, una migrazione: hanno un ambito proprio. Il piano che sono disposto a difendere è più stretto. Il sito continua a fare ciò che già fa. Il backup è stato dimostrato. Una persona risponde dentro le ore che sono state scritte. È meno eccitante di un retainer senza bordi. È anche un piano che puoi controllare.
