Offline zálohování a obnovení postupů pro výměnu

Překlady článku Překlady článku
ID článku: 296788 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Tento článek popisuje metody, které lze obejít online zálohování aplikační programovací rozhraní (API) a ruční zálohování a obnovení databáze úložiště informací serveru Exchange. Máte-li více skupin úložišť na jednom serveru Exchange, každou skupinu úložiště musí být považovány za se nezávislá a samostatná jednotka pro účely zálohování offline a obnovení.Další informace o zálohování offline a snímek klepněte na tlačítko znalostní báze Microsoft Knowledge Base:
296787 XADM: Offline zálohování a obnovení postupy pro Exchange Server 4.0, 5.0 a 5.5

Další informace

Před zahájením

Před provedením offline zálohu, ujistěte se, že máte následující informace:
  • Zjistěte, zda je povoleno cyklické protokolování pro skupinu úložiště. (Cyklické protokolování je zakázáno ve výchozím nastavení Exchange.) Chcete-li zjistit, zda je povoleno cyklické protokolování, otevřete vlastnosti storage_group objekt v nástroji Exchange System Manager a potom zobrazit Obecné stránka. Chcete-li zakázat cyklické protokolování, zrušte zaškrtnutí Cyklické protokolování Zaškrtávací políčko. Cyklické protokolování změny projeví až po ukončení každé databáze ve skupině úložišť.

    Není nutné zakázat cyklické protokolování provádět zálohování offline. Musíte však zakázat cyklické protokolování, chcete-li přehrát protokolů transakcí do obnovené zálohy offline.
  • Určete cestu k umístění databáze Exchange streaming, protokolu transakce a soubory kontrolního bodu a předponu souboru protokolu pro skupinu úložiště.

    Chcete-li vyhledat informace, otevřete vlastnosti storage_group objekt v nástroji Exchange System Manager a potom zobrazit Obecné stránka. Záznam hodnot pro tři následující políčka:
    • Předpona souboru protokolu (E0n, kde může být E0n, E00, E01, E02 nebo E03)
    • Umístění protokolu transakcí (E0n*.log)
    • Cesta k umístění systému (E0n.chk)
    Cesty databáze jsou uvedeny v databázi vlastnosti každého název_databáze objekt. Hodnoty těchto polí pro každou databázi záznam ve skupině úložišť:
    • Databáze serveru Exchange (edb)
    • Databáze Exchange Streaming (STM)
Pokud správce systému Exchange k dispozici, najdete všechny předchozí informace přímo čtení nezpracovaných atributy ze služby Active Directory pomocí nástroje ADSIEDIT nebo LDIFDE. Výstup informací pro všechny servery Exchange v doménové struktuře služby Active Directory můžete použít následující příkaz LDIFDE.

POZNÁMKA:: Čitelnosti byla zalomena text pro tento příkaz.
LDIFDE -F EXPATHS.TXT -D "CN = CONFIGURATION, DC =configuration_container_domainDC =top_level_domain"-L MSEXCHESEPARAMLOGFILEPATH, MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME, MSEXCHESEPARAMCIRCULARLOG, MSEXCHSLVFILE,
MSEXCHEDBFILE -R "(| ()MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Následuje příklad výstupu z předchozího příkazu:
Con D:\Exchsrvr\MDBData>ldifde -f -d "cn = configuration, dc = test, dc = com" -l msexch eseparamlogfilepath, msexcheseparamsystempath, msexcheseparambasename, msexchesepar amcircularlog, msexchslvfile, msexchedbfile - r "(| ()msexcheseparamlogfilepath = *) (ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) (msexchedbfi Le=*)(msexcheseparamcircularlog=*))"
Připojování k "dc1.child.test.com"
Přihlašování jako aktuální uživatel pomocí SSPI
Export adresáře do souboru con
Vyhledávání položek...

<output truncated=""></output>

.DN: CN = první skupina úložiště, CN = InformationStore, CN = Exchange1, CN = servery, CN = první Skupiny pro správu, CN = Administrative Groups, CN = organizace, CN = Microsoft Excha Nge, CN = Services, CN = Configuration, DC = Test, DC = com
changeType: přidání
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: KN úložiště veřejných informací (EXCHANGE1), CN = = první skupina úložiště, CN = Informati onStore, CN = Exchange1, CN = Servers, CN první skupina pro správu, CN = Administrative Groups, CN = organizace, CN = Microsoft Exchange, CN = Services, CN = Configuration, DC = = Tes t, DC = com
changeType: přidání
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.DN: CN = soukromého úložiště informací (Exchange1), CN = první skupina úložiště, CN = Informat ionStore, CN = Exchange1, CN = Servers, CN = první skupina pro správu, CN = Administrative Skupiny, CN organizace, CN = = Microsoft Exchange, CN = Services, CN = Configuration, DC = Te St, DC = com
changeType: přidání
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Chcete-li úspěšně přehrát protokolů transakcí, je třeba obnovit soubory databáze (edb a STM) do stejného umístění cesty, z nichž byly soubory zálohovány. Například je-li zálohovat soubor databáze ze složky E:\Mdbdata a datových proudů databázový soubor ze složky F:\Mdbdata, je třeba obnovit soubory E:\Mdbdata a F:\Mdbdata, resp.. Toto omezení platí i v případě, že chcete obnovit databázi zcela odlišný serveru (například v případě obnovení jedné poštovní schránky).

Pokud změníte cestu databáze po poslední zálohy, pouze částečně opakované přehrání protokoly transakcí a částečné replay můžete dosáhnout pouze v případě, že změníte cestu zpět do původního umístění. Je-li se vrátit k původní cestu, můžete přehrát protokoly až do okamžiku, kdy byla cesta změněna.

Jinou cestu než původní umístění zálohy můžete obnovit soubory protokolu transakcí (E0n*.log). Důvodem je, že protokoly transakcí zaznamenat umístění databáze, které protokoly transakcí, které jsou připojeny k, ale databáze není záznam umístění protokolů transakcí. Během přehrávání protokoly "najít" databází pomocí cesty informace uložené v záhlaví protokolu transakce. (Online záložní rozhraní API na cestu změny databáze kompenzuje interně a tak, aby toto omezení neplatí.)

Nelze zálohovat nebo obnovit soubor kontrolního bodu (E0n.chk), ale protože je nutné ji nebo ji odstranit během obnovení je třeba znát aktuální umístění souboru kontrolního bodu.

Jak soubory databáze serveru Exchange souvisí vzájemně

Soubory edb a STM jsou konečné úložišť pro všechny informace o databázi. Pro většinu účelů považovat tyto dva soubory, jako by se jednalo o jediný soubor; zálohování a obnovení těchto souborů společné. Tyto soubory musí zůstat synchronizovat chronologicky navzájem; soubor edb, který je zálohován v jeden den, nelze najít odpovídající soubor datového proudu, který je zálohován na jiný den.

Exchange 2000 nebo Exchange 2003 server může podporovat až čtyř skupin úložišť a každé skupině úložiště může podporovat až pět databází. Skupina úložišť je sada databází, které sdílejí společnou sadu souborů protokolu transakcí. Microsoft Exchange Server 5.5 může podporovat maximálně jednu skupinu úložiště podporuje až dva databáze (úložišť soukromých a veřejných informací).

Jakmile jsou změny do databáze změny zapsány nejprve aktuální soubor protokolu transakcí a poté v mezipaměti. Jakmile jsou změny v mezipaměti, budou zobrazeny uživatelům tyto změny. Stránky v mezipaměti budou zapsány do souboru databáze v případě, že je vhodné provést. Kontrolní bod označí bod v sekvenci souboru protokolu až do všechny transakce mají byla fyzicky zapsány do souboru databáze. Je běžné, podle zpoždění tři nebo více souborů protokolu za aktuální soubor protokolu kontrolního bodu.

Zabránit nejasnostem, o tom, které soubory protokolu patří do každé skupiny úložiště serveru Exchange protokolů, které patří do skupiny dané úložiště pojmenují s předponou protokolu jedinečné, což je první tři znaky názvu souboru. Předpony protokolu pro čtyři skupiny úložiště, které jsou podporovány na serveru Exchange 2000 nebo Exchange 2003 server jsou E00, E01, E02 a E03. V tomto článku je určen předponou protokolu pro skupinu úložiště jako E0n. Aktuální soubor protokolu pro skupinu úložiště je vždy E0n.log.

Protokoly transakcí jsou jednotné 5 megabajtech (MB) velikost. Pokud aktuální soubor protokolu je plný, je s šestnáctkové číselné řady, nazývá číslo generování protokolu a je generován nový aktuální soubor protokolu. Soubory protokolu jsou číslovány jako E0n00001.log, E0n00002.log a tak dále. V tomto článku očíslované soubory protokolu jsou určeny genericky jako E0nxxxxx. protokolu.

Zastavení databáze je neobvykle kontrolní záznamy souboru (E0n.chk) do protokolu transakce, ze kterého musí začínat obnovení hry obnovení konzistence databáze. Tento proces se nazývá "softwarové obnovení." Softwarové obnovení může být aktualizovaného "pevný zotavení," což je proces protokolu soubory jsou přehrány po obnovení zálohování online. Nejdůležitější rozdíl mezi dočasná a obnovení je interpolace oprava datového souboru do procesu přehrání souboru protokolu během zotavení pevný.

Nekonzistentní databázového souboru serveru Exchange je soubor, aby všechny zbývající transakce nebyly zapsány do dosud. Při běžném provozu jsou nekonzistentní soubory databáze serveru Exchange, protože informace v mezipaměti, které ještě ještě nebyla zapsána fyzicky do souboru. Obecně databázového souboru serveru Exchange lze považovat konzistentní pouze po normální vypnutí služby databáze. Nicméně databáze, jako celku (považovány za součet informace v transakční protokoly a soubory databáze), je vždy konzistentní Pokud jsou soubory protokolu nutné předčasně odstraněn.

Zálohování databáze serveru Exchange Offline

Zálohování databáze serveru Exchange offline:
  1. Odpojte databázi, kterou chcete zálohovat. Není nutné odpojit všechny databází ve skupině úložišť pouze databáze nebo databází, které chcete zálohovat.
  2. Ověřte, zda soubory databáze (soubor Edb i STM) jsou konzistentní a odpovídající navzájem. Chcete-li to provést, spusťte následující příkaz proti každému souboru:
    eseutil /mh databázový soubor | find /i "Podpis DB"
    POZNÁMKA:: Exchange 2000 Service Pack 2 a novějších Neohlašovat stav databáze jako "Konzistentní" nebo "Konzistentní", ale jako "Čistém vypnutí" nebo "Dirty vypnutí. Význam "Čistém vypnutí" je stejné jako "Konzistentní" a "Dirty vypnutí" význam je stejný jako "Konzistentní.". Exchange 2000 Service Pack 2 nebo novější spusťte další příkaz ke zjištění stavu jednotlivých databází:
    eseutil /mh název_databáze | find /i "Vypnutí"
    Následuje příklad výstupu z předchozího příkazu:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    V předchozím příkladu DB podpisy jsou stejné, který prokáže, že soubory edb a STM patří do stejné sady. (Oba řádky podpisu musí odpovídat znak po znaku celek považovat za shodu podpisu.)

    Pouze musí odpovídat DB podpisy, ale soubory musí být také synchronizovat navzájem a konzistentní. U každého souboru, spusťte následující příkaz:
    eseutil /mh databázový soubor | find /i "konzistentní"
    Následuje příklad výstupu, který je výsledkem předchozího příkazu:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    V předchozím příkladu, obě sestavy soubory "stát: konzistentní." Musí odpovídat také šestnáctková čísla v závorkách u každého souboru (0x2CC7, 1F14, 1F7). Poslední konzistentní časové razítko nemusí odpovídat. Tyto soubory jsou konzistentní i odpovídající navzájem.

    Pokud některý soubor sestavy "stát: nekonzistentní" nebo poslední konzistentní umístění protokolu nejsou synchronizovány, databáze odpojen není čistě. Připojit a pak odpojte databázi. Pokud soubory stále správně neshodují nebo nejsou konzistentní, obraťte se na služby technické podpory společnosti Microsoft pro další pomoc.
  3. Zkopírujte do umístění zálohy jednotlivých souborů databáze edb a odpovídajícího souboru datového proudu databáze STM.
  4. Připojení zálohované databáze.
  5. Pokud je povoleno cyklické protokolování, tento krok přeskočte. Pokud je zakázáno cyklické protokolování a chcete "posunout vpřed" později, je nutné zálohovat všechny soubory protokolu transakcí číslovaný (E0nxxxxxlog soubory). Nevytvoří zálohu souborů pro E0n.log, Res1.log a Res2.log.

    Můžete zálohovat očíslované soubory protokolu kdykoli pohodlný, dokonce ihned po vytvoření, protože po soubor protokolu byla přejmenována z E0n.log na E0nxxxxxlog, Exchange nemění tento soubor znovu. Vymazat však zálohování souborů protokolu pouze podle pokynů v kroku 6.

    Zálohování souboru protokolu nemají přímé korespondence, s zálohy databáze. Každý zálohování souborů protokolu je odkaz v řetězci soubory protokolu, které mohou být vhodné proti zálohování několika různých databází. Můžete se vrátit vpřed ze zálohy databáze zejména mít nepřerušený proud protokoly počínaje protokolu, uvedené v "Poslední konzistentní" řádek záhlaví v databázi. V tomto článku poslední konzistentní protokolu je označován jako protokol nízké kotevní"."

    Pokud odkazujete na předchozím příkladu, je poslední položka konzistentní (0x2CC7, 1F14, 1F7). Tři čísla určit soubor protokolu, stránku v souboru protokolu a hodnotu offsetu do stránky. Každý soubor obsahuje přibližně 10 000 stránek 512 bajtů. Odsazení stránky poskytuje dobrou představu o jak blízko je soubor protokolu je plný (soubor protokolu v předchozím příkladu je asi 80 % zaplněná, protože je ekvivalentní desítková 7956 0x1F14), ale není závislé na obnovení. Obnovení vždy začíná na začátku souboru protokolu.

    V tomto příkladu je soubor protokolu nízké kotevní E0n02cc7.log.

    Nemusí být vždy zobrazena poslední konzistentní protokolu na disku jako číslované protokolu, protože poslední konzistentní protokolu může stále být pojmenován E0n.log. Můžete zobrazit pořadí porovnáním v záhlaví souboru protokolu, zatímco databáze je zastavena nakonec dostane číslo E0n.log (přístup byl odepřen záhlaví E0n.log je spuštěna databáze).

    Chcete-li zobrazit číslo generování protokolu vnitřní, spusťte následující příkaz:
    eseutil /ml [soubor protokolu] | find /i "lGeneration"
    Následuje příklad výstupu z předchozího příkazu:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    V mnoha případech je důležitá a ujistěte se, že jsou dobré, než je a ujistěte se, že každé zálohy databáze je dobré zálohování souboru protokolu. Je to proto, že každé zálohy databáze může redundance pro ostatní, ale úplné obnovení ze zálohování databáze je závislá na zachování každého souboru protokolu po této zálohy.
  6. Pokud je povoleno cyklické protokolování, přeskočte tento krok. Zkontrolujte záhlaví souboru kontrolního bodu určit nejvyšší číslovaného souboru protokolu, který lze bezpečně odebrat. Kontrolní bod sleduje nejnižší číslovaného souboru protokolu, který je nezbytné pro automatické obnovení, je-li databáze abnormálně zastavena. Chcete-li zkontrolovat soubor kontrolního bodu, spusťte následující příkaz:
    eseutil /mk E0n.chk
    Následuje příklad výstupu z předchozího příkazu:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    Na třetím řádku, řádku Checkpoint obsahuje příslušné informace (LastFullBackupCheckpoint, položka používá online zálohování a zálohování online nikdy nebude prováděno v databázi zůstává nul). Formát umístění protokolu kontrolního bodu je stejný jako poslední položka konzistentní v záhlaví databáze. V tomto příkladu je kontrolní bod E0002cc7.log.

    Pokud cyklické protokolování je zakázáno, soubory protokolu hromadí, dokud jsou buď ručně odstraněna nebo procesu zálohování online automaticky odstraněny. Je-li cyklické protokolování povoleno, žádné zvláštní řízení starých souborů protokolu je to požadováno, protože databázové služby automaticky odstraní staré soubory protokolu po kontrolu jimi procházejí.

    Po zazálohování všechny soubory protokolu číslované, můžete uvolnit místo na disku odebrání všech souborů protokolu číslované až, ale ne včetně protokolu kontrolního bodu.

    DŮLEŽITÉ: Odebrání protokolu kontrolního bodu.

    V tomto příkladu můžete odebrat všechny protokoly do E0002cc6.log.
  7. Tento krok je volitelný. Nástroj Esefile ověřit integritu úroveň stránky zkopírované databáze.

    Soubor Esefile.exe je k dispozici ve složce Support na CD-ROM Exchange Server 5.5 Service Pack 3, instalační disk CD-ROM serveru Exchange 2000 nebo 2003 Exchange Server instalační disk CD-ROM. Soubor Esefile.exe můžete získat také z oddělení společnosti Microsoft. Soubory edb z Exchange Server 5.0 a 5.5, Exchange 2000 a Exchange 2003 pracuje nástroj Esefile.

    V současné době není žádná metoda než zálohování online ověřit součty pro každou stránku soubor STM. Soubor STM obsahuje nezpracovaná data. Všechny indexy a ukazatelů, které uspořádání dat jsou v souboru Edb. Problém v soubor STM způsobuje některé konkrétního klienta, ztrátu dat, ale nepodporuje nesmí ohrozit strukturální nebo logickou integritu databáze jako celek.

    Chcete-li ověřit součty stránky pro databáze serveru Exchange, spusťte následující příkaz nástroje Esefile:
    esefile /s název_databáze
    Následuje příklad výstupu z předchozího příkazu:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Neinicializované stránky jsou přijatelné, ale v databázi se žádné problémy, jsou 0 chybný kontrolní součet a 0 chybným číslováním stránek.

    Pokud databáze nesplňuje kontrolu integrity nástroj Esefile, je nejlepší možnost obnovení předchozí zálohy, znáte-li být dobrým a k obnovení databáze. Pokud tyto zálohy není k dispozici, naleznete v odborné poradenství o tom, jak opravit nebo zůstatková databáze.
  8. Tento krok je volitelný. Následující příkaz slouží k ověření integrity zálohovaných souborů protokolu:
    eseutil /ml E0n
    Následuje příklad výstupu z předchozího příkazu:
    k:\backups>eseutil /ml E00
    							
    Tento příkaz nutné spustit ze složky, která obsahuje zálohované soubory protokolu. Tento příkaz můžete spustit také proti aktuální složky spuštění protokolu, ale pokud Eseutil se pokusí přečíst hlavičku E0n.log během spuštění všech databází ve skupině úložišť, chybová-1032 (JET_errFileAccessDenied).

    Tento příkaz rozpozná poškození v souborech protokolu a také vás upozorní, pokud chybí soubor protokolu ve středu sekvence nebo existuje neshoda podpisu mezi soubory protokolu.

Obnovení Offline zálohu databáze serveru Exchange

Tato část popisuje dvě metody obnovení offline zálohu:
  • "Bod v čase" obnovení. Žádné soubory protokolu jsou znovu nahrány do databáze. Všechny vytvořené po zálohování dat je ztraceno.
  • "Přejít vpřed" obnovení. Přehrávání souborů protokolu, které byly vytvořeny po zálohování do databáze. Pokud jsou k dispozici všechny soubory protokolu, mohou zachovat všechna data, která byla vytvořena po zálohování. Pokud je povoleno cyklické protokolování, je nutné provést obnovení "bod v čase" offline zálohy; "Přejít vpřed" obnovení nelze vybrat.
Obnovení souboru sadu, musí splňovat následující minimální kritéria:
  • Bod v době obnovení všechny pozastavené databází ve skupině úložišť musí být jednotný a musí být soubor platný kontroly. Odstranit aktuální soubor nebo všechny existující soubory protokolů.
  • Vrácení obnovení vpřed všech databází ve skupině úložišť musí být zastaven a konzistentní a všechny soubory protokolu, které byly vytvořeny po dobu, po kterou bylo převzato zálohování musí existovat (včetně aktuální E0n.log). Soubor kontroly je nutné odstranit.
Pokud soubor nastavení nesplňuje výše uvedené podmínky, obnovení a přehrání není selhat nutně, ale se pravděpodobně zobrazí chybová zpráva-1216 (JET_errAttachedDatabaseMismatch) při softwarovém obnovování.

Obchodování s chybou-1216

Další softwarové obnovení záruky na serveru Exchange 2000 a novější příčinu-1216 chyba Exchange zjistí datové soubory, které bylo pravděpodobně neoprávněně ručně a určuje, že spuštěný obnovení s aktuální sadu dat by vedlo ke ztrátě dříve existující data.

V předchozích verzích serveru Exchange Pokud soubor sady neúplné, ale je platné pro úspěšné replay, spustí softwarové obnovení bez dalšího upozornění správce. Na serveru Exchange 2000 a novější musí správce výslovně přepsat pomocí nástroje Eseutil chyba-1216.

Bod v době obnovení Offline zálohu

Bod provedení v době obnovení offline zálohu:
  1. Pokud databázi, kterou chcete obnovit právě připojeny, ho odpojit. Pokud jsou odpojeny jiných databází ve skupině úložišť, těchto databází databáze a streamování souborů (edb a STM) musí být konzistentní a odpovídající. (Chcete-li ověřit shodu a konzistence, naleznete v kroku 2 v části "Backing Up Exchange databáze Offline" v tomto článku.)

    Pokud jsou odpojeny všechny databází ve skupině úložišť, všechny databáze musí být konzistentní a musí také existovat soubor platný kontroly. Soubor kontroly platný je soubor kontrolního bodu, který byl používán posledním byly spuštěny některou z databází ve skupině úložišť, který má hlavičku obsahující seznam E0n.log jako kontrolní bod. Pokud žádné databáze ve skupině úložišť je stále připojená, platný soubor je soubor právě používá jiný systém. Pokud je spuštěna jakékoli databáze ve skupině úložišť, existuje platný kontrolního bodu.

    Chcete-li ověřit soubor kontrolního bodu, při všech databází jsou zastaveny, spusťte následující příkazy:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Následuje příklad výstupu z předchozích příkazů:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    V předchozím příkladu je kontrolní bod v protokolu s lGeneration z 0x2cc7, což je e00.log. Proto kontrolu mohou být považovány za platné.

    Pokud kontrolní bod není platná, pokud se pokusíte připojit libovolné databázi ve skupině úložišť obdržet chybovou zprávu-1216 (JET_errAttachedDatabaseMismatch). K tomuto problému může dojít i v případě, že jsou všechny ve skupině úložiště databází konzistentní.
  2. Zkopírujte soubory STM a zálohované edb do příslušné databáze a datových proudů umístění souborů. (Chcete-li najít těchto umístění, naleznete v tomto článku v části "Před zahájením".) Ověřte, že obnovené soubory budou konzistentní a odpovídající.

    POZNÁMKA:: Pokud kopie databázových souborů, které chcete obnovit již existují na serveru, zálohujte tyto soubory před obnovením databáze, i v případě, že stávající soubory nejsou spustitelná. Může být opravitelná a je možné data vyřazení z nich pomocí nástroje Exmerge.
  3. Obnovenou databázi připojte. Databáze se připojí na konec souboru E0n.log. Po úspěšném spuštění databáze žádné dříve existující soubory protokolu mohou někdy být znovu nahrány do databáze. Veřejné složky databází, které obsahují tisíce složek v hierarchii může trvat dlouhou dobu spuštění. Povolit alespoň jednu minutu pro každých 1 000 složek v hierarchii.

    V dřívějších verzích Exchange Server obvykle nutné spustit Program ISINTEG-opravy příkaz po obnovení offline zálohu databáze úložiště informací, synchronizace s adresáři databáze úložiště informací. Při provádění oprav pro databáze serveru Exchange je nezbytné opravy provádí automaticky systém, pokud je databáze obnovena na jiný server, skupiny úložišť nebo logické databázový objekt nebo objekt služby Active Directory, databáze odstraněn a znovu vytvoří ve službě Active Directory. V těchto případech se do protokolu událostí aplikace zaznamenána následující chybová zpráva.
    Typ události: Chyba
    Zdroj události: MSExchangeIS Mailbox Store
    Kategorie události: Obecné
    ID události: 1087
    Datum: 5/4/2001
    Čas: 8:33:42 PM
    Uživatel: není k dispozici
    Počítač: EXCHANGE1
    Popis: Úložiště informací byl obnoven z offline zálohu. V aplikaci Microsoft Exchange System Manager, označují, že databáze "první úložiště Group\Private Information Store" je povoleno obnovit, tak, že je oprava zabezpečení.
    Chcete-li tento problém vyřešit, musíte klepnout na výběr Tato databáze může být přepsáno obnovení Zaškrtávací políčko v nástroji Exchange System Manager v dialogovém okně Vlastnosti databáze databázového objektu.

Přejít vpřed obnovení Offline zálohu

Pro nejlepší šance na úspěch dokončení přehrání souborů protokolu do obnovené databáze:
  • Zachovat kopie všech protokolů transakcí, které byly vytvořeny po čase nejstarší úplné zálohy.
  • Neměňte cesty k databázi bez ihned po provedení novou úplnou zálohu.
  • Nelze spustit. ESEUTIL /p nebo ESEUTIL /d přitom novou úplnou zálohu okamžitě později.
  • Nelze přidat nebo odebrat databázi ve skupině úložišť okamžitě bez úplné zálohování všech databází ve skupině úložišť.
Zahájíte proces obnovení:
  1. Je-li připojen k databázi, kterou chcete obnovit, ho odpojit a potom zkopírujte databázové soubory, které chcete obnovit příslušné cesty na serveru. Pokud kopie databázových souborů, které chcete obnovit již existují na serveru, zálohujte tyto kopie před obnovením databáze, a to i v případě, že stávající soubory nejsou spustitelná. Soubory mohou být opravitelná a je možné pomocí nástroje Exmerge data vyřazení z nich.
  2. Odpojení všech databází ve skupině úložišť a proti každou databázi do aktuální skupiny úložišť a každý obnovený databázový soubor, spusťte následující příkaz:
    eseutil /mh database_file_name | find /i "konzistentní"
    POZNÁMKA:: Exchange 2000 Service Pack 2 a novějších Neohlašovat stav databáze jako "Konzistentní" nebo "Konzistentní", ale jako "Čistém vypnutí" nebo "Dirty vypnutí. Význam "Čistém vypnutí" je stejné jako "Konzistentní" a "Dirty vypnutí" význam je stejný jako "Konzistentní.". Exchange 2000 Service Pack 2 nebo novější spusťte další příkaz ke zjištění stavu jednotlivých databází:
    eseutil /mh název_databáze | find /i "Vypnutí"
    Následuje příklad výstupu z předchozího příkazu:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    Tento příkaz má tři funkce:
    • Ověřte, že soubory databáze každý konzistentní.
    • Ověřte, že soubory edb a STM pro každou databázi jsou shodné verze.
    • K identifikaci nízkých a vysokých kotevní soubory protokolu, které jsou první a poslední soubory potřebné k úspěšné obnovení všech dat bez generování chyby-1216. Poslední nejnižší hodnotu konzistentní napříč všech databází je protokol nízké ukotvení a nejvyšší hodnotou poslední konzistentní vysoké kotevní protokolu.
    V předchozím příkladu je soubor protokolu nízké kotevní E0002ac8.log a vysoké kotevní soubor protokolu je E0002cc7.log.
  3. Ověřte podpis protokolu, který je zaznamenán v záhlaví jednotlivých databází podpisu protokolu nízké kotvu. Spusťte následující příkazy:
    eseutil /mh název_databáze | find /i "Podpis protokolu"
    eseutil /ml low_anchor_log | find /i "Podpis"
    Následuje příklad výstupu z předchozího příkazu:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Soubor protokolu se mohou hlásit několik podpisů. První podpis je vždy podpis souboru tohoto protokolu; zbývající jsou databáze, které byly spuštěny v okamžiku, který byl vytvořen soubor protokolu. V předchozím příkladu podpisy protokolu, které jsou zaznamenány v databázové soubory porovnat podpis protokolu v protokolu nízké kotvu.

    Pokud nemůžete najít protokolu nízké kotvu, nelze přehrát protokoly vpřed do databáze. Pokud nemůžete najít soubor protokolu nízké ukotvení, nelze přehrát žádné soubory protokolu do všech databází. Existují dvě metody, které lze řešit chybějící protokolu nízké ukotvení:
    • Můžete odebrat všechny soubory protokolu. Protože jsou všechny konzistentní databáze, spustíte bez přítomnosti všechny soubory protokolů, ale ztratíte-li pravděpodobné, že při obnovení dat, která již není databázové soubory.
    • Databází s nejnižší poslední hodnoty konzistentní, můžete odebrat, dokud vytvářet řadu nepřerušené protokolu z nízké vysoké kotvy a spusťte obnovení na zbývající databází. Po vložení odebrány databází zpět do skupiny úložišť, nelze přehrát další data do nich.
  4. Ověřte, že aktuální umístění cesty databáze jsou stejné, jako byly v době zálohování.

    Ačkoli můžete změnit cestu protokolu transakcí nebo pracovní cesty po provedení zálohy, lze provést pouze přehrání souboru protokolu databáze jsou-li soubory ve stejných místech, které byly zálohovány z. Pokud si nejste jisti z původního umístění, spusťte následující příkaz:
    eseutil /ml "last_consistent" _log | find /i"Název databáze nebo vzorek"
    Následuje příklad výstupu z předchozího příkazu:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    POZNÁMKA:: Pokud je protokol nízké kotevní E0n00001.log, nebude mít informace o cestě v jeho záhlaví, protože hlavičky protokolu první v řadě je generován před první databáze je stále připojena k protokolu. V tomto případě musí vyhledávat v dalším protokolu záhlaví zobrazit informace o cestě k databázi. Ve výjimečných případech také zřejmě platí pro protokoly vyšší než první, databáze byla vytvořena nebo připojené k proudu protokolu poté, co byl vytvořen protokol.
  5. Shromážděte všechny protokoly, co nejvíce dopředu ve nerozdělená sekvence číslo nízké ukotvení a tyto protokoly zkopírovat aktuální cestu protokoly transakcí. Protokoly, které už jsou umístěny na serveru bez zálohy jsou protokoly prvního Nepřepisovat. Chcete-li to provést, budete muset obnovit soubory protokolu z více než jeden typ zálohovacího média.

    V předchozím příkladu je nízká kotva E0002ac8.log a vysoké kotevní je E0002cc7.log. Při kontrole protokolů k dispozici, může být na nejvyšší číslované protokol, který můžete najít jeden číslo menší, než je nezbytné (například E0002cc6.log, namísto 2cc7). Obvykle k tomu dochází, protože E0n.log dosud byla vyplněna a přejmenována na jeho číslo v pořadí. Chcete-li zjistit, zda E0n.log je skutečně vysoké kotevní protokolu, musí použít následující příkaz Prozkoumat lGeneration Hodnota v záhlaví souboru protokolu:
    eseutil /ml E0n.log | find /i "lGeneration"
    Následuje příklad výstupu z předchozího příkazu:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    POZNÁMKA:: Chcete-li zobrazit záhlaví souboru protokolu pomocí nástroje Eseutil, použijte /ml přepínač; Zobrazit záhlaví souboru databáze pomocí /MH přepnete. Pokud jste nezaměnili přepínače, výstup příkazů je nesprávná.

    Obvykle vysoké kotevní protokolu je také nejvyšší protokolu, které jsou k dispozici, ale to neplatí pokud:
    • Soubory protokolu byly zničeny v katastrofy.

      - nebo -
    • Obnovujete všech databází najednou ve skupině úložišť.
    V prvním případě se pravděpodobně dojde k chybě-1216 během obnovy; v druhém případě můžete hrát dopředu, soubory protokolu i přes protokol vysoké kotevní jako pokračují v lGeneration pořadí.
  6. Zkontrolujte všechny protokoly o sdílet stejný podpis protokolu a jsou v nepřerušené řadě. Spusťte následující příkaz:
    eseutil /ml E0n > název_souboru.txt
    Následuje příklad výstupu z předchozího příkazu:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Tento příkaz Eseutil zvládá tři věci: kontroluje každý soubor protokolu škody, hlásí všechny mezery v pořadí souborů protokolu a zjistí problémy podpisu protokolu.

    Všechny podpisy protokolu musí odpovídat mezi všechny soubory protokolu, které jsou kandidáty na přehrání. Je nutné odebrat všechny protokoly, které nemají odpovídající podpisy před zahájením replay.

    V tomto okamžiku po odebrání souborů, které nesplňuje ověřovací zkoušky pouze protokol transakce jsou soubory ve složce protokoly transakcí soubory:
    • Jsou v nepřerušené lGeneration pořadí, počínaje nízké kotevní soubor protokolu a pokračuje až do alespoň souboru protokolu vysoké kotevní a rámec, pokud je to možné.
    • Mají odpovídající podpisy protokolu.
  7. Pokud protokol vysoké kotevní již není název E0n.log, přejmenujte jej.
  8. Odeberte soubor E0n.chk ve složce systémové cestě.

    Při neexistenci soubor kontrolního bodu Exchange Server začne znovu přehrát protokoly z nejnižší číslovaného souboru protokolu, který je k dispozici ve složce protokoly transakcí: protokol nízké kotvu. Pokud soubor E0n.chk existuje, začíná Exchange Server replay u kontrolního bodu, který je zaznamenán v tomto souboru. Pokud E0n.chk body za nízké kotevní protokolu, replay selže zcela obnovený soubor nastavení. V mnoha případech Pokud uděláte s soubor kontrolního bodu, je nutné spustit po obnovení ze zálohy souborů databáze.
  9. Jako konečná kontrola před připojíte skupiny úložišť, ověřte následující skutečnosti:
    • Všechny databázové soubory jsou obsaženy v jejich spuštění cesty.
    • Pouze soubory protokolu ve spuštěné cestu protokolu transakce jsou soubory, které spustit z protokolu nízké ukotvení a pokračovat alespoň vysoké kotevní protokolu s nejvyšší dostupné protokolu s názvem E0n.log.
    • Není žádný soubor E0n.chk ve složce systémové cestě.
    Nyní by měla být moci úspěšně připojit skupiny úložišť a začít znovu přehrát protokoly transakcí s touto sadou souborů. I po dokončení obnovení a spuštění databáze všechna data ve všech souborů protokolu může být skutečně být obnoven z důvodu DB podpis a cesta problémy, které se vyskytují při přehrání. V části "Obchodování s databází podpis a cesta Mismatches" tohoto článku poskytuje další informace o těchto problémech.
  10. Pokud úložiště informací není spuštěná, spusťte ji a potom připojit alespoň jednu databázi ve skupině úložišť. To způsobí, že softwarové obnovení všech databází ve skupině úložišť spustit.

    V dřívějších verzích Exchange Server je obvykle nutné spustit Program ISINTEG-opravy příkaz po obnovení offline zálohu databáze úložiště informací, synchronizace s adresářem v databázi. Při provádění oprav pro databáze serveru Exchange je nezbytné opravy provádí automaticky systém, pokud je databáze obnovena na jiný server, skupiny úložišť nebo logické databázový objekt nebo objekt služby Active Directory, databáze odstraněn a znovu vytvoří ve službě Active Directory. V těchto případech se do protokolu událostí aplikace zaznamenána následující chybová zpráva.
    Typ události: Chyba
    Zdroj události: MSExchangeIS Mailbox Store
    Kategorie události: Obecné
    ID události: 1087
    Datum: 5/4/2001
    Čas: 8:33:42 PM
    Uživatel: není k dispozici
    Počítač: EXCHANGE1
    Popis: Úložiště informací byl obnoven z offline zálohu. V aplikaci Microsoft Exchange System Manager, označují, že databáze "první úložiště Group\Private Information Store" je povoleno obnovit, tak, že je oprava zabezpečení.
    Chcete-li tento problém vyřešit, musíte klepnout na výběr Tato databáze může být přepsáno obnovení Zaškrtávací políčko v nástroji Exchange System Manager v dialogovém okně Vlastnosti databáze databázového objektu.
Zkontrolujte protokol událostí aplikace v prohlížeči událostí systému Windows NT Microsoft žádné chyby nebo odchylky, které mohou nastat při spuštění databáze. Zobrazí se události 301 pro každý soubor protokolu, který je přehrány. Pečlivě sledujte chyby a upozornění během procesu obnovení.

Mismatches se zabývá podpisu databáze a cesta

Databáze, jako soubory protokolu, které mají své vlastní podpisy. Ale přestože podpisy protokolu není změnit po dobu, po kterou je vytvořen soubor E0n000001.log, podpisy databáze změnit kdykoli změněn fyzické topologie databáze, bez změny sledovány prostřednictvím souborů protokolu. Defragmentace v režimu offline nebo opravy databáze pomocí nástroje Eseutil změní podpis DB. Po takovém případě databáze může být připojena ke stejné proudu protokolu jako před, ale databáze nepřijímá přehrání všech transakcí, které byly provedeny během databáze bylo jeho dřívější podpis. Předchozí kopie databáze nepřijímá replay jakékoli transakce, která byla provedena po podpisu v databázi změněn.

Protože jsou podpisy databáze obnovit tímto způsobem, důrazně doporučuje se provést okamžité úplné zálohy po defragmentaci v režimu offline nebo opravě databáze. Pokud obnovíte kopii databáze později staré podpisem, replay úspěšné až do bodu změny podpis, ale ztratíte všechny změny v minulosti tohoto bodu.

Pokud se změní cesty databáze ve středu datový proud protokolu efekt je podobný změna podpisy: replay přeruší v bodě o změně. (Online záložní rozhraní API poskytuje zařízení během zotavení přemapovat cesty, tedy v online záložní rozhraní API můžete přehrát protokoly úplně, i v případě, že cesta změnila bylo převzato zálohování.)

Jako podpis DB nebo DB problémy cesty jsou během došlo k přehrání, ty DB podpis nebo DB cesty problémy, které jsou hlášeny v protokolu událostí aplikace v události 301 replay pro každý soubor protokolu. Soubory protokolu, které se za bod problému, může se hrát úspěšně, ale totiž pouze stejné upozornění neshoda opakovaně není přihlášen. Jako obecné pravidlo je zkrácen přehrání do určité databáze od bodu, kdy první DB podpis nebo cestu odkazující databáze chybě.

Vlastnosti

ID článku: 296788 - Poslední aktualizace: 12. května 2011 - Revize: 6.0
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Klíčová slova: 
kbproductlink kberrmsg kbhowto kbmt KB296788 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:296788

Dejte nám zpětnou vazbu

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com