Dlaczego repozytorium kopii zapasowych z deduplikacją działa w trybie tylko do odczytu po przerwanym czyszczeniu?

Repozytorium może działać w trybie tylko do odczytu po przerwanym czyszczeniu, gdy zmiany blokuje blokada wyłącznego dostępu, błąd pamięci masowej, niezmienny backend lub nieukończony stan konserwacji.

„Tylko do odczytu” może być reakcją bezpieczeństwa klienta kopii zapasowych, a nie rzeczywistym trybem zamontowania systemu plików. Anulowane czyszczenie może pozostawić blokadę wyłącznego dostępu, niedokończone operacje na pakietach lub indeksach, niewystarczającą przestrzeń roboczą do porządkowania albo operacje backendu, które pozwalają na odczyt, ale odrzucają usuwanie. Niezależnie od tego system operacyjny może ponownie zamontować system plików repozytorium w trybie tylko do odczytu po błędach wejścia/wyjścia lub spójności. Zanim usuniesz blokady lub ponownie uruchomisz czyszczenie, ustal, która warstwa odrzuca pierwszą operację zapisu.

Przechwyć pierwszą operację zgłaszającą tryb tylko do odczytu

Uruchom polecenie wyświetlające zawartość repozytorium, a następnie jedną nieniszczącą kontrolę i zapisz pierwszy błąd z dzienników klienta, backendu oraz systemu operacyjnego.

Dokumentacja Restic wyjaśnia, że czyszczenie przepisuje dane repozytorium i wymaga wyłącznego dostępu, ponieważ usuwa nieużywaną zawartość oraz może przepakowywać częściowo wykorzystane pliki.

Jeśli wyświetlanie zawartości działa, ale każda operacja tworząca blokadę lub zapisująca metadane kończy się niepowodzeniem, rozróżnij nieaktualną blokadę, uprawnienia zapisu backendu i przechowywanie obiektów.

Sprawdź, czy po przerwanym czyszczeniu nie pozostała blokada wyłącznego dostępu

Wyświetl blokady repozytorium za pomocą narzędzia do tworzenia kopii zapasowych i ustal hosta, proces, czas utworzenia oraz polecenie, które jest właścicielem każdej blokady.

Dokumentacja Borg wyjaśnia, że polecenia zmieniające repozytorium używają blokad repozytorium zapobiegających jednoczesnemu zapisowi i ostrzega, że przerwanie aktywnej blokady może uszkodzić stan repozytorium.

Usuwaj nieaktualną blokadę wyłącznie za pomocą obsługiwanego polecenia i dopiero po potwierdzeniu, że jej właściciel już nie działa.

Ustal, czy system plików został ponownie zamontowany w trybie tylko do odczytu

Sprawdź tabelę zamontowanych systemów plików, dziennik jądra, stan systemu plików, stan puli pamięci masowej oraz ostatnie błędy USB, SATA, sieciowe lub kontrolera.

Dokumentacja systemu plików ext4 w systemie Linux wymienia errors=remount-ro jako zasadę bezpieczeństwa, pokazując, jak awaria pamięci masowej może sprawić, że repozytorium rzeczywiście stanie się tylko do odczytu.

Nie wymuszaj ponownego zamontowania w trybie odczytu i zapisu, dopóki występują błędy sprzętu lub systemu plików. Najpierw zachowaj dzienniki i napraw pamięć masową.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź częściowy stan czyszczenia, kompaktowania lub indeksowania

Ustal, która faza została przerwana: wybieranie wygasłych migawek, usuwanie odwołań, przepakowywanie danych, odbudowa indeksu czy zatwierdzanie metadanych.

Dokumentacja polecenia prune w Borg wskazuje, że czyszczenie i kompaktowanie to osobne kroki, dlatego archiwa mogą pozostać prawidłowe, mimo że odzyskiwanie miejsca nie zostało ukończone.

Przed kolejnym destrukcyjnym uruchomieniem użyj polecenia sprawdzania repozytorium. Nigdy nie usuwaj ręcznie pakietów, indeksów ani segmentów.

Sprawdź blokadę obiektów, niezmienność i dane uwierzytelniające backendu

W przypadku repozytoriów w chmurze sprawdź przechowywanie obiektów, blokadę prawną, zasady zasobnika, wersjonowanie, uprawnienia usuwania oraz rotację danych uwierzytelniających.

Firma AWS informuje, że S3 Object Lock uniemożliwia usuwanie lub nadpisywanie w chronionym okresie przechowywania, pozwalając na odczyt, gdy czyszczenie kończy się niepowodzeniem.

Nie osłabiaj niezmiennego przechowywania tylko po to, aby czyszczenie się powiodło. Używaj konstrukcji repozytorium obsługiwanej przez narzędzie do tworzenia kopii zapasowych.

Zweryfikuj wolne miejsce, i-węzły oraz przestrzeń roboczą czyszczenia

Sprawdź liczbę wolnych bajtów i i-węzłów w systemie plików, limity, rezerwy migawek, katalogi tymczasowe, limity magazynu obiektów oraz miejsce w lokalnej pamięci podręcznej.

Dokumentacja GNU Coreutils wyjaśnia, że df może raportować wykorzystanie bloków i i-węzłów, rozróżniając pełny system plików od blokady repozytorium lub błędu uprawnień.

Jeśli system plików jest pełny, zwiększ tymczasowo dostępną pojemność lub usuń niezwiązane, zweryfikowane dane zamiast kasować obiekty repozytorium.

Odzyskaj działanie za pomocą sprawdzenia, odblokowania i jednego kontrolowanego uruchomienia konserwacji

Chroń ostatnie znane prawidłowe punkty przywracania, zatrzymaj harmonogramy, uruchom obsługiwane sprawdzanie, usuń wyłącznie potwierdzoną nieaktualną blokadę i wykonaj jedno rejestrowane uruchomienie konserwacji.

Poradnik ZimaSpace dotyczący odzyskiwania pełnego miejsca docelowego kopii zapasowej przedstawia powiązaną zasadę: traktuj repozytorium jako zarządzaną strukturę, a nie zbiór niezależnych plików.

Problem można uznać za rozwiązany, gdy wyświetlanie zawartości, sprawdzanie, tworzenie kopii zapasowej, zasady przechowywania oraz testowe przywracanie działają pomyślnie bez wymuszonych odblokowań ani ręcznego usuwania.

Najczęściej zadawane pytania

Czy mogę ręcznie usunąć plik blokady?

Nie jako pierwszy krok. Potwierdź, że żaden proces go nie używa, i skorzystaj z obsługiwanej przez narzędzie do tworzenia kopii zapasowych operacji odblokowania.

Czy po awarii należy natychmiast ponownie uruchomić czyszczenie?

Nie. Przed kolejnym destrukcyjnym przebiegiem konserwacji zweryfikuj stan repozytorium, indeksu, systemu plików i backendu.

Czy działanie w trybie tylko do odczytu oznacza, że dane kopii zapasowej są bezpieczne?

Niekoniecznie. Brakujące pakiety, błędy pamięci masowej, niezmienne obiekty lub niekompletne indeksy nadal mogą uniemożliwiać przywracanie.