Su un Exchange Server standalone, non è sufficiente garantire la continuità aziendale. Per i requisiti di failover e continuità aziendale, è possibile utilizzare i Gruppi di disponibilità del database (DAG) di Microsoft per garantire che Exchange Server continui a funzionare in caso di guasto di un’istanza. Affinché questo funzioni, sono necessari due o più server per ottenere un DAG, con Microsoft Exchange Server Standard o Enterprise edition. La decisione di optare per l’edizione Standard o Enterprise dipende interamente dalla struttura e dal volume delle caselle di posta elettronica.
Se non avete bisogno di più di cinque database di caselle di posta, potete optare per l’edizione Standard. Per quanto riguarda le licenze, è necessario acquistare Exchange Server Standard/Enterprise per ogni server. Per quanto riguarda le licenze di accesso client (CAL) per gli utenti, è sufficiente acquistarle una sola volta.
Di seguito è illustrato un tipico Database Availability Group (DAG), con due server Exchange e un server File Share Witness, con quorum e maggioranza di voto.
Quando si creano i gruppi di disponibilità dei database (DAG), si ha una copia di un database in un server e una copia passiva su un altro server. La copia attiva è sempre quella a cui si accede e l’altro database replica da essa.
Nell’illustrazione sottostante, si può notare che ci sono due database in cui la copia attiva di DB1 si trova su EX01 Server e la copia passiva su EX02 Server. La copia attiva di DB2 si trova sul server EX02 e la copia passiva sul server EX01.
Quando si aggiunge un nuovo database di mailbox a un Database Availability Group (DAG), è necessario prima eseguire una copia sul secondo server (nel caso della nostra illustrazione, EX02). Una volta completata la copia completa, chiamata primo seed, il Database Availability Group (DAG) continuerà a replicare tutte le modifiche. Si può anche fare una copia del database e copiarla sul server secondario. Tutto dipende dalle dimensioni e dalla velocità della rete tra i due nodi.
A volte, a causa di problemi hardware o software, è necessario riseminare il database. Ciò potrebbe essere dovuto a informazioni corrotte sulla copia del database o a un errore sul database che ha reso la copia inutilizzabile dal Database Availability Group (DAG).
Durante la semina, è possibile che si verifichi un problema con il database passivo e che la semina si interrompa con l’errore “Mailbox Database Copy Failed or Suspended”. Dopo aver indagato, nel visualizzatore eventi viene visualizzato il seguente messaggio.
MSExchangeRepl ID evento: 4113
Il controllo dello stato di salute della ridondanza del database non è riuscito. Copia del database: DB01 Conteggio ridondanza: 1
Errore: La copia passiva ‘DB01\EX02’ non è in buono stato. Stato: Fallita e sospesa
Per iniziare la risoluzione dei problemi, è necessario innanzitutto ottenere lo stato della copia da Exchange Management Shell (EMS) utilizzando il cmdlet PowerShell Get-MailboxDatabaseCopyStatus.
Per capire la causa principale del problema, è possibile utilizzare Exchange Best Practice Analyzer contro i server. Da Exchange Management Shell (EMS), eseguire Test-ServiceHealth e Test-ReplicationHealth. In questo modo si otterrà l’informazione che tutti i servizi necessari sono in esecuzione. Naturalmente, è anche possibile eseguire un’autoverifica dei server Exchange.
Proviamo a riparare il database sospendendo la copia tra il database attivo e quello passivo. Questo può essere fatto utilizzando il comando Suspend-MailboxDatabaseCopy.
Suspend-MailboxDatabaseCopy -Identity “DB01\EX01”
È qui che si può indagare sulla questione. È necessario riseminare il database. Per iniziare, è necessario eliminare tutte le copie del database. È possibile utilizzare il cmdlet PowerShell Update-MailboxDatabaseCopy con l’opzione -DeleteExistingFiles per pulire la configurazione ed eliminare le copie. Di seguito è riportato un esempio del comando:
Update-MailboxDatabaseCopy -Identity “DB01\EX01” -DeleteExistingFiles
In questo modo il database verrà riseminato dalla copia attiva a quella passiva.
Alcuni aspetti da considerare prima di eseguire il processo di risemina:
- A seconda delle dimensioni del database, delle prestazioni dei server e della velocità della rete tra i nodi, il processo può richiedere un tempo considerevole.
- Se avete più di due server, il comando PowerShell prenderà la copia attiva del database. Non è possibile scegliere da dove riseminare la copia.
- Ci sarà una differenza di dimensioni tra la copia attiva e quella passiva, poiché la copia avrà le dimensioni del database insieme al file di log delle transazioni e all’indice dei contenuti.
In alternativa, è possibile riseminare il database utilizzando Exchange Admin Center (EAC).
Per questo,
- Fare clic sulla sezione Server e sul nodo Database.
- Selezionare il database da aggiornare e fare clic sul pulsante Aggiorna per avviare il processo di risemina.
- Selezionare l’origine del database attivo e la destinazione.
Conclusione
La procedura sopra descritta può aiutarvi a eliminare l’errore “Copia del database della cassetta postale non riuscita e sospesa”. Ma cosa fare se il problema si ripresenta? Cosa succede se la copia attiva è danneggiata ed è necessario recuperare i dati dalla copia? Oppure cosa succede se la copia attiva e quella passiva sono entrambe danneggiate?
È possibile affidarsi a uno strumento di recupero del database di Exchange di terze parti, in grado di tirarvi fuori da queste situazioni difficili. Stellar Repair for Exchange è una di queste applicazioni che può aprire qualsiasi tipo di database di Exchange, sano o meno, e recuperare i dati in formato PST e altri formati. È anche possibile esportare direttamente in un nuovo database di cassette postali di Exchange o in un tenant di Office 365.
Was this article helpful?
