Strona 2 tego poradnika społecznościowego zmienia pytanie z „jak uruchomić dd?” na „co właściwie warto chronić?”. Użytkownik miał już duży działający dysk NVMe i znacznie bardziej zależało mu na utracie danych niż na utracie uruchamialnego systemu operacyjnego. Rada gelbuilding polegała na tym, aby unikać ponownego partycjonowania działającego dysku rozruchowego NVMe, w pierwszej kolejności chronić DATA/AppData, a pełną kopię surową systemu przechowywać tylko wtedy, gdy korzyść w postaci krótszego czasu odzyskiwania uzasadnia dodatkowe miejsce na kopię zapasową.
Ten priorytet pasuje do obecnej architektury ZimaOS. System operacyjny ma sloty systemowe A/B umożliwiające szybkie odzyskiwanie, natomiast niezastąpione dane użytkownika, AppData i metadane pamięci masowej znajdują się poza tymi niezmiennymi obrazami systemu. Kopia całego dysku może szybko przywrócić komputer do dokładnego stanu z określonego momentu, ale nie zastępuje niezależnych kopii zapasowych DATA z wersjonowaniem.
dd klonuje całe urządzenie, a nie tylko małe sloty systemowe
W oryginalnym poradniku użyto koncepcyjnie polecenia takiego jak:
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzJeśli system znajduje się na dysku NVMe o pojemności 1 TB, proces tworzenia obrazu surowego nadal odczytuje całe urządzenie blokowe. Kompresja może zmniejszyć rozmiar pliku, ale miejsce docelowe kopii zapasowej i sam proces są powiązane z fizycznym układem dysku, a nie tylko z kilkoma gigabajtami zajmowanymi przez partycje systemowe ZimaOS.
Nie zmieniaj partycji sprawnego działającego systemu tylko po to, aby zmniejszyć kopię dd
gelbuilding uznał ponowne partycjonowanie działającego dysku rozruchowego NVMe za obarczone wysokim ryzykiem, ponieważ błąd może spowodować przestój lub utratę danych. Jeśli obeczy układ działa, przed zmianą granic partycji utwórz zweryfikowane kopie zapasowe danych.
Chroń DATA i AppData przed utworzeniem klonu systemu
Jeśli najważniejsza jest możliwość odzyskania danych, wykonaj kopię zapasową:
- plików użytkownika i pul pamięci masowej;
- danych AppData, baz danych i konfiguracji, których nie można łatwo odtworzyć;
- ważnych eksportów właściwych dla używanych aplikacji;
- metadanych pamięci masowej ZimaOS, takich jak
local-storage.db, gdy ma to zastosowanie; - a dopiero potem, opcjonalnie, całego dysku systemowego.
Obecne zalecenia ZimaOS dotyczące reguły 3-2-1 obejmują zaplanowane kopie zapasowe w niezależnych lokalizacjach oraz wersjonowane punkty przywracania.
Skorzystaj z obecnego modelu kopii zapasowych 3-2-1 w ZimaOS.
Obecny ZimaOS ma już odzyskiwanie systemu A/B
ZimaOS używa dwóch slotów systemowych o pojemności około 6 GB każdy. Jeśli jeden ze slotów ulegnie awarii, aktualny przewodnik odzyskiwania pozwala uruchomić alternatywny slot z poziomu GRUB.
Skorzystaj z obecieżki odzyskiwania systemu A/B.
Czysta ponowna instalacja może odtworzyć system operacyjny, ale nie przywróci automatycznie dokładnej konfiguracji
Jak zauważył constgen, niezmienny system operacyjny często można po prostu zainstalować ponownie. Kontrargument gelbuilding dotyczył czasu odzyskiwania: klon dysku może dokładnie przywrócić aplikacje, konfigurację i stan systemu z chwili wykonania kopii, podczas gdy ponowna instalacja może wymagać ponownego przypisania AppData, zainstalowania aplikacji i ponownego połączenia metadanych pamięci masowej.
Obie strategie odzyskiwania są prawidłowe — optymalizują różne aspekty.
Mały dedykowany dysk rozruchowy upraszcza klonowanie całego dysku
gelbuilding zalecił, aby docelowo przenieść ZimaOS na małe, dedykowane urządzenie o pojemności 32–64 GB, a dużą pamięć NVMe/RAID przeznaczyć na DATA/AppData. Dokładne minimalne wymagania obecnej instalacji ZimaOS to co najmniej 25 GB.
Oddziela to system operacyjny, który można łatwo odtworzyć, od dużej pamięci na dane i znacznie zmniejsza rozmiar pełnego obrazu systemu.
Polecenia przywracania surowego obrazu są destrukcyjne
Przywracanie obrazu dd zapisuje dane bezpośrednio na docelowym dysku. Wybranie niewłaściwego celu /dev/... może zniszczyć inny dysk. Oryginalny poradnik został wyraźnie udostępniony do celów testowych, a tych poleceń należy używać dopiero po zidentyfikowaniu dysków na podstawie modelu i numeru seryjnego oraz zabezpieczeniu DATA w innym miejscu.
Przetestuj proces odzyskiwania, a nie tylko tworzenie kopii zapasowej
Kopia zapasowa jest przydatna tylko wtedy, gdy wiadomo, jak ją przywrócić. W przypadku DATA przywróć reprezentatywne pliki. W przypadku surowego obrazu systemu, jeśli to możliwe, przetestuj procedurę na zapasowym nośniku, zamiast odkrywać założenia dotyczące urządzenia lub ścieżki dopiero podczas rzeczywistej awarii.
ZimaOS: klonowanie a kopie zapasowe — FAQ
Czy pełny klon dysku systemowego jest wymagany do ochrony danych ZimaOS?
Nie. Kopie zapasowe DATA/AppData i metadane pamięci masowej są niezależne od partycji systemowych A/B i mają wyższy priorytet w przypadku niezastąpionych informacji.
Dlaczego mimo wszystko warto przechowywać surowy klon systemu operacyjnego?
Może skrócić czas odzyskiwania, przywracając dokładnie przechwyconą konfigurację systemu i aplikacji zamiast wymagać jej ręcznego odtwarzania.
Czy należy ponownie podzielić działający dysk NVMe na partycje tylko po to, aby zmniejszyć rozmiar klonu?
Zgodnie z pierwotną rekomendacją — nie; najpierw wykonaj kopię zapasową DATA i unikaj niepotrzebnych zmian partycji działającego systemu.
