TM-Platte: Geboren, Gelebt, Gestorben, Reanimiert

20/08/2014 - 10:59 von Başar Alabay | Report spam
Hallo,

ich mußte letztens im laufenden Betrieb in einem Mac Pro die Platten in
den Schàchten 3 und 4 vertauschen. Also habe ich beide mit diskutil
eject ausgeworfen, rausgezogen und umgetauscht. Eine davon war die TM
Platte … und das System scheint den Tausch nach dem Neuanfahren der
Platten und dem Aktivieren/Mounten nicht ganz geblickt zu haben. Also
mußte ich rebooten, die eine Platte war danach wieder sie selbst, aber
die TM Platte blieb inaktiv. Das Festplattendienstprogramm wies sie als
defekt aus. Eine Reparatur wurde recht schnell als »wurde repariert«
angezeigt, allerdings dauerte es knapp 4 Stunden, bis die 3 TB auch
wirklich durch waren, und (natürlich) hieß es dann, kann nicht repariert
werden. Bin ich ja irgendwie vom FPDP gewöhnt. Also, was tun?

Die letzten Tage habe ich mich eingehend mit fsck_hfs
auseinandergesetzt. Außerdem kann ich jetzt langsam meine Partitionen
alle mit diskxsy direkt ansprechen :-) Auf alle Fàlle ist fsck,
respektive fsck_hfs via Terminal ein großer Spaß … und bringt sogar mehr
als via GUI. Da man im Netz alles Mögliche liest, ich aber nirgends mal
einen zu Ende gedachten/gemachten »Thread« samt Conclusio gefunden habe,
poste ich das jetzt hier im (völlisch ürrelewantöm) Usenet. Hahaaa!

Also, gegeben ist eine Platte, deren FS einen ordentlichen Schlag
abbekommen haben könnte. Nach der »Verwechslung« hatte TM versucht, das
Backup zu reindizieren, was die Platte endgültig abschoß. Ich hatte
keine Lust, alle Backups bis 2012 einfach wegzubügeln, also?
Terminalspielchen.

Zuerst einmal ein su admin, um alle sudo absetzen zu können. Ich habe
den Alltagsuser absichtlich aus der sudoers rausgelassen.

Dann ein diskutil list. Da sah man, daß /dev/disk2 besagte Platte und
disk2s2 der Partitionsabschnitt ist, um den es geht.

Es folgte also ein sudo diskutil unmount /dev/disk2s2 … um die Platte
mal aus dem Rennen zu nehmen. Besser gesagt, die Partition.

Nun also eine Reparatur, die über Nacht laufen soll: sudo fsck_hfs -d -f
-r -y -c 2g /dev/rdisk2s2. Statt disk rdisk (raw), -d erzàhlt, -f
nötigt, -y sagt zu allem ja und amen, -c 2g gibt dem Programm 2 GB RAM
als Spielwiese (es heißt, man solle maximal die Hàlfte des verbauten RAM
angeben, ich blieb da drunter), und -r sagt, daß der catalog btree neu
aufgebaut werden soll. Gerade dieses -r scheint via GUI in keiner Weise
erreichbar zu sein. Ich habe zwar die Debug-Zusàtze an, aber habe das
nicht gesehen. Nun denn.

Am nàchsten Morgen dann tatsàchlich die Meldung, daß die Platte wieder
repariert zu sein scheint. Sie ist nun auch wieder normal ansprechbar,
und es sieht auch alles so aus, wie es soll. Aber es gibt noch einen
kleinen Fallstrick. Zuerst einmal habe ich alle unsichtbaren Elemente
sichtbar gemacht, um zu schauen, ob da evtl. ein lost+found angelegt ist
… war nicht. Dann sah ich aber im Konsolenprogramm im system.log, daß da
was zu klemmen scheint. Irgendwas in bezug auf ./fseventsd wollte nicht
sauber … also, noch einmal prüfen :-/ Kein Problem gefunden. Etwas
Netzrecherche und dann beherzt den Ordner gelöscht und neu gebootet.
Danach wurde er neu angelegt und eine neue UUID angelegt. Ob jetzt für
die Platte, Partition oder nur für die FS-Änderungen, die geloggt
werden, weiß ich nun nicht. Jedenfalls waren die Fehler nun endlich weg.

Noch einmal eine Reparatur: sudo fsck_hfs -d -f -y -c 3g /dev/rdisk2s2,
diesmal ohne -r und mit -c 3g. Ging verhàltnismàßig flott (also nur
wenige Stunden statt viele). Platte wird als okay gemeldet.

Spotlight auf der Platte aus- und wieder eingeschaltet, allerdings nicht
via Spotlight Privacy-GUI, sondern so: sudo mdutil -i off
/Volumes/Backup und mdutil -i on /Volumes/Backup. Danach dann mit renice
das Indizieren hochgeschraubt (jaja …).

In diesem Fall war das zuerst ein sudo renice -20 -u _spotlight -p 88,
womit alle Prozesse des Users _spotlight und den Prozeß mit der PID 88
(in dem Fall mds) Dampf bekamen. Es waren aber noch einige mdworker, die
nachstarteten … ich habe mir die PID notiert und dann ein sudo renice
-20 -p 4497 4488 4480 4041 3633 (z. B.) nachgesetzt. Danach sah ich in
der Aktivitàtsanzeige, in der ich oben via »md« gefiltert hatte, daß
einiges hochfàhrt. CPU steckte das locker weg (hier, man sollte
natürlich beachten, was man da für eine Kiste vor sich hat, hier ist es
der antike (haha) Mac Pro 1,1).

Irgendwann merkte man, daß wohl das Gröbste durch ist. Nochmal ein
Reboot und dann endlich Time Machine wieder anschalten und gucken, was
passiert … es waren ca. 60 GB zu speichern. Das waren tatsàchlich
dedizierte 60 GB Material, das ich kurz vorher neu angelegt hatte, also
nichts Unbekanntes. Aber … seeehr langsam 404 kB, irgendwann mal 500 MB,
laaaangsaaam 1 GB … man bekam schon schlechte Laune und dachte an die
nàchste Nachtschicht, aber dann, nach ca. 2 GB machte es plöpp, und der
Rest rutschte durch, wie gewohnt. Blick in system.log, ob es Fehler gibt
… nein. Backup wird geschrieben, alte Backups werden ausgegeizt, alles
wie es sein soll.

Hier noch die Meldungen der ersten Nachtschicht-Reparatur:

admin@xx:/Users/user% sudo fsck_hfs -d -f -r -y -c 2g /dev/rdisk2s2
Password:
journal_replay(/dev/disk2s2) returned 0
** /dev/rdisk2s2
Using cacheBlockSize2K cacheTotalBlocke536
cacheSize 97152K.
Executing fsck_hfs (version diskdev_cmds-540.1~25).
** Checking Journaled HFS Plus volume.
The volume name is Backup
** Checking extents overflow file.
** Checking catalog file.
** Rebuilding catalog B-tree.
hfs_UNswap_BTNode: invalid node height (1)
** Rechecking volume.
** Checking Journaled HFS Plus volume.
The volume name is Backup
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
privdir_valence(0237, calc_dirlinks”3840,
calc_dirinode(0237
** Checking volume bitmap.
** Checking volume information.
Invalid volume file count
(It should be 26032240 instead of 26313069)
Invalid volume directory count
(It should be 2269030 instead of 2394142)
Invalid volume free block count
(It should be 115518578 instead of 132294333)
invalid VHB nextCatalogID
Volume header needs minor repair
(2, 0)
Verify Status: VIStat = 0x8000, ABTStat = 0x0000 EBTStat = 0x0000
CBTStat = 0x0000 CatStat = 0x00000000
** Repairing volume.
** Rechecking volume.
** Checking Journaled HFS Plus volume.
The volume name is Backup
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking multi-linked directories.
privdir_valence(0237, calc_dirlinks”3840,
calc_dirinode(0237
** Checking volume bitmap.
** Checking volume information.
** The volume Backup was repaired successfully.

Es folgten ja noch weitere Reparaturen, siehe oben.

Und nun, nach zwei Tagen: Klippen scheinen umschifft zu sein.

Ergànzende und korrigierende Kommentare könnten das hier für’s Archiv
wertvoll machen. Ich hoffe, ich habe nichts vergessen. Daß da natürlich
ganz viel man xyz im Terminal nötig war, setze ich voraus.

B. Alabay

http://www.thetrial.de/
ケディエ・ばく・ハヤテ・あんら
 

Lesen sie die antworten

#1 Patrick Kormann
20/08/2014 - 13:24 | Warnen spam
Am 20.08.14 10:59, schrieb Başar Alabay:

eject ausgeworfen, rausgezogen und umgetauscht. Eine davon war die TM
Platte … und das System scheint den Tausch nach dem Neuanfahren der
Platten und dem Aktivieren/Mounten nicht ganz geblickt zu haben. Also



Eh, sind die Slots in irgend einer Weise Hot-Plug fàhig? Nein, oder?

Ansonsten würde ich persönlich ein Backup, das so kaputt war als
Not-Backup auf die Seite legen und ein neues Anfangen. Ein Backup sollte
kein Glücksspiel sein.

Ähnliche fragen