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
3) Dołączamy (ale nie montujemy) wirtualny dysk z kopią zapasową:
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)
-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
Brak komentarzy
Prześlij komentarz