Czy przed wykonaniem migawki serwera NAS należy wstrzymać kontenery aplikacji czy użyć kopii zapasowych aplikacji?

Bezpieczne podejście polega na traktowaniu wyboru właściwego dla danego obciążenia - między kopią zapasową aplikacji, skoordynowanym wstrzymaniem operacji a prawidłowym zatrzymaniem przed utworzeniem migawki - jako sekwencji obserwowalnych etapów kontrolnych, a nie pojedynczego polecenia.

W przypadku aplikacji kontenerowych na serwerze NAS obsługującym migawki praktyczne ryzyko polega na niepewności, czy migawka działającego serwera NAS przywróci kontenery ze stanem w sposób spójny. Zapisz bieżącą tożsamość i punkt odzyskiwania, rozpocznij od najmniej inwazyjnego testu rozróżniającego, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej i przerwij, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia byłaby narażona. Poniższy proces kończy się dopiero wtedy, gdy pierwotne obciążenie działa poprawnie albo dowody osiągną granicę wymagającą eskalacji.

Ustal sposób zapewnienia spójności przed rozpoczęciem pracy ze stosem

Użyj natywnej dla aplikacji kopii zapasowej, jeśli aplikacja lub baza danych ją udostępnia. Użyj skoordynowanego haka wstrzymania operacji i utworzenia migawki tylko wtedy, gdy baza danych obsługuje taki proces, a prawidłowe zatrzymanie wybierz wtedy, gdy krótka przerwa w działaniu jest akceptowalna. Proste wstrzymanie kontenera traktuj najwyżej jako zapewniające spójność awaryjną, a nie automatycznie jako spójne na poziomie aplikacji.

To rozróżnienie ma znaczenie, ponieważ działanie Docker pause zamraża procesy bez uruchamiania ich standardowej ścieżki zamykania i opróżniania buforów. Może zatrzymać nowe zapisy podczas bardzo krótkiego wykonywania migawki systemu plików, ale nie może potwierdzić, że bufory bazy danych, dzienniki, załączniki i usługi zależne przedstawiają stan aplikacji możliwy do przywrócenia.

Zapisz silnik bazy danych, funkcję tworzenia kopii zapasowej aplikacji, ścieżki woluminów, ścieżki przesyłanych plików, sekrety, wersję obrazu oraz akceptowalny czas przestoju. Jeśli którykolwiek komponent przechowujący stan jest nieznany, decyzja pozostaje nierozstrzygnięta, a migawki nie wolno uznać za przetestowaną kopię zapasową.

Wybierz prawidłową ścieżkę powodującą najmniejsze zakłócenia

W przypadku PostgreSQL, MariaDB i innych baz danych usług preferuj obsługiwany przez nie proces zrzutu lub kopii fizycznej. W przypadku SQLite użyj eksportu aplikacji lub kopii online SQLite, jeśli jest dostępna. Przechwyć przesłane pliki i konfigurację w tym samym oknie odzyskiwania, aby baza danych nie wskazywała brakujących lub nowszych plików.

Gdy nie istnieje żadna obsługiwana ścieżka online, najpierw zatrzymaj procesy zapisujące, a następnie prawidłowo zatrzymaj bazę danych i potwierdź zakończenie procesów przed utworzeniem migawki. Wstrzymanie może być wąskim rozwiązaniem pomostowym tylko wtedy, gdy dokumentacja i test przywracania pokażą, że odzyskiwanie po awarii jest wystarczające dla tego konkretnego obciążenia; nie jest ono uniwersalnym zamiennikiem kopii zapasowej aplikacji.

Niewielki stos na serwerze domowym może korzystać z powiązanego przewodnika dotyczącego spójnych kopii zapasowych kontenerów baz danych, obejmującego natywne dla bazy zrzuty i kopie po prawidłowym zatrzymaniu. Zakres tego artykułu jest węższy: określa on działanie przed utworzeniem migawki, podczas gdy powiązany przewodnik omawia zawartość szerszego pakietu kopii zapasowej.

Przeprowadź skoordynowane okno tworzenia migawki

Wstrzymaj zaplanowane zadania i zapisy użytkowników, uruchom wybrane przygotowanie aplikacji lub bazy danych i przed utworzeniem migawki systemu plików potwierdź jego powodzenie. Szybko utwórz migawkę, a następnie zwolnij wstrzymanie lub uruchom stos ponownie; później skopiuj migawkę lub wykonaj jej replikację, aby czas przestoju nie był równy czasowi transferu.

Dodaj procedurę obsługi błędów do każdego niestandardowego haka. Jeśli przygotowanie zakończy się niepowodzeniem, nie twórz migawki; jeśli tworzenie migawki się nie powiedzie, zawsze wznawiaj działanie aplikacji; jeśli wznowienie się nie powiedzie, nie udostępniaj usługi użytkownikom i celowo przywróć jej działanie. Rejestruj każde przejście, aby ciche przekroczenie limitu czasu haka wstępnego nie utworzyło pozornie udanego zadania tworzenia kopii zapasowej.

Wynik pozytywny oznacza, że aplikacja wraca do normalnego działania, migawka ma oczekiwany znacznik czasu i oczekiwane zestawy danych, a żadna zależność nie została przechwycona poza tym oknem. Wycofaj automatyzację, jeśli którykolwiek kontener pozostaje wstrzymany lub baza danych zgłasza odzyskiwanie przy każdej rutynowej migawce.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Potwierdź wybór za pomocą izolowanego przywracania

Przywróć migawkę lub natywną kopię zapasową do projektu tymczasowego, używając innych portów i ścieżek pamięci masowej. Najpierw uruchom bazę danych i wykonaj jej kontrolę integralności, a następnie połącz aplikację i sprawdź najnowsze rekordy, użytkowników, załączniki, zaplanowane zadania oraz uprawnienia. Nie testuj na produkcyjnej bazie danych.

Wynik pozytywny wymaga czegoś więcej niż czystego uruchomienia kontenera: aplikacja musi odczytywać i aktualizować przywrócony stan, powiązane pliki muszą odpowiadać odwołaniom w bazie danych, a drugie ponowne uruchomienie również musi zakończyć się poprawnie. Porównaj ten wynik z przywracaniem natywnej kopii zapasowej, jeśli zamierzasz polegać na migawkach zapewniających spójność awaryjną.

Używaj metody opartej na migawkach dopiero wtedy, gdy pierwotne obciążenie przejdzie ten test. Jeśli odzyskiwanie oparte na wstrzymaniu jest niestabilne, wymagana jest naprawa bazy danych lub któregoś komponentu nie można powiązać z tym samym punktem odzyskiwania, przełącz się na natywną kopię zapasową aplikacji albo prawidłowe zatrzymanie i zachowaj nieudaną migawkę jako dowód, zamiast ją nadpisywać.