Zrozumienie wpływu / ryzyka wyłączenia „weryfikacji integralności kopii zapasowej” na kopii zapasowej SQL

Obecnie korzystamy ze standardowych planów konserwacji kopii zapasowych na serwerach SQL Server 2005/2008 / 2008R2 / 2012 w naszym środowisku, a pole „Zweryfikuj integralność kopii zapasowej” zawsze było zaznaczone.

Niektóre kopie zapasowe działają bardzo długo, dlatego zaleciłem wyłączenie tej opcji, ale zarząd potrzebuje mnie do udokumentowania wpływu i ryzyka tej zmiany.

Rozumiem użycie i historię tej opcji, po prostu wydaje mi się, że nie ma potrzeby podwajania czasu wykonywania kopii zapasowej, kiedy (moim zdaniem), każdy błąd, który prawdopodobnie wystąpi, wystąpi na etapie tworzenia kopii zapasowej , a nie podczas weryfikacji.

Czy się mylę? Czy wyłączenie tego ryzyka jest minimalne, jeśli tworzę kopię zapasową na dysku, a nie na strumieniowej taśmie? (Tworzymy kopię zapasową przez sieć na urządzeniu do tworzenia kopii zapasowych EMC DD-800, jeśli jest to istotne).

Czy istnieją jakieś oficjalne zalecenia państw członkowskich dotyczące bezpiecznego wyłączenia tego urządzenia?

Czy uruchamiasz „weryfikuj” na każdej kopii zapasowej w swoim środowisku? Sprawdzasz je na miejscu?

EDYCJA : Aby to wyjaśnić, po zaznaczeniu opcji „weryfikuj integralność kopii zapasowej” w planie konserwacji, SQL wykona pełny WERYFIKOWANY PRZYWRACANIE każdej bazy danych natychmiast po każdej kopii zapasowej. Jest to tak samo intensywne w zakresie danych / operacji we / wy, jak oryginalna kopia zapasowa i (w zasadzie) podwaja całkowity czas wykonywania kopii zapasowej. To nie jest to samo, co włączenie opcji „suma kontrolna” podczas tworzenia kopii zapasowej (o ile wiem, nie można tego zrobić w kreatorze).

Czy się mylę? Czy wyłączenie tego ryzyka jest minimalne, jeśli tworzę kopię zapasową na dysku, a nie na strumieniowej taśmie?

Nie, masz rację :-)

RESTORE VERIFYONLYtylko nie zapewni, że będziesz w stanie odzyskać bazę danych w przypadku uszkodzenia. Z natury nie będzie przeprowadzać żadnych kontroli integralności.

Lepszym sposobem będzie okresowe wykonywanie kopii zapasowych i wykonywanie prawidłowego przywracania na innym serwerze i wykonywanie na nim DBCC CHECKDB.

Jest to jeden z powodów, dla których nie jestem wielkim fanem planów konserwacji, ponieważ GUI nie ujawnia wielu takich opcji, backup .. with CHECKSUMktóre można uzyskać za pomocą T-SQL.

Z bloga Myth Paula Randala

24p) przy użyciu PRZYWRACANIA… Z WERYFIKOWANYM sprawdza poprawność całej kopii zapasowej

Nie. Używanie VERIFYONLY tylko sprawdza, czy nagłówek kopii zapasowej wygląda jak nagłówek kopii zapasowej. Tylko wtedy, gdy wykonasz kopię zapasową za pomocą WITH CHECKSUM i wykonasz PRZYWRÓCENIE… Z VERIFYONLY i używając WITH CHECKSUM, przywracanie wykonuje bardziej rozbudowane kontrole, w tym sumę kontrolną całej kopii zapasowej.

Czy uruchamiasz „weryfikuj” na każdej kopii zapasowej w swoim środowisku? Sprawdzasz je na miejscu?

Nie uruchamiam VERIFYONLY. Zamiast tego biorę kopię zapasową za pomocą CHECKSUM, a następnie przywracam je + CHECKDB na innym serwerze. Jeśli chcesz być kreatywny, możesz zastosować metodę statystycznego próbkowania do weryfikacji kopii zapasowych baz danych .

To nie jest to samo, co włączenie opcji „suma kontrolna” podczas tworzenia kopii zapasowej (o ile wiem, nie można tego zrobić w kreatorze).

Możesz włączyć Trace Flag 3023, aby CHECKSUMopcja była automatycznie włączona dla polecenia BACKUP. Jak zawsze przetestuj zachowanie wszelkich flag śledzenia w swoim środowisku!

Najważniejsze jest - plany konserwacji rowów i skorzystaj z bardziej sensownego rozwiązania do tworzenia kopii zapasowych (wskazówka: rozwiązanie do tworzenia kopii zapasowych Oli) , które pozwoli Ci dostosować je do własnych potrzeb.

(Tworzymy kopię zapasową przez sieć na urządzeniu do tworzenia kopii zapasowych EMC DD-800, jeśli jest to istotne).

Utwórz kopię zapasową lokalnie na dysku, a następnie wykonaj zadanie przesyłania PowerShell, które skopiuje kopię lokalnie z serwera do udziału sieciowego (serwer kopii zapasowej). Będzie to szybsze niż bezpośrednie kopiowanie do udziału sieciowego.

Włącz także natychmiastową inicjalizację plików, co pomoże w automatycznym powiększaniu plików danych, a także skróci czas przywracania (w przypadku konieczności przywrócenia baz danych). Zawsze dobrze jest mieć pod ręką opcje.

Dobry tekst to: Kopie zapasowe: planowanie strategii odzyskiwania

Najważniejsze jest to, że dopóki nie dokonasz przywrócenia bazy danych, nie możesz być całkowicie pewien, że dany plik kopii zapasowej jest dobry.

Idealnym testem do weryfikacji kopii zapasowych jest skonfigurowanie środowiska, w którym kopie zapasowe bazy danych i kopie zapasowe dziennika bazy danych są przywracane przez cały czas w ramach codziennego procesu. Jest to jedna z zalet korzystania z log-shipping ...

Jeśli nadal chcesz pozostać przy weryfikacji, możesz skonfigurować środowisko specjalnie po to, aby to zrobić. Spowodowałoby to odciążenie pracy (prawdopodobnie) serwera produkcyjnego i skrócenie czasu pracy.

Wreszcie, czy zastanawiałeś się nad odejściem od planów konserwacji? Skrypty, takie jak skrypty Oli, są wyjątkiem do tworzenia kopii zapasowych i konserwacji: https://ola.hallengren.com/

Z technicznego punktu widzenia przywracanie jest podobne do przywracania, jednak nie ma lepszego sprawdzenia, czy rzeczywiście przywracanie bazy danych w celu sprawdzenia jej prawidłowej kopii zapasowej. Mieliśmy instancję, w której weryfikacja została pomyślnie zakończona, jednak baza danych nie mogła zostać przywrócona z powodu uszkodzenia, nie mam jednak na to znaczenia, ponieważ weryfikacja kopii zapasowej jest prawidłowa. Opracowaliśmy teraz system, który przywraca wszystkie nasze bazy danych w osobnej instancji, aby sprawdzić ich ważność, najwyraźniej nie zawsze jest to możliwe, więc spróbuj próbkować określoną bazę danych na tydzień. Długie i krótkie nie ufają wyłącznie 100%.