Pełny klon systemowego dysku SSD z ZimaOS nie jest jedynym — ani koniecznie najważniejszym — zasobem do odzyskiwania. Użytkownik miał 512 GB NVMe z systemem operacyjnym oraz cztery dyski NVMe o pojemności 2 TB, planowane do pracy w macierzy RAID 5, i chciał wiedzieć, czy utrata dysku z systemem zagrozi macierzy.
Obecny projekt odzyskiwania ZimaOS daje jaśniejszą odpowiedź niż pierwotny wątek z 2025 roku: ZimaOS korzysta z dwóch partycji systemowych umożliwiających szybkie odzyskiwanie podczas uruchamiania, dane są przechowywane oddzielnie od partycji systemowych, a IceWhale dokumentuje teraz tworzenie kopii zapasowej pliku local-storage.db, aby po ponownej instalacji systemu można było przywrócić konfigurację RAID. Najcenniejszym celem kopii zapasowej nadal pozostają rzeczywiste dane i stan aplikacji.
ZimaOS ma system odzyskiwania oparty na dwóch partycjach
Aktualna dokumentacja IceWhale dotycząca odzyskiwania systemu mówi, że ZimaOS korzysta z partycji Slot A i Slot B, z których każda ma około 6 GB, dzięki czemu użytkownik może uruchomić system z alternatywnej partycji, gdy jedna z nich ulegnie awarii.
Pozwala to obsłużyć niektóre awarie oprogramowania lub procesu uruchamiania bez wymiany dysku SSD.
Skorzystaj z aktualnej procedury odzyskiwania ZimaOS z dwóch partycji, zanim uznasz, że każdy problem z uruchamianiem wymaga pełnego odtworzenia dysku.
Uszkodzenie systemowego dysku SSD różni się od awarii partycji systemowej
Jeśli sam dysk NVMe uległ fizycznej awarii, obie partycje A/B przepadają razem z nim. W takiej sytuacji konieczna jest wymiana dysku systemowego i ponowna instalacja ZimaOS.
Celem jest przeprowadzenie ponownej instalacji w taki sposób, aby system mógł ponownie wykryć lub przywrócić konfigurację danych i pamięci masowej, bez traktowania członków macierzy RAID jak pustych dysków.
Utwórz kopię zapasową pliku local-storage.db, zanim będzie potrzebny
Aktualny przewodnik IceWhale dotyczący odbudowy RAID zaleca zapisanie pliku:
/ZimaOS-HD/.casaos/db/local-storage.dbprzed ponowną instalacją systemu. Po zainstalowaniu nowego systemu ZimaOS przewodnik zaleca zmianę nazwy nowej bazy danych, przesłanie kopii zapasowej do tej samej lokalizacji i ponowne uruchomienie systemu.
Postępuj zgodnie z oficjalną procedurą odbudowy RAID po ponownej instalacji, zamiast ręcznie edytować bazę danych.
Nie twórz ponownie macierzy RAID tylko dlatego, że świeża instalacja systemu inaczej pokazuje dyski
Dyski należące do macierzy RAID mogą nadal zawierać prawidłowe metadane RAID i dane, nawet gdy nowa instalacja systemu nie ma już poprzedniej bazy danych pamięci masowej ZimaOS.
Jeśli na tych dyskach znajdują się ważne pliki, nie klikaj opcji tworzenia macierzy RAID, nie formatuj ich ani nie usuwaj metadanych, dopóki nie poznasz właściwej ścieżki odzyskiwania.
Twórz kopie zapasowe AppData i baz danych aplikacji
Odpowiedź społeczności z 2025 roku upraszczała kwestię stanu aplikacji, wskazując, że znajduje się on w lokalizacji /DATA/AppData. Obecny ZimaOS wyraźniej oddziela te dane, ale obsługuje również różne lokalizacje danych aplikacji i niestandardowe montowania bind.
Twórz kopie zapasowe trwałych folderów aplikacji i korzystaj z eksportu uwzględniającego specyfikę aplikacji w przypadku baz danych, takich jak Nextcloud, Immich i inne usługi, dla których samo skopiowanie folderu może nie wystarczyć.
Aktualne wskazówki dotyczące ścieżek pamięci aplikacji w ZimaOS pomagają ustalić, które dane przetrwają ponowne utworzenie kontenera.
Pełny klon systemu operacyjnego nadal może być przydatny, ale ma swoje kompromisy
Klon na poziomie bloków może skrócić czas odzyskiwania, jeśli jest aktualny, spójny i utworzony za pomocą metody, która prawidłowo przechwytuje działający system plików. Klon szybko jednak staje się nieaktualny wraz ze zmianami ustawień aplikacji, metadanych pamięci masowej i aktualizacji systemu operacyjnego.
Jeśli podczas tworzenia obrazu na dysku systemowym aktywnie zapisywane są dane, spójność ma znaczenie. Nie zakładaj, że „skopiowanie każdego bloku podczas pracy systemu” automatycznie utworzy niezawodny obraz do przywrócenia.
Kopia zapasowa danych jest ważniejsza niż wymienny system operacyjny
Obecny ZimaOS zawiera aplikację Backup, która może chronić dane na dyskach lokalnych, innym serwerze NAS, urządzeniu USB lub w chmurze, a także obsługuje zaplanowane kopie zapasowe i wersjonowanie.
Skorzystaj z aktualnej strategii kopii zapasowych 3-2-1 dla plików, których nie można po prostu ponownie zainstalować.
Praktyczny plan na wypadek awarii dysku systemowego
- Przechowuj aktualną kopię pliku
local-storage.dbpoza dyskiem systemowym. - Niezależnie twórz kopie zapasowe stanu aplikacji i danych użytkownika.
- Udokumentuj niestandardowe woluminy aplikacji i stosy Compose.
- Dowiedz się, jak uruchomić system z alternatywnej partycji ZimaOS.
- Jeśli dysk SSD ulegnie fizycznej awarii, wymień go i zainstaluj ponownie ZimaOS.
- Przywróć bazę danych pamięci masowej, korzystając z oficjalnej procedury.
- Sprawdź macierz RAID przed wprowadzeniem jakichkolwiek destrukcyjnych zmian w pamięci masowej.
- Zainstaluj ponownie aplikacje lub podłącz je ponownie do ich trwałych danych.
Najczęstsze pytania dotyczące kopii zapasowej dysku systemowego
Czy awaria uruchamiania ZimaOS zawsze oznacza konieczność wymiany systemowego dysku SSD?
Nie. Obecny ZimaOS ma dwie partycje systemowe, a alternatywna partycja może umożliwić odzyskanie systemu po niektórych awariach.
Jaki niewielki plik jest szczególnie przydatny przed ponowną instalacją systemu?
Aktualny przewodnik IceWhale dotyczący odzyskiwania RAID zaleca utworzenie kopii zapasowej pliku local-storage.db.
Czy sama macierz RAID 5 jest kopią zapasową danych?
Nie. RAID zapewnia dostępność danych po awarii dysku; przechowuj niezależne kopie zapasowe na wypadek usunięcia, uszkodzenia, kradzieży lub katastrofy.
