Odpowiedzi:
Przesyłanie dziennika nie jest scenariuszem zapasowym. Jest to scenariusz o pół wysokiej dostępności.
W przypadku kopii zapasowych istnieją pełne, różnicowe i dzienniki transakcji. Wszystkie powinny być używane razem. Twoja umowa SLA określa, jak z nich korzystasz. Najbardziej typowe scenariusze to pełna kopia zapasowa, powiedzmy o północy, różnicowa kopia zapasowa w południe i kopie zapasowe dziennika transakcji co 30 lub 15 minut.
I pamiętaj: nie masz prawidłowej kopii zapasowej, dopóki jej nie przywrócisz, aby sprawdzić, czy jest w porządku.
Prawdopodobnie nie ma takiej koncepcji, jak strategia tworzenia kopii zapasowych: masz strategię przywracania , ponieważ określa ona czas, po którym powrócisz do pracy *.
Wszystkie strategie wymagają pełnej kopii zapasowej, aby oprzeć wszelkie późniejsze przywracanie różnicowych i / lub dzienników kopii zapasowych.
W praktyce możesz mieć pełną kopię zapasową sprzed 6 miesięcy z 15-minutowymi kopiami zapasowymi dziennika: jednak musisz zastosować każdą kopię zapasową dziennika od ostatniej pełnej.
Jako przypadkowy przykład jeden scenariusz może być pełny co tydzień, różnicowy codziennie, rejestrować 15 minut.
Interwał tworzenia kopii zapasowej określa, ile danych stracisz w najgorszym przypadku: 15-minutowe kopie zapasowe dziennika powodują utratę danych od 1 sekundy do 14 minut 59 sekund, średnio 7,5 minuty. Czy to jest dopuszczalne?
Przesyłanie dziennika jest w trybie gotowości z ręcznym przełączaniem awaryjnym: nie jest to kopia zapasowa, ale opcja wysokiej dostępności.
Nie ma jednej strategii, która pasowałaby do każdej sytuacji. Ale ważne jest, aby zrozumieć, co masz do dyspozycji. Pełne kopie zapasowe są dokładnie tak, jak brzmią: pełna kopia zapasowa bazy danych, bez dziennika transakcji. Różnicowe kopie zapasowe to kopie zapasowe zmian w plikach danych od ostatniej pełnej kopii zapasowej. Kopie zapasowe dziennika transakcji utworzą kopię zapasową wszystkich transakcji zapisanych w dzienniku transakcji od ostatniej kopii zapasowej dziennika transakcji. Kopie zapasowe dziennika transakcji umożliwiają przywrócenie do określonego momentu. Jeśli jest to wymagane, musisz ustawić tryb odzyskiwania na „Pełny” i będziesz musiał regularnie wykonywać kopie zapasowe dziennika transakcji w zależności od tego, ile danych chcesz stracić w przypadku sytuacji odzyskiwania.
Podczas wykonywania kopii zapasowych dziennika transakcji ważne jest, aby zrozumieć, czym jest łańcuch dziennika. Moim zdaniem łańcuch dziennika to seria kopii zapasowych, które należy przywrócić, aby przywrócić bazę danych do określonego punktu w czasie. Aby rozpocząć przywracanie dzienników transakcji, musisz najpierw przywrócić pełną kopię zapasową za pomocą opcji Z NORECOVERY. Jeśli wykonujesz także różnicowe kopie zapasowe, będziesz chciał przywrócić najnowszą różnicową kopię zapasową przed momentem, w którym chcesz przywrócić korzystanie z tej samej opcji Z NORECOVERY. W tym momencie musisz przywrócić kopie zapasowe dziennika transakcji, sekwencyjnie, używając opcji Z NORECOVERY na wszystkich kopiach oprócz ostatecznej kopii zapasowej. Aby uzyskać więcej informacji na temat przywracania punktu w czasie, sprawdź ten link. http://msdn.microsoft.com/en-us/library/ms175093.aspx
Jak wspomniano, Log Shipping nie jest strategią tworzenia kopii zapasowych, ale może znacznie skrócić czas przywracania w przypadku odzyskiwania po awarii. Należy zwrócić uwagę na to, że wszelkie publikacje dotyczące replikacji będą musiały zostać napisane w skrypcie na serwerze Log Shipping i zainicjowane, aby replikacja działała tak jak przed katastrofą. W przypadku większych publikacji może to spowodować znaczny wzrost czasu przywracania do poziomu produkcji.
Mam nadzieję że to pomoże,
Matt
Ja drugi Mladen Prajdic. Ten artykuł pomoże Ci wybrać właściwą strategię tworzenia kopii zapasowych w zależności od modelu wyszukiwania baz danych.
nie są to strategie tworzenia kopii zapasowych dla SQL Server. Pełne i różnicowe kopie zapasowe to typy kopii zapasowych, które można wykonać w bazie danych SQL Server, podczas gdy Log Shipping to strategia wysokiej dostępności (poprzez przenoszenie kopii zapasowych dziennika w zaplanowanym czasie z serwera na inny i synchronizację tych 2 baz danych do limit twoich kopii zapasowych).
Ładne informacje na temat odzyskiwania po awarii (tworzenie kopii zapasowych i przywracanie :-)) można znaleźć w witrynie MSDN: tutaj i tutaj . Krótko mówiąc, musisz wybrać, ile danych możesz odzyskać z kopii zapasowych w przypadku awarii. Dobrym przykładem strategii tworzenia kopii zapasowych będzie pełna kopia zapasowa każdego dnia i zapisywanie kopii zapasowych co godzinę (zależy to od twoich potrzeb), więc w takim przypadku będziesz w stanie przywrócić bazę danych z pełnej kopii zapasowej + wszystkie dzienne kopie zapasowe dziennika.
Kolejne miłe odniesienie na temat DR można znaleźć na Simple_Talk .
Oczywiście nie tylko musisz przywrócić bazę danych, ale odzyskiwanie odbywa się w kontekście serwera i aplikacji, której część stanowi baza danych. Jeszcze go nie używałem, ale Data Protection Manager chce wykonać bardziej kompleksową pracę, jeśli jej potrzebujesz.
Najlepszym sposobem jest użycie wszystkich trzech typów kopii zapasowych. Oczywiście można zignorować różnicową kopię zapasową kopii dziennika transakcji. Wszystko zależy od bazy danych, jej szybkiego wzrostu, częstotliwości dokonywania zmian w bazie danych i innych. Zanim wybierzesz plan tworzenia kopii zapasowych, zastanów się, ile danych chcesz stracić? Ile czasu jesteś gotów poświęcić na odzyskanie bazy danych?
Na przykład: jeśli baza danych szybko się rozwija, możesz użyć następującej strategii tworzenia kopii zapasowych programu SQL Server: pełna kopia zapasowa - raz dziennie, różnicowe kopie zapasowe - co dwie godziny i kopie zapasowe dziennika transakcji - co 20 minut. W takim przypadku, jeśli wystąpi awaria, stracisz nie więcej niż 19 minut pracy. Kolejny przykład, jeśli powolny wzrost bazy danych, możesz wykonać pełną kopię zapasową raz dziennie, różnicową kopię zapasową co sześć godzin i co godzinę wykonać kopię zapasową dziennika transakcji.
Jeszcze jedna wskazówka - aby mieć pewność, że baza danych jest bezpieczna, od czasu do czasu przywracaj kopie zapasowe na serwerze testowym.