Dlaczego kontrola integralności repozytorium może zakończyć się pomyślnie, podczas gdy przywrócenie jednego pliku nadal się nie udaje?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Can a Repository Integrity Check Pass While One File Still Fails to Restore? - Zima Store Online

Sprawdzenie repozytorium może zakończyć się powodzeniem, mimo że przywrócenie jednego pliku się nie powiedzie, jeśli kontrola weryfikuje metadane lub próbkę danych zamiast dokładnie tej ścieżki odzyskiwania.

Weryfikacja kopii zapasowej nie jest jedną uniwersalną operacją. Niektóre kontrole potwierdzają strukturę repozytorium, indeksy, manifesty i wskazywane fragmenty bez odczytywania każdego przechowywanego bajtu. Inne pobierają próbki danych, pomijają pliki, które nigdy nie zostały przechwycone, albo nie informują o nazwach, uprawnieniach, listach ACL, etykietach, wolnym miejscu i blokadach aplikacji w docelowym systemie plików. Potraktuj niedziałający plik jako ścieżkę prowadzącą od wyboru migawki przez zapisane obiekty do utworzenia pliku w miejscu docelowym.

Ustal dokładnie, co zostało zweryfikowane podczas pomyślnego sprawdzenia

Zapisz polecenie sprawdzające, opcje, wersję narzędzia do tworzenia kopii zapasowych, backend repozytorium, identyfikator migawki i końcowy dziennik. Ustal, czy sprawdzono strukturę repozytorium, metadane archiwum, wskazywane fragmenty, zapisane dane czy rzeczywistą ekstrakcję.

Borg informuje, że jego standardowe sprawdzanie archiwum odczytuje domyślnie metadane, ale nie dane plików, chyba że jawnie zażądano weryfikacji danych.

Zielony wynik może więc potwierdzać wewnętrzną spójność odwołań, pozostawiając niektóre fragmenty zawartości bez odczytu. Nie uznawaj repozytorium za w pełni przywracalne, dopóki nie wyodrębnisz reprezentatywnych plików.

Ustal, czy zapisane dane pliku zostały rzeczywiście odczytane

Znajdź plik w wybranej migawce i określ pakiety, fragmenty lub obiekty wymagane do jego odtworzenia. Porównaj nieudane przywracanie z zakresem odczytu danych podczas sprawdzania repozytorium.

Restic opisuje kontrole read-data i read-data-subset, pokazując, że rutynowe sprawdzenie struktury i pełny odczyt zawartości to różne poziomy weryfikacji.

Jeśli odczytano tylko podzbiór danych, niedziałający plik może zależeć od niesprawdzonego pakietu. Przed próbą naprawy uruchom obsługiwaną ukierunkowaną lub pełną kontrolę danych.

Potwierdź, że plik został uwzględniony w tej migawce

Wyświetl dokładną ścieżkę względną w wybranej migawce. Sprawdź filtry, wykluczenia, ostrzeżenia dotyczące nieczytelnego źródła, reguły dotyczące dowiązań symbolicznych, granice punktów montowania oraz to, czy interfejs przywracania nie wybrał innej wersji.

Kopia ostrzega, że zasady ignorowania pomijają pasujące ścieżki, więc spójność repozytorium może zostać potwierdzona nawet wtedy, gdy żądany plik nigdy nie został przechwycony.

Ścieżka zastępcza lub wpis katalogu nadrzędnego nie dowodzi, że zawartość pliku istnieje. Porównaj zawartość migawki, rozmiar, sumę kontrolną i znacznik czasu z oczekiwanym rekordem źródłowym.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Sprawdź ograniczenia dotyczące nazwy pliku i ścieżki w miejscu docelowym

Przywróć ten sam plik do krótkiej, pustej ścieżki lokalnej, używając prostej nazwy. Porównaj niedozwolone znaki, nazwy zastrzeżone, konflikty wielkości liter, końcowe spacje, długość ścieżki i normalizację znaków Unicode.

Wytyczne firmy Microsoft dotyczące nazw plików opisują ograniczenia nazw plików i ścieżek w systemie Windows, które mogą odrzucić jedną przywracaną ścieżkę, podczas gdy samo repozytorium pozostaje sprawne.

Jeśli plik zostanie przywrócony do tymczasowej, krótkiej ścieżki, oznacza to, że zapisana zawartość jest dostępna. Zamiast naprawiać repozytorium, popraw układ miejsca docelowego lub mapowanie nazw.

Zweryfikuj przywracanie list ACL, atrybutów rozszerzonych i właściciela

Powtórz przywracanie z wyłączonym zachowywaniem metadanych, wyłącznie w jednorazowym środowisku docelowym, a następnie porównaj je ze standardowym przywracaniem z obsługą metadanych. Zapisz pierwszy atrybut, którego zastosowanie się nie powiodło.

GNU tar dokumentuje oddzielne przywracanie list ACL i atrybutów rozszerzonych, pokazując, dlaczego dane pliku mogą być czytelne, a zastosowanie metadanych może się nie powieść.

Nie uznawaj przywracania bez metadanych za produkcyjne rozwiązanie, jeśli aplikacje zależą od list ACL, właściciela, zakresów rzadkich lub atrybutów rozszerzonych. Użyj go wyłącznie do zidentyfikowania wadliwej warstwy.

Sprawdź etykiety bezpieczeństwa i zasady obowiązujące w miejscu docelowym

Sprawdź etykiety SELinux, program antywirusowy lub ochronę punktów końcowych, zabezpieczenia przed ransomware, niezmienne flagi, uprawnienia udziału oraz blokady aplikacji w miejscu docelowym przywracania.

Red Hat opisuje przywracanie domyślnych kontekstów bezpieczeństwa, gdy pliki pojawiają się z brakującymi lub nieodpowiednimi etykietami.

Plik, który zostaje wyodrębniony, ale nie może zostać otwarty, może wskazywać na problem z zasadami obowiązującymi w miejscu docelowym, a nie na awarię repozytorium. Przetestuj go przy użyciu tego samego użytkownika i tej samej aplikacji, które będą korzystać z przywróconego pliku.

Wykonaj izolowane przywracanie przed rozpoczęciem naprawy

Przywróć niedziałający plik, metadane jego katalogu nadrzędnego oraz kilka plików znajdujących się w pobliżu do pustego zbioru danych lub katalogu tymczasowego. Przed uruchomieniem poleceń naprawczych zapisz sumy kontrolne, dzienniki i stan repozytorium.

Przewodnik ZimaSpace dotyczący weryfikacji sum kontrolnych i metadanych przedstawia powiązane rozróżnienie między integralnością zapisanej zawartości a użytecznym odzyskiwaniem danych przez aplikację.

Problem zostaje rozwiązany, gdy wybrany plik zostanie przywrócony z właściwej migawki, będzie zgodny z oczekiwaną zawartością, otrzyma wymagane metadane i otworzy się za pośrednictwem produkcyjnej ścieżki aplikacji.

Często zadawane pytania

Czy pomyślne sprawdzenie repozytorium dowodzi, że każdy plik można przywrócić?

Nie. Zależy to od tego, czy kontrola odczytała wszystkie zapisane dane oraz czy miejsce docelowe może odtworzyć każdą ścieżkę i jej metadane.

Czy po jednym nieudanym przywracaniu należy od razu uruchomić naprawę?

Nie. Najpierw przetestuj inne miejsce docelowe, potwierdź obecność pliku w migawce i uruchom obsługiwaną kontrolę danych. Naprawa może usunąć uszkodzone metadane lub obiekty.

Czy pomyślne przywrócenie testowe jest lepszym potwierdzeniem niż raport weryfikacji?

Tak, jeśli chodzi o przetestowaną ścieżkę odzyskiwania. Potwierdza ono wybór, deszyfrowanie, odczyt zawartości, utworzenie miejsca docelowego i obsługę metadanych dla konkretnej próbki.