Perché il recupero dati da database richiede competenze che vanno oltre il file system
Quando un database si corrompe, il problema non è mai semplicemente “il file è danneggiato”. Ogni DBMS organizza i dati secondo strutture interne proprietarie: pagine di dati, extent, tablespace, segmenti di rollback, redo log, write-ahead log. Un blocco corrotto in posizione critica — la page zero di un datafile Oracle, una pagina di sistema in SQL Server, il file pg_control di PostgreSQL — può rendere l’intero database inaccessibile anche se il 99% dei dati è fisicamente integro sul disco.
Il recupero richiede la lettura diretta delle strutture binarie del DBMS, la ricostruzione manuale dei cataloghi di sistema e l’estrazione riga per riga dal livello di storage engine — bypassando completamente il motore del database.
Recupero dati da database corrotti: struttura del problema
I database relazionali e NoSQL strutturano i dati in layer sovrapposti: lo storage fisico (file .mdf, .dbf, datafile, WAL), il layer di gestione (buffer pool, transaction log, undo tablespace) e il catalogo di sistema (system tables, pg_catalog, information_schema). Quando uno qualsiasi di questi layer si corrompe, il DBMS non riesce ad avviarsi o restituisce errori che bloccano l’accesso ai dati.
RecDati interviene direttamente sul layer di storage: legge le pagine dati in formato binario nativo, ricostruisce le strutture di catalogo danneggiate e recupera le righe valide anche da file con corruzione parziale, senza mai avviare il motore del database sui file originali.
Attenzione: non tentare DBCC CHECKDB con opzioni di riparazione (REPAIR_ALLOW_DATA_LOSS), ALTER DATABASE … SET EMERGENCY, o equivalenti su Oracle e PostgreSQL. Questi comandi possono eliminare definitivamente pagine corrotte che sarebbero ancora recuperabili con tecniche forensi dirette sul file binario.
Recupero dati SQL Server
Recupero da file .mdf/.ndf/.ldf corrotti, pagine 823/824/825, database in stato SUSPECT/RECOVERY_PENDING, transaction log troncato, system database msdb/master danneggiati.
Recupero dati Oracle Database
Interventi su datafile corrotti, redo log inaccessibili, undo tablespace danneggiato, ORA-600/ORA-1578/ORA-27072, dizionario di dati corrotto, ASM diskgroup non montabile.
Recupero dati PostgreSQL
Recupero da pg_control corrotto, relfilenode danneggiato, WAL segment mancante o troncato, tablespace inaccessibile, heap page con checksum failure su PostgreSQL 9.x fino a 17.x.
Recupero dati MySQL e MariaDB
Interventi su InnoDB tablespace corrotto (ibdata1, .ibd), frm/sdi file mancanti, redo log inaccessibile, tabelle MyISAM con .MYI/.MYD danneggiati, replica binlog interrotta.
Perché un database smette di funzionare: scenari reali e approcci di recupero
Ogni DBMS ha pattern di corruzione specifici. Conoscere la struttura interna di SQL Server, Oracle, PostgreSQL e MySQL è il prerequisito per scegliere la tecnica di estrazione corretta. Questi sono i quattro scenari più frequenti che gestiamo in laboratorio.
Corruzione di pagine dati e header di datafile
Ogni database relazionale suddivide i file di dati in pagine di dimensione fissa: 8 KB in SQL Server e PostgreSQL, blocchi da 2 KB a 32 KB in Oracle, pagine da 16 KB in InnoDB. La corruzione anche di una singola pagina critica — in particolare le prime pagine che contengono i metadati del file — rende il datafile non montabile dall’engine.
In SQL Server, un errore 823 indica un I/O failure a livello OS; un 824 segnala checksum failure o torn page; un 825 è una read-retry riuscita al secondo tentativo — indizio precoce di degrado hardware imminente. In Oracle, ORA-01578 identifica il numero di file e il numero di blocco corrotti, consentendo un intervento chirurgico mirato senza toccare i dati sani.
Importante: l’unica operazione sicura in presenza di pagine corrotte è un imaging bit-level del file originale su supporto separato. Qualsiasi tentativo di riparazione in-place con gli strumenti nativi del DBMS (DBCC CHECKDB REPAIR, RMAN blockrecover) deve avvenire esclusivamente sul clone, mai sull’originale.
Cause comuni
- Guasto hardware del disco durante un’operazione di write (torn page)
- Interruzione di corrente durante checkpoint o flush del buffer pool
- Errori ECC su RAM che corrompono le pagine in memoria prima del flush su disco
- File system sottostante con journaling disabilitato (ext4 nodata=writeback su VM)
Soluzioni RecDati
- Imaging bit-level del datafile con settori difettosi rimappati
- Parsing diretto delle pagine binarie per isolare i blocchi validi
- Estrazione delle righe dalle pagine integre bypassando le pagine corrotte
- Ricostruzione degli indici a partire dai dati heap recuperati
Transaction log corrotto o troncato: database bloccato in recovery
SQL Server, PostgreSQL e Oracle non avviano il database se il transaction log (o WAL) è inaccessibile, perché il processo di crash recovery richiede di ripristinare o annullare le transazioni incomplete. Un file .ldf mancante in SQL Server, un WAL segment corrotto in PostgreSQL, un redo log group non leggibile in Oracle bloccano l’avvio dell’istanza in modo apparentemente irrecuperabile.
In PostgreSQL, la perdita di pg_wal o un pg_control con LSN incoerente genera errori del tipo “could not locate a valid checkpoint record”. In Oracle, un redo log corrotto con status CURRENT (quello attivo al momento del crash) è lo scenario più critico: senza di esso, l’istanza non completa il recovery e rifiuta di aprire il database anche in modalità RESETLOGS.
Importante: evitare pg_resetwal (PostgreSQL) e ALTER DATABASE OPEN RESETLOGS senza una strategia di estrazione preventiva dei dati. Questi comandi azzerano il WAL e possono rendere irrecuperabili le transazioni commesse nell’ultimo intervallo di tempo prima del crash.
Cause comuni
- Crash del server durante un’operazione di log switch (Oracle) o checkpoint (PG)
- Disco su cui risiede il log group separato dal datafile — guasto selettivo del volume
- Troncamento manuale errato del .ldf in SQL Server senza shrink corretto
- File system pieno: il DBMS non riesce a estendere il WAL e il processo si blocca
Soluzioni RecDati
- Ricostruzione sintetica del transaction log (SQL Server) per consentire il detach del database senza avvio dell’istanza
- Reset controllato di pg_control con LSN coerente e successiva estrazione con pg_dump logico
- Bypass del redo log Oracle con tecniche di estrazione diretta dal datafile tramite parsing del dizionario di dati
Corruzione del catalogo di sistema e dei dizionari interni
Il catalogo di sistema è il DNA del database: contiene la definizione di ogni tabella, indice, procedura, utente e permesso. In SQL Server è distribuito nelle system tables di ogni database (sys.objects, sys.columns, sys.indexes) e nel database master. In Oracle è il dizionario dati in SYSTEM tablespace. In PostgreSQL è pg_catalog con relazioni fisiche in pg_class, pg_attribute, pg_type.
Un catalogo corrotto genera errori apparentemente inspiegabili: tabelle che “non esistono” pur avendo i file .ibd o i segmenti dati fisicamente presenti, query che restituiscono errori di tipo inconsistency anche su tabelle non toccate, impossibilità di avviare il DBMS in modalità normale anche dopo un restore parziale.
Importante: un database con catalogo corrotto non deve mai essere avviato in produzione nel tentativo di “vedere cosa funziona ancora”. L’avvio parziale può propagare la corruzione ad altre strutture di sistema e sovrascrivere le pagine ancora leggibili con dati incoerenti.
Cause comuni
- Upgrade di versione del DBMS con migrazione del catalogo incompleta
- Corruzione del tablespace SYSTEM (Oracle) o del database master (SQL Server) per guasto hardware durante un’operazione DDL
- Perdita di pg_class o pg_attribute in PostgreSQL per troncamento del file durante un autovacuum su tablespace degradato
- Drop accidentale di tablespace SYSTEM o di system tables con CASCADE
Soluzioni RecDati
- Parsing diretto dei file di dati del catalogo per ricostruire le definizioni delle tabelle utente senza dipendenza dal catalogo stesso
- Ricostruzione manuale di pg_class/pg_attribute da pagine binarie per PostgreSQL con catalogo parzialmente illeggibile
- Estrazione row-by-row da segmenti Oracle con dizionario di dati corrotto tramite lettura diretta dei data block
Cancellazione accidentale, DROP TABLE e ransomware su file di database
Il DROP TABLE senza WHERE su un database in produzione, la cancellazione accidentale di un datafile da filesystem, o la cifratura dei file del database da parte di ransomware sono scenari operativi molto più frequenti di quanto si pensi. In InnoDB, una tabella eliminata con DROP lascia tracce recuperabili nel tablespace condiviso ibdata1 o nel file .ibd dedicato, se lo spazio non è stato riutilizzato. In SQL Server, le righe eliminate con DELETE (e in alcuni casi con TRUNCATE) rimangono nelle pagine del file .mdf finché il relativo extent non viene riallocato dal page allocator.
Nel caso del ransomware, se la cifratura è avvenuta direttamente sui file del DBMS e non è disponibile una chiave di decifratura, il recupero dipende dall’esistenza di shadow copies, backup su storage non raggiungibile dalla rete, o versioni precedenti del file non ancora sovrascritte.
Importante: dopo un DROP TABLE o una cancellazione accidentale, interrompere immediatamente qualsiasi attività in scrittura sul database (inclusi log applicativi, INSERT automatici, job schedulati). Ogni nuova transazione aumenta la probabilità che lo spazio delle righe eliminate venga riutilizzato, riducendo le possibilità di recupero.
Cause comuni
- DROP TABLE / TRUNCATE senza backup preliminare in ambiente di produzione
- Script di migrazione eseguito sull’istanza sbagliata (prod invece di staging)
- Cancellazione manuale dei file .mdf/.dbf/.ibd da filesystem per liberare spazio
- Attacco ransomware che cifra selettivamente i file del DBMS lasciando intatto l’OS
Soluzioni RecDati
- Carving delle righe eliminate da pagine InnoDB con parsing del formato di riga COMPACT/DYNAMIC/BARRACUDA
- Recupero da transaction log SQL Server per ricostruire le operazioni DML precedenti al DROP tramite log mining
- Analisi dei file di database cifrati da ransomware per identificare pattern di cifratura parziale o header originali ancora leggibili
Come funziona il recupero dati da database con RecDati
Ogni intervento su database corrotto segue un processo strutturato: dall’analisi del file binario al DBMS di destinazione, passando per la validazione riga per riga dei dati estratti. Nessun tool automatico: ogni operazione è condotta manualmente da un tecnico con conoscenza diretta delle strutture interne del DBMS coinvolto.
Analisi del file binario
Ispezione diretta dei file del database (MDF, datafile Oracle, pg_filenode, ibdata1) per identificare l’estensione e la posizione della corruzione senza avviare il DBMS.
Imaging e isolamento
Clone bit-level del file originale su storage separato. Tutti gli interventi successivi avvengono esclusivamente sul clone. L’originale viene conservato integro per eventuale secondo tentativo.
Estrazione e ricostruzione
Parsing delle strutture di pagina native del DBMS, ricostruzione del catalogo, estrazione riga per riga con validazione dei tipi di dato e integrità referenziale.
Consegna e verifica
I dati recuperati vengono consegnati in formato nativo (dump SQL, CSV, backup RMAN) con report di copertura che indica le tabelle recuperate e l’eventuale percentuale di righe non recuperabili.
Perché RecDati è il partner giusto per il recupero dati da database
Il recupero da database richiede competenze che la maggior parte dei laboratori di data recovery non ha: conoscenza delle strutture interne di SQL Server, Oracle, PostgreSQL e MySQL al livello di singola pagina di storage, capacità di scrivere parser binari ad hoc per strutture di riga non standard, e familiarità con le differenze tra versioni dello stesso DBMS (il formato di pagina InnoDB di MySQL 5.7 non è identico a quello di MySQL 8.0 con atomic DDL).
Laboratorio di Recupero Dati da Database: competenza tecnica e approccio enterprise
RecDati è specializzata nel recupero dati da database per i principali DBMS enterprise e open source: Microsoft SQL Server (2008 fino a 2022), Oracle Database (10g fino a 23c), PostgreSQL (9.x fino a 17.x), MySQL e MariaDB, IBM Db2, SAP HANA e MongoDB. Operiamo su istanze in esecuzione su Windows Server, Linux, ambienti virtualizzati VMware e Hyper-V, container Docker e Kubernetes, storage SAN e NAS enterprise.
Ogni intervento viene condotto con parser binari sviluppati internamente, in modo da non dipendere mai dal motore del DBMS originale per l’estrazione dei dati. Questo approccio consente di recuperare dati anche quando il database non è avviabile e nessun tool nativo è in grado di accedere al file.
Parser binari nativi per ogni DBMS
Strumenti sviluppati internamente per leggere le strutture di pagina di SQL Server, Oracle, PostgreSQL e InnoDB senza dipendere dal motore del database. Operativi su file corrotti dove i tool nativi falliscono.
Copertura multi-versione
SQL Server 2008–2022, Oracle 10g–23c, PostgreSQL 9.x–17.x, MySQL 5.6–8.4, MariaDB, MongoDB, IBM Db2, SAP HANA. Interveniamo anche su istanze legacy su sistemi operativi non più supportati.
NDA e riservatezza dei dati
I database contengono spesso dati sensibili (PII, dati sanitari, dati finanziari). Tutti gli interventi sono coperti da NDA. I dati estratti non vengono mai trattenuti nei nostri sistemi dopo la consegna.
Recupero Dati da Database in Tutta Italia
RecDati offre servizi professionali di recupero dati da database con centri distribuiti su tutto il territorio nazionale. Interveniamo su SQL Server, Oracle, PostgreSQL, MySQL e MariaDB per aziende in tutte le principali città italiane, con ritiro a domicilio e analisi da remoto per i casi logici.
Recupero dati da database: domande tecniche frequenti
Le domande più frequenti che riceviamo da DBA e responsabili IT quando un database smette di funzionare. Per una valutazione tecnica del tuo caso specifico contatta direttamente il laboratorio.
È possibile recuperare dati dopo un DROP TABLE su SQL Server o MySQL?
È possibile in molti casi, dipende da quanto tempo fa è avvenuto il DROP e se il database ha continuato a ricevere scritture. In InnoDB, le righe eliminate restano fisicamente nel tablespace finché l’extent non viene riallocato a nuovi dati. In SQL Server, le righe sono recuperabili dal file .mdf e in alcuni casi anche dal transaction log tramite log mining, se il log non è stato troncato o sovrascritto dal processo di checkpoint.
Si possono recuperare dati da un database in stato SUSPECT o con ORA-01578?
Dipende dal DBMS e dal punto di corruzione. Se il database è in stato SUSPECT (SQL Server) o ha un datafile con ORA-01578 (Oracle), il recupero dei dati dalle pagine integre è spesso possibile anche senza il log. Se invece il transaction log è necessario per completare il crash recovery di transazioni in-flight, la perdita del log equivale alla perdita delle transazioni non ancora flushed su disco al momento del crash, ma i dati già consolidati (committed e checkpointed) sono generalmente recuperabili.
È possibile recuperare un database cifrato da ransomware?
Sì, a patto che i file del database non siano stati completamente sovrascritti dalla cifratura. Molti ransomware cifrano i file in-place mantenendo la struttura del filesystem, il che consente di verificare se esistono shadow copies, backup VSS, o versioni precedenti dei file su storage separato. In alcuni casi è possibile recuperare porzioni di dati dai blocchi che il ransomware non ha ancora cifrato al momento dell’interruzione dell’attacco.
Il recupero da database richiede di spedire il server fisico?
L’analisi iniziale è gratuita. In molti casi è sufficiente inviare una copia del file di database (o un subset) per una valutazione remota senza necessità di spedire hardware fisico. Per i database su server fisici guasti o su storage SAN/NAS non accessibile, organizziamo il ritiro dell’hardware con corriere assicurato.
Quanto tempo richiede il recupero dati da un database corrotto?
Standard: 10–15 giorni lavorativi per database di dimensioni medie (fino a 500 GB) con corruzione localizzata. Express: 5–10 giorni (+30%). Emergency: 2–4 giorni lavorativi (+40%), disponibile anche nel weekend per infrastrutture critiche. I database di grandi dimensioni (multi-TB) o con corruzione estesa possono richiedere tempi aggiuntivi: il parser deve elaborare ogni singola pagina del file.
Guide tecniche sul recupero dati da database
Procedure operative, analisi degli errori più comuni e casi reali per DBA e responsabili IT che si trovano a gestire un database corrotto o inaccessibile.
Server Bare Metal vs Server Virtuale: Scegliere tra server dedicato e VPS
Scopri le differenze tra server bare metal e server virtuale. Confronto su prestazioni, costi, sicurezza e flessibilità per aiutarti a scegliere la soluzione ideale per la tua infrastruttura IT aziendale.
Come installare Windows 11 in macchina virtuale su NAS Synology
Scopri come creare e gestire una macchina virtuale Windows 11 su NAS Synology: requisiti hardware, guida passo-passo, errori frequenti, consigli su CPU, RAM e storage SSD.
VMware vs VirtualBox: Qual è la scelta migliore?
Confronto tra VMware e VirtualBox: scopri le principali differenze in prestazioni, usabilità e sicurezza tra le due piattaforme di virtualizzazione per scegliere quella più adatta alle tue esigenze IT.
Recupero dati da database: casi risolti da RecDati
DROP TABLE in produzione su SQL Server, datafile Oracle corrotto dopo un’interruzione di corrente, tablespace PostgreSQL inaccessibile per guasto dello storage: i casi reali che abbiamo risolto in laboratorio.
NAS Synology in tilt a Milano: come abbiamo salvato i progetti del cliente
Hai un problema simile? Invia oggi stesso una richiesta di preventivo a RecDati e ottieni assistenza immediata.
Recupero Dati per Pubblica Amministrazione – Server colpito da Ransomware
Il recupero dati da server colpito da ransomware rappresenta una delle sfide più complesse nel campo della data recovery, soprattutto quando si tratta di infrastrutture della Pubblica Amministrazione, dove ogni minuto di downtime può avere impatti significativi sull’operatività e sulla sicurezza dei dati. Questo case study descrive un intervento su
Recupero dati NAS QNAP in RAID 5 per studio di architettura a Roma
Hai un RAID 5 QNAP danneggiato? Invia ora una richiesta a RecDati e ricevi assistenza immediata da laboratorio specializzato.