12 typowych błędów podczas tworzenia kopii zapasowych baz danych

Autor: Alexey Kovyazin, 11 listopada 2015

Pobierz PDF (angielski) Ten artykuł był początkowo adresowany do deweloperów i administratorów systemu DBMS Firebird, ale kontakty z administratorami innych baz danych jasno pokazały, że większość błędów jest wspólna również dla nich i dosłownie każdy potyka się o niemal te same kamienie. Jeśli możesz coś dodać do tej listy (nawet coś specyficznego dla konkretnego DBMS), skontaktuj się z nami przez nasz e-mail [email protected].

1. Usuwanie poprzedniej kopii zapasowej przed utworzeniem nowej kopii zapasowej

Ten błąd jest najczęstszy wśród nowicjuszy, którzy nie zdają sobie sprawy, że głównym celem kopii zapasowej bazy danych nie jest tylko utworzenie kopii bazy danych, ale zapewnienie, aby przestój systemu informatycznego (którego ważną częścią jest baza danych) był jak najkrótszy.

W rezultacie system pozostaje niechroniony od momentu usunięcia najnowszej kopii zapasowej do momentu utworzenia nowej, ponieważ w tym okresie baza danych nie ma ani jednej kopii zapasowej. Ponieważ utworzenie kopii zapasowej może zająć sporo czasu, to idealny moment, aby prawo Murphy’ego zadziałało. To podejście sprawdza się szczególnie dobrze w połączeniu z problemem 7 (patrz poniżej).

Zalecenia: nie usuwaj poprzedniej kopii zapasowej przed utworzeniem nowej! (i nie twórz nowej kopii zapasowej do istniejącego pliku).

Zalecenie dla Firebird: Narzędzie FBDataGuard dołączone do HQbird (zaawansowanego pakietu dystrybucyjnego Firebird) usuwa najwcześniejszą kopię zapasową w historii dopiero po utworzeniu nowej.

2. Nadpisywanie istniejącej bazy danych podczas przywracania jej z kopii zapasowej

Ten błąd jest rzadszy, choć skutki mogą być znacznie gorsze. Jeśli kopia zapasowa nie została zweryfikowana i okaże się uszkodzona (patrz problem 6), nie będziesz mieć ani poprzedniej kopii bazy danych, ani ważnej kopii zapasowej.

Taki bałagan zdarza się zwykle w piątkowy wieczór, gdy panuje pośpiech, a polecenia kierownictwa są nieco sprzeczne. Trochę pecha i leniwy weekend w serwerowni masz zapewniony.

Firebird ma pewnego rodzaju ochronę przed tym błędem — nie będzie możliwe przywrócenie bazy danych z kopii zapasowej za pomocą narzędzia gbak, jeśli jego domyślny przełącznik -create jest włączony, a podana nazwa pliku wskazuje na istniejącą bazę danych. Niestety, istnieje sposób obejścia tej ochrony: przełącznik -rep nadal pozwala nadpisać istniejący plik.

Zalecenie: nigdy nie nadpisuj pliku działającej bazy danych bez pisemnego polecenia od kierownictwa.

Zalecenie dla Firebird: Używaj FBDataGuard, ponieważ nigdy nie nadpisuje pliku bazy danych.

3. Używanie jednostopniowego tworzenia kopii zapasowej/przywracania bez użycia pośredniego pliku kopii zapasowej

Standardowe strumienie wejścia/wyjścia umożliwiają zrobienie zabawnego triku z wieloma DBMS (w tym Firebird): zaimplementowanie strumieniowej kopii zapasowej z jednoczesnym przywróceniem z niej bazy danych. W rezultacie nie jest tworzony żaden pośredni plik kopii zapasowej. Jest to wygodne do rutynowej konserwacji i do uruchamiania testowej operacji przywracania (pod warunkiem, że dostępna jest inna kopia zapasowa), ale nie wolno używać tego do automatycznego tworzenia kopii zapasowych!

Na przykład, jeśli podczas tego procesu tworzenia kopii zapasowej/przywracania wystąpi poważna awaria dysku, początkowa baza danych może zostać uszkodzona, podczas gdy nowa baza danych nie została jeszcze utworzona. Oczywiście, jeśli weźmiesz pod uwagę problem 1 i istnieje kopia bazy danych z poprzedniej próby, utracone zostaną tylko dane utworzone lub zaktualizowane w bazie danych po utworzeniu tej kopii.

Zalecenia: nie używaj jednostopniowego tworzenia kopii zapasowej/przywracania w trybie automatycznym i zawsze sprawdzaj dostępność wystarczająco aktualnej kopii w trybie ręcznym.

4. Przechowywanie kopii zapasowych i bazy danych na tym samym urządzeniu fizycznym

Wielu z was może uznać za zabawne, że udzielana przez nas rada jest niejako dziecinna — abecadło tworzenia kopii zapasowych. Racja, to prawda, ale baza danych i dysk mogą ostatecznie znaleźć się na jednym systemie przechowywania danych z powodu popularności środowisk wirtualnych. I z pewnością zawiedzie w najbardziej nieodpowiednim momencie. Do tego wciąż są ludzie, którzy wierzą, że nic nie może się stać z ich danymi, jeśli używają macierzy RAID (wersja 1 lub wyższa :)). Poza tym są ludzie, którzy wierzą, że niektóre serwery „markowe" są niezawodne, ale to szczególny przypadek.

Zalecenia: nie przechowuj kopii zapasowych i bazy danych na jednym urządzeniu, niezależnie od tego, jak niezawodne może się to wydawać.

5. Brak kontroli nad pomyślnym zakończeniem procesu tworzenia kopii zapasowej

To dość częsty błąd zarówno wśród administratorów, jak i szefów działów IT. Jeśli nie sprawdzasz wyników procesu tworzenia kopii zapasowej, równie dobrze możesz go w ogóle nie wykonywać. Musisz otrzymywać powiadomienia o pomyślnie zakończonym procesie tworzenia kopii zapasowej przez e-mail lub, jeszcze lepiej, także przez SMS. A brak takich powiadomień jest oznaką problemu!

Uważny czytelnik, który dotarł do tego miejsca w naszym artykule (choć na nagrodę za to jest jeszcze za wcześnie), może zapytać: „Ale co to ma wspólnego z kierownictwem?" Oto co — administrator zwykle konfiguruje proces tworzenia kopii zapasowej, ale uważa, że sprawdzanie powiadomień jest zbyt nudne, zwłaszcza gdy są przechowywane w osobnym folderze, więc nigdy nie zaszkodzi poprosić o dodatkowe raporty o stanie procesu. To odpowiada na pytanie, kto jest winny, gdy wydaje się, że kopie zapasowe były, ale w rzeczywistości nie ma ich w momencie, gdy ich potrzebujesz :)

! w połączeniu z problemem 2 nie mamy ani bazy danych, ani jej kopii zapasowej.

Zalecenia: używaj narzędzi automatyzacji tworzenia kopii zapasowych, które mogą monitorować udane i nieudane procesy tworzenia kopii zapasowych, powiadamiać użytkowników o problemach i oferować narzędzia kontroli zbiorczej (jest to szczególnie istotne, gdy trzeba kontrolować dziesiątki i setki procesów tworzenia kopii zapasowych na różnych serwerach).

Zalecenie dla Firebird: FBDataGuard sprawdza, czy proces tworzenia kopii zapasowej został zakończony, i wysyła odpowiednie powiadomienie. Dla systemów z dużą liczbą baz danych dostępny jest drugopoziomowy monitoring zbiorczy za pomocą narzędzia Control Center, które pozwala zobaczyć statusy wszystkich monitorowanych serwerów i baz danych na jednej stronie.

6. Brak walidacji kopii zapasowej

Fakt, że kopie zapasowe są gdzieś przechowywane, nie oznacza, że można je stamtąd odczytać.

Dlatego musisz regularnie weryfikować tworzone kopie zapasowe, aby upewnić się, że nie są uszkodzone ani skopiowane do /dev/null.

Zalecenie dla Firebird: możesz zautomatyzować walidację kopii zapasowych za pomocą FBDataGuard.

7. Brak kontroli stanu bazy danych podczas używania niezweryfikowanych kopii zapasowych

Zwykle bazy danych używają kilku rodzajów kopii zapasowych — zrzutów, zwykłych kopii zapasowych itp. Nie wchodząc w szczegóły, możemy wyróżnić dwie kategorie: zweryfikowane i niezweryfikowane. W przypadku Firebird są to gbak i nbackup.

Gbak odczytuje całą bazę danych na poziomie rekordów w celu utworzenia pliku kopii zapasowej i tworzy bazę danych, wstawiając rekordy do nowej bazy danych, weryfikując w ten sposób kopię zapasową (istnieją sposoby, aby błędy wkradły się do przywróconej kopii, ale to inny sposób, w jaki administrator bazy danych może coś zepsuć, związany ze źle zorganizowaną migracją) oraz samą bazę danych (jeśli można ją odczytać od początku do końca, najprawdopodobniej nie jest uszkodzona).

Nbackup (znany również jako kopia przyrostowa) tymczasowo blokuje główny plik bazy danych przed aktualizacjami (w spójnym stanie) i umożliwia szybkie skopiowanie pliku bazy danych (w całości lub częściowo/przyrostowo).

W przypadku dużych baz danych Firebird (większych niż 500 GB) zaleca się używanie nbackup, aby nie spowalniać operacji użytkowników, ale jednocześnie konieczna jest walidacja bazy danych, ponieważ tworzone przez niego niezweryfikowane kopie zapasowe są kopiami stron bazy danych i jeśli błąd tkwi na poziomie rekordów (z powodu awarii pamięci RAM) lub na poziomie logicznym, niezweryfikowana kopia zapasowa będzie go zawierać tak samo jak oryginalna baza danych.

Aby tego uniknąć, należy używać walidacji online dla oryginalnej bazy danych (walidacja online za pomocą gfix jest dostępna począwszy od wersji Firebird 2.5.4, podczas gdy nasze narzędzie FBDataGuard obsługuje walidację bazy danych online dla wersji 1.5-2.5).

Ponadto zaleca się od czasu do czasu wykonywanie zweryfikowanej kopii zapasowej (na przykład raz w tygodniu) oprócz niezweryfikowanej kopii zapasowej.

Zalecenie dla Firebird: oprócz kontroli stanu online, FBDataGuard pozwala testować proces przywracania kopii zapasowej w trybie automatycznym.

8. Brak kontroli wolnego miejsca na kopie zapasowe

Właściwie to klasyczny błąd: jeśli brakuje miejsca, kopie zapasowe zajmują całą wolną przestrzeń, a proces kończy się błędem. Przechowywanie kopii zapasowych na jednym dysku z bazą danych może doprowadzić do przerwy w działaniu bazy danych, a przechowywanie ich na dysku systemowym może spowodować awarię systemu.

W połączeniu z problemem 4 najlepszym możliwym wynikiem będzie sytuacja, w której system przestanie funkcjonować, ponieważ baza danych również potrzebuje wolnego miejsca, ale jest ono zajęte przez kopie zapasowe. Jeśli chodzi o połączenie z problemami 5 i 2, znowu pozostaje nam ani baza danych, ani jej kopia zapasowa.

Zalecenia: używaj narzędzi do tworzenia kopii zapasowych, które przewidują rozmiar kopii zapasowej i ostrzegają o możliwym braku wolnego miejsca.

Zalecenie dla Firebird: FBDataGuard kontroluje rozmiar wolnego miejsca na potrzeby kopii zapasowych, a także rozmiar wolnego miejsca na dysku z bazami danych oraz na dysku systemowym.

9. Brak kontroli nad czasem tworzenia kopii zapasowej

Proces tworzenia kopii zapasowej zajął dosłownie pół roku temu 40 minut, a potem nagle zajmuje już trzy godziny — dlaczego? Rozmiar bazy danych mógł się zwiększyć lub dysk mógł wypaść z macierzy RAID, co znacznie spowolniło wydajność zapisu, i wszystkie twoje kopie zapasowe mogą być bliskie odejścia z tego świata. Albo dobry kolega mógł uruchomić jednocześnie jeszcze jeden system tworzenia kopii zapasowych (swoją drogą, Firebird pozwala uruchomić kilka procesów tworzenia kopii zapasowych naraz, choć nie jest do końca jasne, po co komuś miałoby to być potrzebne). Jeśli nie kontrolujesz czasu tworzenia kopii zapasowej, możesz przeoczyć nowo powstały problem i stracić szansę na jego naprawę, zanim stanie się masowy.

Poza tym, jeśli system tworzenia kopii zapasowych nie monitoruje statusów zadań tworzenia kopii zapasowych i uruchamia je tylko zgodnie z harmonogramem, możesz łatwo „przedobrzyć", co oznacza sytuację, w której system rozpoczyna nowy proces tworzenia kopii zapasowej, podczas gdy poprzedni jeszcze się nie zakończył.

Zalecenia: używaj narzędzi, które kontrolują czas trwania procesu tworzenia kopii zapasowej!

Zalecenie dla Firebird: FBDataGuard kontroluje czas trwania procesu tworzenia kopii zapasowej.

10. Tworzenie kopii zapasowej bazy danych podczas stosowania aktualizacji systemu operacyjnego

To bardzo częsty problem, zwłaszcza w połączeniu z problemem 9 i włączonymi automatycznymi aktualizacjami Windows (domyślnie aktualizacje są stosowane o 3:00). W najlepszym razie prowadzi to do spowolnienia, ale jeśli system operacyjny zostanie ponownie uruchomiony w celu zastosowania aktualizacji, kopia zapasowa zostanie uszkodzona. Przynajmniej dobrą wiadomością jest to, że system operacyjny nie jest aktualizowany codziennie.

Zalecenia: zaplanuj aktualizacje systemu operacyjnego wtedy, gdy nie kolidują z procesem tworzenia kopii zapasowej.

11. Tworzenie kopii zapasowej bazy danych za pomocą narzędzi do tworzenia kopii zapasowych plików lub narzędzi do tworzenia kopii zapasowych maszyn wirtualnych, gdy serwer bazy danych jest uruchomiony

Wielu administratorów zapomina, że każdy DBMS ma aktywną i złożoną pamięć podręczną zawierającą dane odczytywane i zapisywane, podczas gdy same pliki bazy danych są otwierane w trybie dostępu swobodnego. Dlatego konieczne jest używanie specjalnych typów kopii zapasowych zamiast zwykłego tworzenia kopii zapasowych plików (w tym samego kopiowania plików bazy danych) lub tworzenia kopii zapasowych maszyn wirtualnych. Narzędzia do tworzenia kopii zapasowych plików odczytują bazę danych sekwencyjnie i może to zająć sporo czasu, zwłaszcza w przypadku dużych baz danych, więc nie można zagwarantować integralności utworzonej kopii zapasowej.

Maszyny wirtualne mogą wykorzystywać mechanizmy migawek i Changed Block Tracking, ale konieczna jest synchronizacja tworzonych kopii zapasowych, aby uzyskać spójną kopię zapasową bazy danych, ponieważ kopia zapasowa będzie niespójna w przypadku jakichkolwiek aktywnych operacji zapisu do bazy danych w momencie zbierania zmienionych bloków.

Tym, którzy chcą tworzyć kopie zapasowe swoich baz danych za pomocą narzędzi do tworzenia kopii zapasowych plików lub maszyn wirtualnych, możemy zaproponować dwie metody:

1. całkowite wyłączenie usług i procesów DBMS, aby w pamięci podręcznej nic nie pozostało,
2. użycie agentów i/lub skryptów, które przełączają bazę danych w specjalny tryb umożliwiający bezpieczne sekwencyjne kopiowanie pliku bazy danych. Na przykład dla baz danych MSSQL istnieje mechanizm o nazwie VSS writer. Na żądanie przełącza on bazę danych w tryb przyjazny dla migawek w momencie tworzenia migawki. Jeśli korzystasz z mechanizmów opartych na Changed Block Tracking, sam musisz zadbać o to, aby baza danych była spójna w momencie synchronizacji.

Jeśli nie przełączysz bazy danych w tryb przyjazny dla tworzenia kopii zapasowych, uzyskana kopia bazy danych będzie wyglądać tak, jakby na komputerze hosta nastąpił twardy reset (na przykład zanik zasilania). Ten poziom niezawodności jest absolutnie niewystarczający dla większości firm. Więcej na ten temat można dowiedzieć się z artykułu „Peculiarities of Working with Databases on Virtual Machines”.

W przypadku Firebird konieczne jest zablokowanie głównego pliku bazy danych za pomocą nbackup przed rozpoczęciem procesu tworzenia kopii zapasowej i odblokowanie go po zakończeniu procesu. Dla innych DBMS istnieją podobne narzędzia do włączania/wyłączania odpowiednich trybów.

Niektórzy administratorzy baz danych są przekonani, że mogą bezpiecznie tworzyć kopie zapasowe swoich baz danych za pomocą standardowych narzędzi do tworzenia kopii zapasowych plików, jeśli DBMS posiada dziennik transakcji, ponieważ w najgorszym razie uszkodzeniu ulegnie tylko ten dziennik. To niebezpieczne błędne przekonanie, którego twórcy DBMS nie popierają.

Korzenie tego błędnego przekonania są jasne: agresywna reklama ze strony twórców maszyn wirtualnych i narzędzi do tworzenia kopii zapasowych zazwyczaj nie wspomina, że bazy danych, podobnie jak inne intensywnie aktualizowane pliki, wymagają zaawansowanej konfiguracji. Nie wierz w hype - nie wszystkie jogurty mają równie wiele korzyści.

Zalecenia: nie używaj narzędzi do tworzenia kopii zapasowych plików i maszyn wirtualnych bez odpowiednich narzędzi automatyzacji dla baz danych.

Zalecenie dla Firebird: używaj FBDataGuard (z pakietu dystrybucyjnego HQbird), zapewnia on integrację z narzędziami do tworzenia kopii zapasowych obsługującymi VSS.

12. Zastępowanie kopii zapasowej replikacją

Kopia zapasowa danych i replikacja danych są używane w celu zwiększenia niezawodności i zapobiegania utracie danych, ale mimo to są one zupełnie różne.

Wszyscy uwielbiają replikację za możliwość synchronizowania danych na innym serwerze z minimalnym opóźnieniem, ale kopia zapasowa ma również pewne niepodważalne zalety. Na przykład w przypadku przypadkowego (lub celowego) usunięcia danych replikacja szybko i niezmordowanie wyśle zmiany do repliki, podczas gdy kopia zapasowa (zwłaszcza z kopiami na nośnikach tylko do odczytu) jest odporna na takie operacje. Skonfigurowanie zarówno replikacji, jak i kopii zapasowej poprawnie wymaga pewnego wysiłku, a mimo to możliwość wystąpienia błędów i tak istnieje.

Zalecenia: Jeśli masz skonfigurowaną replikację, nie zaniedbuj kopii zapasowych, używaj obu.

Zalecenie dla Firebird: używaj pakietu dystrybucyjnego HQbird Enterprise, zawiera on zarówno narzędzia do tworzenia kopii zapasowych, jak i replikacji.

Podsumowanie

Skonfigurowanie kopii zapasowej dla ulubionego DBMS nie jest takie łatwe, dlatego administratorzy baz danych z organizacji, w których cenią swoje dane, zazwyczaj korzystają z profesjonalnych narzędzi do tworzenia kopii zapasowych, które pozwalają uwzględnić opisane powyżej problemy i zapobiec im.

Dla Firebird (przepraszamy za reklamę) istnieje pakiet o nazwie HQbird, który zawiera FBDataGuard.

Nasza firma zapewnia również kompleksowe wsparcie w zakresie tworzenia kopii zapasowych i utrzymania dla Firebird i innych baz danych, to dobry wybór dla tych, którzy nie znają wszystkich szczegółów technicznych tworzenia kopii zapasowych.

I oczywiście pielęgnuj swoją administracyjną paranoję, na przykład wstań i sprawdź swoje kopie zapasowe już teraz :)

Kontakty

Zapraszamy do zadawania pytań: [email protected]

Chcesz otrzymywać wiadomości i artykuły o Firebird? Dołącz do nas w Telegramie https://t.me/firebirdsql