Backup, ripristino e ripristino di emergenza in Exchange Server
La pianificazione della protezione dei dati è un processo complesso basato su molte decisioni prese durante la fase di pianificazione della distribuzione. Nell'ambito della pianificazione, è importante comprendere i modi in cui i dati possono essere protetti e determinare il metodo più adatto alle esigenze dell'organizzazione.
Tradizionalmente, i backup sono stati utilizzati per gli scenari seguenti:
Ripristino di emergenza: in caso di errore hardware o software, più copie di database in un dag consentono la disponibilità elevata con failover rapido e perdita di dati minima o nessuna. Ciò elimina i tempi di inattività e la risultante perdita di produttività che rappresenta un costo notevole per l'organizzazione derivante dal ripristino da un backup temporizzato precedente su disco o nastro. I DAG possono essere estesi su più siti e possono offrire la resilienza contro errori del disco, del server, della rete e del datacenter.
Recupero di elementi eliminati accidentalmente: storicamente, in una situazione in cui un utente ha eliminato gli elementi che in seguito dovevano essere recuperati, è stato necessario trovare il supporto di backup in cui sono stati archiviati i dati che dovevano essere recuperati e quindi in qualche modo ottenere gli elementi desiderati e fornirli all'utente. Con la cartella Elementi ripristinabili in Exchange 2016 ed Exchange 2019 e i criteri di blocco che possono essere applicati, è possibile conservare tutti i dati eliminati e modificati per un periodo di tempo specificato, in modo che il ripristino di questi elementi sia più semplice e veloce. In questo modo si riduce l'onere per gli amministratori di Exchange e l'help desk IT consentendo agli utenti finali di recuperare gli elementi eliminati accidentalmente, riducendo così la complessità e i costi amministrativi associati al ripristino di un singolo elemento. Per altre informazioni, vedere Criteri di messaggistica e conformità in Exchange Server e Prevenzione della perdita di dati in Exchange Server.
Archiviazione dei dati a lungo termine: i backup sono stati usati anche come archivio e in genere vengono usati su nastro per mantenere gli snapshot temporizzato dei dati per lunghi periodi di tempo, come regolato dai requisiti di conformità. Le nuove funzionalità di archiviazione, ricerca in più cassette postali e conservazione dei messaggi in Exchange Server offrono un meccanismo per mantenere in modo efficiente i dati in modo accessibile all'utente finale per lunghi periodi di tempo. In questo modo vengono eliminati costosi ripristini da nastro e aumenta la produttività. Per altre informazioni, vedere Archiviazione sul posto in Exchange Server, eDiscovery sul posto in Exchange Server e Blocco sul posto e blocco per controversia legale in Exchange Server.
Snapshot temporizzato del database: se un'ultima copia temporizzato dei dati delle cassette postali è un requisito per l'organizzazione, Exchange offre la possibilità di creare una copia di database ritardata in un ambiente dag. Questo può essere utile nel raro evento che archivia le repliche di danneggiamento logico in più copie di database nel dag, causando la necessità di tornare a un punto precedente nel tempo. Può essere utile anche se un amministratore elimina accidentalmente le cassette postali o i dati utente. Il ripristino da una copia ritardata può essere più veloce del ripristino da un backup perché le copie in ritardo non richiedono un processo di copia che richiede molto tempo dal server di backup al server Exchange. Ciò può ridurre significativamente il costo totale di proprietà riducendo i tempi di inattività.
Poiché esistono funzionalità di Exchange Server native che soddisfano ognuno di questi scenari in modo efficiente ed economico, è possibile ridurre o eliminare l'uso dei backup tradizionali nell'ambiente.
Protezione dei dati nativi di Exchange
L'architettura preferita di Microsoft per Exchange Server 2016 e Exchange Server 2019 sfrutta un concetto noto come Exchange Native Data Protection. La protezione dei dati nativa di Exchange si basa sulle funzionalità integrate di Exchange per proteggere i dati della cassetta postale, senza usare i backup (anche se è comunque possibile usarli). Exchange 2016 ed Exchange 2019 includono diverse funzionalità che, se distribuite e configurate correttamente, possono fornire protezione dei dati nativa che elimina la necessità di eseguire backup tradizionali dei dati. L'uso delle funzionalità di disponibilità elevata integrate in Exchange Server per ridurre al minimo i tempi di inattività e la perdita di dati in caso di emergenza può anche ridurre il costo totale di proprietà del sistema di messaggistica. Combinando queste funzionalità con altre funzionalità incorporate, come la conservazione a fini giudiziari, è possibile ridurre o eliminare l'uso di backup temporizzati e abbassare notevolmente i costi.
Oltre a determinare se Exchange Server consente di abbandonare i backup temporizzato tradizionali, è consigliabile valutare il costo dell'infrastruttura di backup corrente. Considerare il costo dei tempi di inattività dell'utente finale e la perdita dei dati quando si cerca di eseguire il ripristino da un'infrastruttura di backup esistente. Inoltre, includere i costi relativi alla licenza, all'installazione e all'hardware, così come i costi di gestione associati al ripristino dei dati e al mantenimento dei backup. A seconda dei requisiti dell'organizzazione, è molto probabile che un ambiente Exchange 2016 o Exchange 2019 puro con almeno tre copie del database delle cassette postali fornirà un costo totale di proprietà inferiore rispetto a uno con i backup.
Prima di usare le funzionalità incorporate in Exchange Server, è necessario considerare diversi problemi in sostituzione dei backup tradizionali. Potrebbero esserci anche considerazioni specifiche per la propria organizzazione. Considerare i seguenti problemi e tenere presente che non si tratta di un elenco esaustivo:
È necessario determinare la quantità di copie di database da distribuire. Si consiglia di distribuire almeno tre copie (non ritardate) di un database delle cassette postali prima di eliminare i tradizionali sistemi di protezione del database, quali i backup tradizionali basati su VSS o le soluzioni RAID (Redundant Array of Independent Disks).
È necessario definire in modo chiaro l'obiettivo temporale di recupero e gli obiettivi per il punto di recupero e stabilire che l'utilizzo di un insieme combinato di funzionalità incorporate al posto di backup tradizionali consente di raggiungere questi obiettivi.
È necessario determinare il numero di copie del database necessarie a risolvere diversi scenari di errore.
È necessario determinare se l'eliminazione dell'uso di un gruppo di disponibilità del database o di alcuni dei suoi membri consenta un risparmio sufficiente a supportare una soluzione di backup tradizionale. In questo caso, è necessario determinare se quella soluzione migliora i contratti di servizio dell'obiettivo temporale di recupero o dell'obiettivo per il punto di recupero.
È necessario determinare se ci si possa permettere di perdere una copia temporizzata se nel membro del gruppo di disponibilità del database che ospita la copia si verifica un errore che influenza la copia o l'integrità della copia.
Exchange Server consente di distribuire cassette postali molto più grandi, con una dimensione massima consigliata del database delle cassette postali di 2 terabyte (quando vengono usate due o più copie del database delle cassette postali a disponibilità elevata). In base alle cassette postali di dimensioni maggiori che verranno probabilmente distribuite dalla maggior parte delle organizzazioni, è necessario determinare il proprio obietti per il punto di recupero qualora si dovessero riprodurre numerosi file di registro durante l'attivazione di una copia del database o di una copia del database ritardata.
È necessario determinare la modalità di rilevamento del danneggiamento della parte logica in una copia attiva del database e il modo per impedire che tale danneggiamento si ripeta nelle copie passive del database. Ciò include la definizione del piano di recupero per questa situazione e della quantità di volte in cui si è verificato questo scenario in passato. Se il danneggiamento della parte logica si verifica di frequente nell'organizzazione, si consiglia di calcolare questo scenario nel progetto utilizzando una o più copie ritardate con una finestra relativa all'intervallo di riesecuzione per consentire all'utente di rilevare e correggere il danneggiamento della parte logica quando si verifica, ma prima che tale danneggiamento viene replicato in altre copie del database.
Una delle funzioni eseguite al termine di un backup incrementale o di un backup completo è il troncamento dei file di registro non più necessari per il ripristino del database. Se i backup non vengono acquisiti, non si verifica il troncamento del registro. Per impedire che i file di registro aumentino, occorre abilitare la registrazione circolare per i database replicati. Quando si unisce la registrazione circolare con la replica continua, si forma un nuovo tipo di registrazione circolare denominata registrazione circolare a replica continua (CRCL), diversa dalla registrazione circolare ESE. Mentre la registrazione circolare ESE viene eseguita e gestita dal servizio Archivio informazioni di Microsoft Exchange, la registrazione circolare a replica continua viene eseguita e gestita dal servizio di replica di Microsoft Exchange. Quando abilitata, la registrazione circolare ESE non genera file di registro aggiuntivi ma, se necessario, sovrascrive il file di registro corrente. Tuttavia, in un ambiente di replica continua, i file di registro sono necessari per la distribuzione e la riproduzione dei registri. Di conseguenza, quando si abilita la registrazione circolare a replica continua, il file di registro corrente non viene sovrascritto e vengono generati file di registro chiusi per il processo di distribuzione e riproduzione dei registri.
In particolare, il servizio di replica di Microsoft Exchange gestisce la registrazione circolare a replica continua in modo da mantenere la continuità dei registri e i registri non vengono eliminati se sono ancora necessari per la replica. Il servizio di replica di Microsoft Exchange e il servizio Archivio informazioni di Microsoft Exchange comunicano utilizzando chiamate di procedura remote (RPC) relative ai quali file di registro possono essere eliminati.
Per eseguire il troncamento su copie di database delle cassette postali altamente disponibili (non ritardate), è necessario che sia vero quanto riportato di seguito:
È stato eseguito il backup del file di registro o è abilitata la registrazione circolare a replica continua.
Il file di registro è al di sotto del punto di arresto.
Le altre copie non ritardate del database accettano l'eliminazione.
Il file di registro è stato ispezionato da tutte le copie ritardate del database.
Per eseguire il troncamento su copie di database ritardate, è necessario che sia vero quanto riportato di seguito:
Il file di registro è al di sotto del punto di arresto.
Il file di registro è precedente a ReplayLagTime + TruncationLagTime.
Il file di registro viene eliminato sulla copia attiva del database.
Tecnologie di backup supportate
Exchange Server supporta solo backup basati su VSS compatibili con Exchange. Exchange Server include un plug-in per Windows Server Backup che consente di eseguire e ripristinare backup basati su VSS dei dati di Exchange. Per eseguire il backup e il ripristino di Exchange Server, è necessario usare un'applicazione compatibile con Exchange che supporti il writer VSS per Exchange Server, ad esempio Windows Server Backup (con il plug-in VSS), Microsoft System Center 2012 - Data Protection Manager o un'applicazione basata su VSS compatibile con Exchange di terze parti.
Per la procedura dettagliata su come eseguire il backup e il ripristino dei dati di Exchange utilizzando Windows Server Backup, vedere Utilizzo di Windows Server Backup per eseguire il backup e il recupero dei dati di Exchange.
Exchange Server VSS Writer
Le versioni precedenti di Exchange includevano due writer VSS: uno all'interno del servizio Microsoft Exchange Information Store (store.exe) e uno all'interno del servizio Replica di Microsoft Exchange (msexchangerepl.exe). In Exchange 2013, la funzionalità writer VSS precedentemente disponibile nel servizio Archivio informazioni di Microsoft Exchange è stata spostata nel servizio Replica di Microsoft Exchange. Questa architettura rimane la stessa in Exchange 2016 ed Exchange 2019. Questo writer, denominato Microsoft Exchange Writer, viene usato dalle applicazioni basate su VSS compatibili con Exchange per eseguire il backup di copie attive e passive del database e per ripristinare le copie del database di cui è stato eseguito il backup. Anche se il writer viene eseguito nel servizio Replica di Microsoft Exchange, è necessario che il servizio Archivio informazioni di Microsoft Exchange sia in esecuzione per l'annuncio del writer. Ciò implica che per eseguire un backup o un ripristino dei database di Exchange occorrono entrambi i servizi.
Ripristino di Exchange Server
Quasi tutte le impostazioni di configurazione per i server Cassette postali e i servizi Accesso client sono archiviate in Active Directory. Come per le versioni precedenti di Exchange, Exchange 2016 ed Exchange 2019 includono un parametro di installazione per il ripristino dei server persi. Questo parametro, /m:RecoverServer, viene usato per ricompilare e ricreare un server perso usando le impostazioni e le informazioni di configurazione archiviate in Active Directory. Tenere comunque presente che esistono diverse impostazioni che non vengono ripristinate, come le modifiche ai file web.config locali e ad altri file di configurazione. Inoltre, le voci di registro personalizzate non vengono ripristinate. Si consiglia di utilizzare un processo di gestione delle modifiche affidabile per tenere traccia e ricreare tali modifiche.
Per i passaggi dettagliati su come eseguire un ripristino del server di un server Exchange perso, vedere Ripristinare un Exchange Server. Per i passaggi dettagliati su come ripristinare un server perso membro di un gruppo di disponibilità del database, vedere Ripristinare un server membro del gruppo di disponibilità del database.
Ripristino dell'archivio unico dei contatti
Quando Microsoft Lync Server 2013 o Skype for Business Server 2015 viene usato in un ambiente Exchange 2016 o Exchange 2019, le informazioni di contatto di Lync/Skype for Business dell'utente vengono archiviate in una cartella contatto speciale nella cassetta postale dell'utente. Questo viene definito archivio unico dei contatti (UCS). Se si ripristina una cassetta postale migrata da UCS, può essere influenzato l'elenco dei contatti di messaggistica istantanea dell'utente di destinazione. Se l'utente è stato migrato dopo l'ultimo backup, il ripristino della cassetta postale può provocare la perdita completa dell'elenco contatti dell'utente. In casi meno gravi, potrebbero essere perse le modifiche apportate all'elenco contatti dopo l'ultimo backup. Per mitigare queste potenziali perdite di dati, assicurarsi che l'utente venga riportato nel server di messaggistica istantanea prima di ripristinare la cassetta postale.
Database di ripristino
Un database di ripristino è un tipo speciale di database delle cassette postali che consente di installare un database delle cassette postali ripristinato e di estrarre i dati dal database ripristinato durante un'operazione di ripristino. È possibile utilizzare il cmdlet New-MailboxRestoreRequest per estrarre i dati da un database di ripristino. Dopo l'estrazione, i dati possono essere esportati in una cartella o uniti in una cassetta postale esistente. I database di ripristino consentono di ripristinare i dati da un backup o dalla copia di un database senza interferire nell'accesso ai dati correnti dell'utente.
L'uso di un database di ripristino per un database delle cassette postali proveniente da qualsiasi versione precedente di Exchange non è supportato. Inoltre, la cassetta postale di destinazione utilizzata per l'unione e l'estrazione dei dati deve trovarsi nella stessa foresta di Active Directory del database installato nel database di ripristino.
Per ulteriori informazioni, vedere Database di ripristino. Per la procedura dettagliata su come creare un database di ripristino, vedere Creare un database di ripristino. Per la procedura dettagliata su come utilizzare un database di ripristino, vedere Recupero dei dati utilizzando un database di ripristino.
Portabilità del database
La portabilità del database è una funzionalità che consente di spostare e montare un database delle cassette postali di Exchange in qualsiasi altro server Cassette postali di Exchange nella stessa organizzazione. Utilizzando la portabilità del database, è possibile migliorare l'affidabilità perché si eliminano dalle procedure di ripristino numerose operazioni manuali facilmente soggette a errore. Inoltre, la portabilità riduce i tempi totali di ripristino a fronte di diversi scenari di errore.
Per la procedura dettagliata relativa all'utilizzo della portabilità del database, vedere Spostamento di un database delle cassette postali utilizzando la portabilità del database.
Portabilità temporanea
Portabilità temporanea è una funzionalità che fornisce una soluzione di continuità aziendale limitata in caso di errori relativi a un database delle cassette postali, a un server o a un intero sito. La portabilità temporanea consente agli utenti di disporre di una cassetta postale temporanea per l'invio e la ricezione di messaggi di posta elettronica durante il ripristino o la riparazione della cassetta postale originale. La cassetta postale temporanea può trovarsi nello stesso server Cassette postali di Exchange o in qualsiasi altro server Cassette postali di Exchange nell'organizzazione. Ciò consente a un server alternativo di ospitare le cassette postali di utenti che si trovavano precedentemente su un server non più disponibile. I client che supportano l'individuazione automatica, ad esempio Microsoft Outlook, vengono automaticamente reindirizzati al nuovo server senza dover aggiornare manualmente il profilo desktop dell'utente. Una volta ripristinati i dati della cassetta postale originale dell'utente, un amministratore può unire la cassetta postale ripristinata e la cassetta postale temporanea dell'utente in una singola cassetta postale aggiornata.
Questo processo di utilizzo della portabilità temporanea è definito ripristino temporaneo. Un ripristino temporaneo presuppone la creazione di un database vuoto su un server Cassette postali per sostituire il database danneggiato. Il database vuoto, definito database temporaneo, consente agli utenti di inviare e ricevere messaggi di posta elettronica durante il ripristino del database danneggiato. Dopo aver ripristinato il database danneggiato, il database temporaneo e il database ripristinato vengono scambiati e i dati del database temporaneo vengono uniti nel database ripristinato.
Per ulteriori informazioni, vedere Portabilità temporanea. Per la procedura dettagliata relativa all'esecuzione di un ripristino temporaneo, vedere Esecuzione di un ripristino del segnale.