Strategia backupu aplikacji
Ułożysz plan kopii danych, konfiguracji i procedury odtwarzania dla ćwiczeniowej aplikacji.
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
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.