# Migawki i kopie zapasowe: wybierz awarię, którą musisz przetrwać | SwissOctet Insights https://swissoctet.com/pl/insights/snapshots-backups-consistency/ SwissOctet / Spostrzeżenia / Pamięć masowa i odzyskiwanie Pamięć masowa i odzyskiwanie Praktyczne · 4 min czytania Migawki i kopie zapasowe: wybierz awarię, którą musisz przetrwać Porównaj punkty odtwarzania, granice awarii i spójność aplikacji, zamiast zakładać, że migawka i niezależna kopia zapasowa zapewniają taką samą ochronę. Autor: SwissOctet Editorial Zapisz przewodnik Kopiuj link NA TEJ STRONIE 01 Opisz kopię, zanim ją nazwiesz 02 Porównaj awarie, które oczekujesz przetrwać 03 Sprawdź spójność aplikacji 04 Traktuj retencję jako okno odzyskiwania 05 Oddziel udane zadania od zweryfikowanych danych 06 Przetestuj małe, kompletne odzyskiwanie 07 Czytaj opcjonalne kopie zapasowe jako konkretną usługę Twoja praktyczna lista kontrolna Źródła i dalsza lektura Powrót do biblioteki BEZPOŚREDNIA ODPOWIEDŹ 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. 01 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. 02 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? 03 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. 04 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. 05 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. 06 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. 07 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. ZAMIEŃ TO W DZIAŁANIE 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. Pobierz listę kontrolną CZĘSTE PYTANIA 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ć. GŁÓWNE ŹRÓDŁA 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. POŁĄCZ WIEDZĘ Powiązana infrastruktura. Vault Storage Szwajcaria Pulse NVMe Szwajcaria Metal Zenith Szwajcaria ZACHOWAJ WĄTEK Twoje następne notatki z terenu. Poznaj wszystkie przewodniki NOTATKA Z TERENU / 01 + Pamięć masowa i odzyskiwanie Podstawy Kiedy NVMe robi różnicę w Twojej aplikacji Rozróżnij wydajność, opóźnienie i przepustowość, aby szybsza etykieta storage odpowiadała realnemu problemowi aplikacji. 4 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 02 + Pamięć masowa i odzyskiwanie Zaawansowane Zmierz wydajność NVMe bez wprowadzania się w błąd Zdefiniuj wzorzec wejścia/wyjścia, kontroluj efekty pamięci podręcznej i sprawdź rozkłady opóźnień, zanim wyciągniesz wniosek o aplikacji z testu dysku. 6 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 03 + Pamięć masowa i odzyskiwanie Podstawy Pamięć obiektowa, plikowa lub blokowa: wybierz interfejs potrzebny aplikacji Rozróżnij interfejsy pamięci masowej, semantykę dostępu i obowiązki operacyjne, zanim przekształcisz wymaganie pojemności w architekturę aplikacji. 4 min czytania Przeczytaj przewodnik