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
| Zapis | Co przechwycić |
|---|---|
| Punkt odtworzenia | Czas przechwycenia i najnowszy oczekiwany rekord |
| Czas trwania odzyskiwania | Czasy rozpoczęcia/zakończenia i kroki ręczne |
| Sprawdzenia | Wiersz bazy danych, zawartość załącznika i sprawdzenia aplikacji |
| Wyjątki | Brakujące role, uprawnienia, konfiguracja lub zależności |
| Następne ćwiczenie | Wyzwalacz, 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.