O sprawności i testach kopii zapasowej

Wyobraźmy sobie sytuacja. Słoneczny lipiec, w samochodzie w pełni zadowolona rodzina zmierzająca na wyczekiwane wakacje. Po dobry kilkunastu kilometrach coś nie gra, konieczny postój. Niby nic takiego, tylko przebita opona.

I tutaj nasuwa się pytanie, kiedy ostatnio zaglądałeś na swoją zapasówkę w aucie? Masz w ogóle koło zapasowe czy zestaw naprawczy? Jeśli zestaw to czy wiesz jak go użyć? Szczerze, ja nie wiem.

Pewnie się teraz zastanawiasz, co ma przebita opona do kopii zapasowej, a no ma. Z kopiami jest podobnie, nie wystarczy, że je mamy. Muszą być sprawne i „odtwarzalne” w najmniej spodziewanym momencie. Poniżej kilka opcji, co można zrobić, aby o nie zadbać.

CHECKSUM

Pierwszą rzeczą i najmniej wymagającą jest umieszczenie CHECKSUM do poleceń wykonujące kopie zapasowe.

Dodanie CHECKSUM powoduję zapis sumy kontrolnej dla każdej strony w pliku kopii zapasowej. Podczas odtwarzania wartości te są ponownie wyliczane dla odtwarzanych stron  i porównywane z wartością zapisanymi w kopii zapasowej. Jeśli wartości te nie zgadzają się odtworzenia zostaje przerwane.

Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x8a4c329c; actual: 0x7a14b77c).
It occurred during a read of page (1:274) in database ID 28 at offset 0x00000000874000 in file
‚D:\SQLDATA\BackupFull.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Wyliczanie sumy kontrolnej, powoduję dodatkowe obciążenie dla procesora. Może to się przełożyć minimalnie na szybkość a w konsekwencji  na czas tworzenia kopii zapasowej.

Dodatkowo należy pamiętać, że wykonana kopia z CHECKSUM nie gwarantuje, że baza danych jest wolna od korupcji (temat na inny wpis). Daje jednak pewność, że nie wystąpiło uszkodzenie stron w trakcie odczytu z kopii i zapisu na dysk docelowy. Jeśli nie stosujesz CHECKSUM w poleceniu tworzenia kopii zapasowej to warto zacząć.

Dla instancji od SQL Server  2012 sterując ustawieniem backup_checksum_default możemy włączyć lub wyłączyć globalnie sumy kontrolne podczas tworzenia kopii zapasowej i przywracania. Dodając do parametrów uruchomienia flagę 3023 dla starszych wersji SQL Server, uzyskamy identyczny efekt.

RESTORE VERIFYONLY

Gdy posiadamy kopie zapasową wraz sumą kontrolną to należałby je weryfikować. W tym celu można posłużyć się poleceniem RESTORE VERIFYONLY, które sprawdzi kopie, ale co ciekawe bez jej faktycznego przywracania. Celem tego polecenia jest możliwie jak najbliżej odwzorowania rzeczywistej operacji przywracania, podczas której weryfikuje się:

  • możliwość odczytu kopii zapasowej z źródła,
  • niektóre pola nagłówka stron,
  • sume kontrolną jeśli została naliczona podczas backupu,
  • ilość wolnego miejsca wymaganego do odtworzenia kopii

Za pomocą tego polecenia jesteśmy wstanie sprawdzić kopie pełne, różnicowe oraz logi transakcyjnego. Jednak każdą z osobna bez możliwości sprawdzenia zachowania łańcucha kopii zapasowych co jest mega istotne. RESTORE VERIFYONLY również jak CHECKSUM nie daje gwarancji, że nasze dane nie są uszkodzona. Nie do tego to służy.

RESTORE DATABASE

Tak, dokładnie, odtworzenie bazy danych. To jest jedyna droga aby w pełni weryfikować kopie zapasowe. Najlepiej cyklicznie w zautomatyzowany sposób, odtwarzając kopie pełne, różnicowe oraz logi transakcyjne sprawdzając to wyżej wymieniony łańcuch

Wszystko pięknie ale jak to zrobić? Zaraz Ci pokaże ale najpierw…

DBATOOLS

Mało prawdopodobne, że nie natknąłeś się na dbatools, ale jeśli nie to najwyższy czas. Jest to darmowy moduł PowerShell zawierający ponad 350 instrukcji SQL Server dotyczących najlepszych praktyk, administracji, rozwoju i migracji. Obecnie zawiera funkcje dla takich komponentów SQL Server, takie jak SSIS, SSRS i SSAS.

Aby go pobrać należy wywołać jedno z polecenie w zależności od tego, na jakim systemie operacyjnym pracujemy.

Test-DBALastBackup

Dokładnie to polecenie zrobi za nas całą „robotę”:

  • Pobierze informacje o ostatnich pełnych kopiach z serwera źródłowego,
  • Odtworzy kopie w lokalizacji docelowej, gdzie domyślnie baza będzie miała nazwę „dbatools-testrestore-$databaseName”,
  • Odtworzy  kopie różnicową oraz kopie logów transakcyjnych jeśli istnieją,
  • Wykona polecenie DBCC CHECKDB w celu sprawdzenia integralności danych,
  • Na końcu usunie baza danych „dbatools-testrestore-$databaseName”

Polecenie Test-DBALastBackup opakowałem w funkcji w której również korzystam z poleceń Out-DbaDataTabel oraz Write-DbaDataTable do zapis wyniku do bazy danych.

Wykorzystując ten skrypt realizuję odtworzenie z kilku serwerów, kilkunastu baz danych. Aby nie sprawdzać za każdym razem rezultatów, wykorzystuję zapisane dane do bazy do wysyłki raportu z wynikami poszczególnych zadań które również stanowi potwierdzenie wykonywania cyklicznych testów kopii dla regulatorów.

Co dalej?

Zastanów się czy to co napisałem i to czym się podzieliłem jest dla Ciebie przydatne i jeśli tak to spróbuj to zastosować u siebie. Jeśli masz jakieś pytanie, to chętnie pomogę.

Z pasją poświęcam czas na zdobywanie wiedzy w zakresie szeroko rozumianej Data Platform. Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *