Indice dei contenuti
Il ripristino di un database MS Exchange corrotto o non più raggiungibile è, ahimé, un compito che la maggior parte degli amministratori di sistema si trova a dover effettuare relativamente spesso: le cause che determinano il verificarsi di tale eventualità sono molteplici, ma nella maggior parte dei casi sono una diretta conseguenza dei seguenti fattori:
- Problemi hardware o altro malfunzionamento del supporto di memorizzazione (Hard-Disk) su cui risiede il database di MS Exchange, ovvero il file .edb all'interno del quale sono memorizzate le cassette postali, cartelle pubbliche/condivise.
- Riavvio repentino della macchina server (magari a seguito di un blackout o arresto anomalo), specie se avviene in un momento di intensa attività di lettura/scrittura.
- Attività malevola di virus, malware o altro software che effettua attività di scrittura "non previste" sull'archivio.
La principale avvisaglia della indisponibilità del database di MS Exchange è quasi sempre riscontrabile attraverso i problemi di connessione dei client MS Outlook, i quali non riescono più a connettersi a Exchange presentando lo stato DISCONNESSO (o DISCONNECTED, nelle versioni in lingua inglese) nella taskbar, ovvero riportando il seguente messaggio di errore in conseguenza dei tentativi di accesso alle cartelle pubbliche/condivise:
Impossibile visualizzare la cartella. Impossibile accedere da Microsoft Outlook al percorso di cartella specificato. Il computer che esegue Microsoft Exchange Server non è disponibile. È probabile che vi siano problemi di rete o che il server di Exchange sia inattivo.
Ovviamente, prima di intervenire sul server MS Exchange, è opportuno verificare che il problema non sia dovuto ad altre cause, come ad esempio la temporanea irraggiungibilità del server dovuta a problemi di rete, mancata connettività o altre situazioni non legate al database delle cassette postali: a tal proposito, consigliamo di leggere questo articolo che descrive la maggior parte di queste eventualità.
La certezza che il problema sia legato a un malfunzionamento del database di MS Exchange può essere ottenuta collegandosi alla Exchange Management Interface, raggiungibile tramite un link apposito presente all'interno nel menu MS Exchange creato a seguito dell'installazione. Una volta connessi, è possibile immediatamente verificare se il database è installato e raggiungibile (Mounted) oppure no (Unmounted).
MS Exchange Transaction Log
La prima cosa da fare quando si ha a che fare con un database di MS Exchange corrotto è individuare il percorso file system del database stesso e di tutti i file ad esso correlati. Nella maggior parte dei casi, salvo diversamente specificato al momento dell'installazione, questi file si trovano in una singola cartella posta all'interno del percorso di installazione dell'istanza MS Exchange Server in uso. Ad esempio, per le versioni di MS Exchange 2013 e 2016, il percorso è il seguente:
- C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\<database_name>
Per un elenco completo delle build number, version ID e path predefiniti di tutte le principali edizioni di MS Exchange server, consultare il seguente articolo: MS Exchange Server Build Number, Version ID e Path predefiniti – tutte le edizioni.
Una volta recuperato il percorso esatto, è consigliabile navigare al suo interno per verificare la presenza dei seguenti file:
- <DatabaseName>.edb: il database di MS Exchange.
- E00.log: questo file contiene i transaction log, ovvero il log di tutte le ultime operazioni effettuate dal server.
- E000000001F.log, E000000001E.log etc.: questi file contengono i transaction log archiviati e vengono tipicamente creati da Exchange quando il file precedente supera le dimensioni massime predefinite (solitamente 1MB o 5MB).
- E00.chk: questo è il file checkpoint, utilizzato da Exchange per mettere in relazione le informazioni scritte sul database e quelle presenti nei transaction log.
- E00res00001.jrs, E00res00002.jrs: file creati da Exchange quando l'hard disk che ospita i transaction log non ha più spazio disponibile.
- E00tmp.log: un file temporaneo che viene utilizzato quando il sistema provvede ad archiviare il transaction log e sostituirlo con un nuovo file.
Nel corso dei paragrafi successivi vedremo come questi file possono essere utilizzati per tentare varie attività di recupero/ripristino dei dati attraverso i software forniti in dotazione con MS Exchange Server o prodotti di terze parti. E' però importante sottolineare che, nel momento stesso in cui si è in grado di determinare con relativa certezza che il problema riguarda la compromissione dell'unità di memorizzazione e/o del controller in uso, è imperativo sostituire l'hardware difettoso prima di effettuare qualsivoglia operazione di recupero software.
Auto-Ripristino
Il ruolo dei transaction log e del file checkpoint è fondamentale, in quanto consente spesso di recuperare tutti i dati anche in caso di crash o compromissione del database: nella maggior parte dei casi, grazie alla presenza di questi file di registro Exchange è in grado di auto-riparare il proprio database al momento dell'avvio/riavvio, ripristinandolo al momento immediatamente precedente all'errore. Per questo motivo, a meno che non si abbiano già forti indizi che il problema sia dovuto a un malfunzionamento hardware, la prima cosa da fare in caso di crash del database di Exchange è riavviare il servizio (o, se possibile, il server) e forzare in tal modo la procedura di auto-riparazione prevista in questi casi.
Naturalmente, esistono numerosi casi in cui il server non riuscirà a compiere un ripristino automatico del database, rendendo indispensabile un intervento manuale da parte dell'amministratore di sistema. A questo proposito, prima di continuare, è opportuno prestare particolare attenzione al seguente disclaimer:
Database di ripristino
La prima attività manuale che consigliamo di effettuare per recuperare i dati senza compromettere ulteriormente il database corrotto è basata sulla creazione di un Database di Ripristino (RDB): quest'ultimo è un tipo speciale di database che consente di montare un database delle cassette postali ripristinato e di estrarre i dati dal database ripristinato durante un'operazione di ripristino. Per estrarre i dati da un database di ripristino è possibile utilizzare il cmdlet New-MailboxRestoreRequest. Dopo l'estrazione, i dati possono essere esportati in una cartella o uniti in una cassetta postale esistente. Il vantaggio principale di un database di ripristino è quello di rendere possibile il ripristino dei dati da un backup o dalla copia di un database senza interferire con l'accesso dell'utente ai dati correnti.
Microsoft Exchange Server supporta la possibilità di ripristinare i dati direttamente in un database di ripristino. L'installazione dei dati recuperati come database di ripristino consente all'amministratore di ripristinare le singole cassette postali o anche i singoli elementi di una cassetta postale. Il recupero di un database di ripristino può essere effettuato in due modi:
- Se esiste già un database di ripristino, l'applicazione può smontare il database originale, ripristinare i dati nel database di ripristino e i file di registro e quindi montare nuovamente il database originale.
- È possibile ripristinare il database e i file di registro in qualsiasi percorso su disco. Exchange analizza i dati ripristinati e riesegue i registri delle transazioni per aggiornare il database originale; successivamente, è possibile configurare un database di ripristino affinché faccia riferimento a file di database già ripristinati.
Le modalità per la creazione di un database di ripristino sono spiegate in modo esaustivo nei seguenti articoli ufficiali Microsoft:
- Database di ripristino (in lingua italiana)
- Recovery databases (in lingua inglese)
Eseutil
Qualora le condizioni del database non rendano praticabile l'utilizzo del database di ripristino è possibile utilizzare le funzionalità avanzate dello strumento eseutil, fornito gratuitamente insieme al pacchetto di Exchange Server, direttamente sul database corrotto (possibilmente non prima di averne fatto una copia, transaction log inclusi, come avremo modo di spiegare a breve). Si tratta di un tool estremamente utile che consente di effettuare una serie di operazioni sui database corrotti: controllo dei dati, deframmentazione dell'archivio, integrity check, riduzione dello spazio occupato e, ovviamente, vari tentativi di recupero e/o ripristino di un file .edb danneggiato.
Lo strumento Eseutil si trova all'interno della cartella Bin relativa alla versione di MS Exchange Server in uso: ad esempio, per le versioni di MS Exchange 2013 e 2016, il percorso è il seguente:
- C:\Program Files\Microsoft\Exchange Server\V15\Bin
E' possibile lanciare lo strumento Eseutil con uno dei vari switch disponibili. Ciascuno di essi consente di attivare una delle molte operazioni supportate:
- Per effettuare una duplicazione del database e dei file relativi ai transaction log: eseutil /y
- Per effettuare un recupero del database: eseutil /r
- Per effettuare una riparazione di emergenza del database: eseutil /p
- Per deframmentare il database: eseutil /d
- Per effettuare un hard recovery del database: eseutil /c
- Per verificare il checksum del database: eseutil /k
- Per controllare l'integrità del database: eseutil /g
- Per visualizzare le informazioni del database (headers, file dei log e/o checkpoint files): eseutil /m
Backup del database
Prima di effettuare qualsivoglia tentativo di riparazione (o hard recovery) del database, è opportuno effettuare un backup di sicurezza utilizzando l'apposita funzione eseutil /y descritta sopra.
Nel caso in cui il database da MS Exchange Server si trovi ancora nello stato mounted, eseguire l'apposito comando Powershell Dismount-Database per effettuare il dismount:
PS> Dismount-Database –Identity <name of the database>
Nel momento in cui il database non è più mounted è possibile procedere con la copia del database utilizzando il comando eseutil /y:
> eseutil /y <path_db> /d <path_destinazione>
Una volta fatto questo si può procedere a effettuare le varie attività di ripristino/riparazione del database, che consigliamo di svolgere nel seguente ordine (dalla meno "distruttiva" alla più "distruttiva").
Verifica dello stato del Database con eseutil /mh
Subito dopo aver effettuato il backup è consigliabile controllare lo stato del Database con il comando eseutil /mh:
eseutil.exe /mh <path_db>
L'output di questo comando dovrebbe visualizzare alcuni parametri del database e dei relativi transaction log, tra cui lo Stato: i possibili valori di questo parametro possono essere:
- pulito (clean): il database può essere montato e utilizzato: non è necessaria alcuna attività di riparazione, ripristino o recupero dati.
- sporco (dirty): il database contiene errori e/o inconsistenze tali da non poter essere utilizzato.
E' opportuno ripetere questo comando al termine di ogni operazione di recupero/ripristino/riparazione descritta nei paragrafi successivi, così da controllare se i nostri tentativi sono andati a buon fine oppure no.
Recupero del Database con eseutil /r
La funzione eseutil /r consente di tentare un recupero (recovery) del database sulla base delle informazioni reperibili all'interno dei transaction log, con l'obiettivo di ripristinare il database in uno stato coerente. Si tratta senza ombra di dubbio della procedura più sicura, in quanto non prevede lo "scarto" (ovvero l'eliminazione) di dati potenzialmente recuperabili.
L'utilizzo più semplice di questa funzione è il seguente:
> eseutil /r Enn
Il parametro obbligatorio Enn va valorizzato indicando il prefisso (nome file senza estensione) del file transaction log che si desidera utilizzare per verificare (ed eventualmente ripristinare) l'integrità del database: tipicamente, il valore da indicare è quello del transaction log più recente, ovvero E00.
Riparazione di emergenza del Database con eseutil /p
Il comando eseutil /r è nella maggior parte dei casi la scelta più sicura quando si dispone dei transaction log. Esistono tuttavia casi in cui questi file non sono disponibili o il loro utilizzo è reso impossibile dalla presenza dei seguenti errori:
- Error -501 (JET_errLogFileCorrupt) – "Log File is Corrupt"
- Error -514 (JET_errBadLogVersion) – "Log file generated with different Exchange Server or edition"
- Error -515 (JET_errInvalidLogSequence) – "Any log file from the sequence is missing"
- Error -533 (JET_errCheckpointCorrupt) – "Checkpoint file is deleted or corrupt"
Qualora si verifichi uno scenario di questo tipo, è possibile utilizzare il comando eseutil /p per eseguire una riparazione del database Exchange senza utilizzare i transaction log. Tuttavia, questa funzione potrebbe comportare una perdita di dati qualora il database contenga record corrotti, danneggiati e/o relazioni inconsistenti tra le tabelle interne: in tutti questi casi, il comando eseutil /p eliminerà tutti i record in questione, con il rischio concreto di perdere dati e/o persino di rendere il database "non mountabile". Per questo motivo l'utilizzo di tale switch è da considerarsi una extrema ratio, anche perché potrebbe comportare attività ulteriori da svolgere sul database "recuperato" al fine di renderlo utilizzabile: tra queste, vi sarà certamente la deframmentazione del database illustrata nel prossimo paragrafo.
Deframmentazione del Database con eseutil /d
La funzione eseutil /d consente di deframmentare il database Exchange, ovvero di recuperare lo spazio relativo ai record eventualmente eliminati (ad esempio tramite eseutil /p) e che occupano ancora spazio all'interno delle pagine del database. Il comando da effettuare è il seguente:
eseutil /d <path_database>
New-MailboxRepairRequest
Nei casi in cui il comando eseutil /p non si rivelasse sufficiente a risolvere il problema o il database "riparato" non fosse utilizzabile, è possibile utilizzare il comando Powershell New-MailBoxRepairRequest per riparare gli errori eventualmente presenti nel database:
PS> New-MailboxRepairRequest -Database <nome del db> -CorruptionType <tipo di errore da correggere>
Questo comando Powershell è estremamente potente e supporta numerosi parametri interessanti: tra questi è particolarmente importante il parametro -CorruptionType, che consente di orientare le attività di identificazione e correzione degli errori logici verso alcune caratterie specifiche. I possibili valori sono:
- SearchFolder
- AggregateCounts
- ProvisionedFolder
- FolderView
Altri parametri utili sono: -DetectOnly, che consente di individuare gli errori senza effettuare le correzioni sul database; -Mailbox, che consente di limitare le attività di controllo e riparazione a una cassetta di posta specifica; e così via. Per un elenco completo delle funzionalità di questo comando e una serie di altre informazioni utili consigliamo di consultare questo articolo ufficiale su docs.microsoft.com.
Software di terze parti
Qualora l'utilizzo combinato di Eseutil e New-MailboxRepairRequest non fosse sufficiente per risolvere il vostro problema potete provare una delle molte soluzioni commerciali disponibili sul mercato:
- Stellar Repair for Exchange, di Stellar Inc.
- Exchange Server Data Recovery, di Lepide Software Inc.
- SysTools Exchange Recovery, di SysTools Inc.
Tutti i software di cui sopra consentono di effettuare il recupero e il ripristino di un database Exchange attraverso vari metodologie di data recovery: ciascuno di essi dà la possibilità di scaricare una demo gratuita e senza impegno, che però ha funzionalità limitate (ripristino di un numero limitato di e-mail su un database separato). La demo può essere molto utile per verificare se il software consente il recupero dei propri dati, procedendo con l'acquisto soltanto in caso affermativo.
Conclusioni
Il ripristino di un database MS Exchange Server danneggiato è sicuramnte un'attività delicata e molto seccante: ci auguriamo che questo articolo possa essere d'aiuto a quanti sono costretti a cimentarsi con questa sfortunata evenienza, ahimé non sufficientemente rara visto l'utilizzo sempre più intenso delle e-mail ad ogni livello.
Per il momento è tutto: felice ripristino!
