È iniziato un sabato sera con mia moglie che mi chiedeva perché il nostro DVR improvvisamente ha smesso di suonare uno spettacolo che stava guardando. Le ho detto che probabilmente era solo un problema tecnico, ma darei un'occhiata. Cammino nella stanza della famiglia per cercare, e l'errore sostanzialmente ha dichiarato che il disco sottostante non era più disponibile. Non bene! Questo è stato l'inizio della mia storia horror di tre giorni …
Un piccolo sfondo
Il mio DVR è in realtà solo un software specializzato (SageTV per quelli che sono curiosi) in esecuzione su un PC. Il software è molto flessibile e ti consente di separare tutti i vari aspetti di esso. Ho una macchina separata per il controllo centralizzato, la pianificazione e la registrazione, macchine separate per la riproduzione e il protagonista di questa storia, una macchina separata per l'archiviazione. Per l'archiviazione utilizzo un file server Linux, utilizzando LVM (Logical Volume Manager) per aggregare molte unità separate e non identiche in una grande unità logica (~ 6 TB al momento) che il sistema operativo vede. Dal momento che il backup di più TB di dati non è pratico e poiché tali dati sono "solo" programmi TV, la mia filosofia di backup è sempre stata quella di non preoccuparmene. Fino a eventi recenti, questa filosofia non era stata testata da un evento del mondo reale.
Tentativo di recupero dei dati
Dopo aver visto l'errore sul DVR, inizio immediatamente a guardare il server di archiviazione. Il filesystem è incredibilmente lento e lento a rispondere, quindi interrogo LVM sullo stato delle unità fisiche alla base del suo volume logico. Dopo un lungo ritardo, viene fuori e dice che manca un'unità da 750 GB. Uh Oh! Riavvio il server e sorprendentemente, l'unità torna. Emetto un comando pvmove per migrare automaticamente tutti i dati da quell'unità, ma non riesce a completare meno del 2%.
Di fronte a un'unità che non è molto collaborativa nella lettura dei suoi dati, ma almeno si presenta nel BIOS, mi rivolgo al mio strumento di recupero unità preferito, Spinrite. Sebbene Spinrite si avvii normalmente da supporti rimovibili, anni fa ho impostato l'avvio di rete a casa mia per varie utility, quindi non dovevo preoccuparmi di tenere traccia di alcun supporto. Normalmente mi collego alla mia rete, seleziono l'avvio dalla rete e ho una varietà di strumenti a disposizione per risolvere molti problemi. Il problema è che la macchina che fa funzionare tutto questo incantesimo è la stessa macchina che è attualmente inattiva. Non è un grosso problema, dico, farò il boot da un CD Spinrite. Tranne un paio d'anni fa, l'unità ottica sul mio file server ha rinunciato al fantasma. Al momento, ho deciso che, dal momento che non uso mai supporti ottici in quella macchina, non avevo bisogno di sostituirli. Non preoccuparti, mi dissi, toglierò semplicemente l'unità ottica dal mio computer principale. Spengo il mio computer principale ed estraggo l'unità ottica. Quindi cerco il mio CD di avvio di Spinrite. Non lo trovo! Ci siamo trasferiti in una nuova casa qualche mese fa, quindi tutto è un po 'in disordine. Immagino che brucerò solo una nuova copia, ma non riesco nemmeno a trovare alcun supporto ottico vuoto! Sul piano successivo, un'unità flash avviabile! Dopo alcuni minuti su Google per aggiornare la mia memoria, ho un'unità flash Spinrite avviabile. Avvio il mio Linux box da quello e lancio Spinrite. Il computer si blocca e sembra bloccarsi. Cercando di eliminare le variabili, sposto il disco rigido dall'essere collegato a una scheda di espansione PCI-e per essere collegato direttamente alla scheda madre. Ora Spinrite si avvia bene, ma impiega anni e secoli per enumerare le unità ad esso collegate. Scollego sistematicamente tutte le altre unità tranne quella difettosa, ma non finisce mai di enumerare le unità, non importa quanto tempo aspetto. Sul prossimo piano! Prendo l'unità dalla mia scatola Linux, la collego al mio computer principale e avvio dalla mia nuova brillante unità flash Spinrite. Spinrite si avvia e vede immediatamente l'unità, e gli dico di iniziare a recuperare i dati, soddisfatto che finalmente sto facendo dei progressi. Torno a controllarlo dopo circa 10 minuti e sullo schermo è presente un errore e sembra che l'unità sia nuovamente scomparsa. Frustrato, ci provo ancora qualche volta e dico a Spinrite di iniziare da varie parti dell'unità, ma ottenere lo stesso risultato ogni volta. Sembra che non mi aiuterà dopo tutto.
In un impeto di irrazionale speranza, rimetto l'unità nella mia scatola di Linux e la accendo. Con mia grande sorpresa, l'unità si presenta e LVM porta tutto attivo. Provando ulteriormente la mia fortuna, invio un altro comando pvmove per provare a spostare nuovamente i dati dall'unità. All'inizio, vedo messaggi di errore su non essere in grado di leggere dall'unità, ma sorprendentemente, il pvmove continua a fare progressi, avvicinandosi sempre di più al completamento al 100%. Una miscela di confusione, sollievo ed eccitazione mi travolge. Sto andando via da questo incolume? Purtroppo, l'ultima cosa che LVM fa sotto le copertine per completare in modo pulito un pvmove è scrivere un registro aggiornato su tutte le unità sotto il suo controllo. Questo ovviamente fallisce quando tenta di scrivere sul disco rigido e quindi interrompe l'intero processo. La sconfitta strappata di nuovo dalle fauci della vittoria! Mi tuffo di nuovo in Google e scopro che è possibile controllare la quantità di dati che il comando pvmove sposta invece di spostare TUTTI i dati in un colpo solo. Lo provo e ho un buon successo spostando una piccola porzione dei miei dati alla volta. Divento avido e l'unità scompare alcune volte, ma ritorna sempre dopo un ciclo di accensione del computer. Teorizzando che forse solo alcune parti del disco sono cattive, comincio a saltare in giro invece di lavorare all'inizio del disco. Dopo alcune iterazioni di questo, ho quasi tutti i 40 GB su 750 GB spostati in modo sicuro dall'unità. Per i restanti 40 GB, non è riuscito a spostarsi, qualunque cosa io abbia provato. Era domenica sera ed ero esausto, così ho deciso di andare a letto e affrontare il problema più il giorno successivo.
Il giorno seguente, dopo un po 'di sonno e la prima metà della mia giornata di lavoro, decido di mordere il proiettile perché non mi importava degli ultimi 40 GB di programmi TV registrati e ho iniziato a rimuovere l'unità dalla mia configurazione LVM . L'ho già fatto molte volte prima, quindi va abbastanza bene. L'elenco di pulizia successivo ripara il buco nel mezzo del filesystem. Immagino che mancino solo 40 GB invece di 750 GB, non può essere così male, giusto? Sbagliato! Dopo la riparazione, avevo 900 GB di spazio libero in più rispetto a prima dell'inizio del calvario, quindi mi ha colpito un po '. Oh bene, mi dico, era comunque solo la TV. Il mio DVR è finalmente nuovamente funzionante dopo tre giorni di pausa, e posso finalmente smettere di pensarci su ogni ciclo del cervello di riserva.
Lezioni imparate
Quindi cosa ho imparato da tutto questo? Avrei dovuto fare un lavoro migliore di ciò che contava davvero. Questo è successo poche settimane fa, e in quel momento non ho nemmeno perso nessuno dei contenuti TV che sono scomparsi. Mi rammarico tuttavia di aver impedito a me stesso, ma soprattutto alla mia famiglia, di poter usare la TV per tre giorni, e di essermi messo in modalità di crisi ad alto stress per quei tre giorni. Se avessi rinunciato al recupero dei miei dati all'inizio, la funzione sarebbe stata ripristinata in circa un'ora, non tre giorni. So fin troppo bene che il più delle volte i nostri dati sono preziosi, ma in questa situazione non lo era.
In secondo luogo, se i tuoi dati sono davvero preziosi e il 99% delle volte lo sono davvero, devi proteggerli! Esegui il backup dei tuoi dati, non ci sono scuse. Per i miei dati insostituibili, come migliaia di foto di mio figlio che ho sul mio computer, mi assicuro di eseguirne il backup in non meno di tre posizioni, una delle quali è un provider di backup su cloud. Per quanto riguarda l'archiviazione del DVR, non penso ancora che sia pratico eseguirne il backup sul cloud, ma con il prezzo delle unità in questi giorni, non ho scuse per non averlo protetto da RAID, ed è proprio quello che sto intenzione di fare. Quando ho configurato il mio cluster di archiviazione per la prima volta anni fa, penso che mi servissero almeno 10 unità per arrivare a un pool di TB multipli. Ho appena controllato i prezzi e ora puoi acquistare un'unità da 3 TB per meno di $ 100. Semplicemente non ho scuse per lasciare i miei dati non protetti, e se una perdita di dati come questa mi accade di nuovo, è davvero colpa mia.
