Informazioni su backup, ripristino e ripristino di emergenza

Si applica a: Exchange Server 2010

Ultima modifica dell'argomento: 2009-12-09

Microsoft Exchange Server 2010 offre una nuova piattaforma unificata per l'elevata disponibilità e la resilienza del sito che consente di distribuire in modo rapido e semplice database delle cassette postali a elevata disponibilità ridondanti. Tuttavia, anche le forme più estreme di ridondanza e tolleranza di errore non sono in grado di proteggere l'utente da ogni possibile errore o problema. È necessario verificare che nell'organizzazione Exchange ci sia la protezione sufficiente ed adeguata per i dati importanti.

Per questo, è importante capire in che modo i dati possono essere protetti e determinare il metodo che meglio soddisfa le esigenze dell'organizzazione. La pianificazione della protezione dei dati è un processo complesso basato su molte decisioni prese durante la fase di pianificazione della distribuzione.

Sommario

Tecnologie di backup supportate

Ripristino del server

Database di ripristino

Portabilità del database

Portabilità temporanea

Protezione dei dati nativi di Exchange

Tecnologie di backup supportate

Microsoft Exchange Server 2007 e Exchange Server 2003 includono due diverse opzioni per il backup e il ripristino dei dati: API di backup del flusso di Extensible Storage Engine (ESE) e il supporto per API di backup Servizio Copia Shadow del volume (VSS). Exchange 2010 non supporta più API di flusso di ESE per il backup e il ripristino dei dati o dei programmi. Invece, Exchange 2010 supporta solo i backup basati su VSS.

Exchange 2010 include un plug-in per Windows Server Backup che consente di creare backup basati su VSS dei dati di Exchange. È possibile utilizzare Windows Server Backup per eseguire il backup e il ripristino dei database di Exchange. Per eseguire il backup e il ripristino di Exchange 2010, è necessario utilizzare un'applicazione compatibile con Exchange che supporti VSS writer per Exchange 2010, ad esempio Windows Server Backup (con il plug-in VSS), Microsoft System Center Data Protection Manager o un'applicazione di terze parti basata su VSS compatibile con Exchange. Tenere presente queste limitazioni quando si utilizza VSS per il backup e il ripristino dei dati di Exchange:

• Il plug-in VSS fornito con Exchange 2010 può essere utilizzato per eseguire il backup dei volumi contenenti copie del database delle cassette postali attive o solo database delle cassette postali autonomi (non replicati). Non può essere utilizzato per eseguire il backup dei volumi contenenti copie del database delle cassette postali passive. Per eseguire il backup delle copie del database cassette postali passive, è necessario Microsoft System Center Data Protection Manager o un'applicazione di terze parti basata su VSS compatibile con Exchange.
• Il backup delle copie del database cassette postali passive viene eseguito utilizzando un VSS writer separato nel servizio di replica di Microsoft Exchange. Il VSS Writer del servizio di replica di Microsoft Exchange non supporta il ripristino. Anche se è possibile eseguire il backup di una copia del database delle cassette postali passiva utilizzando Microsoft System Center Data Protection Manager o un'applicazione di terze parti basata su VSS compatibile con Exchange, non è possibile eseguire un ripristino VSS direttamente su una copia del database delle cassette postali passiva. Tuttavia, è possibile eseguire un ripristino VSS in un percorso alternativo, sospendere la replica sulla copia passiva, quindi copiare il database e i file di registro dal percorso alternativo nel percorso della copia del database passiva nel file system.

Per la procedura dettagliata relativa al backup e al 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.

Inizio pagina

Ripristino del server

Quasi tutte le impostazioni di configurazione per i ruoli del server Cassette postali, Accesso client, Trasporto Hub e Messaggistica unificata vengono archiviate in Active Directory. Come con le versioni precedenti di Exchange, Exchange 2010 include un parametro di configurazione per il ripristino dei server persi. Questo parametro, /m:RecoverServer, viene utilizzato per creare nuovamente un server perso utilizzando le impostazioni e le informazioni di configurazione archiviate in Active Directory.

Per la procedura dettagliata relativa al ripristino di un server perso di Exchange 2010, vedere Ripristino di un server Exchange. Per la procedura dettagliata relativa al ripristino di un server perso membro di un gruppo di disponibilità del database, vedere Ripristino di un server membro di un gruppo di disponibilità del database.

Inizio pagina

Database di ripristino

Un database di ripristino è una funzionalità di Exchange 2010 che sostituisce il gruppo di archiviazione di ripristino (RSG) presente nelle versioni precedenti di Exchange. 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 Restore-Mailbox 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.

Prima di poter utilizzare un database di ripristino, è necessario rispettare alcuni requisiti. Un database di ripristino può essere utilizzato solo per i database delle cassette postali di Exchange 2010. I database delle cassette postali di versioni precedenti di Exchange non sono supportati. 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 relativa alla creazione di un database di ripristino, vedere Creazione di un database di ripristino. Per la procedura dettagliata relativa all'utilizzo di un database di ripristino, vedere Recupero dei dati utilizzando un database di ripristino.

Inizio pagina

Portabilità del database

La portabilità del database è una funzionalità che consente di spostare o installare un database cassette postali di Exchange 2010 su qualsiasi altro server Cassette postali di Exchange 2010 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à del database riduce i tempi totali di ripristino a fronte di diversi scenari di errore.

Per ulteriori informazioni, vedere Portabilità del database. Per la procedura dettagliata relativa all'utilizzo della portabilità del database, vedere Spostamento di un database delle cassette postali utilizzando la portabilità del database.

Inizio pagina

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 sullo stesso server Cassette postali di Exchange 2010 o su qualsiasi altro server Cassette postali di Exchange 2010 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 2010 o Office Outlook 2007, 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.

Inizio pagina

Protezione dei dati nativi di Exchange

Exchange 2010 include diverse nuove funzionalità e modifiche principali che, quando vengono distribuite e configurate correttamente, possono fornire la protezione dei dati nativi. Perciò, non sarà più necessario eseguire operazioni di backup dei dati. L'utilizzo delle funzionalità di elevata disponibilità incorporate in Exchange 2010 per ridurre i tempi di inattività e la perdita dei dati in caso di emergenza può ridurre anche il costo totale di proprietà del sistema di messaggistica. Combinando queste funzionalità con altre funzionalità incorporate, come Sospensione legale, le organizzazioni possono evitare di eseguire i backup temporizzati e possono abbassare notevolmente i costi.

Oltre a determinare se Exchange 2010 consente di non eseguire i backup tradizionali temporizzati, si consiglia di 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. In base ai requisiti dell'organizzazione, è probabile che un ambiente Exchange 2010 puro con almeno tre copie del database delle cassette postali fornirà costi totali di proprietà inferiori rispetto a uno con backup.

I backup vengono di solito utilizzati per gli scenari seguenti ed esistono funzionalità di Exchange 2010 che consentono di soddisfare ogni esigenza in modo efficace.

• Ripristino d'emergenza   Nel caso in cui si verifichi un errore software o hardware, più copie del database in un gruppo di disponibilità del database (DAG) abilitano l'elevata disponibilità con tempi di failover più brevi e nessuna perdita di dati. Ciò elimina i tempi di inattività dell'utente finale 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 datacenter.
• Ripristino di elementi eliminati accidentalmente   Prima, quando un utente eliminava degli elementi che in seguito dovevano essere ripristinati, era necessario individuare il supporto di backup in cui erano archiviati i dati e in qualche modo recuperare gli elementi desiderati e fornirli all'utente. Grazie alla nuova cartella degli elementi ripristinabili in Exchange 2010 e al criterio di blocco che è possibile applicare, è possibile mantenere tutti i dati eliminati e modificati per un determinato periodo di tempo. In questo modo, il ripristino di questi elementi è più semplice e più veloce. Ciò riduce il carico di lavoro degli amministratori e dell'assistenza tecnica di Exchange consentendo agli utenti finali di ripristinare da soli gli elementi eliminati accidentalmente, semplificando il processo e riducendo i costi associati al ripristino di un singolo elemento. Per ulteriori informazioni, vedere Criteri di messaggistica e conformità, Understanding Recoverable Items e Informazioni sui tag di conservazione e sui criteri di conservazione.
• Archiviazione dei dati a lungo termine   Qualche volta, i backup hanno la funzione di archiviare i dati e di solito viene utilizzato il nastro per conservare istantanee temporizzate dei dati per lunghi periodi di tempo, come dettato dai requisiti di conformità. Le nuove funzionalità relative all'archiviazione, alla ricerca in più cassette postali e alla conservazione dei messaggi in Exchange 2010 consentono all'utente finale di conservare i dati in modo semplice per lunghi periodi di tempo. In questo modo non è più necessario eseguire ripristini costosi da nastro. La produttività dell'utente finale viene aumentata consentendo ai rich client, ad esempio Microsoft Outlook e Applicazione Web Outlook di accedere a dati meno recenti. Per ulteriori informazioni, vedere Informazioni sugli archivi personali, Informazioni sulla ricerca su più cassette postali e Informazioni sui tag di conservazione e sui criteri di conservazione.
• Istantanea del database temporizzata   Se per l'organizzazione è necessaria una copia precedente temporizzata dei dati della cassetta postale, Exchange offre la possibilità di creare una copia ritardata in un ambiente DAG. Ciò può essere utile nel caso in cui si verifichi un danneggiamento della partizione logica che si ripete nei database del DAG e quindi sia necessario tornare a uno stato precedente. Potrebbe anche essere utile se un amministratore elimina accidentalmente i dati dell'utente o delle cassette postali. È possibile che il ripristino da una copia ritardata sia più veloce rispetto al ripristino da un backup. Infatti le copie ritardate non richiedono il processo di copia (dispendioso in termini di tempo) dal server di backup al server Exchange. Questo può ridurre in modo significativo il costo totale di proprietà, riducendo i tempi di inattività dell'utente finale.

Troncamento dei file di registro senza backup

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 eseguiti, il troncamento dei file di registro non verrà effettuato. 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 è eseguita e gestita dal Servizio Archivio informazioni di Microsoft Exchange, CRCL è eseguita e gestita dal servizio di replica di Microsoft Exchange. Quando viene abilitata, la registrazione circolare ESE non crea ulteriori file di registro ma sovrascrive il file di registro corrente, se necessario. 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 CRCL, 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, se sono ancora necessari per la replica, i registri non vengono eliminati dall'eliminatore di registri.

Per informazioni su come abilitare e disabilitare la registrazione circolare, vedere Configurazione delle proprietà del database delle cassette postali.

Considerazioni per l'implementazione della protezione dei dati nativi di Exchange

È necessario considerare diversi motivi di natura tecnica e diversi problemi prima di utilizzare le funzionalità incorporate in Exchange 2010 in sostituzione ai backup tradizionali. L'elenco seguente include alcune di queste considerazioni, anche se non è un elenco esaustivo. È possibile che compaiano considerazioni speciali o considerazioni univoche per l'organizzazione. Prendere in considerazione i seguenti problemi:

• Quante copie del database verranno distribuite? Si consiglia di distribuire almeno tre copie di un database delle cassette postali prima di eliminare forme tradizionali di protezione del database, ad esempio backup basati su VSS tradizionali o RAID.
• L'obiettivo temporale di recupero e l'obiettivo per il punto di recupero devono essere definiti ed è necessario 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.
• Se non si utilizza più un DAG o alcuni dei suoi membri, è possibile ottenere un risparmio sufficiente a supportare una soluzione di backup tradizionale? Se così fosse, la soluzione migliora gli accordi sui livelli di servizio (SLA) dell'obiettivo temporale di recupero o dell'obiettivo per il punto di recupero?
• Ci si può permettere di perdere una copia temporizzata se nel membro del DAG che ospita la copia si verifica un errore che influenza la copia o l'integrità della copia?
• Exchange 2010 consente di distribuire cassette postali di dimensioni maggiori. La dimensione massima del database delle cassette postali consigliata è aumentata da 200 gigabyte (GB) in Exchange 2007 a 2 terabyte (quando vengono utilizzate tre o più copie del database delle cassette postali). In base alle cassette postali di dimensioni maggiori che probabilmente la maggior parte delle organizzazioni distribuirà, quale sarà l'obiettivo per il punto di recupero se occorre riprodurre numerosi file di registro quando si attiva una copia del database o una copia del database ritardata?
• In che modo si rileverà ed eviterà che il danneggiamento della parte logica in una copia del database attiva si replicherà nelle copie passive del database? Che cos'è il piano di ripristino per questa situazione? Quanto spesso 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.

Inizio pagina