Il server applicativo non risponde più, l’hypervisor mostra la macchina virtuale in errore, e non è possibile riavviarla. Guardando più da vicino, è il database SQL Server che fa funzionare l’ERP, il CRM o l’applicazione gestionale che è semplicemente scomparso. Questo scenario, sempre più frequente nelle aziende che ospitano i loro database MSSQL su infrastrutture virtualizzate, disorienta anche gli amministratori di sistema più esperti: gli strumenti abituali non rispondono, e il database sembra essersi volatilizzato mentre nulla indica un guasto hardware classico.
Perché un database MSSQL può scomparire con una VM corrotta
Un database SQL Server gira quasi sempre su una macchina virtuale, sia sotto VMware, Hyper-V o Proxmox. Questa VM si basa a sua volta su un disco virtuale (un file VMDK o VHDX secondo l’hypervisor), e questo disco virtuale è memorizzato su un’infrastruttura fisica: un NAS, un array SAN o un server locale. Tre livelli si sovrappongono quindi tra il tuo database e l’hardware reale, e ognuno di essi può essere il punto di partenza di una corruzione.
Quando lo storage fisico si corrompe o si satura bruscamente (un NAS che raggiunge il 100% della sua capacità, un controller RAID guasto, una scrittura interrotta durante una replica), non è solo il file del database a essere colpito. È il file system della VM stessa, il più spesso NTFS, che può essere danneggiato nella sua struttura.
Il ruolo centrale della MFT
Su un volume NTFS, la Master File Table (MFT) è la struttura che indicizza l’intero insieme dei file presenti: la loro posizione, la loro dimensione, i loro attributi. Senza una MFT utilizzabile, il sistema operativo non sa più dove si trovano i file, anche se i dati sono ancora fisicamente presenti sul disco. In concreto, questo significa che nessun accesso standard ai file .mdf e .ldf del tuo database è possibile: Windows semplicemente non li vede più, e SQL Server ovviamente non può montare un database di cui non trova i file.
Perché i riflessi SQL classici non bastano in questo caso
Un DBA di fronte a questo tipo di incidente si ritrova spesso impotente, e questo è legittimo: gli strumenti su cui si basa quotidianamente non hanno semplicemente presa su questo tipo di guasto. Il riflesso naturale è lanciare DBCC CHECKDB per diagnosticare una corruzione interna al database, o ripristinare l’ultimo backup disponibile. Questi due approcci partono da un presupposto che non tiene in questo caso specifico: presuppongono che il database sia accessibile, ma “corrotto in senso SQL”, cioè che i suoi file esistano e siano leggibili, ma che il loro contenuto sia problematico.
Ma qui il problema si trova un livello più in basso: non è il database a essere corrotto, è il file system che lo contiene ad essere scomparso. Nessuno strumento di riparazione SQL, per quanto performante, può agire su file a cui il sistema operativo stesso non ha più accesso. Tentare di ripristinare un backup su un volume che non risponde più, o lanciare una riparazione applicativa su un database fantasma, non fa che perdere tempo preziosissimo senza risolvere il problema reale.
Cosa fare, e soprattutto cosa non fare, nell’immediato
Di fronte a questo tipo di incidente, i primi minuti contano, ma non nel senso in cui si immagina generalmente. Non si tratta di agire in fretta per “riparare”, si tratta prima di tutto di non fare nulla che possa aggravare la situazione.
- Ferma immediatamente l’host di virtualizzazione interessato. Continuare a scrivere sullo storage, anche tramite meccanismi automatici come il TRIM o l’UNMAP sui dischi SSD, rischia di cancellare definitivamente dati ancora presenti ma che il sistema non sa più indicizzare.
- Non lanciare una riparazione NTFS generica tipo chkdsk sul volume interessato. Esattamente come un rebuild RAID lanciato troppo presto, una riparazione automatica di questo tipo può riscrivere strutture e distruggere le ultime tracce utilizzabili dei dati.
- Non tentare di rimontare il disco virtuale in scrittura “per vedere se riparte”. Ogni tentativo di questo genere riduce le possibilità di un recupero completo in seguito.
- Richiedi una valutazione professionale prima di qualsiasi nuova manipolazione. La maggior parte dei laboratori di recupero dati, tra cui Chronodisk, propongono una diagnosi iniziale gratuita per valutare precisamente lo stato del volume prima di intraprendere qualsiasi azione.
Questi riflessi si applicano sia che la tua infrastruttura si basi su un volume RAID classico sia su una macchina virtuale: in entrambi i casi, la priorità assoluta è preservare lo stato attuale del supporto, anche degradato, invece di moltiplicare i tentativi che complicano il lavoro di ricostruzione.
In cosa consiste un recupero professionale in questo contesto
Senza una struttura NTFS o MFT utilizzabile, non esiste un “restore” semplice. Il recupero passa per una ricostruzione manuale a basso livello del disco: bisogna identificare, blocco per blocco, le zone che appartengono ai file del database a partire da firme e schemi interni propri del formato MDF e LDF di SQL Server, per poi ricostituire una struttura di tabella utilizzabile a partire da questi frammenti ritrovati.
Questo lavoro non ha nulla a che vedere con un ripristino di backup classico. Richiede una comprensione approfondita sia del formato interno dei database SQL Server sia della meccanica dei file system virtualizzati, il che spiega perché questo tipo di caso non si risolve né con gli strumenti SQL standard, né in poche ore. È un lavoro di reverse engineering meticoloso, che deve fare i conti con lo stato reale del supporto e la quantità di dati ancora recuperabili.
Chronodisk interviene su questo tipo di corruzione, che riguardi volumi RAID fisici o macchine virtuali sotto VMware, Hyper-V o Proxmox. Quando nessun guasto hardware fisico è associato all’incidente (nessun disco che non si accende più, nessun rumore anomalo che segnali un guasto meccanico), l’intervento può spesso avvenire da remoto, il che permette di guadagnare tempo prezioso rispetto a un trasferimento fisico del materiale. In ogni caso, una diagnosi preliminare permette di determinare se la MFT è parzialmente recuperabile, se è necessaria una ricostruzione tramite firme, e quale volume di dati può ragionevolmente essere ripristinato.
Se il tuo database SQL Server è diventato inaccessibile a seguito della corruzione di una VM, la prima cosa da fare è resistere alla tentazione di “provare ancora una volta”. Ogni manipolazione non controllata riduce le possibilità di recupero. Una diagnosi professionale permette di fare chiarezza rapidamente, senza rischiare di aggravare una situazione già complicata.