Dlaczego migawka domowego NAS może zachować dane, które są już uszkodzone?

Migawka domowego NAS może zachować uszkodzone dane, ponieważ jej zadaniem jest zachowanie stanu systemu plików, a nie decydowanie, czy każdy plik w tym stanie jest zdrowy. Jeśli baza danych, dokument, zdjęcie lub plik multimedialny jest już uszkodzony w momencie tworzenia migawki, przywrócenie tej migawki może odtworzyć tę samą uszkodzoną wersję.

Czas wystąpienia uszkodzenia ma znaczenie. Migawka może chronić wcześniejszą wersję przed późniejszym nadpisaniem, ale nie może stworzyć czystej wersji, która nigdy nie została uchwycona. Udostępnianie bloków metodą copy-on-write tworzy też drugi przypadek: uszkodzenie fizyczne bloku może wpłynąć na więcej niż jeden widok systemu plików, który nadal odnosi się do tego bloku.

Migawka zachowuje stan systemu plików, a nie znaną, dobrą kopię

Migawka systemu plików rejestruje stan magazynu w określonym momencie. Na przykład w OpenZFS migawka to tylko do odczytu wersja systemu plików lub woluminu, która początkowo współdzieli dane z aktywnym zestawem danych, zamiast duplikować każdy plik. Dokumentacja migawek OpenZFS opisuje, jak migawka zachowuje dane, które w przeciwnym razie pozostałyby współdzielone do momentu zmiany aktywnego zestawu danych.

Ta operacja nie ustala, czy przechowywana zawartość jest semantycznie poprawna. System plików może zachować strukturalnie czytelny plik, nawet gdy aplikacja zapisała nieprawidłowe rekordy, narzędzie synchronizacyjne skopiowało niewłaściwą wersję lub ransomware zastąpiło oryginalne bajty zaszyfrowaną zawartością. Sukces migawki oznacza więc, że stan został zachowany; nie gwarantuje, że stan był dobry.

Uszkodzenie obecne w momencie migawki staje się częścią punktu odzyskiwania

Weźmy pod uwagę zaplanowaną migawkę utworzoną o północy. Jeśli aplikacja uszkodzi bazę danych o 22:00, migawka z północy rejestruje stan systemu plików po uszkodzeniu. Przywrócenie do tej migawki cofa bazę danych do północy, ale północ jest już za późno, by zapewnić zdrową kopię.

Ta sama sekwencja może wystąpić po błędnej synchronizacji, niepełnym imporcie, przypadkowym zapisie lub nieautoryzowanym zaszyfrowaniu. Migawka nie „utrwala” uszkodzenia jako specjalnej właściwości; po prostu zachowuje wersję istniejącą w momencie jej wykonania. Starsza migawka może nadal zawierać użyteczną wersję, ale każda migawka utworzona po uszkodzeniu może zawierać ten sam błąd logiczny.

Czas wystąpienia uszkodzenia decyduje, czy migawka może pomóc

Migawka jest najbardziej przydatna, gdy niepożądana zmiana logiczna następuje po punkcie odzyskiwania. Jeśli migawka z poniedziałku zawiera zdrowy plik, a plik na żywo zostanie nadpisany we wtorek, widok z poniedziałku nadal może ujawnić wcześniejsze dane. Jeśli plik był już uszkodzony w poniedziałek, ten sam punkt odzyskiwania nie rozwiąże problemu.

Uszkodzenie podstawowego nośnika tworzy inną ścieżkę. Migawka mogła być zdrowa w momencie utworzenia, ale później stać się nieczytelna, jeśli uszkodzony zostanie fizyczny blok, do którego nadal się odnosi, a system plików nie może odtworzyć zweryfikowanej kopii. Dlatego czas wystąpienia korupcji musi być rozpatrywany razem ze współdzieleniem bloków i nadmiarowością pamięci.

Współdzielenie bloków copy-on-write może ujawnić uszkodzony blok w wielu migawkach

Migawki copy-on-write są efektywne pod względem przestrzeni, ponieważ niezmienione dane są współdzielone. Dokumentacja modelu przechowywania Btrfs wyjaśnia, że migawka i jej źródłowy podwolumin współdzielą swoje wspólne, niezmodyfikowane dane. Migawka jest więc historycznym widokiem systemu plików, a nie automatycznie drugą fizyczną kopią na oddzielnym nośniku.

Gdy plik na żywo jest normalnie modyfikowany, copy-on-write przydziela nowe miejsce na zmianę, podczas gdy migawka nadal odnosi się do wcześniejszych bloków. To rozdzielenie umożliwia wycofanie zmian. Jednak jeśli niezmieniony blok jest nadal współdzielony, a przechowywany blok później staje się nieczytelny lub zwraca błędne dane, wszystkie widoki zależne od niego mogą napotkać tę samą awarię.

Sumy kontrolne i nadmiarowa pamięć mogą zmienić wynik, wykrywając niezgodność i dostarczając inną kopię, ale sama migawka nie tworzy tej ochrony. Copy-on-write zapewnia rozdzielenie wersji; nie tworzy niezależnej domeny awarii sprzętowej.

Sumy kontrolne i skanowania testują integralność; migawki tego nie robią

Migawki, sumy kontrolne i skanowanie należą do różnych części stosu ochrony. Migawka zachowuje historię, suma kontrolna pomaga określić, czy przechowywane bajty zmieniły się nieoczekiwanie, a skanowanie proaktywnie odczytuje przechowywane dane w poszukiwaniu błędów. Traktowanie tych funkcji jako wymiennych prowadzi do fałszywego poczucia pewności co do tego, co punkt odzyskiwania może potwierdzić.

Sumy kontrolne mogą wykrywać nieoczekiwane zmiany bloków

Dokumentacja Btrfs dotycząca sum kontrolnych stwierdza, że sumy kontrolne są obliczane przed zapisami i weryfikowane po odczycie bloków z magazynu. Niezgodność może ujawnić, że pobrany blok nie jest tym samym, który system plików spodziewał się przechowywać.

Zgodność sumy kontrolnej nie dowodzi, że dokument, baza danych lub plik multimedialny jest logicznie poprawny. Jeśli aplikacja zapisze złe dane przez normalną ścieżkę zapisu, system plików może obliczyć prawidłową sumę kontrolną dla tych złych bajtów. Blok jest nienaruszony z perspektywy systemu plików, mimo że zawartość na poziomie aplikacji jest bezużyteczna.

Redundancja decyduje, czy skanowanie może naprawić uszkodzenie

Skanowanie może wykryć błędy sum kontrolnych, błędy odczytu i niektóre problemy z metadanymi, ale wykrycie nie jest tym samym co naprawa. Dokumentacja Btrfs dotycząca skanowania wyjaśnia, że automatyczna naprawa na replikowanym magazynie wykorzystuje zweryfikowane dobre dane z innej repliki. Bez ważnej alternatywnej kopii system plików może zidentyfikować uszkodzony blok, ale nie być w stanie go odtworzyć.

Badanie USENIX dotyczące integralności danych w ZFS podobnie rozdziela wykrywanie oparte na sumach kontrolnych od odzyskiwania za pomocą redundancji. Praktyczna lekcja jest węższa niż „skanowanie naprawia uszkodzenia”: skanowanie może naprawić tylko te błędy, dla których system przechowywania może zlokalizować lub odtworzyć wiarygodne dane zastępcze.

Przechowywanie migawek pomaga tylko wtedy, gdy istnieje jeszcze zdrowy stan

Uszkodzenia nie zawsze są zauważane od razu. Rzadko otwierane zdjęcie, archiwum lub plik projektu może pozostać uszkodzony przez tygodnie, zanim ktoś spróbuje go użyć. Jeśli rotacja migawek usunęła już każdą wersję sprzed uszkodzenia, nawet głęboka kolekcja niedawnych migawek może nie zawierać żadnego zdrowego punktu przywracania.

Okres przechowywania powinien zatem odzwierciedlać prawdopodobny czas wykrywania, a nie tylko częstotliwość tworzenia migawków. Migawki godzinowe zapewniają szczegółową, niedawną historię, podczas gdy dłużej przechowywane punkty dzienne, tygodniowe lub miesięczne wydłużają okres, w którym można wykryć niezauważony błąd. Nie ma uniwersalnego harmonogramu: użyteczny interwał zależy od szybkości zmian, dostępnej pojemności oraz tego, jak szybko zwykle sprawdzane są ważne pliki.

Zweryfikuj migawkę przed zastąpieniem aktywnych danych NAS

Wybór migawki według daty to tylko pierwszy krok. Przed przywróceniem całego zestawu danych lub zastąpieniem aktywnego pliku, przywróć wersję kandydata do osobnej lokalizacji, jeśli platforma domowego NAS na to pozwala. Zapobiega to nadpisaniu nowszych danych, które mogą być jeszcze przydatne, przez niezweryfikowaną próbę odzyskania.

1. Oszacuj, kiedy pojawiło się uszkodzenie.
2. Wybierz migawkę sprzed tego czasu.
3. Przywróć kandydat do alternatywnego folderu lub klonu.
4. Otwórz, zweryfikuj lub porównaj odzyskane dane przed zastąpieniem aktywnych danych.

Weryfikacja powinna odpowiadać typowi danych. Znana suma kontrolna może potwierdzić niezmieniony archiwum, podczas gdy baza danych może wymagać własnej kontroli spójności, a zdjęcie lub wideo może wymagać dekodowania. Aby poznać szersze powiązania między punktami odzyskiwania, niezależnymi kopiami i ochroną poza urządzeniem, zobacz tę strategię kopii zapasowych domowego NAS.

FAQ

Czy migawka wykonana przed uszkodzeniem może stać się nieczytelna?

Tak. Migawka chroni wcześniejszy stan logiczny przed późniejszymi zmianami plików, ale może nadal współdzielić ten sam pulę pamięci i fizyczne bloki. Jeśli jeden z tych bloków jest uszkodzony i nie ma dostępnej zweryfikowanej kopii zapasowej, wcześniejsza migawka może stać się nieczytelna, mimo że powstała przed logicznym uszkodzeniem, które jest badane.

Czy udana migawka oznacza, że każdy plik w niej jest zdrowy?

Nie. Udana migawka wskazuje, że system plików utworzył punkt odzyskiwania. Nie oznacza to, że każdy plik został otwarty, zdekodowany, sprawdzony względem zaufanej wersji lub zweryfikowany przez aplikację, która go utworzyła.

Czy skanowanie danych może naprawić uszkodzenia zapisane przez aplikację?

Zazwyczaj nie, gdy aplikacja zapisała nieprawidłową zawartość normalnie. W takim przypadku system plików może przechowywać złe bajty z prawidłową sumą kontrolną, nie pozostawiając żadnej niespójności na poziomie bloków, którą mógłby wykryć skan. Odzyskanie wymaga wcześniejszej zdrowej wersji, procesu naprawy świadomego aplikacji lub niezależnej kopii.

Czy zastąpienie uszkodzonego aktywnego pliku naprawia starsze migawki?

Nie. Zastępowanie aktywnego pliku zapisami lub odniesieniami do zdrowych danych dla aktywnego zestawu danych, ale starsze migawki nadal reprezentują swoje historyczne stany. Migawka, która zachowała uszkodzoną wersję, zazwyczaj pozostaje uszkodzona, dopóki nie wygaśnie lub nie zostanie usunięta.