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

autor: Alexey Kovyazin, 11 listopada 2015

Pobierz PDF (angielski) Artykuł ten był początkowo przeznaczony dla programistów i administratorów DBMS Firebird, ale kontakty z administratorami innych baz danych pokazały, że większość błędów jest wspólna również dla nich i dosłownie każdy potyka się o prawie 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 jest nie tylko utworzenie kopii bazy, ale skrócenie do minimum przestoju systemu informatycznego (którego ważną częścią jest baza danych).

W rezultacie system pozostaje niechroniony od momentu usunięcia najnowszej kopii zapasowej do momentu utworzenia nowej, ponieważ baza danych nie ma w tym okresie żadnej kopii zapasowej. Ponieważ tworzenie kopii zapasowej może zająć sporo czasu, jest to idealny moment na zadziałanie prawa Murphy’ego. To podejście działa 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 w istniejącym pliku).

Zalecenie dla Firebird: Istnieje narzędzie FBDataGuard zawarte w HQbird (zaawansowanym pakiecie dystrybucyjnym Firebird), które usuwa najstarszą kopię zapasową w historii dopiero po utworzeniu nowej.

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

Ten błąd jest mniej powszechny, chociaż 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 prawidłowej kopii zapasowej.

Taki bałagan zwykle zdarza się w piątek wieczorem, gdy robi się gorąco i gdy polecenia kierownictwa stają się dość sprzeczne. Odrobina pecha i leniwy weekend w serwerowni jest dla Ciebie 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 i jeśli podana nazwa pliku wskazuje na istniejącą bazę danych. Niestety, istnieje sposób na obejście tej ochrony: przełącznik -rep nadal pozwala na nadpisanie istniejącego pliku.

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

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

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

Standardowe strumienie wejścia/wyjścia umożliwiają wykonanie zabawnej sztuczki w wielu systemach 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 przeprowadzania testowego przywracania (pod warunkiem, że dostępna jest inna kopia zapasowa), ale nie wolno używać tego do automatycznej kopii zapasowej!

Na przykład, jeśli podczas tego procesu kopii/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 po utworzeniu tej kopii.

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

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

Wielu z Was może uznać za zabawne, że nasza rada jest dość dziecinna - to ABC kopii zapasowych. Tak, to prawda, ale baza danych i dysk mogą skończyć na tym samym systemie przechowywania danych ze względu na popularność środowisk wirtualnych. I na pewno 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 “markowe” serwery są niezawodne, ale to szczególny przypadek.

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

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

To dość powszechny 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 e-mailem lub, co lepsze, także SMS-em. A brak takich powiadomień jest oznaką problemu!

Uważny czytelnik, który dotarł do tego miejsca w naszym artykule (choć na nagrodę 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 sprawdzanie powiadomień uważa za zbyt nudne, zwłaszcza gdy są przechowywane w osobnym folderze, więc nigdy nie zaszkodzi poprosić o dodatkowe raporty dotyczące statusu procesu. To w kwestii tego, kto jest winien, gdy wydaje się, że kopie zapasowe są, a w rzeczywistości ich nie ma 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 do automatyzacji kopii zapasowych, które mogą monitorować udane i nieudane procesy tworzenia kopii zapasowych, powiadamiać użytkowników o problemach i oferować narzędzia do zbiorczej kontroli (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 wieloma bazami 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 zapasowych

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 sprawdzania kondycji bazy danych przy użyciu niezweryfikowanych kopii zapasowych

Zazwyczaj bazy danych używają kilku typó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, aby utworzyć plik kopii zapasowej, i tworzy bazę danych poprzez wstawianie rekordów do nowej bazy, 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 namieszać, 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 stanie spójnym) 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 znajduje się 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 oryginalnej bazy danych (walidacja online za pomocą gfix jest dostępna od wersji Firebird 2.5.4, podczas gdy nasze narzędzie FBDataGuard obsługuje walidację online baz danych dla wersji 1.5-2.5).

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

Zalecenie dla Firebird: oprócz sprawdzania kondycji online, FBDataGuard pozwala na testowanie procesu 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łe wolne miejsce, a proces kończy się błędem. Przechowywanie kopii zapasowych na tym samym dysku co baza danych może prowadzić do przerwania działania bazy danych, a przechowywanie ich na dysku systemowym może skutkować awarią systemu.

W połączeniu z problemem 4, najlepszym możliwym skutkiem będzie sytuacja, w której system przestaje działać, 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 zostajemy ani z bazą danych, ani z jej kopią zapasową.

Zalecenia: używaj narzędzi do tworzenia kopii zapasowych, które przewidują rozmiar kopii 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 czasu tworzenia kopii zapasowej

Proces tworzenia kopii zapasowej zajmował 40 minut dosłownie pół roku temu, a teraz nagle trwa już trzy godziny - dlaczego? Rozmiar bazy danych mógł wzrosnąć lub dysk mógł wypaść z macierzy RAID, co skutkuje znacznie wolniejszą wydajnością zapisu, a wszystkie Twoje kopie zapasowe mogą być o krok od pożegnania się z tym światem. Albo dobry kolega mógł uruchomić w tym samym czasie kolejny system kopii zapasowych (nawiasem mówiąc, Firebird pozwala na uruchomienie kilku procesów tworzenia kopii zapasowych jednocześnie, choć nie do końca wiadomo, po co to komu). Jeśli nie kontrolujesz czasu tworzenia kopii zapasowej, możesz przeoczyć nowo powstały problem i stracić szansę na naprawienie go, zanim urośnie.

Ponadto, jeśli system kopii zapasowych nie monitoruje statusów zadań kopii zapasowych i uruchamia je tylko zgodnie z harmonogramem, możesz łatwo “wyskoczyć przed szereg”, co oznacza sytuację, w której system uruchamia nowy proces tworzenia kopii zapasowej, podczas gdy poprzedni jeszcze się nie zakończył.

Zalecenia: używaj narzędzi kontrolujących czas trwania procesu tworzenia kopii zapasowej!

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

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

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

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

11. Tworzenie kopii zapasowej bazy danych za pomocą narzędzi do kopii plików lub narzędzi do kopii maszyn wirtualnych podczas działania serwera bazy danych

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ą otwarte w trybie dostępu swobodnego. Dlatego konieczne jest stosowanie specjalnych typów kopii zapasowych zamiast zwykłej kopii plików (w tym zwykłego kopiowania plików bazy danych) lub kopii maszyn wirtualnych. Narzędzia do kopii plików odczytują bazę danych sekwencyjnie, co może zająć dość dużo czasu, zwłaszcza w przypadku dużych baz danych, więc nie można zagwarantować integralności utworzonej kopii zapasowej.

Maszyny wirtualne mogą korzystać z mechanizmów snapshotów i Changed Block Tracking, ale konieczne jest zsynchronizowanie utworzonych 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 sortowania kolekcji zmienionych bloków.

Tym, którzy chcą tworzyć kopie zapasowe swoich baz danych za pomocą narzędzi do kopii 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 zostało,
2. użycie agentów i/lub skryptów, które przełączają bazę danych w specjalny tryb, czyniący bezpiecznym sekwencyjne kopiowanie pliku bazy danych. Na przykład istnieje mechanizm o nazwie VSS writer dla baz danych MSSQL. Na żądanie przełącza bazę danych w tryb przyjazny dla snapshotów w momencie ich tworzenia. Jeśli używasz 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 kopii zapasowych, powstała kopia bazy danych będzie wyglądać tak, jakby na komputerze hosta nastąpił twardy reset (na przykład awaria zasilania). Ten poziom niezawodności jest absolutnie niewystarczający dla większości firm. Więcej na ten temat można przeczytać w artykule „Specyfika pracy z bazami danych na maszynach wirtualnych".

W przypadku Firebirda konieczne jest zablokowanie głównego pliku bazy danych za pomocą nbackup przed rozpoczęciem procesu tworzenia kopii zapasowej i odblokowanie go po jego zakończeniu. W przypadku innych systemów 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 kopiowania plików, jeśli DBMS posiada dziennik transakcji, ponieważ w najgorszym wypadku uszkodzony zostanie tylko ten dziennik. To niebezpieczne błędne przekonanie, którego producenci DBMS nie popierają.

Źródła tego błędnego przekonania są jasne: agresywna reklama producentów maszyn wirtualnych i narzędzi do tworzenia kopii zapasowych zwykle nie wspomina, że bazy danych, podobnie jak inne intensywnie aktualizowane pliki, wymagają zaawansowanej konfiguracji. Nie wierzcie szumowi - nie wszystkie jogurty są równie korzystne.

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

Zalecenie dla Firebirda: użyj 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ą

Kopie zapasowe danych i replikacja danych są używane do zwiększenia niezawodności i zapobiegania utracie danych, ale jednak są to dość różne rzeczy.

Wszyscy kochają replikację za możliwość synchronizacji danych na innym serwerze z minimalnym opóźnieniem, ale kopia zapasowa ma również niezaprzeczalne zalety. Na przykład w przypadku przypadkowego (lub celowego) usunięcia danych replikacja szybko i spokojnie 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 wymaga pewnego wysiłku, a mimo to zawsze istnieje możliwość wystąpienia błędów.

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

Zalecenie dla Firebirda: użyj 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 proste, dlatego administratorzy baz danych z organizacji, w których ceni się dane, zwykle używają profesjonalnych narzędzi do tworzenia kopii zapasowych, które pozwalają uwzględnić wspomniane powyżej kwestie i zapobiec problemom.

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

Ponadto nasza firma zapewnia pełne wsparcie w zakresie tworzenia kopii zapasowych i utrzymania Firebirda oraz innych baz danych - to dobry wybór dla tych, którzy nie znają wszystkich technicznych szczegółów tworzenia kopii zapasowych.

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

Kontakt

Zachęcamy do zadawania pytań: [email protected]

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