V režimu offline zálohování a obnovení postupů pro výměnu

Souhrn

Tento článek popisuje metody, které můžete obejít online záložní aplikace programovací rozhraní (API) a ruční zálohování a obnovení databáze úložiště informací serveru Exchange. Pokud máte více skupin úložišť na jednom serveru Exchange, každou skupinu úložiště musí být považovány za je nezávislá, samostatná jednotka pro účely zálohování offline a obnovení. Další informace o zálohování offline a snímek, klepněte na následující číslo článku 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álohování, ujistěte se, zda 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 objektu storage_group v nástroji Exchange System Manager a potom zobrazit stránku Obecné . Chcete-li zakázat cyklické protokolování, klepněte na tlačítko zrušte zaškrtnutí políčka Cyklické protokolování . Cyklické protokolování změny neprojeví, dokud neukončíte každou databázi ve skupině úložišť.


    Není nutné zakázat cyklické protokolování provádět zálohování offline. Nicméně je nutné zakázat cyklické protokolování, pokud chcete opakované přehrání protokolů transakcí do obnovené zálohy offline.
  • Určete umístění cesty databáze Exchange, streaming, protokolu transakce a soubory kontrolního bodu a předpony souboru protokolu pro skupinu úložiště.


    Tyto informace vyhledáte, otevřete vlastnosti objektu storage_group v nástroji Exchange System Manager a potom zobrazit stránku Obecné . Záznam hodnot pro následující tři pole:
    • Předpona souboru protokolu (E0n, kde může být E0n, E00, E01, E02 a 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 objektu název_databáze . Zaznamenejte hodnoty těchto polí pro každou databázi ve skupině úložišť:
    • Databáze serveru Exchange (edb)
    • Exchange Streaming databáze (STM)
Pokud správce systému Exchange k dispozici, můžete vyhledat všechny předchozí informace načtením přímo surového atributy ze služby Active Directory pomocí nástroje, například nástroj ADSIEDIT nebo nástroje LDIFDE. Lze předat výstupní informace 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: text pro tento příkaz má byla důvodu čitelnosti zalomeny.
LDIFDE -F EXPATHS. TXT -D "CN = CONFIGURATION, DC =configuration_container_domain, DC =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:
D:\Exchsrvr\MDBData > ldifde -f ko -d "cn = konfigurace, dc = test, dc = cz" -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řihlaste se jako aktuální uživatel pomocí SSPI
Export adresáře do souboru con
Vyhledávání položek...

< výstup zkrácen >

.DN: KN první skupina úložiště, CN = InformationStore, CN = Exchange1, CN = Servers, CN = První skupina pro správu, CN = Administrative Groups, CN = organizace, CN = Microsoft Excha nit, CN = Services, CN = Configuration, DC = = Test, DC = com
changeType: Přidat
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: KN úložiště informací veřejnosti (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 = přenos zpráv Tes t, DC = = cz
changeType: Přidat
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB. EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.DN: KN úložiště soukromých informací (Exchange1), CN = První skupina úložiště, CN = Informat ionStore, CN = Exchange1, CN = Servers, CN = První skupina pro správu, CN = Administrative Groups, CN = organizace, CN = Microsoft Exchange, CN = Services, CN = Configuration, DC = Te st, DC = = cz
changeType: Přidat
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV. EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Úspěšně znovu přehrát protokoly transakcí, je nutné obnovit do stejného umístění cesty, z nichž byly soubory zálohovány soubory databáze (edb a STM). Například pokud 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, v uvedeném pořadí. Toto omezení platí i v případě, že chcete obnovit databáze na serveru zcela odlišný (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í protokolů 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í. Pokud obnovíte původní cestu, začne přehrávat znovu přihlásí do chvíle, kdy byla cesta změněna.


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ází, 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í informace o cestě, který je uložen v záhlaví protokolu transakcí. (Online záložní rozhraní API změny cesty databáze kompenzuje interně, a tak toto omezení neplatí.)


Nelze zálohovat nebo obnovit soubor kontrolního bodu (E0n.chk), ale vzhledem k tomu, že budete muset prozkoumat jej nebo odstranit během obnovení je třeba znát aktuální umístění souboru kontrolního bodu.

Jak soubory databáze Exchange vzájemně souvisejí

Soubory edb a STM jsou konečné úložiště 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ů v tandem. Tyto soubory musí zůstat synchronizované chronologicky navzájem; edb soubor, 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.


Server Exchange 2000 nebo Exchange 2003 server může podporovat až čtyř skupin úložišť a každou skupinu ú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ž dvě databáze (úložišť soukromých a veřejných informací).


Při provedení změn do databáze změny jsou zapsány nejprve do aktuálního souboru protokolu transakce a do mezipaměti v paměti. Jakmile jsou změny v mezipaměti, budou tyto změny viditelné pro uživatele. 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 soubor protokolu, které mají byla fyzicky vyprázdnění všech transakcí do souboru databáze. Je běžné zpoždění tři nebo více souborů protokolu za aktuální soubor protokolu kontrolního bodu.


Chcete-li zabránit nejasnostem o tom, které soubory protokolů patří k každou skupinu úložiště Exchange protokoly, které patří do skupiny dané úložiště jsou pojmenovány 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 celém 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) v velikost. Pokud je aktuální soubor protokolu plný, je přejmenován s šestnáctkové pořadové číslo, 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 celém tomto článku očíslované soubory protokolu jsou určeny obecně jako E0nxxxxx. protokolu.


Pokud je databáze abnormálně zastavena, záznamy (E0n.chk) soubor kontrolního bodu transakční protokol, ze kterého musí začít obnovení přehrávání obnovíte databázi konzistence. Tento proces se nazývá "měkký zotavení." Lze rozdíl od aktualizovaného měkké zotavení s "pevný využitím," což je proces protokolu soubory jsou přehrány po obnovení zálohování online. Nejdůležitější rozdíl mezi měkké a pevné obnovení je interpolace oprava souboru dat do procesu přehrání souboru protokolu během zotavení pevný.


Soubor je soubor nekonzistentní databáze serveru Exchange, 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ě dosud 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 celek (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 v režimu Offline

Zálohování databáze serveru Exchange v režimu offline:
  1. Odpojte databázi, kterou chcete zálohovat. Nepotřebujete k odpojení všech databází ve skupině úložišť pouze databáze nebo databází, které chcete zálohovat.
  2. Ověřte, že soubory databáze (soubor Edb i STM) budou konzistentní a odpovídající navzájem. Chcete-li to provést, spusťte následující příkaz u každého souboru:
    eseutil /mh databázový soubor | najít /i "DB podpis"
    Poznámka: Exchange 2000 Service Pack 2 a novější nejsou údaje stav databáze jako "Konzistentní" nebo "Konzistentní", ale jako "Clean vypnutí" nebo "Dirty vypnutí". "Clean vypnutí" význam 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 | najít /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í shodují znak po znaku jako celek považovat za shodu podpisu.)


    Pouze musí odpovídat DB podpisy, ale soubory musí být také konzistentní a vzájemně synchronizovány. U každého souboru, spusťte následující příkaz:
    eseutil /mh databázový soubor | najít /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ích." Odpovídat také šestnáctková čísla v závorkách u každého souboru (0x2CC7, 1F14, 1F7). Poslední konzistentní časové razítko není třeba odpovídat. Tyto soubory jsou konzistentní a odpovídající navzájem.


    Pokud některý soubor sestavy "stát: nekonzistentní" nebo pozice poslední konzistentní protokolu nejsou synchronizovány, databáze nebyla čistě odpojeny. Připojit a pak odpojíte databázi. Pokud soubory stále správně neshodují nebo nejsou konzistentní, obraťte se na Microsoft Product Support Services (PSS) požádejte o pomoc.
  3. Zkopírujte do umístění zálohy jednotlivých souborů databáze edb a jeho odpovídající datových proudů databázový soubor 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 "Přejít vpřed" později, je nutné zálohovat všechny soubory protokolu číslované transakcí (soubory logxxxxxE0n). Nevytvoří zálohu souborů E0n.log, Res1.log a Res2.log.

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


    Zálohování souboru protokolu nemají přímé korespondenci 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 několika jiné zálohy databáze. Můžete vrátit vpřed ze zálohy konkrétní databázi, dokud máte nepřerušený proud protokolů počínaje protokolu, uvedené v "Poslední konzistentní" řádek záhlaví v databázi. V tomto článku poslední konzistentní protokolu se nazývá "protokolu nízké kotvu."


    Pokud odkazujete na předchozím příkladu, je poslední položka konzistentní (0x2CC7, 1F14, 1F7). Tři čísla určit soubor protokolu, stránky v souboru protokolu a hodnotu offsetu do této stránky. Každý soubor obsahuje přibližně 10 000 stránek, 512 bajtů. Odsazení stránky vám dává 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í vždy zobrazí poslední konzistentní protokolu na disku jako číslované protokolu, protože poslední konzistentní protokolu může stále být pojmenován E0n.log. Zobrazí pořadové číslo E0n.log dostane nakonec porovnáním hlavičky souboru protokolu při zastavené databáze (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] | najít /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é zajistit, že jsou dobré, než je zajistit, ž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í, tento krok přeskočte. Zkontrolujte záhlaví souboru kontrolního bodu určit nejvyšší souboru číslované protokolu, který lze bezpečně odebrat. Kontrolní bod sleduje nejnižší číslovaného souboru protokolu, který je nezbytný pro automatické obnovení, pokud je 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)

    Třetí řádek řádku Checkpoint obsahuje relevantní informace (LastFullBackupCheckpoint, položka používá zálohování online a pokud zálohování online nikdy nebude prováděno v databázi zůstane všechny nuly). 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 automaticky odstraněny proces zálohování online. Pokud cyklické protokolování je povoleno, ne zvláštní Správa starých souborů protokolu je to požadováno, protože databázové služby automaticky odstraní staré soubory protokolu po jimi procházejí kontrolní bod.


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

    Důležité: neodstraňujte 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 můžete ověřit integritu úrovni stránky zkopírované databáze.

    Esefile.exe soubor je k dispozici ve složce Support na disku CD-ROM Exchange Server 5.5 Service Pack 3, instalační disk CD-ROM serveru Exchange 2000 Server nebo Exchange Server 2003 instalační disk CD-ROM. Esefile.exe soubor také můžete získat od společnosti Microsoft PSS. Nástroj Esefile lze použít u souborů EDB Exchange Server 5.0 a 5.5, Exchange 2000 a Exchange 2003.


    Momentálně neexistuje žádná metoda než zálohování online ověřit kontrolní 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 souboru STM způsobuje, že některé konkrétní klient ztrátu dat, ale dosud nebylo ohroženo strukturální nebo logickou integritu databáze jako celek.


    Chcete-li ověřit kontrolní součty stránka pro databáze serveru Exchange, spusťte následující příkaz nástroje Esefile:
    /s esefile 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 s žá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 podmínky, je nejlepší možnost obnovení předchozí zálohy, víte, být dobrý a posunout vpřed databáze. Tyto zálohy není k dispozici, naleznete odborné poradenství o tom, jak opravit nebo zachránit 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žku spuštění protokolu, ale pokud Eseutil se pokusí přečíst hlavičku E0n.log během 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 během 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 přehrány do databáze. Všechna data, které jsou vytvořeny po zálohování budou ztraceny.
  • "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, můžete 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" zálohování offline; "Přejít vpřed" obnovení nelze vybrat.
Danou sadu souborů, který obnovujete, musí splňovat následující minimální kritéria:
  • Bod v době obnovení zastaveno databází ve skupině úložišť musí být konzistentní a musí být soubor platný kontroly. Odstranění aktuální soubor s kontrolním protokolem nebo všechny existující soubory protokolu.
  • Role dopředného obnovení všechny databází ve skupině úložišť musí být zastavena 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 kontrolního bodu je třeba odstranit.
Pokud sada soubor nesplňuje výše uvedené podmínky, obnovení a reprodukce nemusí nutně selhat, ale pravděpodobně při softwarovém obnovování se zobrazí chybová zpráva-1216 (JET_errAttachedDatabaseMismatch).

Nakládání s chybou-1216

Další softwarové obnovení záruku-1216 na serveru Exchange 2000 a novější příčinu chyba při Exchange rozpozná datové soubory, které mají manipulováno ručně a určuje, že spuštěné obnovení s aktuální sadu dat by mělo za následek ztrátu dříve existující data.

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

Bod v době obnovení Offline zálohu

Chcete-li provést bod v době obnovení offline zálohu:
  1. Pokud je databáze, kterou chcete obnovit právě připojeny, ho odpojit. Pokud jsou odpojeny jiných databází ve skupině úložišť, databází a datových proudů soubory (edb a STM) tyto databáze 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 kontrolního bodu platný je soubor kontrolního bodu, který byl používán při posledním byly spuštěny některou z databází ve skupině úložišť, který má záhlaví, které jsou uvedeny E0n.log jako kontrolní bod. Pokud jakékoli databáze ve skupině úložišť je stále připojená, je soubor platný kontroly soubor kontrolního bodu, který je aktuálně používán 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, pokud jsou zastaveny všechny databáze, spusťte následující příkazy:
    eseutil /mk E0n.chk | NAJÍT /i "checkpoint"
    eseutil /ml E0n.log | NAJÍT /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. Kontrolu lze tedy považovat za platné.

    Pokud kontrolní bod není platný, je pravděpodobně-1216 chybová zpráva (JET_errAttachedDatabaseMismatch) při pokusu připojit libovolné databáze ve skupině úložišť. Tomuto problému může dojít i v případě, že všechny databáze ve skupině úložišť jsou konzistentní.
  2. Zkopírujte zálohované edb a STM soubory do příslušné databáze a datových proudů umístění souborů. (Pro vyhledání těchto umístění, naleznete "Než začnete" části tohoto článku.) 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á. Mohou být opravitelná a je možné na data vyřazení z nich pomocí nástroje Exmerge.
  3. Připojte obnovené databáze. 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í. Umožnit alespoň jednu minutu pro každých 1 000 složek v hierarchii.


    V dřívějších verzích Exchange Server, je obvykle potřebné ke spuštění ISINTEG-oprava příkaz po obnovení offline zálohu databáze úložiště informací, synchronizace s adresářem 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 obnovit na jiný server, skupiny úložišť nebo logické databázový objekt nebo objekt služby Active Directory, databáze byl odstraněn a znovu vytvořen ve službě Active Directory. V těchto případech je zaznamenána následující chybová zpráva v protokolu událostí aplikace.
    Typ události: Chyba
    Událost zdroj: MSExchangeIS Mailbox úložiště
    Kategorie události: Obecné
    Událost ID:1087
    Date:5/4/2001
    Čas: 8:33: 42 PM
    User:N/A
    Computer:EXCHANGE1
    Popis: Úložiště informací byl obnoven z offline zálohu. V aplikaci Microsoft Exchange System Manager, označuje, že databáze "první úložiště Group\Private úložiště informací" může být obnovena, takže lze opravovaná.
    Chcete-li vyřešit tento problém, musí klepnutím zaškrtněte políčko tuto databázi mohou být přepsány obnovení v Exchange System Manager v dialogovém okně Vlastnosti databáze databázového objektu.

Role dopředného 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 bez provedení nové úplné zálohování ihned po dokončení cesty k databázi.
  • Nelze spustit ESEUTIL /p nebo ESEUTIL /d bez provedení nové úplné zálohování ihned poté.
  • Přidání nebo odebrání databáze ve skupině úložišť, aniž by okamžitě úplnou zálohu všech databází ve skupině úložišť.
Chcete-li zahájit proces obnovení:
  1. Pokud je připojen k databázi, kterou chcete obnovit, ho odpojit a potom zkopírujte soubory databáze, 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, 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 před každou databázi ve skupině úložišť aktuální a před každý obnovený databázový soubor, spusťte následující příkaz:
    eseutil /mh database_file_name | najít /i "konzistentní"
    Poznámka: Exchange 2000 Service Pack 2 a novější nejsou údaje stav databáze jako "Konzistentní" nebo "Konzistentní", ale jako "Clean vypnutí" nebo "Dirty vypnutí". "Clean vypnutí" význam 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 | najít /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:
    • Chcete-li ověřit, že databázové soubory jsou konzistentní každý.
    • Chcete-li ověřit, ž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í protokolu soubory, které jsou povinny úspěšně obnovit všechna data bez generování chyby-1216. Nejnižší hodnota poslední konzistentní přes všechny databáze je protokolu nízké ukotvení a je nejvyšší hodnotou poslední konzistentní protokolu vysoké kotevní.
    V předchozím příkladu soubor protokolu nízké ukotvení je E0002ac8.log a vysoké kotevní soubor protokolu je E0002cc7.log.
  3. Ověřte, zda je podpis protokolu, který je zaznamenán v záhlaví databáze podpisu protokolu nízké kotvu. Spusťte následující příkazy:
    eseutil /mh název_databáze | najít /i "Podpis protokolu"
    eseutil /ml low_anchor_log | najít /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 může hlásit několik podpisů. První podpis je vždy souboru vlastního podpisu 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ázi soubory shodovat podpis protokolu v protokolu nízké kotvu.


    Pokud nemůžete najít protokolu nízké kotvu, nelze přehrát protokoly vpřed do této databáze. Pokud nelze najít soubor protokolu nízké kotevní, nelze přehrát žádné soubory protokolu do všech databází. Existují dvě metody, které můžete použít k řešení chybějící protokolu nízké ukotvení:
    • Můžete odebrat všechny soubory protokolu. Vzhledem k tomu, že jsou všechny konzistentní databáze, můžete lze spustit bez přítomnosti všechny soubory protokolů, ale ztratíte všechny šance na obnovení dat, který již není v databázové soubory.
    • Databází s nejnižší poslední konzistentní hodnoty, lze odebrat až po konstrukci řadu nepřerušené protokolu z nízké vysoké kotvy a na zbývající databáze spusťte obnovení. Po vložení odebrány databází zpět do skupiny úložiště, 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í.

    Přestože po provedení zálohy můžete změnit cestu protokolu transakce nebo pracovní cestu, lze provést pouze přehrání souboru protokolu Pokud databázové soubory umístěny na 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 | Najděte /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, protože hlavičky protokolu první v řadě je generována před první databáze je stále připojena k protokolu nebude mít informace o cestě v jeho záhlaví. V tomto případě se musí hledat v dalším protokolu záhlaví chcete-li zobrazit informace o cestě k databázi. Ve výjimečných případech to také pravděpodobně platí pro protokoly vyšší než první z nich, protože databáze byla vytvořena nebo připojené k proudu protokolu poté, co byl vytvořen protokol.
  5. Shromážděte všechny protokoly z co nejdále dopředu v nepřerušené řadě čí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, je třeba obnovit soubory protokolu z více než jeden typ zálohovacího média.


    V předchozím příkladu nízké ukotvení je E0002ac8.log a vysoké kotevní je E0002cc7.log. Při kontrole protokolů k dispozici, může být nejvyšší číslované protokolu, který můžete najít jeden číslo menší než číslo nezbytné (například E0002cc6.log, mí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, že zda E0n.log je skutečně vysoké kotevní protokolu, musí použít příkaz Prozkoumat hodnota lGeneration v záhlaví souboru protokolu:
    eseutil /ml E0n.log | najít /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 přepínač /ml ; Chcete-li zobrazit záhlaví souboru databáze, použijte přepínač /mh . 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 není tomu tak pokud:
    • Soubory protokolu byly zničeny v případě katastrof.


      - nebo -
    • Jsou obnovení všech databází ve skupině úložiště najednou.
    V prvním případě se pravděpodobně vyskytnou chyby,-1216 během obnovy; v druhém případě můžete přehrávat soubory protokolu, i přes vysoké kotevní protokolu také pokračují v lGeneration pořadí.
  6. Zkontrolujte všechny protokoly sdílejí 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 posloupnost souboru protokolu a zjistí problémy podpisu protokolu.


    Všechny podpisy protokolu musí odpovídat mezi všechny soubory protokolu, které jsou kandidáty před zneužitím. Je nutné odebrat všechny protokoly, které nemají odpovídající podpisy před začátkem opětovného přehrání.


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


    V případě neexistence soubor kontrolního bodu, začne Exchange Server znovu přehrát protokoly z nejnižší číslovaného souboru protokolu, který je k dispozici ve složce protokoly transakcí: protokolu nízké kotvu. Pokud soubor E0n.chk existuje, začne Exchange Server replay u kontrolního bodu, který je zaznamenán v tomto souboru. Pokud E0n.chk body protokolu nízké ukotvení v minulosti, 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 transakcí jsou soubory, které spustit z protokolu nízké ukotvení a pokračovat alespoň do protokolu vysoké kotevní s nejvyšší dostupný protokol s názvem E0n.log.
    • Není žádný soubor E0n.chk ve složce systémové cestě.
    Nyní byste měli být schopni úspěšně připojit úložiště skupiny 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 souborech protokolu pravděpodobně skutečně obnovit z důvodu problémů DB podpis a cesta, které se vyskytují během přehrávání. "Obchodování s databází podpis a cesta se neshoduje" části 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 nejméně jednu databázi ve skupině úložišť. To způsobí, že softwarové obnovení spustit proti všechny databáze ve skupině úložišť.


    V dřívějších verzích Exchange Server, je obvykle nutné spustit ISINTEG-oprava příkaz po obnovení offline zálohu databáze úložiště informací, synchronizace s adresářem databáze. Při provádění oprav pro databáze serveru Exchange je nezbytné opravy provádí automaticky systém, pokud je databáze obnovit na jiný server, skupiny úložišť nebo logické databázový objekt nebo objekt služby Active Directory, databáze byl odstraněn a znovu vytvořen ve službě Active Directory. V těchto případech je zaznamenána následující chybová zpráva v protokolu událostí aplikace.
    Typ události: Chyba
    Událost zdroj: MSExchangeIS Mailbox úložiště
    Kategorie události: Obecné
    Událost ID:1087
    Date:5/4/2001
    Čas: 8:33: 42 PM
    User:N/A
    Computer:EXCHANGE1
    Popis: Úložiště informací byl obnoven z offline zálohu. V aplikaci Microsoft Exchange System Manager, označuje, že databáze "první úložiště Group\Private úložiště informací" může být obnovena, takže lze opravovaná.
    Chcete-li tento problém vyřešit, musí klepnutím zaškrtněte políčko tuto databázi mohou být přepsány obnovení v 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í.


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

Databází, například soubory protokolu, mají své vlastní podpisy. Ale Přestože podpisy protokolu není změnit po čase, který je vytvořen soubor E0n000001.log, podpisy databáze změnit kdykoli změnit 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 dřívější podpisu. Předchozí kopie databáze nepřijímá přehrání jakoukoliv transakci, která byla provedena po podpisu v databázi změněn.


Vzhledem k tomu, že jsou podpisy databáze obnovit tímto způsobem, důrazně doporučujeme zálohovat okamžité úplné databáze po defragmentaci v režimu offline nebo opravit databázi. Pokud obnovit kopii databáze později staré podpisem replay úspěšné až do bodu změny podpis, ale ztratíte všechny změny, které v minulosti tohoto bodu.


Pokud se změní cesty databáze uprostřed proudu protokolu efekt je podobný změna podpisů: replay přeruší v bodě změny. (Online záložní rozhraní API poskytuje zařízení během zotavení přemapovat cesty, tedy online záložní rozhraní API můžete znovu přehrát protokoly úplně, i když cesta změnila bylo převzato zálohování.)


Jako DB podpis nebo DB cestu problémy se vyskytují během replay, ty DB podpis nebo DB cesty, problémy jsou hlášeny v protokolu událostí aplikace v události 301 replay pro každý soubor protokolu. Soubory protokolu, které jsou za čárkou problém zdánlivě úspěšně hrát, ale totiž pouze stejné upozornění neshoda není zaznamenána opakovaně. Jako obecné pravidlo zkrácen přehrání do konkrétní databáze od okamžiku, kdy první DB podpis nebo cestu odkazující na databáze dojde k chybě.


Vlastnosti

ID článku: 296788 - Poslední kontrola: 19. 1. 2017 - Revize: 1

Váš názor