Oggi voglio raccontarti la storia di come ho quasi perso tutti i dati sul mio NAS con OMV, per la seconda volta. Seppur ci saranno molte persone più pratiche ed esperte che leggeranno un sacco di banalità facendosi due risate, potrebbe esserci sempre qualcuno che evita di arrivare nella situazione in cui sono io ora, cioè dove devo aspettare 130 giorni per terminare la copia di file per poter salvare tutta la baracca.

Questo sarà una specie di diario, una mini serie, in cui di settimana in settimana ti racconterò come sta andando questa avventura (perché ci sarà tanto che dovrò fare).

Ma andiamo con calma che qui devo raccontarti un po’ di cose che, messe nero su bianco, ti faranno capire quanto stupidi si può essere, nonostante “ci si vanti di aver assemblato un server multimediale con OMV“.

Non preoccuparti: anche se pensi che un HDD sia qualche cosa di commestibile, potrai comunque farti due risate alle mie spalle.

Il NAS: cos’è, come funziona e perché l’ho assemblato

Un NAS (Network Attached Storage) è un dispositivo, una sorta di pc sempre acceso e accessibile ovunque tu ti trovi, che – sostanzialmente – funge da deposito dati. Un po’ come il tuo cloud personale. Hai presente Google Drive o One drive? Ecco, semplificando, si può dire che sono la stessa cosa.

Un po’ di anni fa – siccome evidentemente avevo molto ma molto tempo libero – mi è saltato in mente di assemblarne uno. Tra le mille peripezie è salata fuori una macchina che anche io nel tempo, mano a mano che i problemi saltavano fuori, mi immaginavo potesse parlare e chiedermi con tono impietoso:

Perché mi hai creato? Uccidimi ti prego

Le prime parole del mio NAS

Un NAS fa anche un sacco di altre cosette interessanti, tipo fare essere il tuo Netflix, Spotify, server fi backup dati, server VPN e server di libri. Ovviamente il tutto nel massimo della legalità:

• OpenMediaVault (OMV) su USB e software per NAS
• NAS/HTPC con Plex: assemblaggio, consumi e prestazioni
• Plex Media Server e J3355/J4105/J5005: DIY NAS HTPC
• Booksonic Air e OMV 5: il tuo server di audiolibri!
• GParted: ridimensiona, sposta o elimina una partizione in OMV
• Calibre e OMV 5: ebook e audiolibri sempre con te
• Nextcloud Pi e OMV 5: guida all’installazione del tuo cloud
• Crea la tua VPN su OMV/Raspberry Pi con WireGuard in 5 minuti
• Come fare il backup di OMV con un semplice comando
• Sicurezza informatica: così ho perso 10 TB di dati dal mio server linux (OMV)
• Nextcloud problemi con la cartella /tmp: due soluzioni
• Software per backup automatici e sicuri. Duplicati, guida passo passo
• Workstation/Server Plex per 10+ transcodifiche e multiple VM

Ma torniamo a noi e alla storia che ti stavo raccontando.

Il primo segnale

Circa quattro mesi fa, stavo ascoltando musica su Plex, quando ad una certa noto che la maggiorparte delle tracce audio sono skippate in automatico, senza venire minimamente riprodotte.

ahai, non promette nulla di buono (l’ulitma volta che mi è successa una cosa così era un ransomware)

Io, mentre pensavo alle possibili cause del disservizio

E nulla, siccome era “solo” musica e io ero nel mezzo della specialistica, ho pensato di rimandare il problema, giacché gli altri servizi continuavano a funzionare alla grande.

E niente, passano ancora molte settimane prima che accedo a OMV e inizio a rugare con le impostazioni e a capire cosa sta succedendo.

In pratica vedo che un disco, quello su cui c’era la musica, era stato scollegato da OMV e non era più disponibile ai servizi (tra cui appunto Plex). La cosa spiegava anche come mai Nicole non era più in grado di caricare e scaricare foto.

Smanetto un po’ e sostanzialmente scopro che, modificando alcuni file di cui manco ricordo la posizione, riesco a fare ri-identificare il disco al sistema. Tutto felice, proseguo la mia esistenza.

Il secondo segnale

Passa nemmeno una settimana che il problema si ripresenta: musica non più disponibile, foto non più apribili né scaricabili/caricabili. Frustrato, inizio a ascoltare YouTube e le sue playlist mentre pompo in appartamento e considero il problema relativo alle foto come un problema di capienza, per cui “serve solo un altro disco più grande“.

Intanto non avevo ancora aperto nessuna utility per controllare lo stato di salute dei dischi (genio del male eh?).

Soddisfatto della mia inutilità sin qui, ignoro il problema ulteriormente.

Alla ricerca del nuovo disco: dal shucking allo shocking

Ad una certa, ho trovato il tempo di “comprare il disco nuovo”, penando di risolvere il problema.

Faccio la mia ricerchina, vedo che i WD Red Plus sono ancora tra i migliori dischi per quanto riguarda l’applicativo NAS, provo a vedere se trovo qualche WD MyElements per fare lo shucking, ma non trovo nulla. Compro quindi infine un HDD WD Red Plus da 4TB.

Parallelamente riapro OMV e mi ci dedico con un attimo più di tempo. Nel rispolverare il NAS scopro che OMV è aggiornabile alla versione 6, quindi lo faccio senza troppi ripensamenti, sperando anche di “risistemare il disco che continua a singhiozzare”, e … sminchio tutto Nextcloud, per cui perdo qualche giornata a ripristinare i backup e resincronizzare tutto. Per il resto nessun problema sostanziale, anzi: il disco è ora visibile ad OMV.

Torno a analizzare i dischi e l’attuale configurazione è quella in foto: un mezzo disastro.

Oltre alla consapevolezza che il disco HGST da 1 TB è BAD, capisco che oltre alla musica su quel disco ci sono anche le foto degli ultimi 10 anni. L’ultimo backup freddo l’ho fatto forse qualche mese fa. Un po’ mi viene male.

Qui mi rendo conto che non avevo programmato i controlli periodici consigliati: breve (uno al giorno, di notte meglio) e lungo (uno al mese). Mi do del pirla da solo, mentre prendo consapevolezza che, per come sono impostati ora i dischi, un po’ di questo male me lo merito.

Dal problema al piano

Ok, il disco nuovo l’ho preso, ma che ci faccio con il disco vecchio? Come gestire i nuovi dischi per evitare che questo accada di nuovo?

Il disco incriminato era inoltre entrato in stato di read-only, vale a dire uno stato di sola lettura che il sistema aveva impostato per evitare la non intenzionale perdita di dati.

Non potevo manco eliminare un po’ di spazio dal disco, a meno di forzare il sistema (“smontando” e “rimontando” il disco). Cosa che, a quanto pare, non consigliano.

Avevo quindi iniziato una disperata azione di copia che si prospettava molto lunga: circa 3 mesi. Ma lo avevo accettato. Così, dopo 84 ore aveva copiato 12 gb. In quel momento ho capito quanto poteva esser lungo quel periodo e mi sono detto:

Chi non rischia non beve champagne

Io, prima di forzare OMV a leggere/scrivere quel benedetto disco

In realtà quello che mi ha salvato, che pensavo anche di aver provato, è stato forzare il comando di riconntrollo del file system con:

fsck -f /dev/sde1

Questo comando, infatti, lo avevo già provato ma non avendo ottenuto a montior un elaborato in tempi di 1-2 minuti, avevo chiuso tutto. Questa volta però avevo avuto un assaggio della lentezza del disco. Quindi, aspettando circa un’ora, finalmente il processo si era concluso.

Potevo finalmente eliminare file dal disco! Quindi, il piano è così composto:

1. liberare il 10% del disco per accelerare il processo di copia
2. copiare tutto ciò che non è stato copiato dal NAS al backup freddo
3. usare UnionFs e SnapRaid per ricreare una specie di RAID dei poveri per evitare di rimanere senza servizio in futuro

Chiaro? Ah una cosa interessante è che per il comando di copia è l’aver usato il comando linux screen, senza il quale non sarei qui a raccontarvi tutta questa storia. Ma questo contenuto e l’update, in un prossimo articolo!

Torna settimana prossima per sapere se il nostro eroe riuscirà a salvare i dati dal NAS o se accadrà qualche altro imprevisto!