Po raz kolejny mojemu backupu trafiła się przypadłość pod tytułem "To improve reliability, Time Machine must create a new backup for you".


Przy pierwszym razie rzeczywiście pozwoliłem na utworzenie nowej kopii (tracąc wszystkie poprzednie). Przy drugim pomyślałem że w końcu co, kurczę blade, nie po to się robi backupy aby je potem tracić, odłączyłem dysk od routera, podpiąłem do komputera i - posiłkując się kilkom tutorialami z sieci - reanimowałem go. Przy trzecim razie uznałem, że trzeba wiedzę zebrać w jednym miejscu bo najwyraźniej będzie się od czasu do czasu przydawać. Uruchamiamy Terminal i:

1) Po podłączeniu dysku do komputera zostanie on automatycznie zamontowany. U mnie nazywa się Time Machine, więc jest dostępny jako /Volumes/Time\ Machine i zawiera tylko jeden plik: nazwa.sparsebundle.

2) Profilaktycznie ustawiamy uprawnienia - system po stwierdzeniu, że kopia jest uszkodzona może ustawić immutable flag (nie wiem od czego to zależy - w tutorialach o tym nie było, ale u mnie tak robi).
Uwaga: tę i wszystkie dalsze komendy musimy wykonywać z uprawnieniami administratora, stąd przed każdą sudo.

sudo chflags -R nouchg /Volumes/Time\ Machine/nazwa.sparsebundle

3) Dołączamy (ale nie montujemy) wirtualny dysk z kopią zapasową:

sudo hdiutil attach -nomount -noverify -noautofsck /Volumes/Time\ Machine/nazwa.sparsebundle

System wypisze znajdujące się na nim partycje (mogą mieć inne numery):

/dev/disk3           Apple_partition_scheme        
/dev/disk3s1         Apple_partition_map            
/dev/disk3s2         Apple_HFSX 

4) Interesuje nas ostatnia z partycji, to na niej jest backup i ona jest weryfikowana. Aby ją naprawić trzeba wykonać komendę:

sudo fsck_hfs -fyrd /dev/disk3s2

Znaczenie poszczególnych opcji:

-f (force) wymusza sprawdzenie i naprawę, nawet gdyby system uważał inaczej

-y próbuje naprawiać wszelkie znalezione nieprawidłowości

-r (rebuild) przebudowuje b-drzewo katalogów (cokolwiek to znaczy - w tutorialach sugerują, aby to zrobić)

-d (debug) będzie wypisywać sporo informacji w terminalu ale dzięki temu będziemy wiedzieli, że coś się dzieje (proces sprawdzania może trwać nawet kilka godzin)

5) Całkiem możliwe, że fsck_hfs odmówi współpracy i napisze:

Unable to open block device /dev/disk3s2:
Resource busyjournal_replay(/dev/disk3s2) returned 16
** /dev/rdisk3s2 (NO WRITE)

co znaczy, że system po podłączeniu dysku zaczął automatyczne sprawdzanie i trzeba poczekać aż skończy. Aby stwierdzić kiedy to nastąpi należy zajrzeć do logu:

tail -f /var/log/fsck_hfs.log

będzie tam:

** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine Backups
** Checking extents overflow file.
** Checking catalog file.

i po jakimś czasie pojawi się:

/dev/rdisk3s2: ** The volume Time Machine Backups could not be verified completely.

wtedy możemy wrócić do punktu 4).

6) Drugi z możliwych problemów to:

Unable to open block device /dev/disk3s2:
Permission deniedjournal_replay(/dev/disk3s2) returned 13
** /dev/rdisk3s2 (NO WRITE)

- tutaj pomaga restart komputera

7) Kiedy fsck_hfs zacznie pracę wypisze (m. in.):

** Checking Journaled HFS Plus volume.
...
** Rebuilding catalog B-tree.

i po dłuższym czasie:


** Rechecking volume.

Jeżeli po kolejnym sprawdzaniu zobaczymy niezbyt zachęcający komunikat:


** The volume Time Machine Backups could not be repaired.

nie należy się tym zrażać tylko uruchomić fsck_hfs po raz kolejny. W moim przypadku dopiero za drugim razem zobaczyłem oczekiwane:

** The volume Time Machine Backups was repaired successfully.
CheckHFS returned 0, fsmodified = 1

8) Pomimo, że partycja z kopią zapasową jest już naprawiona, to system nie rejestruje tej informacji - musimy zrobić to ręcznie edytując plik com.apple.TimeMachine.MachineID.plist:

sudo nano /Volumes/Time\ Machine/nazwa.sparsebundle/com.apple.TimeMachine.MachineID.plist 

dla klucza:

VerificationState

zmieniamy wartość 2 na 0.

Gotowe!

0 komentarze: