opis konfiguracji przyrostowej kopii bazy danych

Centralny Ośrodek Informatyki Górnictwa S.A.
K S OP
Opis przyrostowej kopii bazy danych
Copyright © 2013 COIG SA
Wszelkie prawa zastrzeżone.
Nieautoryzowane
rozpowszechnianie
całości
lub
fragmentu
niniejszej
publikacji
w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną,
a także kopiowanie na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw
autorskich niniejszej publikacji.
COIG, Logo COIG są znakami zastrzeżonymi firmy COIG SA
Opis przyrostowej kopii bazy danych
__________________________________________________________________
Przyrostowa kopia bazy danych pozwala na minimalizację ilości utraconych danych w
przypadku awarii. W celu wdrożenia rozwiązania należy zmienić typ kopii we
właściwościach bazy, oraz wdrożyć politykę wykonywania kopii z odpowiednią
częstotliwością. Polityka powinna być dostosowana do wewnętrznych potrzeb jednostki,
sugerowane w dokumencie częstotliwości wykonywania kopii są tylko poglądowe. Dokument
przeznaczony jest dla służb informatycznych lub osób posiadających odpowiednie
uprawnienia do wykonywania działań administracyjnych na serwerze.
1. Przestawienie bazy danych w tryb kopii przyrostowej
Wykonanie poniższych czynności zalecamy wykonać, gdy żaden użytkownik nie jest
zalogowany do bazy.
Należy uruchomić program Microsoft SQL Server Management Studio logując się jako
użytkownik posiadający uprawnienia do bazy produkcyjnej systemu KSOP (na przykład
użytkownik „sa”). Po zalogowaniu należy rozwinąć gałąź „Databases” i kliknąć prawym
przyciskiem myszy na bazie systemu KSOP. Z rozwiniętego menu należy wybrać opcję
„Properties”.
Na stronie „Options” należy dla opcji „Recovery model” z rozwijającego się menu
wybrać opcję „Full”
2
Opis przyrostowej kopii bazy danych
__________________________________________________________________
2. Mechanizm wykonywania kopii przyrostowej
Pełna kopia bazy danych wykonywana jest za pomocą skryptu 1_backup_full.bat. W
skrypcie należy poprawić ścieżki, w których będzie zapisywana kopia. Najnowsza kopia
będzie zapisywana pod nazwą full2.bak, poprzednia kopia pod nazwą full1.bak. Kopia
powinna być wykonywana okresowo, na przykład raz w tygodniu, lub raz w miesiącu.
Z bardzo dużą częstotliwością (na przykład co 15 minut) należy wywoływać skrypt
3_backup_log.bat, który do pliku log2.bak zapisuje kolejne logi bazy. W skrypcie znajduje się
ścieżka do lokalizacji, gdzie plik z logami będzie zapisany – zalecamy, aby była to ta sama
lokalizacja, do której zapisywane są pozostałe kopie. Częstotliwość uruchamiania skryptu do
wykonania kopii logów określa maksymalną ilość danych, jaka jest akceptowalna do utraty w
przypadku awarii.
Okresowo można uruchamiać skrypt 2_backup_diff.bat, który zapisuje plik kopii
różnicowej o nazwie diff2.bak. Działanie skryptu nie jest niezbędne dla poprawnej pracy
mechanizmu, jednak w przypadku posiadania kopii różnicowych proces przywracania bazy
może ulec znacznemu skróceniu.
Uruchomienie skryptu 2_backup_diff.bat powoduje powstanie nowego pliku z danymi i
zachowanie nowej kopii różnicowej (poprzednia jest już zbędna, więc jest usuwana). Skrypt
1_backup_full.bat powoduje zmianę nazwy diff2.bak na diff1.bak i analogiczną zmianę nazw
plików z logami. W przypadku braku możliwości wykonania kopii pełnej zakładany jest
katalog z datą bieżącą, do którego są przenoszone logi zapisane od czasu wykonania ostatniej
kopii pełnej.
Skrypty w obecnej formie dopuszczają istnienie do 5 plików z logami, więc między
wykonaniem pełnych kopii bazy danych można maksymalnie 4 razy wykonywać kopie
różnicowe.
Wszystkie operacje wykonywania kopii są logowane do pliku tekstowego log.txt
znajdującego się domyślnie w lokalizacji, w której zapisywane są kopie.
UWAGA
Należy pamiętać, że uszkodzenie lub utrata choćby jednego pliku kopii może
uniemożliwić odzyskanie bazy danych. Uruchomienie mechanizmu jest równoznaczne z
rezygnacją z dotychczasowego sposobu wykonywania kopii – nie można uruchomić
opisanego mechanizmu a jednocześnie wykonywać kopii „na wszelki wypadek” na
obecnych zasadach. Pewnym rozwiązaniem może być wykonywanie kopii plików bazy
danych, jednak odzyskanie takiej kopii następuje poprzez operację „attach”.
Jednostki posiadające płatną wersję MS SQL Server mogą uruchomić automatyczne
wykonywanie kopii w oparciu o wbudowany mechanizm „scheduler”, który jest
zaprojektowany do tego typu zadań. Opisany w niniejszym dokumencie mechanizm tylko
imituje działanie „schedulera”.
3
Opis przyrostowej kopii bazy danych
__________________________________________________________________
3. Konfiguracja harmonogramu zadań
Do wykonywania kopii należy wykorzystać Harmonogram zadań. Dzięki temu kopie
będą wykonywane regularnie w określonych odstępach czasu. W celu wprowadzenia nowego
zadania należy uruchomić Zaplanowane zadania w Panelu Sterowania i uruchomić
funkcjonalność Dodaj zaplanowane zadanie.
W konfiguracji zadania należy kliknąć przycisk [Przeglądaj] i wskazać skrypt, który
powinien być uruchamiany.
Należy określić częstotliwość uruchamiania skryptu oraz wskazać godzinę wywołania.
4
Opis przyrostowej kopii bazy danych
__________________________________________________________________
Niezbędne jest podanie danych użytkownika, który będzie wywoływać zadanie.
4. Postępowanie w przypadku awarii
W momencie stwierdzenia awarii należy zabezpieczyć wszystkie pliki kopii bazy.
Najnowsze kopie mają w swojej nazwie numer 2, kopie wcześniejsze numer 1.
Można ręcznie uruchomić skrypt 3_backup_log.bat, który spowoduje zapisanie do pliku
logów z ostatnich operacji wykonanych na bazie. Odzyskując dane można określić godzinę,
do której mają być odzyskane (ostatni moment, w którym baza była nieuszkodzona).
5
Opis przyrostowej kopii bazy danych
__________________________________________________________________
KONFIGURACJA KSOP
Po uruchomieniu mechanizmu tworzenia kopii przyrostowej należy dostosować
konfigurację KSOP do nowej konfiguracji. W tym celu należy przejść na formatkę
„Konfiguracja systemu” i zweryfikować ustawienie parametru dla systemu „MS_KOPIA –
Tryb pracy serwera bazy danych MS SQLServer (kopia zapasowa)”: powinna być przypisana
wartość „Full Recovery model”.
Mechanizm wykonywania kopii przyrostowych nie zmienia zapisów w bazie mówiących
o dacie ostatnio wykonanej kopii bezpieczeństwa, w związku z czym funkcjonalność
informowania o braku wykonanej kopii przypomina o tym fakcie. Istnieje możliwość
wyłączenia wspomnianej funkcjonalności poprzez zmianę parametru systemowego
„OST_KOPII – Ostrzeżenia o braku kopii zapasowej bazy danych”. Jest to parametr dla stacji
roboczej, wobec czego komunikat może być wyłączony dla poszczególnych stacji, lub można
nową wartość zastosować do wszystkich stacji roboczych.
6
Opis przyrostowej kopii bazy danych
__________________________________________________________________
ODZYSKIWANIE BAZY DANYCH
W celu odtworzenia bazy danych należy w pierwszej kolejności odzyskać ostatnią pełną
kopię (z pliku full2.bkp). W przypadku niemożliwości skorzystania z ostatniej kopii należy
powrócić do wcześniejszej (plik full1.bkp), jednak w tym przypadku odzyskiwanie danych
będzie wiązało się z koniecznością odzyskania większej ilości plików, przez co będzie trwało
dłużej.
Przed uruchomieniem odzyskiwania wersji pełnej, po wskazaniu pliku kopii, należy
zmienić ustawienia domyślne na stronie Options – w sekcji Recovery state należy wybrać
środkową opcję: Leave the database non-operational, and do not roll back uncommitted
transactions.Additional transaction logs can be restored. (RESTORE WITH NORECOVERY)
Po odzyskaniu pełnej kopii bazy, obok nazwy bazy pojawi się status (Restoring…).
Pozostałe kopie należy odzyskiwać przy ustawionym parametrze Leave the database
non-operational…, jedynie ostatni plik należy wczytać z domyślną wartością opcji Recovery
state, czyli Leave the database ready to use by rolling back uncommitted transactions.
Additional transaction logs cannot be restored (RESTORE WITH RECOVERY).
W przypadku istnienia kopii różnicowych można odzyskać dane z ostatniego backupu
(plik diff2.bkp). Jeżeli została odzyskana pełna kopia bazy z pliku full1.bkp należy
wykorzystać kopię różnicową z pliku diff1.bkp.
W celu wczytania backupu różnicowego należy na odzyskanej bazie wybrać z menu
kontekstowego opcję Tasks, następnie Restore i ostatecznie Database… Po wskazaniu pliku
należy zaznaczyć kopię, która ma być odzyskana (powinna być tylko jedna). Kopia różnicowa
zawiera w sobie wszystkie zmiany wprowadzone do bazy od momentu wykonania pełnej
kopii bazy do wykonania wskazanej kopii różnicowej.
7
Opis przyrostowej kopii bazy danych
__________________________________________________________________
Niezależnie od odzyskania danych z kopii różnicowej należy doczytać dane z plików
logów. Na odzyskanej bazie należy wybrać z menu kontekstowego opcję Tasks, następnie
Restore i ostatecznie Transaction Log… Należy wskazać plik logów stworzony po ostatnio
odzyskanej kopii:
•
jeżeli była odzyskana kopia pełna, bez wczytywania kopii różnicowych, należy
wybrać odpowiednio plik log2.bkp (gdy kopia była odzyskana z pliku full2.bkp) lub
log1.bkp w przeciwnym wypadku.
•
jeżeli była odzyskana kopia różnicowa, należy zaznaczyć odpowiednio plik
log2_x.bkp (gdy kopia była odzyskana z pliku diff2.bkp) lub log1_x.bkp w
przeciwnym wypadku. Symbol „x” w nazwie pliku oznacza najwyższy numer z
dostępnych.
Po wybraniu pliku należy wskazać ostatnią kopię, co spowoduje zaznaczenie wszystkich
wcześniejszych pozycji.
W przypadku rozpoczęcia procesu odzyskiwania danych od pliku full1.bkp, należy w
opisany wyżej sposób doczytać dane z wszystkich plików logów log2_x.bkp.
UWAGA
Jeżeli istnieją foldery, których nazwy zawierają w sobie daty, należy przed wczytaniem
logów log2_x.bkp wczytać wszystkie logi z folderów, których daty są późniejsze niż data
powstania wczytanej kopii pełnej, w kolejności ich powstawania. Foldery powstają w
przypadku niepowodzenia powstawania kopii pełnej.
Ostatni plik backupu należy wczytać do systemu przy zaznaczonej opcji pierwszej od
góry Leave the database ready to use by rolling back uncommitted transactions. Additional
transaction logs cannot be restored (RESTORE WITH RECOVERY) w sekcji Recovery state
na stronie Options. W sekcji Restore to można zostawić ustawienia domyślne i odzyskać
wszystkie dane, albo przyciskiem […] wskazać konkretny moment, do którego dane mają być
odzyskane.
UWAGA
Skrypty w obecnej formie powodują przeniesienie plików logów do folderów z datą, w
przypadku wystąpienia problemów z wykonywaniem pełnej kopii bazy danych. W związku z
tym pełna kopia bazy danych powinna być wykonywana nie częściej niż raz dziennie
8