Wyobraźmy sobie, że podczas aktualizacji sklepu internetowego z bazy znikają zamówienia z kilku ostatnich godzin. Sklep nadal się otwiera, produkty są widoczne, a serwer działa. Pracownicy nie wiedzą jednak, co i dokąd wysłać. Część zakupów można odtworzyć z wiadomości e-mail i historii płatności. Adresy, pozycje zamówień i uwagi klientów trzeba odzyskać osobno.
Kopia zapasowa, czyli backup, pozwala przywrócić zapisany stan danych. To, jak aktualny będzie ten stan i ile potrwa powrót do pracy, zależy od przyjętej strategii. Właściciel produktu powinien wiedzieć, co jest zapisywane, jaką utratę danych firma akceptuje i kto odpowiada za odtworzenie systemu.
Kiedy backup jest potrzebny
Kopie są potrzebne, gdy utrata danych uniemożliwi realizację zamówień, obsługę klientów lub dalszą pracę, a ponowne zebranie informacji będzie trudne. Dotyczy to historii zamówień, zgłoszeń i przesłanych dokumentów także w małym produkcie z pierwszymi klientami.
Zacznij od pytania: jeśli te dane znikną, skąd je weźmiemy i ile czasu to zajmie? Wiadomość klienta lub oryginał dokumentu mogą istnieć tylko w aplikacji. Ochronę warto przygotować, zanim produkt zacznie przyjmować rzeczywiste dane.
Pamięć podręczną lub indeks wyszukiwania można czasem zbudować ponownie. Trzeba wówczas zachować dane źródłowe i sprawdzić, czy czas odbudowy będzie akceptowalny. Pliki tymczasowe i stale zmieniająca się baza zamówień nie muszą mieć takiego samego harmonogramu kopii.
Przed migracją lub masową zmianą danych warto utworzyć dodatkową kopię i ustalić sposób wycofania nieudanych zmian. Przywrócenie starszej kopii może usunąć zamówienia, które pojawiły się później. Zespół musi wcześniej zaplanować zachowanie tych nowych rekordów lub ich uzgodnienie z innymi źródłami.
Jakie ryzyko wiąże się z brakiem kopii
Do utraty danych nie jest potrzebna duża awaria. Wystarczy usunąć niewłaściwy folder, źle skonfigurować import lub wykonać zmianę w bazie produkcyjnej zamiast testowej.
| Zdarzenie | Możliwy skutek dla firmy | Co powinna uwzględniać strategia |
|---|---|---|
| Przypadkowe usunięcie lub masowa zmiana | Brak zgłoszeń, cen lub dokumentów; ręczne uzgadnianie danych | Wersje sprzed błędu przechowywane wystarczająco długo, aby go wykryć |
| Awaria sprzętu lub pamięci masowej | Przerwa w działaniu aplikacji i brak dostępu do danych | Kopia poza uszkodzonym zasobem i procedura odtworzenia |
| Nieudane wdrożenie lub migracja | Uszkodzone dane albo niezgodność z aplikacją | Kopia danych i zgodna z nimi wersja aplikacji |
| Przejęcie konta lub złośliwe oprogramowanie | Zniszczenie danych produkcyjnych i dostępnych kopii | Osobno chronione kopie oraz uprawnienia dostępu |
| Utrata dostępu do głównego środowiska | Dane istnieją, lecz firma nie może z nich korzystać | Możliwość pobrania kopii i odtworzenia systemu gdzie indziej |
Strata nie ogranicza się do plików. Pracownicy porównują informacje, realizacja zamówień się opóźnia, a wsparcie wyjaśnia problemy klientom. Jeśli oryginalne informacje nie istnieją w innym miejscu, pełne odtworzenie może być niemożliwe.
Backup pomaga odzyskać dane po awarii. Zapobieganie wyciekom i skracanie przestojów wymagają dodatkowych działań, na przykład kontroli dostępu i przygotowania środowiska zapasowego. Drugi serwer z bieżącą repliką bazy może powtórzyć to samo błędne usunięcie. Potrzebna jest też możliwość powrotu do stanu sprzed błędu.
Od czego zacząć planowanie
Spisz elementy potrzebne do działania aplikacji: bazy, pliki użytkowników, kod, konfigurację i dane dostępowe do usług. Przy każdym wskaż miejsce przechowywania i osobę odpowiedzialną. Dodaj zależności zewnętrzne, takie jak płatności, poczta i logowanie.
Sprawdź zakres kopii wykonywanych przez dostawcę. Wbudowana kopia bazy może zawierać tylko informacje o plikach, a nie same załączniki. Przywrócenie bazy nie odzyska wtedy usuniętego dokumentu. Pliki wymagają osobnej ochrony.
Następnie uzgodnij dwa cele:
- RPO, dopuszczalna utrata danych wyrażona w czasie: RPO wynoszące godzinę oznacza możliwość odtworzenia stanu danych nie starszego niż godzina w chwili awarii.
- RTO, dopuszczalny czas przywrócenia działania: obejmuje okres od przerwania usługi do odzyskania wymaganych funkcji.
Cele ustala się z osobami odpowiedzialnymi za pracę firmy. Czy dział sprzedaży poradzi sobie bez wczorajszych zgłoszeń? Czy aplikacja może nie działać do następnego dnia roboczego? Bardziej wymagające cele zwykle oznaczają większe nakłady.
Jedna kopia na dobę nie zapewni utraty najwyżej godziny danych bez innych źródeł odtworzenia. Częstsze kopie nie oznaczają też automatycznie krótszego przestoju. Uzyskanie dostępu, uruchomienie aplikacji i sprawdzenie jej działania również zajmują czas.
Jak wybrać sposób tworzenia kopii
Właściciel produktu określa dopuszczalną utratę danych i czas przestoju. Zespół dobiera metodę i sprawdza, czy odtworzenie spełnia te wymagania.
Przy niewielkiej ilości danych można zacząć od kopii pełnych, z których każda zawiera cały wybrany zbiór. To rozwiązanie ma sens, dopóki czas tworzenia i odtwarzania, koszty przechowywania oraz odstęp między kopiami są akceptowalne.
Gdy pełne kopie zajmują za dużo czasu lub miejsca, zapisuje się zmiany. Kopie przyrostowe obejmują zmiany od poprzedniej kopii, a różnicowe od ostatniej pełnej. Zespół musi sprawdzić, czy wszystkie części potrzebne do odtworzenia są dostępne i można je poprawnie wykorzystać razem.
Przy intensywnie zmieniającej się bazie przydatne bywa odtwarzanie do wybranego punktu w czasie, czyli PITR. Pozwala na przykład wrócić do momentu sprzed błędnego importu. PostgreSQL wykorzystuje do tego kopię bazową i zarchiwizowane dzienniki zmian. Wymagana sekwencja dzienników musi być kompletna. Mechanizm nie odtwarza wszystkich plików i ustawień aplikacji.
Gdzie przechowywać kopie i za co płacić
Miejsce przechowywania dobiera się do zdarzeń, przed którymi firma chce się zabezpieczyć.
| Podejście | Kiedy je rozważyć | Zaleta | Ograniczenie |
|---|---|---|---|
| Osobny lokalny magazyn | Trzeba szybko odtworzyć dużo danych, a zespół może utrzymywać magazyn | Mniejsza zależność od łącza zewnętrznego | Zdarzenie obejmujące całą lokalizację może dotknąć oryginał i kopie |
| Magazyn zdalny lub chmurowy | Kopia ma przetrwać utratę głównej lokalizacji | Dane pozostają w innym miejscu | Czas pobierania zależy od łącza i usługi; występują koszty przechowywania i transferu |
| Połączenie obu sposobów | Potrzebne są szybkie odtworzenie lokalne i osobna ścieżka po utracie lokalizacji | Dwie ścieżki odzyskiwania | Oba magazyny wymagają utrzymania, finansowania i testów |
Punktem wyjścia może być zasada 3-2-1: trzy egzemplarze danych łącznie z produkcyjnym, dwa rodzaje nośników i jedna kopia poza główną lokalizacją. Zasada nie określa częstotliwości, retencji ani uprawnień.
Porównując oferty, uwzględnij przechowywanie i transfer kopii, odzyskiwanie danych, konfigurację, utrzymanie oraz próbne odtworzenia. Do rachunku dostawcy dochodzą czas zespołu i środowisko testowe. Niższa cena za gigabajt nie przesądza o koszcie całej strategii.
Kopie dostawcy mogą być podstawą strategii, jeśli obejmują wymagane dane, historię i czas odtworzenia. Gdy uwzględniasz utratę głównego konta, potrzebujesz osobno chronionego sposobu uzyskania kopii. Jeśli uruchomienie od zera trwa zbyt długo, rozważ przygotowane środowisko zapasowe i koszty jego utrzymania.
Częstotliwość, retencja i ochrona kopii
Częstotliwość zależy od dopuszczalnej utraty danych i tempa zmian. Czas przechowywania zależy również od tego, kiedy wykrywane są błędy. Jeśli niepoprawny import zostanie zauważony po tygodniu, a historia obejmuje tylko trzy dni, potrzebnego stanu może już nie być.
Sprawdź, kto może usunąć kopie. Inna lokalizacja nie rozwiązuje problemu przejętego konta, jeśli te same dane dostępowe pozwalają skasować oba środowiska. Można rozdzielić uprawnienia administracyjne, przechowywać część kopii offline albo zastosować magazyn blokujący zmiany i usuwanie przez określony czas. Dobór zależy od scenariusza.
Warto zautomatyzować kopiowanie, ale powiadomienia o błędach muszą trafiać do osoby, która wie, jak zareagować. Kontroluj datę ostatniej użytecznej kopii: zadanie mogło kończyć się błędem przez kilka dni. Jeśli kopie są szyfrowane, osoba odpowiedzialna za odtworzenie musi mieć dostęp do kluczy także po utracie głównego środowiska.
Przykład strategii dla aplikacji biznesowej
Rozważmy hipotetyczny serwis zgłoszeń z dokumentami klientów. Firma jest gotowa ręcznie odtworzyć najwyżej godzinę nowych zgłoszeń i zaakceptować cztery godziny przestoju. Pracownicy sprawdzają importy raz w tygodniu.
Nocna kopia bazy nie wystarczy, bo pomiędzy kopiami mogą przybyć zgłoszenia z niemal całego dnia. Zespół rozważa PITR i sprawdza, czy w razie awarii da się odzyskać stan nie starszy niż godzina. Dokumenty potrzebują osobnego procesu kopiowania z takim samym dopuszczalnym opóźnieniem.
Baza i pliki muszą wrócić do zgodnego stanu. Odtworzone zgłoszenie może wskazywać dokument, którego nie ma już w magazynie. Podczas testu należy otworzyć załączniki z odzyskanych zgłoszeń i sprawdzić dostęp właściwych użytkowników.
W tym przykładzie zespół proponuje historię z 14 dni. Błąd może czekać na cotygodniową kontrolę, a potem potrzebny jest czas na analizę. Okres trzeba jeszcze ocenić wobec innych scenariuszy utraty danych i wymagań firmy.
Kod i konfigurację zapisuje się przy każdej zmianie. Hasła i klucze trafiają do chronionego magazynu sekretów dostępnego osobom odpowiedzialnym za odtworzenie. Następnie mierzy się czas uruchomienia usługi. Jeśli przekracza cztery godziny, częstszy backup tego nie naprawi. Trzeba przyspieszyć uruchamianie lub przygotować środowisko zapasowe.
Jak utrzymać skuteczną strategię
Regularnie odtwarzaj dane w osobnym środowisku. Czy użytkownik może się zalogować, otworzyć zgłoszenie z załącznikiem i utworzyć nowy rekord? Ogranicz dostęp do odtworzonych danych oraz wyłącz rzeczywiste płatności i wysyłkę wiadomości. Zapisz czas i problemy napotkane podczas testu.
Powtarzaj kontrole po istotnych zmianach produktu. Harmonogram zależy od znaczenia danych i tempa zmian. Test w osobnym środowisku nie potwierdza pełnego RTO produkcji, jeśli nie obejmuje wykrycia awarii, reakcji specjalisty i przełączenia użytkowników.
Rozmowę z zespołem lub wykonawcą zacznij od czterech pytań:
- Co stracimy, jeśli główny serwer lub konto staną się niedostępne?
- Jak aktualną kopię uzyskamy i gdzie jest przechowywana?
- Kto odtworzy aplikację i ile trwał ostatni test?
- Co zmieniło się od tego testu i czy plan backupu to obejmuje?
Odpowiedzi ujawnią konkretne braki: pominięte załączniki, zbyt krótką historię, niedostępne klucze lub zbyt długi czas uruchomienia. Na tej podstawie można zlecić prace i porównać oferty wykonawców.
Planujesz uruchomienie lub rozwój aplikacji? Opisz projekt w formularzu poniżej. Wskaż dane, które trzeba chronić, oraz dopuszczalny czas przestoju, abyśmy mogli uwzględnić te wymagania podczas rozmowy o pracach.
