Migawka to reprezentacja punktu w czasie, której ochrona zależy od jej implementacji. Strategia kopii zapasowych dodaje celową retencję, rozdzielenie dostępu i przetestowane odzyskiwanie. Niektóre migawki są kopiami zapasowymi; inne zależą od oryginalnej pamięci masowej. Zapytaj, co przetrwa usunięcie, kompromitację lub utratę środowiska podstawowego.
Opisz kopię, zanim ją nazwiesz
Słowo „snapshot” mówi, że został odwzorowany pewien punkt w czasie, ale nie mówi, gdzie znajdują się dane możliwe do odzyskania ani kto może je usunąć. Snapshot systemu plików w oryginalnym magazynie i snapshot blokowy zarządzany przez dostawcę mogą mieć różne granice awarii. Zacznij od implementacji, zamiast traktować etykietę jako uniwersalną obietnicę.
AWS dokumentuje snapshoty EBS jako przyrostowe kopie zapasowe wolumenów w określonym punkcie w czasie. To konkretna implementacja, a nie dowód, że każda opcja snapshotów działa tak samo. W przypadku dowolnej usługi zapytaj, czy odtworzenie zależy od oryginalnego wolumenu, czy kopie opuszczają główną domenę awarii i co się dzieje, gdy źródło zostanie usunięte.
Porównaj awarie, które oczekujesz przetrwać
Szybkie wycofanie po aktualizacji i odzyskanie po utracie konta to różne problemy. Lokalny snapshot może być wygodny w pierwszym przypadku, oferując niewielkie rozdzielenie w drugim. Niezależne kopie mogą zwiększyć ochronę, ale tylko wtedy, gdy ich ścieżki przechowywania, dostępu i usuwania są wystarczająco oddzielone od incydentu, na który się przygotowujesz.
Zapisz awarię i wymagany rezultat. To ilustracyjne porównanie jest pomocą w podejmowaniu decyzji, a nie listą funkcji SwissOctet. Zachęca do zadawania pytań o kopie i kontrolę, zamiast twierdzenia, że jedna technologia jest zawsze lepsza. Rzeczywisty wynik zależy od konfiguracji i udokumentowanego procesu odzyskiwania operatora.
| Scenariusz | Pytanie o snapshot | Pytanie o kopię zapasową |
|---|---|---|
| Nieudana aktualizacja aplikacji | Czy mogę wrócić do zamierzonego punktu? | Ile trwa użyteczne odtworzenie? |
| Utrata dysku podstawowego | Czy kopia zależy od tego dysku? | Czy mogę odtworzyć na nowym magazynie? |
| Przejęcie konta administracyjnego | Czy to konto może usunąć każdą kopię? | Czy uprawnienia do usuwania są rozdzielone? |
| Błąd wykryty tygodnie później | Czy ten punkt jest nadal przechowywany? | Czy okres przechowywania obejmuje opóźnienie wykrycia? |
Sprawdź spójność aplikacji
Dysk może przechwycić pliki, gdy aplikacja wciąż je zmienia. W zależności od oprogramowania i procesu tworzenia snapshotów wynik może przedstawiać stan spójny po awarii, a nie skoordynowany stan aplikacji. Nie zakładaj, że czytelne pliki oznaczają zgodność bazy danych i powiązanych z nią przesłanych plików. Użyj metody tworzenia kopii zapasowych udokumentowanej przez aplikację lub bazę danych.
Projekt ciągłego archiwizowania w PostgreSQL ilustruje tę różnicę: odzyskiwanie wymaga odpowiedniej kopii bazowej i ciągłej sekwencji wymaganych plików write-ahead log. Katalog skopiowany bez staranności podczas działania bazy danych nie jest równoważną procedurą. Jeśli aplikacja przechowuje również pliki poza bazą danych, zaplanuj, jak oba te zbiory danych są odzyskiwane razem.
Traktuj retencję jako okno odzyskiwania
Okres przechowywania powinien uwzględniać, jak długo błąd może pozostać niezauważony. Okno dziesięciu dni nie pomoże w przypadku przypadkowego usunięcia wykrytego po miesiącu. Przechowywanie każdej kopii bezterminowo tworzy inny problem: koszty, rosnące narażenie danych wrażliwych i niejasną politykę usuwania. Wybierz okres przechowywania na podstawie konkretnych wymagań operacyjnych i dotyczących przetwarzania danych.
Oznaczaj punkty odzyskiwania użytecznym kontekstem, takim jak wersja aplikacji i czas zakończenia zadania, bez osadzania sekretów. Zachowaj wystarczającą historię, aby odróżnić dobry stan od uszkodzonego. Przed czyszczeniem potwierdź, jak wybrany system obsługuje dane współdzielone lub przyrostowe; usunięcie oznaczonego punktu może nie odpowiadać usunięciu prostego, samodzielnego pliku.
Oddziel udane zadania od zweryfikowanych danych
Narzędzie do tworzenia kopii zapasowych zgłaszające sukces potwierdza, że jego proces zakończył się zgodnie z jego regułami. Nie dowodzi automatycznie, że wybrano wszystkie ważne dane aplikacji, że każdy przechowywany bajt pozostaje nienaruszony ani że nowy serwer może użyć wyniku. To różne kontrole. Uwzględnij w planie operacyjnym kondycję repozytorium, przegląd wyboru danych i reprezentatywne odtworzenie.
Restic dokumentuje różnicę między domyślnym sprawdzaniem repozytorium a weryfikacją, która odczytuje przechowywane dane pakietów. Pełne sprawdzenie odczytujące dane może zużywać więcej czasu i przepustowości. Ten przykład konkretyzuje kwestię planowania: zdecyduj, co weryfikacja faktycznie odczytuje, i zaplanuj na to budżet. Korzystaj z dokumentacji narzędzia, zamiast zakładać, że każde polecenie o nazwie „check” ma takie samo pokrycie.
Przetestuj małe, kompletne odzyskiwanie
Wyobraź sobie publikację z bazą danych, przesłanymi obrazami i konfiguracją. Odtwórz wszystkie trzy elementy w prywatnym środowisku testowym, a następnie otwórz artykuł i zweryfikuj jego załączniki. Podczas ćwiczenia pozostaw wyłączone zaplanowane integracje poczty, płatności i publikowania. Testowanie tylko losowego pliku tekstowego pominęłoby relacje, które czynią aplikację użyteczną.
Zmierz wymagany czas i zapisz, których danych uwierzytelniających, wersji pakietów lub zależności zewnętrznych brakowało. Sprawdź uprawnienia do odzyskanych plików, nie tylko ich zawartość. Ćwiczenie odzyskiwania często ujawnia, że dane istnieją, ale instrukcje lub dostęp potrzebne do ich użycia nigdy nie zostały zachowane razem z planem operacyjnym.
Czytaj opcjonalne kopie zapasowe jako konkretną usługę
Konfigurując SwissOctet, sprawdź dokładną opcję tworzenia kopii zapasowych i okres przechowywania dla danej rodziny. Zapytaj, które wolumeny i dane aplikacji obejmuje, czy odzyskiwanie jest samoobsługowe i co się dzieje, gdy zmienia się konfiguracja podstawowa. Sama etykieta opcji nie ustanawia niezależnej kopii, niezmiennego repozytorium ani punktu odzyskiwania spójnego z bazą danych.
Używaj snapshotów tam, gdzie pasują do obciążenia, i utrzymuj szerszą strategię tworzenia kopii zapasowych na wypadek awarii, których nie obejmują. Zapisz niezależną ścieżkę odzyskiwania ważnych danych, chroń dane uwierzytelniające, które mogą usunąć kopie, i testuj procedurę. Najlepszy wybór to ten, który przetrwa zdefiniowany scenariusz, a nie ten o najbardziej kojącej nazwie.
Twoja praktyczna lista kontrolna.
- Ustal, gdzie znajdują się dane możliwe do odzyskania.
- Wymień awarie, które kopia musi przetrwać.
- Użyj metody spójności obsługiwanej przez aplikację.
- Wybierz okres przechowywania odpowiedni do okna wykrycia.
- Chroń uprawnienia do usuwania osobno.
- Odtwórz kompletną aplikację w izolacji.
Szczegóły, które mają znaczenie.
Czy snapshot nigdy nie jest kopią zapasową?+
Niektóre implementacje snapshotów są kopiami zapasowymi. Użyteczne rozróżnienie dotyczy ich zależności od magazynu, okresu przechowywania, modelu dostępu i przetestowanego odzyskiwania, a nie samej etykiety.
Czy udane sprawdzenie integralności dowodzi, że aplikacja będzie działać?+
Dowodzi tylko tego, co obejmuje to sprawdzenie. Przetestuj osobno odtwarzanie aplikacji, konfigurację, uprawnienia i relacje między danymi.
Czy kopię zapasową należy przechowywać na tym samym serwerze?+
Kopia na tym samym serwerze może pomóc w ograniczonych błędach, ale dzieli ważne awarie. Ważne dane wymagają ścieżki odzyskiwania poza granicą awarii, którą zamierzasz przetrwać.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- Amazon EBS: snapshoty docs.aws.amazon.com
- PostgreSQL: ciągłe archiwizowanie i odzyskiwanie do punktu w czasie www.postgresql.org
- Restic: praca z repozytoriami i sprawdzanie integralności restic.readthedocs.io
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.