Backup dei dati di Exchange Server 2003 e i servizi Copia Shadow del Volume

Riepilogo

La funzionalità del servizio Copia Shadow del Volume in Microsoft Windows Server 2003 può essere utilizzata per creare applicazioni di backup e ripristino di Microsoft Exchange Server 2003. Il servizio di copia Shadow (VSS) di Windows Volume fornisce un'infrastruttura che consente a programmi di gestione di archiviazione di terze parti, programmi aziendali e i provider hardware a cooperare nella creazione e gestione di copie shadow. Soluzioni basate su questa infrastruttura è possono utilizzare le copie shadow o copie speculari per backup e ripristino di uno o più database di Exchange Server 2003.

Il servizio Copia Shadow del Volume coordina la comunicazione tra i richiedenti (applicazioni di backup), gli autori (applicazioni in servizi di Windows come Exchange Server 2003 e SQL Server 2000) e provider (sistema, software o i componenti hardware che crea le copie shadow). Per utilizzare la funzionalità del servizio Copia Shadow del Volume per backup Exchange Server 2003, il programma di backup deve includere un richiedente del servizio Copia Shadow del Volume in grado di riconoscere Exchange Server 2003. Poiché il programma di backup che viene fornito con Windows Server non dispone di alcun tale richiedente, le organizzazioni devono utilizzare le applicazioni di backup di terze parti.

Per essere compatibile con Exchange Server 2003, le applicazioni di backup VSS basati su devono seguire tre requisiti di base per garantire l'integrità e la recuperabilità dei backup della copia shadow. Se questi requisiti non sono seguiti, Microsoft Product Support Services (PSS) prenderà in considerazione la soluzione di backup sia all'esterno del framework VSS di Exchange e non sarà in grado di risolvere i problemi di backup e ripristinare i problemi. Clienti devono verificare con i fornitori di backup che l'applicazione di backup soddisfa i requisiti compatibili con Exchange elencati in questo articolo della Knowledge Base. Nella sezione "Informazioni" di questo articolo vengono presentati i dettagli dei requisiti di Exchange VSS.

Come con qualsiasi soluzione di terze parti, il fornitore dell'applicazione di backup è il supporto tecnico per problemi di backup e ripristino. PSS può aiutare a diagnosticare o analizzare i problemi con i database disponibili e insiemi di file log transazione. Tuttavia, Microsoft non risolvere i problemi o debug prodotti di terze parti. Assistenza PSS è limitato a consigli su come meglio continuare a ripristinare il database disponibili e i file di registro delle transazioni.

Per ulteriori informazioni su come soluzioni VSS basata sono supportate dal servizio supporto tecnico clienti, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

841696 panoramica dei criteri di supporto Microsoft storage di terze parti software solutions

Ulteriori informazioni

Nell'elenco seguente vengono descritti il backup di Exchange Server 2003 con processo del servizio Copia Shadow del Volume:

  1. Il programma di backup (o agente) viene eseguito un processo pianificato.
  2. Il servizio Copia Shadow del Volume del richiedente nel programma di backup invia un comando al servizio Copia Shadow del Volume per richiedere una copia shadow dei gruppi di archiviazione di Exchange Server 2003 selezionati.
  3. Servizio Copia Shadow del volume comunica con Exchange Server 2003 Writer per preparare un backup snapshot.
  4. Servizio Copia Shadow del volume comunica con il provider di archiviazione appropriato per creare una copia shadow del volume di archiviazione o dei volumi di archiviazione che contengono il gruppo di archiviazione di Exchange Server 2003 o di gruppi di archiviazione.
  5. Servizio Copia Shadow del volume rilascia Exchange Server 2003 per riprendere il normale funzionamento.
  6. Il servizio Copia Shadow del Volume richiedente verifica l'integrità del backup impostata prima di informare Exchange che il backup è stata eseguita correttamente.
Ad esempio, quando viene ricevuta una richiesta di copia shadow da un programma di backup di Exchange Server 2003 che dispone del servizio Copia Shadow del Volume del supporto (un richiedente), Copia Shadow del Volume servizio comunica con Exchange Server 2003 Writer per prepararsi a questo punto dello snapshot, Exchange Server 2003 impedisce azioni amministrative contro il gruppo di archiviazione, verifica le dipendenze di volume e sospende tutte operazioni di scrittura al database e file registro delle transazioni pur consentendo l'accesso in sola lettura. Servizio Copia Shadow del volume comunica quindi con il provider di archiviazione appropriato per avviare il processo di copia shadow per i volumi dei dischi che contengono i dati di Exchange Server 2003. La copia shadow in genere richiede alcuni secondi che saranno praticamente impercettibile per l'utente finale. Quando la copia shadow è tenuta, servizio Copia Shadow del Volume comunica con il Writer di Exchange Server 2003 che Exchange possibile riprendere il normale funzionamento. Programma di backup verifica lo stato della copia shadow prima di informare Exchange che il backup è stata eseguita correttamente. Alla fine di una corretta Exchange backup tronca i registri e registra l'ora dell'ultimo backup per il database o i database.

Per ulteriori informazioni sull'utilità di backup di Exchange Server 2003 con i servizi Copia Shadow del Volume, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

842066 supporto TechNet WebCast: copia Shadow del Volume per Exchange Server 2003

Nell'elenco seguente vengono descritti i requisiti di Exchange Server 2003 che tutte le applicazioni di backup copia shadow devono seguire per garantire l'integrità e la recuperabilità dei database di Exchange:

Il seguente elenco fornisce i registri eventi di applicazioni specifici che consentono di identificare se sono stati seguiti i requisiti di Exchange. Le applicazioni di backup e il server Exchange eventi altri associati al processo di backup e ripristino. Per confermare che i seguenti eventi vengono registrati durante il backup e ripristino verrà utilizzata come la verifica della conformità ai requisiti di Exchange VSS. Attualmente, non vi è alcun programma di certificazione per qualsiasi soluzione software di terze parti in esecuzione su Exchange. Conformità garantisce l'integrità e la recuperabilità dei backup della copia shadow, ma non fornisce alcuna garanzia sulle prestazioni o l'affidabilità della soluzione di terze parti.
  1. Log delle transazioni di database di Exchange, e necessario backup file di checkpoint esclusivamente attraverso il Writer di Exchange:

    La seguente applicazione vengono registrati eventi se il Writer di Exchange viene avviato durante quelli di copia shadow in "Backup digitare" è il tipo di backup eseguito (completo, copia, incrementale o differenziale).
  2. L'applicazione di backup deve convalidare l'integrità del set di backup copia shadow.

    Microsoft consiglia, ma non richiede, che siano effettuati prima che l'applicazione di backup notifica Exchange ha completato il backup. Il motivo di questa raccomandazione è che Exchange esegue due importanti operazioni dopo aver completato il backup:
    • Exchange Aggiorna le intestazioni dei database di backup in modo da riflettere il successo ora dell'ultimo backup
    • Exchange consente di rimuovere dal server che non sono più necessari per eseguire il rollforward dall'ultimo backup corretto dei registri delle transazioni ("Elimina").
    Se un'applicazione di backup pospone verifica integrità finché dopo queste operazioni completate, quindi speciale necessario prestare attenzione per mantenere l'ultimo backup verificato con copie di tutti i file di registro dell'applicazione di tale backup. Sebbene il backup potrebbe già dichiarato come risolutivo a Exchange, il backup deve essere utilizzato su fino a quando l'applicazione di backup è stata effettivamente completata verifica dell'integrità.

    Fare riferimento a "Come eseguire la verifica di integrità per backup VSS" sezione di questo articolo per informazioni dettagliate su come eseguire i controlli di integrità e come determinare quale database e file di registro delle transazioni deve essere mantenuti fino a quando non ha terminato la verifica di integrità.
  3. Le operazioni di ripristino originale posizione * * deve essere eseguite esclusivamente con il Writer di Exchange

    Writer di Exchange registra eventi nei registri eventi dell'applicazione in seguito durante un processo di ripristino di copia shadow.
* * "Posizione originale" si intende un computer Exchange con lo stesso nome di server e lo stesso percorso di file del computer di Exchange in cui è stato eseguito il backup VSS.

Le operazioni di ripristino percorsi alternativi non possono essere realizzati tramite il Writer di Exchange in Exchange Server 2003 SP1. Le applicazioni di backup VSS basati su è possono scegliere di fornire manuale o altri metodi di programmazione per ripristinare le copie shadow dei database di Exchange in una posizione alternativa.

Come eseguire la verifica dell'integrità dei backup VSS

Quando un database viene eseguito il backup utilizzando l'API di backup di flusso di Exchange, ogni pagina del database è di lettura, a sua volta, e l'integrità del checksum di ogni pagina viene verificato durante il processo di backup. L'integrità del checksum del file registro delle transazioni viene anche controllato prima vengono sottoposti a backup.

Durante un backup VSS, non ha alcuna possibilità di Exchange per la lettura di ogni file di database nel suo complesso e per verificare l'integrità del checksum. Pertanto, integrità dei file registro transazioni e di database deve essere verificata dall'applicazione di backup. Questa operazione può essere eseguita mediante l'esecuzione di Eseutil come descritto alla fine di questo documento.

Se si non checksum-verificare i backup VSS, è possibile che una pagina danneggiata potrebbe rimanere non rilevata nel database e alla fine diventano presente in tutti i backup esistenti. L'unico modo per recuperare questa circostanza consiste nel ripristinare il database. Ripristino database richiederà tempi di inattività completa e ciò comporta almeno alcune perdite di dati (almeno la perdita dei dati contenuti nelle pagine danneggiate).

Tuttavia, se l'ultimo backup VSS è stata verificata per contenere tutte le pagine di buone, è possibile eliminare pagine danneggiate dal database ripristinando la copia di backup valida e l'aggiornamento in sequenza con registri delle transazioni creati dopo il backup. I tempi di inattività richiesto per eseguire questa operazione in genere sarà molto più breve per la riparazione del database, e questo metodo di ripristino è possibile correggere i problemi di database con alcuna perdita di dati.

Pertanto, è consigliabile non una copia di backup VSS la validità finché tutti i file in essa sono state verificate checksum.

È necessario seguire le due regole sottostanti per la verifica integrità backup:
  • I file di database: È necessario mantenere sempre una copia di verifica di integrità dei file di database disponibili. Un backup integrità verificata è uno della pagina ha completato verifica del checksum nel file del database nel set di backup.
Un database di backup recente che non ha superato la verifica di checksum non può essere considerato un backup valido. Deve scartare un backup precedente verificato non senza aver prima verificato l'integrità del backup corrente.
  • Per i file di registro delle transazioni: log delle transazioni di tutti i file necessari per il ripristino del backup del database di verifica di integrità più recente deve anche essere sottoposti a backup e verificate anche loro integrità a livello di checksum.
Questi registri delle transazioni includono, come minimo, l'intervallo inclusivo di file di registro elencati nel campo Log richiesto nell'intestazione di ogni database dell'ultimo backup verificati. Se questi file di registro non sono disponibili, il database non saranno installabile dopo il ripristino.

Importante Questo requisito si applica fino all'ultimo backup integrità verificata, non per il backup più recente eseguito. Fino a quando il backup più recente ha superato la verifica di checksum, non viene considerato un backup valido.

Eventualmente può anche conservare i registri aggiuntivi necessari per completamente rollforward del database dopo il ripristino di un backup del database. Questi sono tutti i registri delle transazioni nella sequenza continua di partire con il file di registro necessario inferiore fino del log delle transazioni creato più di recente che è stato eliminato dal server di Exchange. Esempi dettagliati e le spiegazioni di significato descritte di seguito.

Conservando i registri delle transazioni oltre quelli elencati nel Registro di intervalli richiesti sono facoltativo, nel senso che non è strettamente necessario per effettuare correttamente ripristinare e installare una copia di backup dei database. Tuttavia, se non si mantengono tutti questi registri, quindi il ripristino da backup causerà la perdita di tutte le modifiche nel database di oltre il punto di backup. Si consiglia di mantenere non solo i registri delle transazioni necessari per ripristinare e installare una copia di backup dei database, ma anche tutte le successive dei registri delle transazioni necessari per il ripristino del database senza perdita di dati.

Per determinare quali file di registro delle transazioni sono necessari

Se un database di Exchange viene eseguito il backup in linea, file di log almeno una transazione sarà sempre sottoposti a backup con esso. Non utilizzare se il backup di flusso API o l'API di backup VSS.

Dopo il ripristino di un informazioni di backup, in linea dalla transazione registri devono essere applicati al database ("ripetuto") prima che il database sarà montabile nuovamente. Il campo Log necessario di ogni intestazione di database registra i numeri di sequenza (generazione) dell'intervallo di file di registro delle transazioni che devono essere riprodotti nel database.

Se il campo Log richiesto legge 0-0, significa che il database è montabile senza dover eseguire nuovamente i dati di registro transazioni aggiuntivi. Solo il valore di registro necessario sarà 0-0 è dopo aver importato un database in uno stato di chiusura. Durante l'esecuzione di un database, il campo Log richiesto registra sempre nell'intervallo dei registri delle transazioni che non sono ancora stati applicati al database. Questo intervallo viene aggiornato continuamente.

Un database di backup in linea avrà sempre un intervallo di registro necessario da zero e questi registri eseguire il backup e il database. Se, dopo il ripristino, questi registri non sono disponibili, il database non saranno installabile. (È possibile ripristinare il database se non è possibile trovare i file di registro necessari, ma non è garantito che ripristino sarà corretta e riparazione causerà quasi sempre un certo livello di perdita di dati, anche se solo i dati di mancanti vengono registrati).

Se si utilizza l'API di backup o l'API di backup VSS contenuti in di Exchange VSS writer di flusso di Exchange, quindi il file di registro necessari per installare un database saranno sottoposti a backup automaticamente con il database. Se si riprodurre solo i file di registro necessario, verrà creato nel database da ripristinare e il punto nel tempo in cui il backup completato. Se si desidera riportare passato Avanti database che fanno riferimento, è inoltre necessario riprodurre i file di registro generati dopo che è stato eseguito il backup.

Per completamente rollforward del database da qualsiasi particolare backup, è necessario conservare tutti i file di registro nella sequenza continua a partire dal Registro minimo dell'intervallo di registro necessario in file di log generato più di recente nel gruppo di archiviazione del database. Se tutti i log in questa serie è mancante o danneggiato, solo sarà possibile eseguire il rollforward fino al momento dell'ultimo log buona prima il file manca o danneggiato.

Pertanto, se si desidera ripristinare dal backup senza alcuna perdita di dati, è essenziale mantenere buone copie di tutti i file di log di transazione in futuro successivi all'ultimo backup di database appropriata verificati.

Eliminazione di log transazione

Se i registri delle transazioni non vengono rimossi da un server di Exchange, essi continueranno a essere aggiunti fino a coprire tutto lo spazio disponibile su disco. Pertanto, il flusso e backup VSS API supporta "pruning" dei file log transazione dopo il completamento di un backup normale o incrementale. File di registro precedenti rispetto a quelli necessari per ripristinare il backup più recente vengono automaticamente eliminati dal server dopo che il backup di Exchange i segnali di applicazioni di backup è stata completata.

Con l'API di flusso, viene eseguita la verifica del checksum del database durante il processo di backup. Una volta completato, sono stati verificati l'integrità fisica dell'intero database e i file necessari. Con l'API VSS, verifica del checksum non può essere eseguita come parte del processo di backup effettivo. Il fornitore deve verificare l'integrità fisica del database indipendentemente il processo di backup. Ciò è possibile con Eseutil prima o dopo la segnalazione di Exchange che il backup è stato completato.

Se la verifica di checksum viene eseguita prima di completamento del backup, e viene rilevato un problema nel set di backup, quindi Exchange può essere informati che il backup non è riuscito. Questa operazione impedirà Exchange dall'eliminazione dei file di log dal server.

Se la verifica di checksum viene posticipata fino al completamento del backup di segnalazione, Exchange eliminerà vecchi file di log dal server. Alcuni di questi file di registro potrebbe richiesti per il rollforward da un precedente backup valido. Se non sono già state copie di questi registri, quindi non sarà per eseguire il rollforward completamente.

Pertanto Microsoft consiglia, ma non è necessario, eseguire la verifica checksum su una copia di backup VSS prima che l'applicazione di backup segnala completamento del backup di Exchange. Se la verifica di checksum viene rinviata dopo il backup è già stato completato, l'applicazione di backup deve assicurarsi quindi che vengono effettuate copie di tutti i file registro delle transazioni che sono stati eliminati dal server, a meno che non sia il roll forward completamente non è importante.

Nella maggior parte dei casi, tutti i registri necessari per eseguire il rollforward backup VSS saranno disponibili nel set di file di registro salvato con il backup precedente con quelli salvati con il backup corrente. Tuttavia, i clienti è opportuno verificare che questo è il caso quando si considera un particolare fornitore.

Il ripristino dei backup non verificati

Può accadere che in una situazione di emergenza che richiedono il ripristino si verifica prima che abbia completato la verifica checksum su un backup recente. In questi casi, si consiglia di ripristinare un backup precedente verificato e riporta tale backup in avanti, piuttosto che fare affidamento su una copia di backup non verificata.

Tuttavia, potrebbe essere contratti che richiedono il ripristino dei dati più rapidamente è possibile eseguire il backup precedente. In questi casi, il ripristino del backup non verificato può essere un'opzione migliore, purché si mantenere comunque un precedente backup e verificati tutti i file di registro necessari per eseguire il rollforward completamente da esso. Se soddisfi questi requisiti, sarà ancora in grado eseguire il rollforward da un backup noto valido nel caso in cui l'ultimo backup si riveli non valido.

Come verificare la coerenza dello snapshot

Richiedente VSS è necessario verificare la coerenza dello snapshot eseguendo Eseutil.exe i file di database e di log utilizzando le opzioni appropriate, come nella tabella seguente. Richiedente VSS è necessario verificare che tutte le ERRORLEVELs che vengono restituiti l'uscita sono non negativi. Per visualizzare il valore di ERRORLEVEL nella riga di comando, digitare echo % errorlevel % Eseutil.exe termine dell'esecuzione. Un ERRORLEVEL negativo significa che i file è danneggiato. Prima richiedente VSS chiama BackupComplete, richiedente VSS è necessario assicurarsi che lo stato del componente backup nel documento dei componenti di Backup riflette il risultato della verifica di coerenza. Ovvero, lo stato del componente backup deve essere FALSE se viene rilevato un errore e deve essere TRUE se non viene trovato alcun danno. La verifica di coerenza dello snapshot è un requisito obbligatorio per la soluzione devono essere supportati da team di Exchange.

Nella tabella seguente viene mostrata la combinazione di controlli di integrità per ogni tipo di backup.
Tipo di file \ tipo di BackupBackup completoCopia di BackupBackup incrementaleBackup differenziale
.edb"eseutil /k /i""eseutil /k /i"NANA
.log"eseutil /k" *"eseutil /k" *"eseutil /k" * *"eseutil /k" * *
.stmNANANANA
.chkNANANANA

La natura snap dei backup VSS, JET non riceverà la possibilità di toccare tutte le pagine per eseguire verifiche di coerenza necessarie. Pertanto, è responsabilità del richiedente VSS per garantire la coerenza dello snapshot.

* Tutti i file di registro con numero di generazione del file di registro uguale o maggiore di file di log del checkpoint sono necessari per ripristinare un database snapshot. Se l'oggetto corrente è presente il file di registro (Enn. log) è richiesto anche per il ripristino del database. Se uno qualsiasi dei file di registro obbligatorio di coerenza, richiedente deve garantire che lo stato del componente di backup è impostato su FALSE prima della chiamata BackupComplete. Per determinare il file di log del checkpoint, eseguire eseutil.exe per il file di checkpoint snapshot e analizzare l'output "Checkpoint:" ad esempio, "/mk c:\eseutil.exe E01.chk" Mostra quanto segue:
Checkpoint:  (0x20,9D,187) 
0x20 dove è il numero di log di generazione del file di log del checkpoint.

In questo esempio, tutti i log file, tra cui E0100020.log e sopra, deve essere non danneggiato per il ripristino dello snapshot del database, anche se il database stesso fosse già passato il controllo della consistenza fisica.

* * Tutti i file di registro in un incrementale o differenziale set di backup sono necessari per il ripristino del database. La coerenza di una sequenza intera di registro può essere controllata mediante l'esecuzione di eseutil con il prefisso del file registro. Ad esempio, "eseutil /k E01" eseguirà verifiche di coerenza per tutti i file del modulo E01xxxxx.log su un determinato percorso.
Proprietà

ID articolo: 822896 - Ultima revisione: 30 gen 2017 - Revisione: 1

Feedback