Centralny Ośrodek Informatyki Górnictwa S.A. KSOP 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
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
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
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
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
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
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
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