Wykonywanie kopii zapasowej danych programu Exchange Server 2003 a usługi Kopiowanie woluminów w tle

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

Na tej stronie

Streszczenie

Funkcji usługi kopiowania woluminów w tle w systemie Microsoft Windows Server 2003 można używać do tworzenia aplikacji, które wykonują kopię zapasową danych programu Microsoft Exchange Server 2003 i je przywracają. Usługa Kopiowanie woluminów w tle (VSS) zapewnia infrastrukturę, która umożliwia współpracę programów do zarządzania magazynowaniem, programów użytkowych i dostawców sprzętu innych firm przy tworzeniu kopii w tle oraz zarządzaniu nimi. Rozwiązania wykorzystujące tę infrastrukturę mogą za pomocą kopii w tle (lub kopii lustrzanych) wykonywać kopie zapasowe jednej lub wielu baz danych programu Exchange Server 2003 lub je przywracać.

Usługa Kopiowanie woluminów w tle koordynuje komunikację między obiektami wysyłającymi żądanie (aplikacjami wykonywania kopii zapasowych), obiektami zapisującymi (aplikacjami w usługach systemu Windows, takimi jak Exchange Server 2003 i SQL Server 2000) oraz dostawcami (składnikami systemu, oprogramowania lub sprzętu, które tworzą kopie w tle). Aby użyć usługi Kopiowanie woluminów w tle do wykonania kopii zapasowej danych programu Exchange Server 2003, program wykonywania kopii zapasowych musi zawierać obiekt wysyłający żądanie usługi Kopiowanie woluminów w tle, który rozpoznaje program Exchange Server 2003. Ponieważ program wykonywania kopii zapasowych dołączony do systemu Windows Server nie zawiera takiego obiektu, organizacje muszą używać pochodzących od innych firm aplikacji wykonywania kopii zapasowych.

Ze względu na zgodność z programem Exchange Server 2003 aplikacje wykonywania kopii zapasowej wykorzystujące usługę VSS muszą spełniać trzy podstawowe wymagania, aby zapewnić integralność kopii zapasowych w tle i możliwość odzyskania z nich danych. Jeśli te wymaganie nie są spełnione, Pomoc techniczna firmy Microsoft (PSS) uznaje, że rozwiązanie wykonywania kopii zapasowych nie mieści się w strukturze Exchange VSS, i nie jest w stanie rozwiązać problemów z wykonywaniem kopii zapasowych i przywracaniem danych. Klienci powinni dowiedzieć się, czy ich aplikacja wykonywania kopii zapasowych spełnia wymagania zgodności z programem Exchange wymienione w tym artykule z bazy wiedzy Knowledge Base. Wymagania Exchange VSS opisano szczegółowo w sekcji „Więcej informacji” w tym artykule.

Jak w przypadku każdego rozwiązania pochodzącego od innej firmy, to głównie dostawca aplikacji wykonywania kopii zapasowych jest odpowiedzialny za zapewnienie pomocy technicznej w przypadku problemów z wykonywaniem kopii zapasowych i przywracaniem danych. PSS może pomóc zdiagnozować i przeanalizować problemy z dostępnymi zestawami plików baz danych i dzienników transakcji. Jednak firma Microsoft nie rozwiązuje problemów z produktami innych firm ani nie debuguje tych produktów. Pomoc PSS ogranicza się do porady, w jaki sposób najlepiej kontynuować odzyskiwanie dostępnych zestawów plików baz danych i dzienników transakcji.

Aby uzyskać więcej informacji dotyczących pomocy technicznej PSS w przypadku rozwiązań opartych na usłudze VSS, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
841696 Omówienie zasad firmy Microsoft dotyczących pomocy technicznej w przypadku programowych rozwiązań magazynowania pochodzących od innych firm

Więcej informacji

Proces wykonywania kopii zapasowej programu Exchange Server 2003 za pomocą usługi Kopiowanie woluminów w tle opisano na następującej liście:

  1. Program wykonywania kopii zapasowej (lub agent) uruchamia zaplanowane zadanie.
  2. Obiekt wysyłający żądanie usługi Kopiowanie woluminów w tle w programie wykonywania kopii zapasowych wysyła do usługi Kopiowanie woluminów w tle polecenie utworzenia kopii w tle wybranych grup magazynów programu Exchange Server 2003.
  3. Usługa Kopiowanie woluminów w tle komunikuje się z obiektem zapisującym programu Exchange Server 2003 w celu przygotowania kopii zapasowej migawki.
  4. Usługa Kopiowanie woluminów w tle komunikuje się z odpowiednim dostawcą magazynowania w celu utworzenia kopii w tle woluminu lub woluminów magazynów, które zawierają grupę lub grupy magazynów programu Exchange Server 2003.
  5. Usługa Kopiowanie woluminów w tle zwalnia program Exchange 2003, aby wznowił zwykłe działanie.
  6. Obiekt wysyłający żądanie usługi Kopiowanie woluminów w tle sprawdza integralność zestawu kopii zapasowych, zanim poinformuje program Exchange, że wykonanie kopii zapasowej się powiodło.
Jeśli na przykład żądanie wykonania kopii w tle zostanie odebrane od programu wykonywania kopii zapasowych Exchange Server 2003 obsługującego usługę Kopiowanie woluminów w tle (obiektu wysyłającego żądanie), usługa Kopiowanie woluminów w tle komunikuje się z obiektem zapisującym programu Exchange Server 2003 w celu przygotowania migawki; w tym momencie program Exchange Server 2003 uniemożliwia operacje administracyjne na grupie magazynów, sprawdza zależności woluminu oraz zawiesza wszystkie operacje zapisu w plikach baz danych i dzienników transakcji, zezwalając wyłącznie na dostęp tylko do odczytu. Następnie usługa Kopiowanie woluminów w tle komunikuje się z odpowiednim dostawcą magazynowania w celu zainicjowania procesu tworzenia kopii w tle woluminów zawierających dane programu Exchange Server 2003. Wykonywanie kopii w tle zazwyczaj trwa kilka sekund, więc jest praktycznie niezauważalne dla użytkownika końcowego. Po utworzeniu kopii w tle usługa Kopiowanie woluminów w tle informuje obiekt zapisujący programu Exchange Server 2003, że może wznowić zwykłe działanie. Program wykonywania kopii zapasowych sprawdza kondycję kopii w tle, zanim poinformuje program Exchange, że wykonanie kopii zapasowej się powiodło. Na zakończenie pomyślnej operacji wykonania kopii zapasowej program Exchange obcina dzienniki i rejestruje godzinę wykonania ostatniej kopii zapasowej bazy danych lub baz danych.

Aby uzyskać więcej informacji na temat wykonywania kopii zapasowej danych programu Exchange Server 2003 za pomocą usług Kopiowanie woluminów w tle, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
842066 TechNet Support WebCast: Volume Shadow Copy for Exchange Server 2003

Na poniższej liście opisano wymagania programu Exchange Server 2003, jakie musi spełniać każda aplikacja wykonywania kopii zapasowych w tle, aby zapewnić integralność i możliwość odzyskania baz danych Exchange:

Poniższa lista zawiera informacje z dzienników zdarzeń aplikacji, które określają, czy wymagania programu Exchange są spełnione. Aplikacje wykonywania kopii zapasowych i serwer Exchange mogą rejestrować inne zdarzenia związane z procesem wykonywania kopii zapasowej i przywracania danych. Potwierdzenie, że poniższe zdarzenia są rejestrowane podczas procesu wykonywania kopii zapasowej i przywracania, może służyć za weryfikację zgodności z wymaganiami Exchange VSS. Obecnie nie istnieje żaden program certyfikacji dla żadnego rozwiązania programowego innej firmy uruchamianego na serwerze Exchange. Zgodność zapewnia integralność kopii zapasowych w tle i możliwość odzyskania z nich danych, ale nie daje żadnych gwarancji co do wydajności i niezawodności rozwiązania innej firmy.
  1. Kopie zapasowe plików baz danych, dzienników transakcji i punktów kontrolnych Exchange muszą być wykonywane wyłącznie za pomocą obiektu zapisującego programu Exchange:

    Następujące zdarzenia aplikacji są rejestrowane, jeśli obiekt zapisujący programu Exchange zostanie zainicjowany podczas wykonywania kopii zapasowej w tle.

    Typ zdarzenia: Informacje
    Źródło zdarzenia: ESE
    Kategoria zdarzenia: ShadowCopy
    Identyfikator zdarzenia: 2005
    Data: 6/17/2004
    Godzina: 11:40:41
    Użytkownik: Brak
    Komputer: EXCHSERVER
    Opis: Information Store (2180) Shadow copy instance 3 starting. This will be a “Backup Type”* shadow copy.

    * Gdzie “Backup Type” to typ wykonywanej kopii zapasowej (Full, Copy, Incremental lub Differential).

    Typ zdarzenia: Informacje
    Źródło zdarzenia: MSExchangeIS
    Kategoria zdarzenia: Exchange VSS Writer
    Identyfikator zdarzenia: 9608
    Data: 6/17/2004
    Godzina: 11:40:42
    Użytkownik: Brak
    Komputer: EXCHSERVER
    Opis: Exchange VSS Snapshot prepared for Snapshot successfully.

    Typ zdarzenia: Informacje
    Źródło zdarzenia: MSExchangeIS
    Kategoria zdarzenia: Exchange VSS Writer
    Identyfikator zdarzenia: 9610
    Data: 6/17/2004
    Godzina: 11:40:43
    Użytkownik: Brak
    Komputer: EXCHSERVER
    Opis: Exchange VSS Snapshot has frozen the storage groups successfully.

    Typ zdarzenia: Informacje
    Źródło zdarzenia: MSExchangeIS
    Kategoria zdarzenia: Exchange VSS Writer
    Identyfikator zdarzenia: 9612
    Data: 6/17/2004
    Godzina: 11:40:44
    Użytkownik: Brak
    Komputer: EXCHSERVER
    Opis: Exchange VSS Snapshot has thawed the storage groups successfully.

  2. Aplikacja wykonywania kopii zapasowych musi sprawdzać integralność zestawu kopii zapasowych w tle.

    Firma Microsoft zaleca, ale nie wymaga, aby ta integralność była sprawdzana, zanim aplikacja wykonywania kopii zapasowych powiadomi program Exchange, że kopia zapasowa została wykonana. To zalecenie bierze się stąd, że program Exchange po pomyślnym utworzeniu kopii zapasowej wykonuje dwa ważne zadania:
    • Program Exchange aktualizuje nagłówki baz danych uwzględnionych w kopii zapasowej w celu zarejestrowania godziny wykonania ostatniej pomyślnej kopii zapasowej
    • Program Exchange usuwa z serwera („czyści”) dzienniki transakcji, które nie są już potrzebne do wycofania „do przodu” danych z ostatniej pomyślnej kopii zapasowej.
    Jeśli aplikacja wykonywania kopii zapasowych odkłada sprawdzanie integralności do czasu po wykonaniu tych zadań, to trzeba zwrócić specjalną uwagę, aby zachować ostatnią sprawdzoną kopię zapasową wraz z kopiami wszystkich plików dzienników wymaganych przez tę kopię zapasową. Mimo że program Exchange mógł już zostać powiadomiony o pomyślnym wykonaniu kopii zapasowej, to nie należy polegać na tej kopii, dopóki aplikacja wykonywania kopii zapasowych faktycznie nie dokona sprawdzenia integralności.

    Szczegółowe informacje, w jaki sposób wykonywać kontrole integralności i ustalać, które pliki baz danych i dzienników transakcji trzeba zachować, dopóki nie zostanie zakończone sprawdzanie integralności, znajdują się w sekcji „Jak przeprowadzać sprawdzanie integralności dla kopii zapasowych VSS” tego artykułu.
  3. Operacja przywracania w lokalizacji pierwotnej** musi być wykonywana wyłącznie za pomocą obiektu zapisującego programu Exchange

    W trakcie procesu przywracania danych z kopii w tle obiekt zapisujący programu Exchange rejestruje następujące zdarzenia w dziennikach zdarzeń aplikacji.

    Typ zdarzenia: Informacje
    Źródło zdarzenia: MSExchangeIS
    Kategoria zdarzenia: Exchange VSS Writer
    Identyfikator zdarzenia: 9620
    Data: 6/17/2004
    Godzina: 13:49:59
    Użytkownik: Brak
    Komputer: EXCHSERVER
    Opis: Exchange VSS Snapshot has processed pre-restore event successfully

    Typ zdarzenia: Informacje
    Źródło zdarzenia: MSExchangeIS
    Kategoria zdarzenia: Exchange VSS Writer
    Identyfikator zdarzenia: 9618
    Data: 6/17/2004
    Godzina: 13:59:46
    Użytkownik: Brak
    Komputer: EXCHSERVER
    Opis: Exchange VSS Snapshot has processed post-restore event successfully

** „Lokalizacja pierwotna” oznacza komputer programu Exchange o tej samej nazwie serwera i tej samej ścieżce pliku, co w przypadku komputera programu Exchange, na którym została wykonana kopia zapasowa VSS.

Operacje przywracania w innych lokalizacjach za pomocą obiektu zapisującego programu Exchange są niemożliwie w programie Exchange Server 2003 z dodatkiem SP1 i w jego nowszych wersjach. Aplikacje wykonywania kopii zapasowych wykorzystujące usługę VSS mogą oferować ręczne lub inne metody programistyczne przywracania w innych lokalizacjach baz danych programu Exchange z ich kopii w tle.

Jak przeprowadzać sprawdzanie integralności dla kopii zapasowych VSS

Jeśli kopia zapasowa bazy danych jest wykonywana za pomocą interfejsu API strumieniowego wykonywania kopii zapasowych programu Exchange, każda strona w bazie danych jest odczytywana po kolei i integralność sumy kontrolnej każdej strony jest sprawdzana w trakcie procesu wykonywania kopii zapasowej. Integralność sumy kontrolnej plików dzienników transakcji jest również sprawdzana przed wykonaniem ich kopii zapasowej.

Podczas wykonywania kopii zapasowej VSS nie ma okazji, aby program Exchange odczytał w całości każdy plik bazy danych i sprawdził integralność jego sumy kontrolnej. Dlatego integralność plików baz danych i dzienników transakcji musi sprawdzać aplikacja wykonywania kopii zapasowych. Można to zapewnić, uruchamiając narzędzie Eseutil, jak opisano na końcu tego dokumentu.

Jeśli suma kontrolna kopii zapasowych VSS nie jest sprawdzona, istnieje możliwość, że w bazie danych pozostanie niewykryta uszkodzona strona i w końcu pojawi się ona we wszystkich istniejących kopiach zapasowych. Jedynym sposobem odzyskania danych w takiej sytuacji jest naprawa bazy danych. Naprawa bazy danych wymaga długiego przestoju i w jej wyniku przynajmniej część danych zostaje utracona (przynajmniej dane znajdujące się na uszkodzonych stronach).

Jeśli jednak sprawdzono, że kopia zapasowa VSS zawiera tylko dobre strony, można usunąć uszkodzone strony z bazy danych przez przywrócenie danych ze sprawdzonej kopii zapasowej i wycofanie ich „do przodu” przy użyciu dzienników transakcji utworzonych od czasu utworzenia ostatniej kopii zapasowej. Czas przestoju wymagany do wykonania tych operacji zazwyczaj jest dużo krótszy niż w przypadku naprawy bazy danych i ta metoda odzyskiwania może rozwiązać problemy z bazą danych bez utraty żadnych danych.

Dlatego kopii zapasowej VSS nie należy uważać za dobrą, dopóki nie zostanie sprawdzona suma kontrolna wszystkich składających się na nią plików.

Sprawdzając integralność kopii zapasowej, należy przestrzegać dwóch poniższych reguł.
  • Pliki baz danych: Trzeba zawsze mieć dostępną kopię plików baz danych sprawdzoną pod kątem integralności. Kopia zapasowa o sprawdzonej integralności to taka, dla której sprawdzono sumy kontrolne stron plików baz danych uwzględnionych w zestawie kopii zapasowych.
Ostatnia kopia zapasowa baz danych, dla której nie sprawdzono jeszcze sum kontrolnych, nie może być uważana za prawidłową kopię zapasową. Nie należy pozbywać się poprzedniej sprawdzonej kopii zapasowej, dopóki nie zostanie sprawdzona ostatnia kopia zapasowa.
  • Pliki dzienników transakcji: Wszystkie pliki dzienników transakcji wymagane do odzyskania danych z najnowszej kopii zapasowej bazy danych o sprawdzonej integralności również muszą zostać umieszczone w kopii zapasowej i musi zostać sprawdzona ich integralność na poziomie sumy kontrolnej.
Te dzienniki transakcji obejmują przynajmniej cały zakres plików dzienników wymienionych w polu Log Required w nagłówku każdej bazy danych w ostatniej sprawdzonej kopii zapasowej. Jeśli te pliki dzienników są niedostępne, nie będzie można zainstalować bazy danych po jej przywróceniu.

Ważne To wymaganie odnosi się do ostatniej kopii zapasowej o sprawdzonej integralności, a nie do ostatnio utworzonej kopii zapasowej. Dopóki nie zostaną sprawdzone sumy kontrolne najnowszej kopii zapasowej, nie można jej uważać za prawidłową kopię zapasową.

Opcjonalnie można również zachować dodatkowe dzienniki wymagane do pełnego wycofania bazy danych „do przodu” po jej przywróceniu z kopii zapasowej bazy danych. Są to wszystkie dzienniki transakcji w nieprzerwanej sekwencji, począwszy od najniższego pliku w polu Log Required, aż do ostatnio utworzonego pliku dziennika transakcji usuniętego z serwera Exchange. Poniżej zamieszczono szczegółowe przykłady i wyjaśnienia, co to znaczy.

Zachowywanie dodatkowych dzienników transakcji oprócz wymienionych w zakresach Log Required jest opcjonalne, ponieważ nie jest to absolutnie niezbędne do pomyślnego przywrócenia bazy danych z kopii zapasowej i jej zainstalowania. Jeśli jednak te dzienniki nie są zachowywane, przywrócenie bazy danych z kopii zapasowej powoduje utratę wszystkich zmian wprowadzonych w bazie danych od momentu wykonania kopii zapasowej. Firma Microsoft stanowczo zaleca, aby zachowywać nie tylko dzienniki transakcji wymagane do przywrócenia i zainstalowania bazy danych, ale również wszystkie następne dzienniki transakcji potrzebne do wycofania bazy danych „do przodu” bez utraty danych.

Ustalanie, które dzienniki transakcji są wymagane

Jeśli jest wykonywana kopia zapasowa bazy danych Exchange w trybie online, wraz z nią jest zawsze wykonywana kopia zapasowa przynajmniej jednego pliku dziennika transakcji. Dzieje się tak niezależnie od tego, czy jest używany interfejs API strumieniowego wykonywania kopii zapasowej, czy interfejs API wykonywania kopii zapasowej VSS.

Po przywróceniu danych z kopii zapasowej online informacje z dzienników transakcji muszą zostać zastosowane do bazy danych („odtworzone”) przed jej ponownym zainstalowaniem. Pole Log Required każdego nagłówka bazy danych rejestruje numery sekwencyjne (generacji) zakresu plików dzienników transakcji, które muszą zostać zastosowane do bazy danych.

Jeśli pole Log Required zawiera wartość 0-0, oznacza to, że bazę danych można zainstalować bez konieczności odtworzenia żadnych dodatkowych danych z dzienników transakcji. Wartość pola Log Required może wynosić 0-0 tylko w przypadku, gdy baza danych została zamknięta w sposób „czysty”. Podczas działania bazy danych pole Log Required zawsze rejestruje zakres dzienników transakcji, które jeszcze nie zostały zastosowane do bazy danych. Zakres ten jest stale aktualizowany.

Baza danych, której kopia zapasowa jest wykonywana w trybie online, zawsze ma niezerowy zakres Log Required i kopia zapasowa dzienników z tego zakresu musi zostać wykonana wraz z kopią zapasową bazy danych. Jeśli po przywróceniu bazy danych te dzienniki są niedostępne, nie można zainstalować bazy danych. (Jeśli nie można odnaleźć potrzebnych dzienników, to można spróbować naprawić bazę danych, ale nie ma gwarancji, że ta naprawa się powiedzie, a ponadto w wyniku naprawy prawie zawsze część danych zostaje utracona, przynajmniej dane z brakujących dzienników).

Jeśli jest używany interfejs API strumieniowego wykonywania kopii zapasowej programu Exchange lub interfejs API wykonywania kopii zapasowej VSS zawarty w obiekcie zapisującym Exchange VSS, to kopia zapasowa plików dzienników potrzebnych do zainstalowania bazy danych jest wykonywana automatycznie wraz z kopią zapasową bazy danych. W przypadku odtworzenia samych plików Log Required baza danych zostanie przywrócona w stanie z punktu w czasie, w którym zakończono wykonywanie kopii zapasowej. Aby można było wycofać bazę danych „do przodu” poza ten punkt, trzeba również odtworzyć pliki dzienników wygenerowane po utworzeniu kopii zapasowej.

Aby można było całkowicie wycofać bazę danych „do przodu”, korzystając z dowolnej kopii zapasowej, trzeba zachowywać wszystkie pliki dzienników w nieprzerwanej sekwencji, począwszy od najniższego pliku w zakresie Log Required, aż do ostatnio wygenerowanego pliku dziennika w grupie magazynów bazy danych. W przypadku braku lub uszkodzenia któregokolwiek dziennika z tej serii bazę danych można wycofać „do przodu” jedynie do momentu wygenerowania ostatniego dobrego dziennika przed brakującym lub uszkodzonym plikiem.

Jeśli więc ma istnieć możliwość odzyskania danych z kopii zapasowej bez żadnej utraty danych, zasadnicze znaczenie ma to, aby zachowywać dobre kopie wszystkich plików dzienników transakcji wygenerowanych od czasu utworzenia ostatniej sprawdzonej, dobrej kopii zapasowej bazy danych.

Czyszczenie dzienników transakcji

Gdyby dzienniki transakcji nie były usuwane z serwera Exchange, ich akumulacja trwałaby, aż do zapełnienia całego dostępnego miejsca na dysku. Dlatego oba interfejsy API, strumieniowego wykonywania kopii zapasowej i wykonywania kopii zapasowej VSS, obsługują „czyszczenie” dzienników transakcji po zakończeniu tworzenia normalnej lub przyrostowej kopii zapasowej. Pliki dzienników starsze niż te, które są potrzebne do odzyskania danych z najnowszej kopii zapasowej, są automatycznie usuwane z serwera, gdy aplikacja wykonywania kopii zapasowych powiadomi serwer Exchange o pomyślnym utworzeniu kopii zapasowej.

W przypadku strumieniowego interfejsu API sprawdzanie sum kontrolnych bazy danych jest przeprowadzane w trakcie procesu wykonywania kopii zapasowej. Do czasu zakończenia tego procesu cała baza danych i wymagane pliki dzienników zostają sprawdzone pod kątem fizycznej integralności. W przypadku interfejsu API VSS sprawdzanie sum kontrolnych nie może być częścią procesu rzeczywistego wykonywania kopii zapasowej. Dostawca musi sprawdzać fizyczną integralność bazy danych niezależnie od procesu wykonywania kopii zapasowej. Można to zrobić za pomocą narzędzia Eseutil — przed powiadomieniem serwera Exchange o pomyślnym utworzeniu kopii zapasowej lub po nim.

Jeśli sumy kontrolne są sprawdzane przed zakończeniem wykonywania kopii zapasowej i w zestawie kopii zapasowych zostanie znaleziony problem, to serwer Exchange może zostać powiadomiony o niepowodzeniu operacji wykonywania kopii zapasowej. Zapobiegnie to usunięciu plików dzienników z serwera przez program Exchange.

Jeśli sprawdzanie sum kontrolnych zostanie odłożone do czasu po powiadomieniu o pomyślnym utworzeniu kopii zapasowej, to program Exchange usunie starsze pliki dzienników z serwera. Niektóre z tych plików dzienników mogą być potrzebne do wycofania „do przodu” przy wykorzystaniu poprzedniej dobrej kopii zapasowej. Jeśli wcześniej nie wykonano kopii tych dzienników, nie będzie można przeprowadzić całkowitego wycofania „do przodu”.

Dlatego firma Microsoft zaleca, ale nie wymaga, aby sprawdzanie sum kontrolnych dla kopii zapasowej VSS było przeprowadzane, zanim aplikacja wykonywania kopii zapasowych powiadomi program Exchange, że kopia zapasowa została wykonana. Jeśli sprawdzanie sum kontrolnych jest odkładane do czasu po wykonaniu kopii zapasowej, to aplikacja wykonywania kopii zapasowych musi zapewniać wykonywanie kopii zapasowych wszystkich dzienników transakcji, które są usuwane z serwera, chyba że organizacji nie zależy na możliwości całkowitego wycofania „do przodu”.

W większości przypadków wszystkie dzienniki transakcji potrzebne do wycofania „do przodu” kopii zapasowej VSS są dostępne w zestawie plików dzienników zapisanych z poprzednią i bieżącą kopią zapasową. Jednak wybierając dostawcę, klienci muszą się upewnić, że tak będzie.

Przywracanie danych z niesprawdzonych kopii zapasowych

Może się zdarzyć, że awaria wymagająca przywrócenia danych nastąpi przed zakończeniem sprawdzania sum kontrolnych dla ostatniej bazy danych. W takich przypadkach firma Microsoft zaleca, aby zamiast wykorzystywać niesprawdzoną kopię zapasową przywrócić dane z poprzedniej sprawdzonej kopii zapasowej, a następnie wycofać ją „do przodu”.

Klient może być jednak związany umową serwisową wymagającą szybszego przywrócenia danych niż to jest możliwe przy wykorzystaniu poprzedniej kopii zapasowej. W takich przypadkach przywrócenie danych z niesprawdzonej kopii zapasową może być lepszą opcją, o ile zostanie również zachowana poprzednia sprawdzona kopia zapasowa i wszystkie pliki dzienników potrzebne do całkowitego wycofania „do przodu”. Jeśli te wymagania są spełnione, to nadal można wycofać „do przodu” dane z dobrej kopii zapasowej, gdyby się okazało, że ostatnia kopia zapasowa jest zła.

Jak sprawdzić spójność migawki

Obiekt wysyłający żądanie usługi VSS musi sprawdzać spójność migawki, uruchamiając narzędzie Eseutil.exe dla plików baz danych i dzienników z użyciem odpowiednich opcji, przedstawionych w poniższej tabeli. Obiekt wysyłający żądanie usługi VSS musi sprawdzić, czy wszystkie zwrócone wartości ERRORLEVEL są nieujemne. Aby sprawdzić wartość ERRORLEVEL w wierszu polecenia, należy po zakończeniu działania narzędzia Eseutil.exe wpisać polecenie echo %errorlevel%. Ujemna wartość ERRORLEVEL wskazuje, że w plikach istnieje uszkodzenie. Zanim obiekt wysyłający żądanie usługi VSS wywoła polecenie BackupComplete, musi się upewnić, że stan składnika kopii zapasowej w polu Backup Component Document odzwierciedla wynik kontroli spójności. Stanem składnika kopii zapasowej powinien być stan FALSE w przypadku znalezienia uszkodzenia i TRUE w przeciwnym przypadku. Sprawdzanie spójności migawki jest warunkiem obsługi danego rozwiązania przez zespół Exchange.

W poniższej tabeli pokazano kombinację kontroli integralności dla poszczególnych typów kopii zapasowej.
Zwiń tę tabelęRozwiń tę tabelę
Typ pliku\typ kopii zapasowejPełna kopia zapasowaKopia zapasowa typu kopiującegoPrzyrostowa kopia zapasowaRóżnicowa kopia zapasowa
.edb"eseutil /k /i”"eseutil /k /i"BRAKBRAK
.log"eseutil /k" *"eseutil /k" *"eseutil /k" **"eseutil /k" **
.stmBRAKBRAKBRAKBRAK
.chkBRAKBRAKBRAKBRAK

Z powodu „migawkowej” natury kopii zapasowych VSS aparat JET nie ma możliwości przeprowadzenia niezbędnych kontroli wszystkich stron pod względem spójności. Dlatego zapewnienie spójności migawki to obowiązek obiektu wysyłającego żądanie usługi VSS.

* Wszystkie pliki dzienników o numerze generacji pliku dziennika równym lub większym niż numer pliku dziennika w punkcie kontrolnym są wymagane do odzyskania bazy danych migawki. Jeśli istnieje bieżący plik dziennika (Enn.log), jest on również wymagany do odzyskania bazy danych. Jeśli którykolwiek z wymaganych plików dzienników nie przejdzie kontroli spójności, obiekt wysyłający żądanie musi zapewnić, że przed wywołaniem polecenia BackupComplete stan składnika kopii zapasowej zostanie ustawiony jako FALSE. Aby ustalić plik dziennika w punkcie kontrolnym, należy uruchomić narzędzie eseutil.exe dla pliku punktu kontrolnego migawki i przeanalizować dane wyjściowe „Checkpoint”. Na przykład polecenie „c:\eseutil.exe /mk E01.chk” wyświetla następujące informacje:
Checkpoint:  (0x20,9D,187)
gdzie 0x20 to numer generacji dziennika dla pliku dziennika w punkcie kontrolnym.

W tym przykładzie, aby było możliwe odzyskanie bazy danych migawki, żadne pliki dzienników, od E0100020.log włącznie, nie mogą być uszkodzone, nawet jeśli sama baza danych przeszła już kontrolę fizycznej spójności.

** Wszystkie pliki dzienników w zestawie przyrostowych lub różnicowych kopii zapasowych są wymagane do odzyskania bazy danych. Spójność całej sekwencji dzienników można sprawdzić, uruchamiając narzędzie eseutil dla prefiksu pliku dziennika. Na przykład polecenie „eseutil /k E01” uruchamia kontrole spójności wszystkich plików w postaci E01xxxxx.log w danej ścieżce.

Właściwości

Numer ID artykułu: 822896 - Ostatnia weryfikacja: 3 grudnia 2007 - Weryfikacja: 7.6
Informacje zawarte w tym artykule dotyczą:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Standard Edition na następujących platformach
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
    • Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
    • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
    • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Słowa kluczowe: 
kbtshoot KB822896

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