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.