OffVPSOFFSHORE VPSWsparcie

Utrzymanie działania

Kopia zapasowa jest pytaniem. Przywrócenie jest odpowiedzią.

Użyteczna kopia zapasowa musi przywrócić bazę danych i pliki, do których się odwołuje. Udowodnij tę zależność na izolowanym celu, zanim polegniesz na niej podczas incydentu.

Przewodnik terenowy OffVPS · Zweryfikowano · 5 min czytania

Zacznij pierwsze ćwiczenie celowo od małego zakresu

To ćwiczenie tworzy zabawkową bazę danych notatek i jeden załącznik, przechwytuje oba, a następnie przywraca je do nowej bazy danych i katalogu. Użyj jednorazowej maszyny Linux z serwerem PostgreSQL 17 i pasującymi narzędziami klienta, Bash i GNU coreutils. Nie może zawierać danych produkcyjnych ani mieć połączenia z aplikacjami produkcyjnymi, pocztą wychodzącą lub zadaniami zaplanowanymi. Użyj tylko archiwum utworzonego w tym ćwiczeniu.

Polecenia zakładają wstępnie skonfigurowaną rolę bazy danych bez uprawnień superużytkownika o nazwie restore_lab, uprawnioną do tworzenia testowych baz danych, oraz login systemowy o tej samej nazwie, który może uwierzytelnić się lokalnie. Gniazdo PostgreSQL to /var/run/postgresql na porcie 5432. Administrator powinien przygotować to konto w środowisku jednorazowym; ten przewodnik nie modyfikuje reguł dostępu do bazy danych. Sprawdź punkt końcowy przed utworzeniem czegokolwiek:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Zatrzymaj się, jeśli host, konto lub wersja są nieoczekiwane. W tym pierwszym ćwiczeniu utrzymuj klientów i serwer w tej samej wersji głównej. pg_dump nie może zrzucić serwera nowszego niż jego własna wersja główna, a starszy cel przywracania generalnie nie jest gwarantowany jako zgodny. Zobacz limity wersji pg_dump. Uruchom każdy blok osobno i zatrzymaj się przy błędzie. && zabezpieczenia uniemożliwiają uruchomienie późniejszych poleceń w wklejonym bloku po niepowodzeniu; nigdy nie przechodź do następnego bloku po nieudanym utworzeniu bazy danych lub katalogu.

Utwórz rekord i pasujący do niego plik

Nazwy offvps_restore_source oraz offvps_restore_target muszą być nieużywane. Istniejąca baza danych jest powodem, aby zatrzymać się i wybrać nowe izolowane ćwiczenie, a nie powodem, aby ją usunąć. Utwórz świeżą przestrzeń roboczą systemu plików i źródłową bazę danych:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

Świeża przestrzeń robocza zapobiega nadpisaniu istniejącego katalogu. mktemp tworzy unikalny katalog; createdb tworzy nową bazę danych na podstawie wybranego szablonu. Zapisz te dwa znaczniki:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

Rekord wskazuje, który plik należy do notatki, a oba zawierają ten sam znacznik. Dzięki temu brakujący załącznik lub niedopasowana kopia stają się widoczne. -X unika osobistych ustawień startowych psql, a ON_ERROR_STOP zatrzymuje się przy błędzie SQL; zobacz opcje skryptowe psql. Żadna aplikacja nie zapisuje do tego zabawkowego zestawu danych.

Przechwyć bazę danych i pliki jako jeden zestaw odzyskiwania

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

Archiwum w formacie niestandardowym jest odczytywane przez pg_restore; zwykły zrzut SQL wymaga innej procedury przywracania. Wyświetlenie archiwum pomaga potwierdzić, że oczekiwane wpisy tabeli i danych są obecne. Spójny zrzut bazy danych nie synchronizuje automatycznie zewnętrznych przesłanych plików. W przypadku prawdziwej aplikacji użyj udokumentowanej procedury konserwacji lub wstrzymania zapisu, aby drzewo plików i baza danych opisywały ten sam punkt w czasie. Ćwiczenie zabawkowe jest już wyciszone.

Zapisz wersję bazy danych, wydanie aplikacji, początek/koniec przechwytywania i ścieżkę pliku obok pakietu. Prawdziwe poświadczenia przechowuj oddzielnie, zgodnie z odpowiednimi kontrolami dostępu. Zrzut pojedynczej bazy danych nie przechwytuje globalnych ról i przestrzeni tabel; prawdziwy plan odzyskiwania musi je również uwzględniać. Zakres opisano w przewodniku PostgreSQL dotyczącym zrzutów SQL.

Przywróć do nowych celów bez czyszczenia istniejącego

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

Docelowa baza danych jest tworzona jako pusta. Przywracanie celowo pomija --clean, co mogłoby usunąć istniejące obiekty. --single-transaction powoduje, że przywracanie tej małej bazy danych kończy się sukcesem jako całość lub zatrzymuje się bez zastosowania częściowych zmian; nie można go łączyć z równoległymi zadaniami. --no-owner oraz --no-acl upraszczają własność dla tej roli testowej, więc to ćwiczenie nie weryfikuje produkcyjnych ról ani uprawnień aplikacji. Zobacz pg_restore.

Kopia pliku trafia do nowego katalogu przywracania, pozostawiając źródło nietknięte. GNU cp -a próbuje zachować atrybuty plików; sprawdź własność i dostęp dla konta, które będzie uruchamiać prawdziwą aplikację. Kopiowanie bajtów nie jest testem uprawnień aplikacji. Zobacz opcję archiwum cp.

Sprawdź zależność, nie tylko kody wyjścia

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Oczekiwane wyniki to jeden wiersz o ID 1, treści restore-marker-01 i załączniku marker.txt, plus plik zawierający restore-marker-01. Sprawdź, czy źródło nadal zawiera swój pierwotny wiersz i plik. W przypadku prawdziwej aplikacji skieruj również izolowaną instancję na przywróconą bazę danych i katalog przesłanych plików, otwórz reprezentatywne rekordy, pobierz załącznik i przetestuj zamierzone uprawnienia logowania. Podczas tego procesu utrzymuj wywołania zwrotne, pocztę i zadania w ograniczonym zakresie.

Zapisz, co udowodniłeś, a co pozostaje

ZapisCo przechwycić
Punkt odtworzeniaCzas przechwycenia i najnowszy oczekiwany rekord
Czas trwania odzyskiwaniaCzasy rozpoczęcia/zakończenia i kroki ręczne
SprawdzeniaWiersz bazy danych, zawartość załącznika i sprawdzenia aplikacji
WyjątkiBrakujące role, uprawnienia, konfiguracja lub zależności
Następne ćwiczenieWyzwalacz, taki jak zmiana schematu, przechowywania lub wdrożenia

Powyższe oczekiwane wyniki to kryteria ćwiczenia, a nie wyniki już zaobserwowane przez OffVPS. Ponieważ pierwsze ćwiczenie przechowuje wszystkie pliki na jednej maszynie, nie zapewnia ochrony przed utratą tej maszyny. Prawdziwy plan wymaga chronionej kopii w oddzielnej domenie awarii, użytecznych kluczy deszyfrujących, retencji i przetestowanej ścieżki odzyskiwania. Przed późniejszym czyszczeniem przejrzyj dokładne nazwy jednorazowych baz danych i katalog; trzymaj produkcję poza tym procesem.

Powtarzaj ćwiczenie po ważnych zmianach i zapisuj niepowodzenia równie starannie jak sukcesy. Opcjonalna usługa kopii zapasowej nie dowodzi czasu odzyskiwania Twojej aplikacji. Kontynuuj z planowaniem zadania zaplanowanego gdy będziesz gotowy zautomatyzować przechwytywanie, zachowując jednocześnie oddzielne ćwiczenie przywracania.

Wykorzystana dokumentacja

Główne źródła dla tej strony. Sprawdź dokumentację wersji zainstalowanej we własnym środowisku.