Jaka metoda tworzenia kopii zapasowej utrzymuje spójność działającego kontenera bazy danych na domowym NAS?

Dla większości użytkowników domowego NAS i serwerów self-hosted najbezpieczniejszym domyślnym rozwiązaniem jest natywna logiczna kopia zapasowa bazy danych tworzona podczas działania bazy, a następnie normalna kopia tej kopii wraz z konfiguracją kontenera i plikami aplikacji. Używaj krótkiej kopii zatrzymanego kontenera, gdy dopuszczalny jest czas przestoju, a skoordynowanego migawki systemu plików tylko wtedy, gdy baza jest opróżniona, zablokowana, zrobiony checkpoint lub w inny sposób przygotowana do migawki. Zwykła kopia aktywnego wolumenu bazy danych nie jest spójną metodą kopii zapasowej.

Zdefiniuj „Spójne” jako przywrócenie zaakceptowane przez bazę danych

Spójna kopia zapasowa to nie tylko kompletny drzewo folderów. Po przywróceniu silnik bazy danych musi się uruchomić, poprawnie odzyskać transakcje, przejść kontrole integralności i przedstawić stan punktu w czasie, z którego aplikacja może korzystać. Na domowym serwerze uruchamiającym Immich, Nextcloud, Paperless-ngx, Home Assistant lub inną aplikację self-hosted oznacza to, że baza danych, przesłane pliki, konfiguracja i sekrety muszą być ze sobą zgodne.

Trwałość kontenera wyjaśnia tylko, gdzie znajdują się pliki. Nie zapewnia bezpieczeństwa kopiowania działającej bazy danych. Baza może mieć aktywne transakcje, pamięć podręczną stron, dzienniki zapisu w przód, pliki tymczasowe lub metadane zmieniające się podczas czytania wolumenu przez oprogramowanie kopii zapasowej NAS.

Metoda 1: Użyj natywnego zrzutu logicznego bazy danych jako domyślnego rozwiązania dla domowego NAS

Zrzut logiczny prosi silnik bazy danych o wyeksportowanie spójnej reprezentacji schematów i rekordów. Dla niewielkiego kontenera PostgreSQL lub MariaDB na domowym NAS jest to zwykle najprostsza metoda do zaplanowania, sprawdzenia, skopiowania poza miejsce i przywrócenia do czystego kontenera zastępczego. Aktualny przewodnik po kopiach zapasowych Dockera demonstruje ten wzorzec poprzez uruchamianie natywnych zrzutów baz danych z zaplanowanego kontenera kopii zapasowej.

Zapisz zrzut do dedykowanego katalogu kopii zapasowej poza aktywnym wolumenem danych. Następnie pozwól zadaniu kopii zapasowej NAS chronić zrzut, plik Compose, szablon środowiska, konfigurację aplikacji oraz przesłane dane. Nie ujawniaj haseł produkcyjnych w nazwie pliku zrzutu ani w niezabezpieczonych logach.

Metoda 2: Krótkie zatrzymanie bazy danych przed skopiowaniem jej wolumenu

Kopia zatrzymanego kontenera jest prosta i fizycznie kompletna. Najpierw zatrzymaj procesy zapisujące aplikacji, zatrzymaj bazę danych czysto, potwierdź zakończenie procesu, skopiuj cały trwały wolumen lub katalog bazy danych zamontowany przez bind, a następnie uruchom ponownie stos. Przewodnik Docker i MariaDB opisuje fizyczne kopie wolumenów jako szybkie, ale zależne od wersji i zwykle związane z przestojem.

Ta metoda dobrze sprawdza się w małym domowym NAS, gdzie kilka minut konserwacji jest akceptowalne, a przywracanie będzie używać kompatybilnej wersji bazy danych. Jest mniej przenośna niż logiczny zrzut i może wydłużyć czas przestoju, gdy wolumen jest duży. Zachowaj tag obrazu bazy danych i układ przechowywania z kopią zapasową, aby nie przywrócić plików fizycznych do niekompatybilnej wersji silnika.

Metoda 3: Skoordynuj szybką migawkę z bazą danych

Systemy migawkowe ZFS, Btrfs, LVM i NAS mogą szybko uchwycić duży wolumen bazy danych, ale migawka musi być skoordynowana z bazą danych. Dla MariaDB lub MySQL może to oznaczać krótki okres blokady lub opróżnienia; dla PostgreSQL może to oznaczać obsługiwany przez bazę proces tworzenia kopii zapasowej lub punkt kontrolny; dla bazy zarządzanej przez aplikację może to oznaczać hak przed migawką.

Dyskusja o migawce bazy danych wyjaśnia, że kopiowanie na żywo z dysku może być wewnętrznie niespójne, chyba że baza danych jest zamrożona lub migawka jest wykonana atomowo. Okres blokady lub wyciszenia powinien być krótki: przygotuj bazę danych, utwórz migawkę, zwolnij zapisy i skopiuj migawkę później.

Ta metoda jest przydatna, gdy baza danych jest zbyt duża na częste logiczne zrzuty lub gdy potrzebujesz krótszego interwału punktu odzyskiwania. Wymaga bardziej starannego skryptowania i testowania przywracania niż podstawowy proces zrzutu na serwerze domowym.

Nie traktuj obrazu Dockera ani eksportu kontenera jako kopii zapasowej bazy danych

Obraz kontenera zawiera środowisko uruchomieniowe aplikacji, a niekoniecznie dane trwałe na żywo. Eksportowanie lub zatwierdzanie kontenera może pominąć nazwane wolumeny i nie wymaga od bazy danych utworzenia spójnego punktu odzyskiwania. Konto kopii zapasowej kontenera PostgreSQL stwierdza, że Docker save i commit nie zastępują specyficznych dla PostgreSQL technik tworzenia kopii zapasowych.

Dla domowego serwera ZimaOS lub Docker trzymaj definicję wdrożenia i plan ochrony danych oddzielnie: zachowaj pliki Compose i tagi obrazów, aby można było odbudować usługę, oraz zachowaj bazę danych za pomocą metody spójnej z bazą, aby można było przywrócić jej stan.

Nigdy nie kopiuj zwykłym sposobem aktywnie zapisywanego woluminu bazy danych

Oprogramowanie do kopii zapasowej NAS może odczytywać różne pliki bazy danych w różnych momentach. Powstałe archiwum może zawierać plik danych z jednego stanu transakcji, dziennik z innego i metadane z trzeciego. Przegląd metod kopii zapasowej SQL open-source ostrzega, że baza danych w ruchu może zostać uchwycona w niespójnym momencie, gdy ważny stan jest nadal w pamięci.

Odzyskiwanie po awarii może naprawić niektóre atomowo uchwycone migawki, ale zwykłe rekurencyjne kopiowanie plików nie jest atomowe. Jeśli aplikacja nie może tolerować przestoju, użyj zrzutu logicznego, obsługiwanego narzędzia do kopii fizycznej lub skoordynowanej migawki.

Traktuj kontenery SQLite jako bazy danych, a nie zwykłe pliki

Wiele aplikacji domowych serwerów używa SQLite, ponieważ jest kompaktowy i łatwy do wdrożenia. Ryzyko polega na tym, że administratorzy widzą jeden plik .db i zakładają, że można go kopiować podczas zapisu aplikacji. W trybie WAL ostatnie zatwierdzone zmiany mogą być nadal poza głównym plikiem. Praktyczny artykuł o odzyskiwaniu SQLite zaleca używanie mechanizmu kopii zapasowej online lub czystej zamkniętej kopii zamiast kopiowania aktywnego pliku bazy danych.

Użyj wbudowanej kopii zapasowej aplikacji, jeśli jest dostępna. W przeciwnym razie użyj własnej funkcji kopii zapasowej online SQLite lub zatrzymaj aplikację czysto przed skopiowaniem całego katalogu bazy danych. Nie kopiuj tylko głównego pliku bazy danych, pozostawiając dziennik lub stan WAL.

Wybierz metodę według przestoju, rozmiaru bazy danych i przenośności przywracania

Twórz kopię zapasową całej samodzielnie hostowanej aplikacji, nie tylko bazy danych

Użyteczny pakiet odzyskiwania powinien zawierać kopię zapasową bazy danych, plik Docker Compose, wersje obrazów, zmienne środowiskowe lub odzyskiwalny pakiet sekretów, ustawienia reverse-proxy, konfigurację aplikacji, przesłane pliki oraz wszelkie klucze szyfrowania. Kopiowanie tylko zrzutu SQL może przywrócić rekordy, ale pozostawić aplikację bez możliwości znalezienia zdjęć, dokumentów, miniatur, certyfikatów czy ścieżek przechowywania.

W planowaniu odzyskiwania domowego serwera przewodnik ZimaSpace dotyczący bind mountów i nazwanych wolumenów wyjaśnia, dlaczego widoczne ścieżki przechowywania pomagają w odzyskiwaniu, ale nie zastępują spójnej z aplikacją kopii zapasowej bazy danych.

Potwierdź metodę, przywracając do nowego kontenera

Utwórz izolowany stos testowy z nową nazwą projektu, innymi portami hosta i tymczasowym katalogiem danych. Przywróć zrzut lub migawkę, uruchom bazę danych, wykonaj jej testy integralności lub spójności, a następnie podłącz testową kopię aplikacji. Potwierdź, że użytkownicy, rekordy, załączniki i ostatnie transakcje są obecne.

Mierz zarówno punkt odzyskiwania, jak i czas odzyskiwania. Jeśli zrzut logiczny jest spójny, ale przywracanie trwa zbyt długo, zachowaj go jako przenośną warstwę odzyskiwania i dodaj szybszą, skoordynowaną migawkę. Jeśli kopia zatrzymanego wolumenu przywraca szybko, ale tylko do tej samej wersji bazy, zachowaj zrzut logiczny jako plan awaryjny migracji.

FAQ

Czy wystarczy wstrzymać kontener bazy danych przed skopiowaniem wolumenu?

Nie jako ogólna zasada. Pauza zatrzymuje proces, ale nie dowodzi, że baza danych zapisała poprawny stan do przenośnej kopii zapasowej. Użyj natywnego zrzutu bazy, czystego zamknięcia lub udokumentowanej procedury zatrzymania i migawki.

Czy sama migawka NAS wystarczy dla PostgreSQL lub MariaDB?

Tylko gdy migawka jest atomowa i skoordynowana z obsługiwanym przez bazę procesem spójności. Nieskoordynowana migawka może być jedynie zgodna z awarią, a nieatomowa kopia pliku może być gorsza.

Co powinienem tworzyć kopię zapasową w aplikacji domowego serwera opartej na SQLite?

Używaj eksportu aplikacji lub online backupu SQLite, gdy są dostępne. Zachowaj także konfigurację aplikacji, plik Compose, sekrety, załączniki oraz katalog zawierający bazę danych, zamiast zakładać, że główny .db plik to cała aplikacja.

Ostateczna rekomendacja

Używaj zaplanowanych zrzutów logicznych jako domyślnych dla większości kontenerów PostgreSQL i MariaDB na domowym NAS. Używaj czystej kopii zatrzymanego wolumenu, gdy krótki czas przestoju jest akceptowalny, a w przypadku dużej bazy danych lub wąskiego okna punktu odzyskiwania stosuj skoordynowane migawki lub natywne narzędzia fizyczne bazy danych. Niezależnie od wybranej metody, przywróć ją do nowego kontenera, zanim jej zaufasz.