Recuperare un database MySQL, PostgreSQL o MongoDB corrotto nel 2026: procedure passo dopo passo

Il recupero dei database rappresenta una delle discipline più delicate del recupero dati. A differenza dei singoli file, dove la posta in gioco è binaria (recuperato o no), un database corrotto può apparire intatto all'avvio pur contenendo incoerenze silenziose — indici desincronizzati, vincoli violati, transazioni applicate parzialmente — che si manifestano solo settimane dopo sotto forma di errori applicativi o conti finanziari errati. Questo articolo documenta la procedura completa di recupero per MySQL, PostgreSQL e MongoDB, con strumenti nativi, strumenti di terze parti specializzati, aspettative di recupero e soglie per orientarsi verso un laboratorio professionale.

Tre DBMS dominano il segmento open source consumer e PMI nel 2026: MySQL/MariaDB, PostgreSQL (in crescita costante) e MongoDB (il principale document store NoSQL). Ciascuno adotta un'architettura di archiviazione radicalmente diversa — InnoDB e i suoi file .ibd, PostgreSQL e il suo base/ con WAL separati, MongoDB e il suo motore WiredTiger con collection .wt — che richiede procedure di recupero specifiche. Nessuno strumento generalista di recupero file (EaseUS, PhotoRec, Recuva) è sufficiente qui.

Affiliazione trasparente. Save My Disk percepisce una commissione se acquisti una licenza tramite i link EaseUS presenti in questo articolo. EaseUS interviene solo a livello di filesystem — per il recupero dei file .ibd, base/, .wt che ospitano il database. Per il recupero transazionale vero e proprio (innodb_force_recovery, pg_resetwal, mongod --repair), citiamo esclusivamente strumenti DBMS nativi o Stellar Repair secondo la nostra metodologia pubblica.

MySQL e MariaDB: innodb_force_recovery e mysqldump forense

Il motore di archiviazione InnoDB di MySQL 8.0.x e MariaDB 11.x memorizza i dati in file .ibd, uno per tabella (file-per-table per impostazione predefinita da MySQL 5.6) oppure in un tablespace condiviso ibdata1. Indici, vincoli di chiave esterna e trigger risiedono nei file .frm (fino a MySQL 5.7) o nel dictionary di InnoDB (da MySQL 8.0). Il binary log (binlog) traccia tutte le modifiche per la replica e il point-in-time recovery.

La corruzione tipica di InnoDB si traduce in un crash all'avvio con, nel file error.log, un messaggio InnoDB: Database page corruption on disk oppure una lettura fallita del file alla page X. La procedura standard sfrutta il parametro innodb_force_recovery, che assume valori interi da 0 (modalità normale) a 6 (modalità forense massima). Ogni incremento disabilita una protezione:

• 1 disabilita il controllo delle pagine corrotte (perdita minima)
• 2 disabilita il purge thread (può lasciare transazioni zombie)
• 3 disabilita il rollback delle transazioni (le modifiche parziali persistono)
• 4 disabilita il merge dell'insert buffer (incoerenze degli indici)
• 5 disabilita il redo log (perdita di transazioni non in checkpoint)
• 6 disabilita la crash recovery all'avvio (corruzione grave ignorata)

I livelli da 1 a 3 risolvono la grande maggioranza dei casi, con il livello 1 da solo che ne copre molti. Oltre il livello 3, l'export immediato tramite mysqldump --all-databases --routines --triggers --single-transaction resta l'unico percorso sicuro — qualsiasi ulteriore scrittura rischia una corruzione irreversibile.

Lo strumento Stellar Repair for MySQL 7 (rilasciato a marzo 2026, 299 $) offre un'analisi forense offline dei file .ibd che completa innodb_force_recovery nei casi in cui il server non si avvia più affatto. Recupera una quota elevata di righe da file .ibd corrotti con l'header della pagina intatto.

PostgreSQL: pg_resetwal, point-in-time recovery e standby

PostgreSQL 16.x, rilasciato a settembre 2023, archivia i dati in una struttura data/base/<dbOID>/ con un file per tabella identificato dall'OID. I Write-Ahead Log (WAL) in pg_wal/ tracciano ogni modifica prima del commit e abilitano il point-in-time recovery (PITR). Il checkpoint regolare svuota i vecchi WAL e sincronizza i file di dati.

La corruzione di PostgreSQL assume tre forme principali. Primo scenario: crash durante una scrittura che lascia un WAL incompleto. Al riavvio, PostgreSQL riproduce il WAL e trova uno stato coerente. Nella maggior parte dei casi non è necessario alcun intervento manuale — il replay automatico del WAL di PostgreSQL se ne occupa.

Secondo scenario: corruzione di una pagina di tabella identificata dal messaggio PANIC: corrupted item pointer. La procedura richiede zero_damaged_pages = on nel file postgresql.conf all'avvio, che marca le pagine corrotte come vuote anziché interrompere. I dati su queste pagine vengono persi — l'opzione consente solo l'avvio per esportare il resto.

Terzo scenario: impossibilità di avviarsi anche con zero_damaged_pages. È il caso in cui interviene pg_resetwal. La documentazione postgresql.org insiste: pg_resetwal è un'operazione di ultima istanza che può causare la perdita di dati non in checkpoint e incoerenze. Eseguila su una COPIA della directory dei dati, mai in produzione.

Per i deployment PostgreSQL con standby in streaming replication (configurazione consigliata in produzione da PostgreSQL 12), la procedura di recupero diventa banale: promuovi lo standby a primary tramite pg_ctl promote, poi ricostruisci un nuovo standby dal nuovo primary. Nessun pg_resetwal necessario, nessuna perdita di dati. Ecco perché la maggior parte degli incidenti PostgreSQL in contesti di produzione ben architettati si risolve senza alcun recupero forense.

MongoDB WiredTiger: --repair, replica set e dump delle collection

MongoDB 7.0, rilasciato ad agosto 2023, utilizza esclusivamente il motore di archiviazione WiredTiger (il vecchio motore MMAPv1 è stato rimosso da MongoDB 4.2). Le collection sono archiviate in file .wt per collection, con un journal WiredTiger separato per la durabilità. I replica set duplicano i dati su almeno 3 nodi con un oplog per la sincronizzazione.

La corruzione di WiredTiger si manifesta tipicamente come un crash all'avvio di mongod con il messaggio WT_PANIC: WiredTiger library panic oppure Detected unclean shutdown - this should only occur if the storage volume was corrupted. La procedura --repair esegue tre operazioni: verifica di ogni pagina WiredTiger, ricostruzione degli indici ed eliminazione dei documenti corrotti.

mongod --repair --dbpath /var/lib/mongodb

Questa procedura può durare da 20 minuti per un database da 50 GB a diverse ore per un database multi-TB. La documentazione MongoDB Manual Repair afferma che --repair può eliminare in modo permanente i documenti — la copia completa del dbpath non è negoziabile prima dell'avvio.

Per i replica set, la strategia cambia radicalmente. Il primary corrotto deve essere rimosso dal set (rs.remove("primary:27017")), un secondary integro promosso (rs.stepDown() sul primary problematico forza un'elezione), poi il nodo corrotto ricostruito tramite initial sync. Questo approccio evita qualsiasi ricorso a --repair e preserva la coerenza transazionale ACID del replica set.

Confronto degli strumenti di terze parti per database corrotti

Quando gli strumenti nativi (innodb_force_recovery, pg_resetwal, --repair) non bastano, intervengono diversi strumenti di terze parti specializzati. Ecco i quattro principali.

Per PostgreSQL, nessuno strumento di terze parti a pagamento eguaglia gli strumenti nativi (pg_resetwal, pg_filedump, pg_dirtyread). Gli amministratori PostgreSQL esperti lavorano esclusivamente con questi strumenti + una solida strategia di streaming replication.

Laboratorio professionale: soglie di orientamento e costi 2026

Quattro situazioni impongono l'orientamento verso un laboratorio specializzato in database anziché un tentativo interno. Primo: Transparent Data Encryption (TDE) MS SQL Server con chiavi OEM perse. Secondo: Oracle Database con ASM corrotto, che richiede competenze certificate da DBA Oracle. Terzo: cluster multi-regione Cassandra o ScyllaDB con corruzione del Merkle tree. Quarto: volume fisico in errore che impedisce la clonazione software della directory dei dati — orientati verso un laboratorio hardware per il recupero di SSD/HDD/NVMe prima di qualsiasi procedura DBMS.

I laboratori specializzati in database nel 2026 includono Ontrack Database Recovery Services (USA, UK, Germania), DriveSavers Database Specialist Team (USA), Stellar Data Recovery Database Services (India, presenza globale), Recoveo Database (Polonia) e Kroll Ontrack Forensics Database (forense legale). Prezzi pubblici osservati a maggio 2026:

• MySQL o PostgreSQL consumer / PMI: da 1.200 a 3.500 € (diagnosi forfettaria + recupero + ripristino)
• Replica set MongoDB WiredTiger: da 3.500 a 9.000 € (a seconda del volume e del numero di shard)
• MS SQL Server enterprise: da 5.500 a 16.000 € (MDF/LDF corrotti, TDE attivo)
• Oracle Database enterprise: da 9.000 a 28.000 € (ASM, RAC, RMAN forense)
• Cluster Cassandra / ScyllaDB: da 8.000 a 22.000 € (ricostruzione Merkle tree, multi-regione)

Consulta la nostra guida BitLocker per le specificità della crittografia con chiavi OEM Microsoft. Per i NAS che ospitano database dockerizzati corrotti, consulta la nostra guida al recupero RAID.

Strategia di prevenzione 2026: l'unica vera linea di difesa

La grande maggioranza dei casi di recupero database sarebbe stata evitata o risolta in meno di 30 minuti se tre pratiche fossero state in atto. Primo: backup logico giornaliero (mysqldump, pg_dump, mongodump) su storage remoto, testato con un ripristino mensile. Secondo: backup fisico orario (Percona XtraBackup, pg_basebackup, MongoDB Cloud Backup) con snapshot ZFS o Btrfs della directory dei dati. Terzo: streaming replication o replica set con almeno 2 nodi secondary su storage indipendente.

Per i budget limitati, il minimo vitale resta un mysqldump/pg_dump/mongodump giornaliero su storage S3 crittografato + test di ripristino mensile su un'istanza di staging. Questa strategia basta a trasformare un incidente catastrofico in un semplice inconveniente di 2 ore.

FAQ — Domande frequenti sul recupero dei database

MySQL InnoDB non si avvia: quale innodb_force_recovery usare?

Sempre innodb_force_recovery=1 per primo. I livelli da 1 a 3 bastano nella grande maggioranza dei casi. Oltre il 4, esporta immediatamente con mysqldump --all-databases senza scrivere.

PostgreSQL non si avvia dopo un crash: pg_resetwal è la soluzione?

Non come prima scelta. pg_resetwal può causare la perdita di dati committati. Prima di tutto, prova pg_basebackup da standby, controlla gli archivi WAL, esamina i backup fisici. Se inevitabile, su una COPIA mai in produzione.

MongoDB --repair funziona su WiredTiger 7.0.x?

Sì, ma con limiti. Può eliminare in modo permanente le collection inaccessibili — esegui prima il backup completo del dbpath. Per i replica set, fermare il primary corrotto e ripristinare da un secondary integro tramite initial sync è più sicuro.

Differenza tra recupero di un database e recupero classico di un filesystem?

Tre differenze: (1) indici, vincoli e trigger interni che solo gli strumenti DBMS ricostruiscono; (2) formati binari proprietari versionati (.ibd, .wt, base/); (3) transazioni ACID che richiedono binlog, WAL, oplog intatti.

Quanto costa il recupero professionale di un database nel 2026?

MySQL/PostgreSQL consumer: 1.200-3.500 €. MongoDB WiredTiger: 3.500-9.000 €. MS SQL Server: 5.500-16.000 €. Oracle enterprise: 9.000-28.000 €. Cluster Cassandra: 8.000-22.000 €. Strumenti di terze parti: Stellar 299-599 $, EaseUS MS SQL 299 $.

Verdetto: prevenzione transazionale prima, recupero forense in secondo piano

Il recupero dei database nel 2026 resta asimmetrico: la prevenzione (backup testati + standby di replica + monitoraggio proattivo) costa una piccola frazione del tempo di un DBA e risolve la stragrande maggioranza degli incidenti in pochi minuti. Il recupero forense senza prevenzione costa tra 1.200 € e 28.000 € a seconda del DBMS e della complessità.

Per MySQL e MariaDB, la combinazione Percona XtraBackup giornaliero + binlog abilitato + mysqldump --single-transaction settimanale basta a coprire la stragrande maggioranza degli scenari. Per PostgreSQL, la streaming replication con 1 standby sincrono e 1 standby asincrono + pg_basebackup settimanale resta lo standard di riferimento del 2026. Per MongoDB, un replica set con almeno 3 nodi, backup mongodump giornalieri e MongoDB Cloud Backup mensile è obbligatorio.

Quando il recupero diventa inevitabile, la regola assoluta è una sola riga: lavorare sempre su una copia della directory dei dati, mai sulla produzione di origine. Questa semplice precauzione è ciò che separa un recupero pulito dalla perdita totale: lavorare da un clone corretto protegge i dati, mentre eseguire la procedura direttamente sulla produzione corrotta rischia di perdere tutto.