Procedury wykonywania kopii zapasowej w trybie offline i jej przywracania dotyczące programu Exchange

Tłumaczenia artykułów Tłumaczenia artykułów
Numer ID artykułu: 296788 - Zobacz jakich produktów dotyczą zawarte w tym artykule porady.
Rozwiń wszystko | Zwiń wszystko

Na tej stronie

Streszczenie

W tym artykule opisano metody, które umożliwiają ominięcie interfejsów API kopii zapasowej online i ręczne wykonanie kopii zapasowej baz danych magazynu informacji Exchange oraz ich przywrócenie. Jeśli na pojedynczym serwerze programu Exchange istnieje wiele grup magazynów, każdą z nich należy traktować jako niezależną, samodzielną jednostkę do wykonywania kopii zapasowej danych w trybie offline i ich przywracania.Aby uzyskać dodatkowe informacje dotyczące trybu offline i migawkowych kopii zapasowych, kliknij numer artykułu poniżej w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
296787 XADM: Offline Backup and Restoration Procedures for Exchange Server 4.0, 5.0, and 5.5

Więcej informacji

W tym artykule znajdują się następujące sekcje:

Zanim rozpoczniesz

Przed wykonaniem kopii zapasowej offline należy sprawdzić, czy dostępne są następujące informacje:
  • Ustal, czy odnośnie do grupy magazynu włączono rejestrowanie cykliczne. (Rejestrowanie cykliczne jest domyślnie wyłączone w programie Exchange). Aby ustalić, czy rejestrowanie cykliczne jest włączone, otwórz właściwości obiektu grupa_magazynu w programie Exchange System Manager, a następnie wyświetl stronę General. Aby wyłączyć rejestrowanie cykliczne, kliknij pole wyboru Circular Logging w celu jego wyczyszczenia. Zmiany dotyczące rejestrowania cyklicznego zostaną uwzględnione dopiero po zatrzymaniu wszystkich baz danych w grupie magazynu.

    Aby wykonać kopie zapasowe offline, nie trzeba wyłączać rejestrowania cyklicznego. Należy je natomiast wyłączyć, aby ponownie odtworzyć dzienniki transakcji w bazach danych przywróconych z kopii zapasowych offline.
  • Określ lokalizacje ścieżek bazy danych programu Exchange, plików strumieniowych, dzienników transakcji i plików punktów kontrolnych oraz prefiks pliku dziennika dotyczącego grupy magazynu.

    Aby wprowadzić te informacje, otwórz właściwości obiektu grupa_magazynu w programie Exchange System Manager, a następnie wyświetl stronę General. Zapisz wartości trzech następujących pól:
    • Log File Prefix (E0n, gdzie E0n może mieć wartość E00, E01, E02 lub E03)
    • Transaction Log Location (E0n*.log)
    • System Path Location (E0n.chk)
    Ścieżki baz danych znajdują się we właściwościach bazy danych każdego obiektu nazwa_bazy_danych. Zapisz wartości dwóch następujących pól dotyczących każdej bazy danych w grupie magazynu:
    • Exchange Database (.edb)
    • Exchange Streaming Database (.stm)
Jeśli program Exchange System Manager jest niedostępny, wszystkie te informacje można znaleźć, odczytując bezpośrednio atrybuty pierwotne z usługi Active Directory za pomocą narzędzia takiego jak ADSIEDIT lub LDIFDE. Aby uzyskać informacje o wszystkich serwerach programu Exchange znajdujących się w lesie usługi Active Directory, należy użyć następującego polecenia LDIFDE.

Uwaga: Tekst tego polecenia zawinięto, aby polepszyć jego czytelność.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=domena_kontenera_konfiguracyjnego,DC=domena_najwyższego_poziomu" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Poniżej podano przykładowy wynik działania tego polecenia:
D:\exchsrvr\mdbdata>ldifde -f con -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=*))"
Connecting to "dc1.child.test.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...

<output truncated>

.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
changetype: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Aby pomyślnie ponownie odtworzyć dzienniki transakcji, należy przywrócić pliki baz danych (.edb i .stm) do tych samych lokalizacji ścieżek, z których wykonano kopię zapasową plików. Jeśli na przykład kopię pliku bazy danych wykonano z folderu E:\Mdbdata, a pliku strumieniowej bazy danych z folderu F:\Mdbdata, pliki należy przywrócić odpowiednio do folderów E:\Mdbdata i F:\Mdbdata. Ograniczenie to obowiązuje nawet wtedy, gdy użytkownik chce przywrócić bazę danych na całkowicie inny serwer (na przykład w przypadku odzyskiwania pojedynczej skrzynki pocztowej).

Jeśli po wykonaniu ostatniej kopii zapasowej zmieniono ścieżkę bazy danych, dzienniki transakcji można ponownie odtworzyć tylko częściowo, a częściowe ponowne odtworzenie można uzyskać tylko po zmianie ścieżki z powrotem na oryginalną. Po przywróceniu starej ścieżki można ponownie odtworzyć dzienniki aż do punktu, w którym ścieżka została zmieniona.

Pliki dzienników transakcji (E0n*.log) można przywrócić do ścieżki innej niż oryginalna lokalizacja kopii zapasowej. Jest to możliwe, ponieważ w dziennikach transakcji są rejestrowane lokalizacje baz danych, do których te dzienniki są dołączone, a w bazach danych nie są rejestrowane lokalizacje dzienników transakcji. W trakcie ponownego odtwarzania dzienniki „znajdują” bazy danych przy użyciu informacji o ścieżkach, które są przechowywane w nagłówkach dzienników transakcji. (Interfejs API kopii zapasowej online wewnętrznie kompensuje zmiany ścieżek baz danych i dlatego to ograniczenie nie ma zastosowania).

Nie jest wykonywana ani przywracana kopia zapasowa pliku punktu kontrolnego (E0n.chk), ale należy znać bieżącą lokalizację tego pliku, ponieważ w trakcie operacji odzyskiwania może zajść potrzeba jego zbadania lub usunięcia.

Powrót do listy sekcji

Jakie są relacje między plikami baz danych programu Exchange

Pliki .edb i .stm to końcowe repozytoria dla wszystkich informacji znajdujących się w bazach danych. W większości przypadków należy traktować te dwa pliki jak jeden plik, ponieważ operacje wykonywania ich kopii zapasowych oraz ich przywracania odbywają się razem, jedna po drugiej. Pliki te muszą być zsynchronizowane ze sobą w sposób chronologiczny, tzn. plik .edb, którego kopię zapasową wykonano w danym dniu, nie może być zsynchronizowany z plikiem strumieniowym, którego kopię zapasową wykonano innego dnia.

Serwer programu Exchange 2000 lub Exchange 2003 może obsługiwać maksymalnie cztery grupy magazynu, z których każda może obsługiwać maksymalnie pięć baz danych. Grupa magazynu to zestaw baz danych współużytkujących wspólny zestaw plików dziennika transakcji. Program Microsoft Exchange Server 5.5 może obsługiwać maksymalnie jedną grupę magazynu, która obsługuje maksymalnie dwie bazy danych (magazyny informacji prywatnych i publicznych).

Po wprowadzeniu zmian do bazy danych są one najpierw zapisywane w bieżącym pliku dziennika transakcji, a następnie w pamięci podręcznej. Dopóki informacje o zmianach znajdują się w pamięci podręcznej, są widoczne dla użytkowników. Strony pamięci podręcznej są przerzucane do pliku bazy danych w dogodnym momencie. Punkt kontrolny oznacza punkt w sekwencji pliku dziennika, od którego wszystkie transakcje fizycznie przerzucono do pliku bazy danych. Normalnie punkt kontrolny znajduje się przynajmniej trzy pliki za bieżącym plikiem dziennika.

Aby uniknąć zamieszania z identyfikacją przynależności plików dziennika do grup magazynu, program Exchange rejestruje ich przynależność do danej grupy magazynu za pomocą nazwy o unikatowym prefiksie dziennika, którego pierwsze trzy znaki pochodzą z nazwy pliku. Prawidłowe prefiksy dzienników dla czterech grup magazynów obsługiwanych na serwerze programu Exchange 2000 lub Exchange 2003 to: E00, E01, E02 i E03. W tym artykule jako prefiks dziennika grupy magazynu przyjęto E0n. Nazwą bieżącego pliku dziennika grupy jest zawsze E0n.log.

Dzienniki transakcji mają stały rozmiar 5 megabajtów (MB). Po zapełnieniu pliku bieżącego dziennika następuje zmiana jego nazwy przy użyciu kolejnej liczby szesnastkowej, zwanej numerem generacji dziennika, i utworzony zostaje nowy bieżący plik dziennika. Numerami plików dzienników są E0n00001.log, E0n00002.log itd. W tym artykule przyjęto, że ogólny format numerów plików dziennika ma postać E0nxxxxx.log.

Po nieprawidłowym zatrzymaniu bazy danych w punkcie kontrolnym (E0n.chk) rejestrowany jest dziennik transakcji, od którego należy rozpocząć ponowne odtwarzanie, aby przywrócić spójność bazy danych. Proces ten nosi nazwę „odzyskiwania miękkiego”. Odzyskiwanie miękkie można zestawić z „odzyskiwaniem twardym”, w którym po przywróceniu kopii zapasowej online następuje ponowne odtworzenie plików dzienników. Najważniejsza różnica między odzyskiwaniem miękkim i twardym polega na tym, że w trakcie odzyskiwania twardego wykonywana jest interpolacja danych z pliku poprawki do ponownie odtwarzanego pliku dziennika.

Niespójny plik bazy danych programu Exchange to plik, do którego nie zostały jeszcze zapisane wszystkie zaległe transakcje. W trakcie normalnej pracy niespójność plików baz danych programu Exchange pojawia się, ponieważ w pamięci podręcznej znajdują się informacje, których nie zapisano jeszcze fizycznie do pliku. Ogólnie plik bazy danych programu Exchange można uważać za spójny tylko po prawidłowym zatrzymaniu usługi bazy danych. Tym niemniej baza danych, jako całość (traktowana jako suma informacji znajdujących się zarówno w dziennikach transakcji, jak i plikach baz danych), jest zawsze spójna, chyba że przedwcześnie usunięto niezbędne pliki dzienników.

Powrót do listy sekcji

Wykonywanie kopii zapasowej offline bazy danych programu Exchange

Aby wykonać kopię zapasową offline bazy danych programu Exchange, wykonaj następujące kroki:
  1. Odinstaluj bazę danych, której kopię zapasową chcesz wykonać. Nie trzeba odinstalowywać wszystkich baz danych w danej grupie magazynu, a jedynie te bazy danych, których kopie zapasowe chcesz wykonać.
  2. Sprawdź, czy pliki baz danych (zarówno plik .edb, jak i plik .stm) są spójne i zsynchronizowane ze sobą. W tym celu uruchom następujące polecenie dotyczące obu plików:
    eseutil /mh plik_bazy_danych | find /i "DB Signature"
    Uwaga: W programie Exchange 2000 z dodatkiem Service Pack 2 i nowszych stan bazy danych nie jest raportowany jako „Consistent” lub „Inconsistent”, ale jako „Clean Shutdown” lub „Dirty Shutdown”. Znaczenie stanu „Clean Shutdown” jest takie samo jak stanu „Consistent”, a stanu „Dirty Shutdown” — takie samo jak stanu „Inconsistent”. W programie Exchange 2000 z dodatkiem Service Pack 2 lub nowszym należy uruchomić następujące polecenie dodatkowe, aby ustalić stan każdej z baz danych:
    eseutil /mh nazwa_bazy_danych | find /i "Shutdown"
    Poniżej podano przykładowy wynik działania tego polecenia:
    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:
    							
    W powyższym przykładzie sygnatury baz danych są identyczne, co stanowi dowód na przynależność plików .edb i .stm do tego samego zestawu. (Zgodność sygnatur oznacza, że oba wiersze sygnatur muszą być ze sobą zgodne co do znaku).

    Oprócz wymogu zgodności sygnatur baz danych, pliki muszą być spójne i zsynchronizowane ze sobą. Uruchom następujące polecenie odnośnie do obu plików:
    eseutil /mh plik_bazy_danych | find /i "consistent"
    Poniżej podano przykładowe wyniki działania tego polecenia:
    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
    							
    W powyższym przykładzie informacja o obu plikach ma postać „State: Consistent”. Liczby szesnastkowe w nawiasach dotyczące każdego pliku (0x2CC7,1F14,1F7) muszą być również zgodne. Zgodność sygnatury czasu „Last Consistent” nie jest konieczna. Pliki te są zarówno spójne, jak i ze sobą zgodne.

    Jeśli plik zawiera tekst „State: Inconsistent” lub pozycje dziennika „Last Consistent” są niezsynchronizowane, oznacza to, że baza danych została odinstalowana nieprawidłowo. Należy ją ponownie zainstalować i odinstalować. Jeśli pliki są nadal niezgodne lub niespójne, skontaktuj się z Pomocą techniczną firmy Microsoft, aby uzyskać dalszą pomoc.
  3. Skopiuj każdy plik bazy danych .edb i odpowiadający mu plik strumieniowej bazy danych .stm do lokalizacji kopii zapasowej.
  4. Zainstaluj bazy danych, których kopie zapasowe zostały wykonane.
  5. Jeśli rejestrowanie cykliczne jest włączone, należy pominąć ten krok. W przeciwnym wypadku, aby wykonać operację „roll forward” później, należy wykonać kopię zapasową wszystkich ponumerowanych plików dzienników transakcji (pliki E0nxxxxx.log). Nie należy wykonywać kopii zapasowej plików E0n.log, Res1.log i Res2.log.

    Kopię zapasową ponumerowanych plików dzienników można wykonać w dogodnym czasie, nawet od razu po ich utworzeniu, ponieważ po zmianie nazwy pliku dziennika z E0n.log na E0nxxxxx.log program Exchange nie modyfikuje tej nazwy ponownie. Pliki dzienników, których kopię zapasową wykonano, należy jednak usuwać tylko według instrukcji z kroku 6.

    Kopie zapasowe plików dziennika nie tworzą relacji jeden-do-jednego z kopiami zapasowymi baz danych. Każda kopia pliku dziennika jest łączem w łańcuchu plików dziennika, które można umieścić w dowolnej spośród kilku różnych kopii baz danych. Operację roll forward można wykonywać z konkretnej bazy danych, dopóki istnieje nieprzerwany strumień dzienników rozpoczynający się dziennikiem, którego nazwę podano w wierszu „Last Consistent” nagłówka bazy danych. W tym artykule najdłuższym plikiem dziennika, do którego występuje odwołanie, jest „dziennik zakotwiczony”.

    W przykładzie powyżej ostatnim spójnym dziennikiem jest (0x2CC7,1F14,1F7). Trzy liczby wskazują plik dziennika, stronę w tym pliku dziennika oraz bajt przesunięcia tej strony. W każdym pliku dziennika znajduje się około 10 000 stron, 512 bajtów każda. Offset strony stanowi doskonałą informację o stopniu zapełnienia pliku dziennika (stopień zapełnienia pliku dziennika w przykładzie powyżej wynosi 80 procent, ponieważ wartość szesnastkowa 0x1F14 jest równa wartości dziesiętnej 7956), ale nie ma związku z operacją odzyskiwania, która zawsze rozpoczyna się od pierwszej pozycji w pliku dziennika.

    W tym przykładzie zakotwiczonym plikiem dziennika jest plik E0n02cc7.log.

    Nazwa ostatniego spójnego dziennika na dysku nie zawsze ma postać numerowaną, ponieważ ostatni spójny dziennik może mieć też nazwę w postaci E0n.log. Kolejny numer w nazwie pliku dziennika E0n.log można ewentualnie nadać, badając nagłówek pliku dziennika po zatrzymaniu bazy danych (uzyskanie dostępu do nagłówka pliku dziennika E0n.log podczas działania bazy danych jest niemożliwe).

    Aby wyświetlić wewnętrzny numer generacji dziennika, uruchom następujące polecenie:
    eseutil /ml [plik dziennika] | find /i "lGeneration"
    Poniżej podano przykładowy wynik działania tego polecenia:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    Często ważniejsze jest sprawdzenie, czy kopie zapasowe plików dziennika są prawidłowe, niż to, czy prawidłowe są wszystkie kopie zapasowe baz danych. Dzieje się tak, dlatego że każda kopia zapasowa bazy danych może zawierać dane nadmiarowe, ale pełne odzyskanie danych z dowolnej kopii zapasowej bazy danych wymaga zachowania każdego pliku dziennika po wykonaniu kopii zapasowej.
  6. Jeśli rejestrowanie cykliczne jest włączone, należy pominąć ten krok. Zbadaj nagłówek pliku punktu kontrolnego, aby ustalić nazwę pliku dziennika o jak najwyższym numerze, który można bezpiecznie usunąć. W pliku kontrolnym zapisana jest nazwa pliku dziennika o najniższym numerze, który jest niezbędny do automatycznego odzyskania nieprawidłowo zamkniętej bazy danych. Aby zbadać plik kontrolny, uruchom następujące polecenie:
    eseutil /mk E0n.chk
    Poniżej podano przykładowy wynik działania tego polecenia:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    W wierszu trzecim (Checkpoint) znajdują się stosowne informacje (wiersz LastFullBackupCheckpoint jest używany przez kopię zapasową online i ma wartość zero, jeśli nigdy nie wykonywano kopii zapasowej online bazy danych). Format zapisu pozycji punktu kontrolnego w pliku dziennika jest taki sam, jak ostatniego spójnego wpisu w nagłówku bazy danych. W tym przykładzie punktem kontrolnym jest plik E0002cc7.log.

    Jeśli rejestrowanie cykliczne jest wyłączone, pliki dzienników kumulują się aż do ich ręcznego lub automatycznego usunięcia podczas wykonywania kopii zapasowej online. W przeciwnym wypadku nie jest wymagane żadne specjalne zarządzanie starymi plikami dzienników, ponieważ usługa bazy danych usunie je automatycznie, jeśli punkt kontrolny zostanie przeniesiony za te pliki.

    Po wykonaniu kopii zapasowej wszystkich ponumerowanych plików dzienników można odzyskać miejsce na dysku, usuwając wszystkie ponumerowane pliki dziennika aż do pliku dziennika punktu kontrolnego (ale nie włącznie z nim).

    WAŻNE: Nie należy usuwać dziennika punktu kontrolnego.

    W tym przykładzie można usunąć wszystkie dzienniki aż do E0002cc6.log.
  7. Jest to krok opcjonalny. Za pomocą narzędzia Esefile można sprawdzić integralność skopiowanych baz danych na poziomie strony.

    Program Esefile.exe jest dostępny w folderze Support na dysku CD z dodatkiem Service Pack 3 dla programu Exchange Server 5.5, instalacyjnym dyskiem CD z programem Exchange 2000 Server oraz instalacyjnym dyskiem CD z programem Exchange Server 2003. Program Esefile.exe można również uzyskać z działu Pomocy technicznej firmy Microsoft. Narzędzie Esefile działa z plikami .edb programów Exchange Server 5.0 i 5.5, Exchange 2000 oraz Exchange 2003.

    Obecnie nie istnieje żadna inna metoda sprawdzenia sum kontrolnych każdej strony pliku .stm niż wykonanie kopii zapasowej online. W pliku .stm znajdują się dane niesformatowane. Wszystkie indeksy i wskaźniki służące do organizacji danych są w pliku .edb. Problem w pliku .stm jest przyczyną utraty niektórych specyficznych danych klienckich, ale nie uszkadza integralności strukturalnej ani logicznej bazy danych traktowanej jako całość.

    Aby sprawdzić sumy kontrolne stron bazy danych programu Exchange, uruchom następujące polecenie narzędzia Esefile:
    esefile /s nazwa_bazy_danych
    Poniżej podano przykładowy wynik działania tego polecenia:
    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
    							
    Niezainicjowane strony są akceptowalne, ale w bazie danych, w której nie wystąpiły problemy, nie ma żadnych złych sum kontrolnych ani nieprawidłowych numerów stron.

    Jeśli wynik testu integralności bazy danych wykonany za pomocą narzędzia Esefile jest negatywny, najlepiej jest przywrócić starszą kopię zapasową, o której wiadomo, że jest prawidłowa, oraz wykonać na bazie danych operację „roll forward”. Jeśli taka kopia zapasowa jest niedostępna, należy skonsultować się z Pomocą techniczną, aby uzyskać poradę dotyczącą naprawiania lub ratowania bazy danych.
  8. Jest to krok opcjonalny. Za pomocą następującego polecenia można sprawdzić integralność plików dzienników, których kopię zapasową wykonano:
    eseutil /ml E0n
    Poniżej podano przykładowy wynik działania tego polecenia:
    k:\backups>eseutil /ml E00
    							
    To polecenie należy uruchomić z folderu zawierającego kopię zapasową plików dziennika. Można je również uruchomić w folderze aktualnie uruchomionego dziennika, ale jeśli podczas działania jakiejkolwiek bazy danych w grupie magazynu program Eseutil spróbuje odczytać nagłówek pliku E0n.log, pojawi się komunikat o błędzie -1032 (JET_errFileAccessDenied).

    To polecenie wykrywa uszkodzenia w plikach dzienników, a także ostrzega użytkownika o brakującym pliku dziennika w środku łańcucha lub istnieniu niezgodności sygnatur między dowolnymi plikami dzienników.
Powrót do listy sekcji

Przywracanie bazy danych programu Exchange z kopii zapasowej offline

W tej sekcji opisano dwie metody przywracania danych z kopii zapasowej offline:
  • Przywracanie metodą typu „punkt na osi czasu”. W bazie danych nie są ponownie odtwarzane żadne pliki dziennika. Wszystkie dane utworzone po wykonaniu kopii zapasowej zostaną utracone.
  • Przywracanie metodą typu „roll forward”. Pliki dziennika, które utworzono po wykonaniu kopii zapasowej, są ponownie odtwarzane w bazie danych. Jeśli wszystkie pliki dziennika są dostępne, można zachować wszystkie dane, które utworzono po wykonaniu kopii zapasowej. Jeśli włączone jest rejestrowanie cykliczne, należy przywrócić kopię zapasową offline, korzystając z metody „punkt na osi czasu”. Nie można zastosować metody „roll forward”.
Przywracany zestaw plików musi spełniać następujące wymagania minimalne:
  • W przypadku przywracania kopii zapasowych metodą „punkt na osi czasu” wszystkie zatrzymywane bazy danych w grupie magazynu muszą być spójne, a ponadto musi istnieć prawidłowy plik punktu kontrolnego. Nie należy usuwać bieżącego pliku punktu kontrolnego ani żadnych istniejących plików dziennika.
  • W przypadku przywracania kopii zapasowych metodą „roll forward” wszystkie bazy danych, które należy zatrzymać, muszą być spójne, a ponadto muszą istnieć wszystkie pliki dziennika, które zostały utworzone po wykonaniu kopii zapasowej (w tym bieżący plik dziennika E0n.log). Należy usunąć plik punktu kontrolnego.
Jeśli zestaw plików nie spełnia powyższych warunków, przywracanie i ponowne odtwarzanie niekoniecznie musi zakończyć się niepowodzeniem, ale w trakcie odzyskiwania miękkiego prawdopodobnie pojawi się komunikat o błędzie -1216 (JET_errAttachedDatabaseMismatch).

Powrót do listy sekcji

Eliminowanie błędu -1216

Dodatkowe oprogramowanie zabezpieczające operację odzyskiwania w programie Exchange 2000 i nowszych powoduje błąd -1216 po wykryciu przez program Exchange ręcznie zmodyfikowanych plików danych i ustaleniu, że w wyniku uruchomienia operacji odzyskiwania przy użyciu bieżącego zestawu danych mogłoby dojść do utraty wcześniej istniejących danych.

Jeśli w starszych wersjach programu Exchange istnieje niekompletny zestaw plików, przy użyciu którego można jednak pomyślnie wykonać ponowne odtwarzanie, administrator nie otrzymuje żadnego ostrzeżenia o rozpoczęciu miękkiego odzyskiwania. W programie Exchange 2000 i nowszych administrator musi wyeliminować błąd -1216 przy użyciu narzędzia Eseutil. Powrót do listy sekcji

Przywracanie danych z kopii zapasowej offline metodą punktu na osi czasu

Aby przywrócić dane z kopii zapasowej offline metodą punktu na osi czasu:
  1. Jeśli baza danych, którą chcesz przywrócić, jest aktualnie zainstalowana, należy ją odinstalować. Jeśli wszelkie pozostałe bazy danych w grupie magazynu są odinstalowane, pliki tych baz danych oraz pliki strumieni (.edb i .stm) muszą być spójne i zgodne. (Aby sprawdzić spójność i zgodność, zobacz krok 2 w sekcji „Wykonywanie kopii zapasowej offline bazy danych programu Exchange” w tym artykule).

    Jeśli wszystkie bazy danych w grupie magazynu są odinstalowane, muszą one być spójne, a ponadto musi istnieć prawidłowy plik punktu kontrolnego. Jest to plik punktu kontrolnego, który był używany po raz ostatni w sytuacji, gdy była używana przynajmniej jedna baza danych w grupie magazynu, a w jego nagłówku znajduje się informacja o tym, że punktem kontrolnym jest plik E0n.log. Jeśli którakolwiek z baz danych w grupie magazynu jest nadal zainstalowana, oznacza to, że prawidłowy plik punktu kontrolnego jest aktualnie używany przez system. Prawidłowy plik punktu kontrolnego istnieje wtedy, gdy uruchomiona jest dowolna baza danych w grupie magazynu.

    Aby po zatrzymaniu wszystkich baz danych sprawdzić poprawność pliku punktu kontrolnego, uruchom następujące polecenia:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Poniżej podano przykładowy wynik działania tych poleceń:
    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)
    							
    W powyższym przykładzie rolę punktu kontrolnego pełni dziennik, którego wartość lGeneration wynosi 0x2cc7, co oznacza, że jest to plik e00.log. Na podstawie tych informacji wiadomo, że punkt kontrolny jest prawidłowy.

    Jeśli punkt kontrolny jest nieprawidłowy, przy próbie zainstalowania którejkolwiek bazy danych z grupy magazynu może pojawić się komunikat o błędzie -1216 (JET_errAttachedDatabaseMismatch). Ten problem może wystąpić nawet wtedy, gdy wszystkie bazy danych w grupie magazynu są spójne.
  2. Skopiuj kopie zapasowe plików .edb i .stm do odpowiednich lokalizacji bazy danych i pliku strumieniowego. (Aby odnaleźć te lokalizacje, zobacz sekcję „Zanim rozpoczniesz” w tym artykule). Sprawdź, czy przywrócone pliki są spójne i zgodne.

    Uwaga: Jeśli kopie plików baz danych, które chcesz przywrócić, istnieją już na serwerze, wykonaj kopię zapasową tych plików przed przywróceniem bazy danych nawet wtedy, gdy istniejące pliki są niemożliwe do uruchomienia. Być może uda się je naprawić i będzie można uratować znajdujące się w nich dane przy użyciu narzędzia Exmerge.
  3. Zainstaluj przywróconą bazę danych. Baza danych samodzielnie dołączy informację o sobie na końcu pliku dziennika E0n.log. Po pomyślnym uruchomieniu bazy danych nie będzie w niej można ponownie odtworzyć żadnych istniejących plików dziennika. Uruchamianie bazy danych zawierającej informacje o tysiącach folderów publicznych może trwać dość długo. Zwykle przetwarzanie informacji o każdym tysiącu folderów trwa około jednej minuty.

    Aby w starszych wersjach programu Exchange Server, po przywróceniu danych z kopii zapasowej offline bazy danych magazynu informacji, zsynchronizować bazę danych magazynu informacji z katalogiem, należało zwykle uruchomić polecenie ISINTEG -patch. Jeśli konieczne jest usunięcie usterek bazy danych programu Exchange, operacja ta jest wykonywana automatycznie przez system, chyba że baza danych została przywrócona na inny serwer, do innej grupy magazynu lub logicznego obiektu bazy danych albo obiekt usługi Active Directory dotyczący tej bazy danych usunięto i ponownie utworzono w usłudze Active Directory. W takich wypadkach w dzienniku zdarzeń aplikacji zostanie zarejestrowany następujący komunikat o błędzie.
    Typ zdarzenia: Błąd
    Źródło zdarzenia: MSExchangeIS Mailbox Store
    Kategoria zdarzenia: Ogólne
    Identyfikator zdarzenia: 1087
    Data: 4-05-2001
    Godzina: 20:33:42
    Użytkownik: Brak
    Komputer: EXCHANGE1
    Opis: Magazyn informacji został przywrócony z kopii zapasowej offline. W programie Microsoft Exchange System Manager znajduje się informacja, że do magazynu „First Storage Group\Private Information Store” bazy danych można przywracać dane, dzięki czemu można zainstalować jego poprawkę.
    Aby rozwiązać ten problem, należy w programie Exchange System Manager, we właściwościach Database obiektu bazy danych, kliknąć pole wyboru This database can be overwritten by a restore, aby je zaznaczyć.
Powrót do listy sekcji

Przywracanie danych z kopii zapasowej offline metodą „roll forward”

Aby mieć największe szanse na pomyślne ponowne odtworzenie plików dziennika w przywróconej bazie danych, należy przestrzegać następujących zasad:
  • Należy zachowywać kopie wszystkich dzienników transakcji, które zostały utworzone po wykonaniu najstarszej pełnej kopii zapasowej.
  • Nie należy zmieniać ścieżki bazy danych, nie wykonując wcześniej nowej pełnej kopii zapasowej.
  • Nie należy uruchamiać polecenia ESEUTIL /p ani ESEUTIL /d, nie wykonując wcześniej nowej pełnej kopii zapasowej.
  • Nie należy dodawać bazy danych do grupy magazynu ani usuwać z niej bazy danych, nie wykonując wcześniej pełnej kopii zapasowej wszystkich baz danych w grupie magazynu.
Aby rozpocząć operację przywracania, wykonaj następujące kroki:
  1. Jeśli baza danych, którą chcesz przywrócić, jest zainstalowana, należy ją odinstalować, a następnie skopiować pliki bazy danych, które chcesz przywrócić, do odpowiednich lokalizacji na serwerze. Jeśli kopie plików baz danych, które chcesz przywrócić, istnieją już na serwerze, wykonaj kopię zapasową tych plików przed przywróceniem bazy danych nawet wtedy, gdy istniejące pliki są niemożliwe do uruchomienia. Być może uda się je naprawić i będzie można uratować znajdujące się w nich dane przy użyciu narzędzia Exmerge.
  2. Odinstaluj wszystkie bazy danych w grupie magazynu, a następnie uruchom następujące polecenie dla każdej bazy danych w bieżącej grupie magazynu oraz każdego pliku przywróconej bazy danych:
    eseutil /mh nazwa_pliku_bazy_danych | find /i "consistent"
    Uwaga: W programie Exchange 2000 z dodatkiem Service Pack 2 lub nowszym stan bazy danych nie jest raportowany jako „Consistent” lub „Inconsistent”, ale jako „Clean Shutdown” lub „Dirty Shutdown”. Znaczenie stanu „Clean Shutdown” jest takie samo jak stanu „Consistent”, a stanu „Dirty Shutdown” — takie samo jak stanu „Inconsistent”. W programie Exchange 2000 z dodatkiem Service Pack 2 lub nowszym należy uruchomić następujące polecenie dodatkowe, aby ustalić stan każdej z baz danych:
    eseutil /mh nazwa_bazy_danych | find /i "Shutdown"
    Poniżej podano przykładowy wynik działania tego polecenia:
    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
    							
    To polecenie wykonuje trzy zadania:
    • Sprawdzenie spójności każdego pliku bazy danych.
    • Sprawdzenie zgodności par plików .edb i .stm dla każdej bazy danych.
    • Zidentyfikowanie zakotwiczonych plików dziennika o najniższym i najwyższym numerze, stanowiących odpowiednio pierwszy i ostatni plik dziennika wymagany do pomyślnego odzyskania wszystkich danych i uniknięcia błędu -1216. Ostatnim spójnym dziennikiem o najniższym numerze spośród dzienników we wszystkich bazach danych jest zakotwiczony plik dziennika o najniższym numerze, a ostatnim spójnym dziennikiem o najwyższym numerze — zakotwiczony plik dziennika o najwyższym numerze.
    W powyższym przykładzie zakotwiczonym plikiem dziennika o najniższym numerze jest plik E0002ac8.log, a najwyższym — plik E0002cc7.log.
  3. Sprawdź, czy sygnatura dziennika zarejestrowana w nagłówkach każdej bazy danych jest sygnaturą zakotwiczonego dziennika o najniższym numerze. W tym celu uruchom następujące polecenia:
    eseutil /mh nazwa_bazy_danych | find /i "Log Signature"
    eseutil /ml zakotwiczony_dziennik_o_najniższym_numerze | find /i "Signature"
    Poniżej podano przykładowy wynik działania tego polecenia:
    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:
    							
    W pliku dziennika może się znajdować kilka sygnatur. Pierwsza sygnatura należy zawsze do pliku dziennika, natomiast pozostałe to sygnatury baz danych, które działały podczas tworzenia pliku dziennika. W powyższym przykładzie sygnatury dziennika, które zostały zarejestrowane w plikach baz danych, są zgodne z sygnaturą dziennika w zakotwiczonym pliku dziennika o najniższym numerze.

    Jeśli nie można zlokalizować zakotwiczonego dziennika o najniższym numerze, nie będzie można odtworzyć kolejnych dzienników do tej bazy danych. Jeśli nie można znaleźć pliku zakotwiczonego dziennika o najniższym numerze, nie można będzie ponownie odtworzyć żadnego pliku dziennika w żadnej bazie danych. Istnieją dwie metody postępowania w sytuacji, gdy brakuje zakotwiczonego dziennika o najniższym numerze:
    • Można usunąć wszystkie pliki dzienników. Ponieważ wszystkie bazy danych są spójne, do ich uruchamiania nie są konieczne żadne pliki dzienników. Ten sposób uruchamiania powoduje jednak utratę możliwości odzyskania danych, których nie ma jeszcze w plikach bazy danych.
    • Można usunąć bazy danych zawierające ostatnie najniższe spójne wartości, aby mieć możliwość utworzenia szeregu zakotwiczonych dzienników od dziennika o najniższym numerze do dziennika o najwyższym numerze, a następnie uruchomienia operacji odzyskiwania pozostałych bazach danych. Po ponownym umieszczeniu usuniętych baz danych w grupie magazynu nie będzie można ponownie odtworzyć w nich żadnych dodatkowych danych.
  4. Sprawdź, czy bieżące ścieżki baz danych są takie same, jak podczas wykonywania kopii zapasowej.

    Mimo że po wykonaniu kopii zapasowej można zmienić ścieżkę dziennika transakcji lub ścieżkę roboczą, plik dziennika można ponowne odtworzyć tylko wtedy, gdy pliki bazy danych znajdują się w tych samych lokalizacjach, w których znajdowały się podczas wykonywania kopii zapasowej. Jeśli nie ma pewności co do ich oryginalnych lokalizacji, należy uruchomić następujące polecenie:
    eseutil /ml "Ostatni_spójny_dziennik" | find /i "nazwa bazy danych lub wzorzec"
    Poniżej podano przykładowy wynik działania tego polecenia:
    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
    							
    Uwaga: Jeśli zakotwiczonym plikiem dziennika o najniższym numerze jest plik E0n00001.log, w jego nagłówku nie ma informacji o ścieżce, ponieważ nagłówek pierwszego dziennika z szeregu jest generowany przed dołączeniem bazy danych, która jest zawsze dołączana do dziennika. Aby w takim wypadku uzyskać informacje o ścieżce bazy danych, należy przejrzeć nagłówek kolejnego dziennika. W rzadkich przypadkach ten problem dotyczy również kolejnych dzienników, ponieważ baza danych została utworzona lub dołączona do strumienia dziennika po utworzeniu samego dziennika.
  5. Zbierz wszystkie dzienniki występujące po sobie w jednym, nieprzerwanym szeregu, począwszy od najniższego numeru kotwicy, a skończywszy na możliwe najwyższym numerze, a następnie skopiuj je do bieżącej ścieżki dzienników transakcji. Nie należy zastępować dzienników, które znajdują się już na serwerze, nie wykonując najpierw ich kopii zapasowej. W tym celu konieczne może się okazać przywrócenie plików dziennika z więcej niż jednego typu nośnika kopii zapasowych.

    W powyższym przykładzie zakotwiczonym plikiem dziennika o najniższym numerze jest plik E0002ac8.log, a najwyższym — plik E0002cc7.log. Po zbadaniu dostępnych dzienników może się okazać, że najwyższy numer dziennika, który można odnaleźć, jest o jeden numer mniejszy niż numer wymagany (na przykład E0002cc6.log zamiast 2cc7). Zwykle dzieje się tak dlatego, że dziennik o nazwie E0n.log nie został jeszcze całkowicie zapełniony i w związku z tym nie przyjął nazwy z kolejnym numerem w sekwencji. Aby ustalić, czy plik E0n.log jest rzeczywiście zakotwiczonym dziennikiem o najwyższym numerze, należy zbadać wartość lGeneration w nagłówku pliku dziennika za pomocą następującego polecenia:
    eseutil /ml E0n.log | find /i "lGeneration"
    Poniżej podano przykładowy wynik działania tego polecenia:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Uwaga: Aby wyświetlić nagłówek pliku dziennika za pomocą narzędzia Eseutil, należy użyć przełącznika /ml. Aby wyświetlić nagłówek pliku bazy danych, należy użyć przełącznika /mh. W przypadku niewłaściwego użycia podanych przełączników wynik działania tych poleceń jest nieprawidłowy.

    Zwykle zakotwiczony dziennik o najwyższym numerze jest również dziennikiem o najwyższym dostępnym numerze, ale taka sytuacja nie występuje wtedy, gdy:
    • Pliki dziennika uległy uszkodzeniu w wyniku awarii.

      -lub-
    • Wszystkie bazy danych w danej grupie magazynu są przywracane naraz.
    W pierwszym przypadku w trakcie odzyskiwania prawdopodobnie wystąpiły błędy -1216. W drugim przypadku można odtwarzać kolejne pliki dziennika, nawet bez zakotwiczonego dziennika o najwyższym numerze, dopóki pliki dzienników mają kolejne numery sekwencji lGeneration.
  6. Sprawdź, czy wszystkie dzienniki mają tę samą sygnaturę i czy tworzą nieprzerwaną sekwencję. Uruchom następujące polecenie:
    eseutil /ml E0n > nazwa_pliku.txt
    Poniżej podano przykładowy wynik działania tego polecenia:
    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.
    							
    To polecenie Eseutil wykonuje trzy zadania: sprawdza, czy żaden plik dziennika nie jest uszkodzony, informuje o wszelkich przerwach w sekwencji plików dziennika oraz wykrywa niezgodności sygnatur dzienników.

    Wszystkie sygnatury plików dziennika, które mają być użyte do ponownego odtworzenia, muszą być zgodne. Przed rozpoczęciem ponownego odtwarzania należy usunąć wszelkie dzienniki, których sygnatury są niezgodne.

    Obecnie, po usunięciu plików, których weryfikacja dała wynik negatywny, jedynymi plikami dzienników transakcji znajdującymi się w folderze Transaction Logs są pliki:
    • Tworzące nieprzerwaną sekwencję wartości lGeneration, począwszy od zakotwiczonego pliku dziennika o najniższym numerze, przez zakotwiczony plik dziennika o najwyższym numerze, a skończywszy na pliku dziennika znajdującym się za nim (jeśli to możliwe).
    • Mające zgodne sygnatury dziennika.
  7. Jeśli zakotwiczony plik dziennika o najwyższym numerze nie ma jeszcze nazwy E0n.log, zmień jego nazwę.
  8. Usuń plik E0n.chk z folderu System Path.

    W przypadku braku pliku punktu kontrolnego program Exchange Server rozpoczyna ponowne odtwarzanie dzienników od pliku dziennika o najniższym numerze znajdującego się w folderze Transaction Logs: zakotwiczonego dziennika o najniższym numerze. Jeśli plik E0n.chk istnieje, program Exchange Server rozpoczyna ponowne odtwarzanie w punkcie kontrolnym, który został zarejestrowany w tym pliku. Jeśli punkt kontrolny zarejestrowany w pliku E0n.chk wskazuje na dziennik znajdujący się przed zakotwiczonym dziennikiem o najniższym numerze, ponowne odtworzenie zestawu plików zakończy się niepowodzeniem. W wielu przypadkach błędne wskazanie pliku kontrolnego powoduje, że przywracanie plików bazy danych z kopii zapasowej należy rozpoczynać od początku.
  9. Przez zainstalowaniem grupy magazynu należy jeszcze sprawdzić, czy:
    • Wszystkie pliki bazy danych znajdują się w odpowiednich ścieżkach.
    • Jedynymi plikami dziennika w ścieżce bieżącego dziennika transakcji są: zakotwiczony dziennik o najniższym numerze, wszystkie kolejne pliki dziennika aż do zakotwiczonego dziennika o najwyższym numerze oraz dziennik o najwyższym dostępnym numerze mający nazwę E0n.log.
    • W folderze System Path nie istnieje żaden plik E0n.chk.
    Teraz można pomyślnie zainstalować grupę magazynu i rozpocząć ponowne odtwarzanie dzienników transakcji przy użyciu tego zestawu plików. Jednak nawet po zakończeniu odzyskiwania i uruchomieniu bazy danych operacja przywracania nie musi rzeczywiście objąć wszystkich danych we wszystkich plikach dzienników, ponieważ w trakcie ponownego odtwarzania mogą wystąpić problemy dotyczące sygnatury i ścieżki bazy danych. Dodatkowe informacje o tych problemach znajdują się w sekcji „Eliminowanie niezgodności sygnatury i ścieżki bazy danych” tego artykułu.
  10. Jeśli magazyn informacji nie jest jeszcze uruchomiony, uruchom go, a następnie zainstaluj przynajmniej jedną bazę danych w grupie magazynu. Spowoduje to rozpoczęcie miękkiego odzyskiwania wszystkich baz danych w grupie magazynu.

    Aby w starszych wersjach programu Exchange Server po przywróceniu danych z kopii zapasowej offline bazy danych magazynu informacji zsynchronizować bazę danych z katalogiem, należy zwykle uruchomić polecenie ISINTEG -patch. Jeśli konieczne jest usunięcie usterek bazy danych programu Exchange, operacja ta jest wykonywana automatycznie przez system, chyba że baza danych została przywrócona na inny serwer, do innej grupy magazynu lub logicznego obiektu bazy danych albo obiekt usługi Active Directory dotyczący tej bazy danych usunięto i ponownie utworzono w usłudze Active Directory. W takich wypadkach w dzienniku zdarzeń aplikacji zostanie zarejestrowany następujący komunikat o błędzie.
    Typ zdarzenia: Błąd
    Źródło zdarzenia: MSExchangeIS Mailbox Store
    Kategoria zdarzenia: Ogólne
    Identyfikator zdarzenia: 1087
    Data: 4-05-2001
    Godzina: 20:33:42
    Użytkownik: Brak
    Komputer: EXCHANGE1
    Opis: Magazyn informacji został przywrócony z kopii zapasowej offline. W programie Microsoft Exchange System Manager znajduje się informacja, że do magazynu „First Storage Group\Private Information Store” bazy danych można przywracać dane, dzięki czemu można zainstalować jego poprawkę.
    Aby rozwiązać ten problem, należy w programie Exchange System Manager, we właściwościach Database obiektu bazy danych, kliknąć pole wyboru This database can be overwritten by a restore, aby je zaznaczyć.
Należy sprawdzić, czy w dzienniku zdarzeń aplikacji w przystawce Podgląd zdarzeń systemu Microsoft Windows NT nie zostały zarejestrowane jakiekolwiek błędy lub nieprawidłowości, które mogą się pojawiać po uruchomieniu bazy danych. Zdarzenie o identyfikatorze 301 dotyczy każdego ponownie przywracanego pliku dziennika. Należy zwracać szczególną uwagę na komunikaty o błędach oraz ostrzeżenia pojawiające się w trakcie operacji odzyskiwania.

Powrót do listy sekcji

Eliminowanie niezgodności sygnatury i ścieżki bazy danych

Bazy danych, podobnie jak pliki dziennika, mają własne sygnatury. O ile jednak sygnatury dzienników nie zmieniają się po utworzeniu pliku E0n000001.log, o tyle zmiana sygnatur baz danych następuje po każdej modyfikacji ich fizycznej topologii, przy czym zmiany te nie są rejestrowane w plikach dzienników. Defragmentacja offline lub naprawianie bazy danych za pomocą narzędzia Eseutil powoduje zmianę sygnatury bazy danych. Po takim zdarzeniu bazę danych można dołączyć do tego samego strumienia dzienników co wcześniej, jednak nie będzie można ponownie odtworzyć w tej bazie danych żadnych transakcji, które wykonano przy użyciu jej starszej sygnatury. W starszej kopii bazy danych nie będzie można ponownie odtworzyć żadnych transakcji, które wykonano po zmianie sygnatury bazy danych.

Ponieważ w ten sposób dochodzi do zresetowania sygnatur baz danych, zdecydowanie zaleca się natychmiastowe wykonanie pełnych kopii baz danych po ich zdefragmentowaniu w trybie offline lub naprawieniu. Jeśli w przyszłości zostanie przywrócona kopia bazy danych mająca starą sygnaturę, operacja ponownego odtworzenia informacji sprzed zmiany sygnatury zakończy się powodzeniem, jednak utracone zostaną informacje o wszystkich zmianach dokonanych później.

Efekt zmiany ścieżek baz danych w środku strumienia dzienników przypomina zmianę sygnatur: operacja ponownego odtwarzania zostaje przerwana w punkcie, w którym dokonano takiej zmiany. (Interfejs API kopii zapasowej online umożliwia ponowne zamapowanie ścieżek w trakcie operacji odzyskiwania, dlatego operacja ponownego odtwarzania przy użyciu interfejsu API kopii zapasowej online może zakończyć się pomyślnie, nawet jeśli po wykonaniu kopii zapasowej zmieniono ścieżkę).

Jako że problemy dotyczące sygnatury lub ścieżki bazy danych występują w trakcie operacji ponownego odtwarzania, dlatego są one rejestrowane jako zdarzenia o identyfikatorze 301 w dzienniku zdarzeń aplikacji dla każdego ponownie odtwarzanego pliku. Pliki dzienników, które zostały odtworzone po wystąpieniu tego problemu, mogą wyglądać na prawidłowe, jednak dzieje się tak tylko dlatego, że informacja o zarejestrowaniu określonej niezgodności nie jest powtarzana. Ogólnie można przyjąć, że ponowne odtwarzanie w konkretnej bazie danych zostanie zatrzymane w momencie wystąpienia pierwszego błędu dotyczącego jej sygnatury lub ścieżki.

Powrót do listy sekcji

Właściwości

Numer ID artykułu: 296788 - Ostatnia weryfikacja: 3 grudnia 2007 - Weryfikacja: 4.3
Informacje zawarte w tym artykule dotyczą:
  • 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
Słowa kluczowe: 
kberrmsg kbhowto kbproductlink KB296788

Przekaż opinię

 

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