Jak ustawić backup w ERP XL | Artykuł ERP XL

Wstęp

Kopiami bezpieczeństwa (z ang. backup) są odpowiednio przetworzone dane, które służą do odtworzenia danych operacyjnych w przypadku ich uszkodzenia lub utraty. Kopie bezpieczeństwa powinny być przechowywane są w taki sposób, aby ewentualna awaria nie wpłynęła na dostępność tych kopii. 

Główną korzyścią płynącą z przeprowadzania kopii bezpieczeństwa jest niezależność od przypadków losowych, co obejmuje m.in.: uszkodzenie pliku, awarię dysku, nieopatrzne działania użytkowników oraz ataki hackerów sprowadzających się najczęściej do zaszyfrowania danych. 

Istotą poprawnie wdrożonego systemu wykonywania kopii bezpieczeństwa jest zarówno gwarancja ich wykonania jak i odtworzenia. W tym artykule przedstawię różne metody i praktyki związane z wykonywaniem kopii bezpieczeństwa bazy danych Comarch ERP XL.

Tryby pracy bazy danych

Do prawidłowego wdrożenia systemu backupów konieczne jest zrozumienie sposobu trybu pracy samej bazy danych na serwerze MS SQL.

Baza danych ERP XL składa się z co najmniej dwóch plików zlokalizowanych na dysku serwera: głównego pliku bazy danych (rozszerzenie mdf) i pliku tzw. loga (rozszerzenie ldf). Plik główny przechowuje wszystkie informacje zgromadzone w bazie danych, a plik loga przechowuje historię wykonywanych operacji. Te pliki nie są dostępne dla użytkowników bazy, a zarządza nimi program Microsoft SQL Server.

Tryb pracy bazy danych ma wpływ na możliwości odtworzenia jej kopii zapasowej. Dostępne są dwa tryby: Simple i Full:

• Simple. Bazę danych można odtworzyć tylko na podstawie ostatniej kopii zapasowej. Plik loga przechowuje tylko ostatnie operacje, które nie mieszczą się w pamięci podręcznej w czasie wykonywania poleceń na serwerze. Dzięki temu jest on automatycznie czyszczony i zawsze zajmuje minimalny rozmiar na dysku. Można stosować ten tryb w przypadku baz danych, które nie wymagają archiwizacji (np. baza testowa), czyli jest absolutnie niezalecany dla operacyjnej bazy danych ERP XL.
• Full. Pozwala na odtworzenie bazy danych od konkretnego punktu w czasie. Plik loga przechowuje wszystkie operacje wykonywane na bazie danych od czasu wykonania ostatniej kopii zapasowej tego pliku (wykonanie kopii zapasowej bazy teoretycznie powoduje wyczyszczenie loga). Praca na bazie ustawionej w tym trybie będzie powodować stałe rozrastanie się pliku loga, co może spowodować zapełnienie dostępnego miejsca na dysku i w wyniku tego zaprzestanie działania bazy danych.

Aby sprawdzić lub zmienić ustawienia trybu pracy bazy danych należy otworzyć właściwości wybranej bazy danych w programie SQL Server Managment Studio i przełączyć się na zakładkę Opcje:
 

Nawiasem mówiąc przełączenie bazy z trybu Full na tryb Siple stanowi dobrą metodę na usunięcie pliku loga w trybie awaryjnym, gdy zabraknie miejsca na dysku. 

Odtworzenie bazy do wskazanego punktu w czasie

Mimo ryzyka zapełnienia dysku przez plik loga tryb full recovery mode jest zalecany dla operacyjnej bazy ERP XL. Daje on szansę na odtworzenie kopii zapasowej bazy danych tuż przed wystąpieniem awarii. Jak to zrobić?
Należy dysponować ostatnią pełną kopią bazy danych i plikiem loga, który zapełnił się od czasu wykonania tej kopii. Jeśli plik kopii nie został przeniesiony to program będzie widział jego lokalizację. W oknie odtwarzania bazy danych należy kliknąć przycisk Timeline, co spowoduje otwarcie okna z osią czasu.
 

Zgodnie z dokumentacją Microsoft plik kopii bazy danych w trybie full recovery mode zawiera w sobie również log i wskazanie go jest wystarczające do odtworzenia bazy danych do wskazanego punktu w czasie. W praktyce warto jest jednak oddzielnie wykonywać kopię loga, aby mieć później możliwość wskazania go, gdyby okazało się, że oś czasu nie jest dostępna.

Kopia loga

Dobrą praktyką jest wykonywanie dodatkowej kopii zapasowej loga. Zabezpiecza to przed następstwami awarii bazy, gdzie uszkodzeniu ulega zarówno plik bazy jak i plik loga. Mając kopię loga możliwe jest odtworzenie kopii bazy danych od ostatniego pełnego backupu i odtworzenie jej do wskazanego punktu w czasie na podstawie kopii logów. Kopia loga powinna być wykonywana możliwie często, na przykład co godzinę.
Zautomatyzowanie procesu kopii loga umożliwia narzędzie Maintenance Plans w programie MS SQL Managment Studio:

Dodatkową korzyścią kopii loga jest automatyczne zwalnianie pliku loga bazy danych, co ogranicza jego rozmiar na dysku. Stare kopie loga należy jednak usuwać, gdy dostępny jest pełny backup bazy pokrywający się z tymi kopiami.

Kopia strategiczna i operacyjna

Harmonogram kopii oparty o funkcję wykładniczą

Miejsce przechowywania kopii

Przy wdrażaniu systemu backupów należy zastanowić się nad doborem odpowiednich komponentów sprzętowych wystarczających dla konkretnego rozwiązania. 

Jak już wcześniej wspominałem, przy kopiach operacyjnych dane przechowujemy lokalnie na serwerze. Tutaj możemy wybrać pomiędzy dyskiem HDD lub SSD. Przewagą tradycyjnych dysków HDD jest pojemność w atrakcyjnej cenie lecz kosztem prędkości zapisu oraz odczytu. Dlatego w momencie jeżeli tworzymy kopie po godzinach pracy i nie zależy nam na prędkości ich wykonywania, dysk HDD jest tutaj świetnym wyborem. Dodatkowo przeważnie dyski HDD mają większą żywotność od SSD. W scenariuszu kiedy potrzebujemy przetwarzać większe ilości danych, lepszym wyborem okaże się dysk SSD. 

W momencie tworzenia kopii strategicznych, również w zależności od ilości przechowywanych danych możemy użyć dysków przenośnych lub nawet pendrive. W tym momencie kierujemy się parametrami oraz testami danego sprzętu. Lepszym rozwiązaniem jest użycie dysków sieciowych NAS lub chmury. Przy użyciu dysku NAS również musimy zastanowić się czy będziemy używać dysków HDD czy SSD, pamiętając oczywiście żeby używać dysków w technologii przynajmniej RAID 1, czyli tak zwanego mirroringu.  Chmura okazuje się również atrakcyjnym wyborem, ze względu na jeszcze mniejsze prawdopodobieństwo utraty danych.

Comarch IBARD

Prostą i szybką metodą tworzenia kopii jest skorzystanie z programu Comarch IBARD. Aplikacja pozwala na tworzenie harmonogramów oraz planów kopii, po czym każda kopia zapisywana jest na serwerach Comarch. Zapewnia to nam pewną gwarancję dostępności oraz bezpieczeństwa naszych danych.

Zrzuty ekranu panelu do tworzenia harmonogramów w IBARD:

Podsumowanie

Baza danych narażona jest na różnego rodzaju awarie: uszkodzenie dysku z bazą, uszkodzenie całego serwera, zaszyfrowanie dysków przez hackera, błędy ludzkie. Jeden rodzaj kopii zapasowej nie zabezpiecza wszystkich przypadków. Dlatego warto stosować się do następujących zasad:

• Utrzymuj bazę w trybie full recovery mode, co w razie awarii bazy pozwoli odtworzyć ją do momentu sprzed awarii
• Regularnie kilka razy dziennie twórz operacyjną kopię pliku loga, co w razie awarii dysku z bazą i logiem pozwoli odtworzyć bazę do momentu kopii ostatniego loga.
• Kopie operacyjne przechowuj na oddzielnym dysku, niż plik z bazą danych. W razie awarii dysku z bazą będziesz nadal posiadał kopie.
• Kopie strategiczne utrzymuj poza serwerem. W razie awarii serwera będziesz mógł odtworzyć bazę z poprzedniego dnia.

Na koniec jeszcze jedna ważna zasada: tworzenie kopii, których nie da się odtworzyć w rozsądnym czasie nie niesie żadnej wartości. Sprawdź czy jesteś w stanie odtworzyć kopie bazy. 

Zarządzanie kopiami bezpieczeństwa jest jednym z tematów poruszanych przeze mnie na szkoleniu z Zaawansowanej Administracji Comarch ERP XL, na które zapraszam.

Ponadto w ramach oferty Prospeo świadczymy dla Państwa usługi wdrożenia systemu kopii zapasowych potwierdzonych certyfikatem bezpieczeństwa.