VxVM defekte Private-Region (2)

Wie schon früher geschrieben neigt der Veritas Volume Manager ab und an unter Gedächtnisschwund.
Leider hatte ich heute die Chance herauszufinden wie obriges Verfahren bei CDSDisks funktioniert.

Zum Glück waren die Platten "online", d.h. er hat die PrivateRegion gefunden - aber nix mehr (gültiges) in ihnen. Danach kann man einfach wie im alten Post beschrieben vorgehen.

Es empfiehlt sich also einen täglichen explorer laufen zu lassen um ggf. später eine vxprint-ht.out zu haben die einem die Datenrücksicherung ersparen kann...

VxVM defekte Private-Region

Mein "Lieblings"-VolumeManager VxVM wollte spontan 3 Diskgroups nicht importieren, obwohl die Platten da waren und sogar der vxdisk -o alldgs list anzeigt das die Platten zu der zu importierenden DG hoeren. Raetsels Loesung: vxprivutil beschwert sich das die Private Region kaputt ist.
Zum Glueck haben wir einen Sun Explorer Output von letzter Woche, dort gibts ein vxprint-th.out indem die Config des VxVM steht.

Also nachsehen wie die Platte aufgesetzt war. Format=sliced, d.h. kein Gewusel mit CDS.
Slice 3 war 1.88MB gross und hatte eine 1MB grosse PrivateRegion (VxVM 4.1 default). Nun gabs ein Upgrade auf VxVM 5 und der hat als default 32MB.

Ich moechte also die Volume Manager Config wieder herstellen, ohne Datenverlust im Filesystem.

Zuerst also ein freundliches:

/etc/vx/bin/vxdisksetup -f -i cXtXdX format=sliced privslice=3 privlen=1M

Damit ist eine leere Private Region auf der Platte und wir kommen nicht mehr an die Daten ran. Das heisst aber nicht das sie weg sind - vxdisksetup aendert im sliced layout nichts an der public region in der unsere volumes liegen.
Nun recovern wir die "foodg", welche eine Disk-Media namens foodg01 hatte:

vxdg init foodg foodg01=cXtXdXs2

Jetzt muessen wir uns im vxprint-th.out ansehen wie unsere subdisks ausgesehen haben (Zeile sd) und entsprechen neu anlegen:

vxmake -g foodg sd foodg01-01 disk=foodg01 offset=0 len=16777216
vxmake -g foodg sd foodg01-02 disk=foodg01 offset=16777216 len=16777216

Dazu bauen wir jetzt unsere zwei Plexes:

vxmake -g foodg plex foo01-01 sd=foodg01-01
vxmake -g foodg plex foo02-01 sd=foodg01-02

Und darueber je ein Volume, so wie es vorher war:

vxmake -g foodg -U fsgen vol foo01 plex=foo01-01
vxmake -g foodg -U fsgen vol foo02 plex=foo02-01

Jetzt sollte ein vxprint -g foodg -th genauso aussehen wie in unseren vxprint-th.out - allerdings sind die Volumes "DISABLED EMPTY" und vxvol mag sie nicht starten. Daher muessen wir sie mit einem speziellen vxvol Kommando starten:

vxvol -g foodg init active foo01
vxvol -g foodg init active foo02

Jetzt sollten wir zur Sicherheit einen fsck absetzen (in unserem Falle ein vxfs):
fsck -Fvxfs /dev/vx/rdsk/foodg/foo01
fsck -Fvxfs /dev/vx/rdsk/foodg/foo02

Und koennen sie wieder mounten - und haben unser altes Filesystem nicht ueberschrieben.