Monitoring i utrzymanie Średnio zaawansowany 65 min

Strategia backupu aplikacji

Ułożysz plan kopii danych, konfiguracji i procedury odtwarzania dla ćwiczeniowej aplikacji.

Wróć do listy lekcji

1. Krótka teoria

Backup ma umożliwić powrót do działania po utracie danych, błędzie operatora lub awarii hosta. Najpierw spisz zasoby: bazę PostgreSQL, pliki przesyłane przez użytkowników, konfigurację odtwarzalną z bezpiecznego źródła, definicje wdrożenia i potrzebne sekrety. Sam obraz kontenera ani volume nie zastępują kopii danych. Ustal RPO, czyli największą akceptowaną utratę zmian, oraz RTO, czyli czas na przywrócenie usługi. Te wymagania wyznaczają częstotliwość, metodę i lokalizację kopii. Pełna kopia upraszcza odtwarzanie, a kopie przyrostowe oszczędzają miejsce kosztem zależności od wcześniejszych egzemplarzy. Dla małej bazy logiczny zrzut pg_dump bywa prostym punktem startu; nie zapewnia odtwarzania do dowolnej sekundy. Reguła 3-2-1 przypomina o trzech egzemplarzach danych, dwóch rodzajach nośników i jednej kopii poza główną lokalizacją. W praktyce dobierz niezależną lokalizację, ogranicz dostęp, szyfruj przechowywane i przesyłane kopie oraz zaplanuj retencję. Monitoruj powodzenie zadania, rozmiar i wiek ostatniej kopii. Plik, który istnieje, może być niekompletny lub nieodtwarzalny. Okresowo odtwórz kopię do odizolowanego środowiska testowego i sprawdź ważne dane oraz działanie aplikacji. Przykłady dotyczą wyłącznie danych ćwiczeniowych; nie kopiuj prawdziwych sekretów do notatek, repozytorium ani otwartego katalogu.

2. Przykłady komend

df -h /srv/backups

Sprawdza miejsce w lokalizacji ćwiczeniowych kopii przed zadaniem.

$ df -h /srv/backups
find /srv/backups -maxdepth 1 -type f -name '*.backup' -printf '%TY-%Tm-%Td %TH:%TM %s %f '

Pokazuje datę i rozmiar zapisanych kopii testowych.

$ find /srv/backups -maxdepth 1 -type f -name '*.backup' -printf '%TY-%Tm-%Td %TH:%TM %s %f
'
stat /srv/backups/orders-test.backup

Odczytuje metadane jednej testowej kopii.

$ stat /srv/backups/orders-test.backup
test -s /srv/backups/orders-test.backup

Weryfikuje istnienie i niezerowy rozmiar pliku.

$ test -s /srv/backups/orders-test.backup
sha256sum /srv/backups/orders-test.backup

Tworzy sumę do późniejszego porównania integralności pliku.

$ sha256sum /srv/backups/orders-test.backup
ls -ld /srv/backups

Sprawdza uprawnienia katalogu z kopiami.

$ ls -ld /srv/backups

3. Zadanie praktyczne

Dla fikcyjnej aplikacji orders-api z bazą i plikami zamówień przygotuj tabelę: zasób, metoda kopii, częstotliwość, lokalizacja, retencja i sposób testu. Załóż RPO 24 godziny i RTO 4 godziny; sprawdź, czy plan je spełnia także po utracie hosta. Na nieszkodliwym pliku orders-test.backup przećwicz kontrolę daty, rozmiaru i sumy. Dopisz termin testowego odtworzenia oraz osobę odpowiedzialną za wynik.

4. Typowe błędy

  • Traktowanie volume lub drugiego pliku na tym samym hoście jako odpornej kopii.
  • Kopiowanie tylko bazy, gdy aplikacja przechowuje również pliki użytkowników.
  • Plan retencji bez informacji, jak daleko wstecz można się cofnąć.
  • Przechowywanie zrzutów i sekretów w publicznym repozytorium.
  • Uznanie niepustego pliku za dowód skutecznego odtworzenia.

5. Podsumowanie

Strategia łączy wymagania RPO i RTO z listą zasobów, niezależną lokalizacją, ochroną, retencją i regularnym testem odtwarzania. Kontrola pliku jest początkiem weryfikacji, a pełny dowód daje odtworzenie danych i sprawdzenie aplikacji.

Flow nauki
  1. Teoria
  2. Przykład
  3. Ćwiczenie
  4. Quiz
  5. Praktyka
  6. Podsumowanie