Su un server il recupero non è mai un’operazione sola: è una sequenza di livelli, e ognuno va risolto prima di poter guardare quello sotto.
C’è l’insieme dei dischi governato da un controller dedicato, con una mappa scritta in un formato proprietario. Sopra c’è il filesystem. Sopra ancora, spesso, ci sono macchine virtuali, ognuna con il proprio disco virtuale e il proprio filesystem interno. E dentro quello, il gestionale con il suo database.
Il file che serve al cliente sta in fondo a questa catena, e ogni anello può avere danni propri.
Dove si rompe di solito
Il controller
Quando cede il controller, i dischi stanno bene ma nessuno sa più come rimetterli insieme: la configurazione è scritta in un formato che solo quella famiglia di controller capisce.
Il secondo disco durante la ricostruzione
Si sostituisce il disco guasto, parte la ricostruzione, e sotto quello sforzo cede un altro disco che era già al limite. È il modo più frequente di perdere un insieme completo.
Le macchine virtuali
L’insieme dei dischi si rimonta ma i dischi virtuali risultano danneggiati o incoerenti, spesso per uno spegnimento improvviso mentre le macchine erano in funzione.
L’errore che chiude la porta
Ne segnaliamo uno sopra tutti, perché è frequente e perché è definitivo.
Quando un controller RAID trova dischi in uno stato che non riconosce, spesso propone di inizializzare l’insieme per rimetterlo in servizio. La formulazione sembra innocua e in quel momento si è sotto pressione, con l’azienda ferma. Accettare significa scrivere una configurazione nuova sopra quella esistente: la mappa di dove stavano i dati sparisce, e ricostruirla da zero diventa molto più difficile.
Stessa cosa per la ricostruzione automatica avviata inserendo un disco nuovo senza aver prima verificato lo stato degli altri. Con un server fermo, la mossa giusta è quasi sempre non fare nulla e chiedere prima.
Come procediamo
Si comincia sempre allo stesso modo: copia completa di ogni disco, gli originali da parte, tutto il lavoro sulle copie. Su un server con dischi capienti è la fase più lunga, ed è anche quella che rende reversibile qualsiasi tentativo successivo.
Poi si risale la catena. Si ricostruisce l’insieme dei dischi ricavando i parametri dai dati stessi, si verifica il filesystem, si estraggono i dischi virtuali, si aprono, e si arriva al contenuto. Se c’è un database, si valuta se serve una riparazione a quel livello.
Ti chiediamo tutti i dischi numerati nell’ordine in cui stavano, il modello del controller e, se ce l’hai, la configurazione. Non è indispensabile: accorcia i tempi.
Quando il fermo pesa
Su un server la differenza rispetto a un recupero domestico non è tecnica, è che ogni giorno di fermo costa. Per questo esiste la gestione urgente entro 48 ore, e per questo nella prima chiamata proviamo a capire se una parte dell’attività può ripartire prima che il recupero sia completo: a volte serve solo il database del gestionale, e quello si può privilegiare.
Se invece il problema è che quel server era l’unica copia di tutto, dopo il recupero vale la pena rimettere le cose in ordine: ce ne occupiamo nella parte di assistenza alle aziende.
Come funziona da noi
La valutazione viene prima di qualsiasi intervento e ti dice cosa si può fare, con che probabilità e a che cifra. Il recupero si paga solo se riesce; se riesce in parte, ti formuliamo comunque un preventivo su quello che c’è e sei tu a decidere.
La copia dei dati recuperati la conserviamo 30 giorni, poi cancellazione sicura. Sui supporti già aperti o già trattati da altri c’è un contributo di 100 €: si parte da una situazione che non conosciamo e va ricostruita. Per chi non può aspettare esiste la gestione urgente entro 48 ore.
Siamo a Genova, in Viale Brigata Bisagno, zona Brignole. In laboratorio si parla italiano, inglese e ucraino.
Sistemi collegati
Per i NAS, che seguono una logica simile ma con formati diversi: recupero dati da NAS. Per come si ricostruisce un insieme di dischi: recupero dati RAID.
Se c’è di mezzo un ransomware: recupero da ransomware. Quadro completo: recupero dati.
Domande frequenti
A volte sì, ma solo con un controller della stessa famiglia e con una configurazione compatibile. Il punto delicato è un altro: molti controller, appena vedono dischi che non riconoscono, propongono di inizializzare l’insieme. Accettare quella proposta cancella la mappa dei dati. È l’errore più grave che si possa fare in quel momento.
Succede spesso, ed è il motivo per cui consigliamo di non sostituire nulla prima di aver capito lo stato di tutti i dischi. Se un altro disco è ai limiti, la ricostruzione lo finisce. Se la ricostruzione è già partita ed è in corso, fermala e sentici.
Sì, aggiunge un livello. Prima si ricostruisce l’insieme dei dischi, poi si estraggono i file delle macchine virtuali, poi si apre il disco virtuale e infine il contenuto che ti serve. Ogni livello può avere danni suoi, e ognuno va verificato prima di passare al successivo.
Sì, ma va detto subito. Un database interrotto a metà di una scrittura può richiedere una riparazione a livello di database, oltre al recupero dei file. Sono due lavori diversi e sapere in anticipo che c’è di mezzo un gestionale cambia il modo di procedere.
Il modello del controller e, se puoi recuperarla, la configurazione. Sono le informazioni che accorciano il lavoro. Se non le hai, ricostruiamo comunque tutto dai dischi: serve più tempo, non è un ostacolo.
Diccelo subito: esiste la gestione urgente entro 48 ore e sui casi di fermo aziendale la priorità la diamo davvero. Nella prima chiamata cerchiamo anche di capire se una parte del lavoro può ripartire prima del recupero completo.
Server fermo? Prima di toccare, sentici
Su un server la maggior parte dei danni definitivi nasce nei minuti successivi al guasto, non dal guasto stesso.
