Importversuch eines unvollständigen zpools
Hallo,
ich verzweifelte vor einiger Zeit an einem Problem mit meinem OpenSolaris-BackupServer bzw. einem zpool, das ich bis jetzt auf Eis gelegt habe
(zpool ausgebaut, auf OpenIndiana umgestellt und neue HDDs eingebaut sowie neues Datengrab erstellt), aber ich benötige nun einige der alten Daten.
Leider habe ich mir damals selbst ins Knie geschossen.
Mein Backup-Server mit einem zpool (rpool 20GB) und einem raidz2 (7x1TB + log-device 8GB) für Daten hat sich verabschiedet. Da ich sowieso aus diesem alten PC
einen IPCop aufsetzen wollte (dafür die 8GB-HDD) und der neue Backup-Server ein neues log- und cache-device als mirror aus zwei SDDs bekommen sollte,
habe ich mich erst einmal an den IPCop gesetzt (GROBER FEHLER !!!). Cop läuft ...... nun der neue Backup-Server ........ OpenSolaris 2009.06 installiert,
wegen dedup Repo auf /dev umgestellt und auf snv_134 upgedatet, upgrade des ZFS auf Version 22. Nun nur noch den Daten-zpool importieren ... fertig! .... DENKSTE !!!!!
# zpool import
pool: tank1
id: 5048704328421749681
state: UNAVAIL
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
see:
http://www.sun.com/msg/ZFS-8000-EY
config:
tank1 UNAVAIL missing device
raidz2-0 ONLINE
c7t5d0 ONLINE
c7t0d0 ONLINE
c7t6d0 ONLINE
c7t3d0 ONLINE
c7t1d0 ONLINE
c7t4d0 ONLINE
c7t2d0 ONLINE
Bis jetzt ja noch logisch, also ein:
# zpool import -f tank1
cannot import 'tank1': one or more devices is currently unavailable
Destroy and re-create the pool from
a backup source
aber da fehlt ja nur das, aus meiner Sicht unwichtige, log-device, der Rest sollte importierbar sein.
Danach habe ich eine Woche mit Tante Google verbracht und ca. 100 verschiedene Tipps probiert.
Auch jeder Importversuch mit den Optionen -f, -F, -X, -V,- D, und allen Kombinationen aus diesen, half nichts. Der Import mit der Option -D funktioniert wohl nur bei vorhandener zpool.cache,
aber da ich dämlicherweise das System neu aufgesetzt habe, habe ich diese natürlich nicht mehr.
Auch meine Versuche wieder ein neues log-Device hinzuzufügen, es zu ersetzen, zu entfernen usw. (die üblichen Tipps aus dem Troubleshoootingguide) enden damit, dass er es nicht kann,
weil er angeblich den zpool nicht kennt, wenn er nicht importiert ist.
Ich drehe mich im Kreis:
- kein Import, weil device fehlt
- kein replace / attach / detach / remove ......., weil zpool nicht importiert ist.
Zum Zeitpunkt des Crashs wurden auch keine Schreiboperationen auf den Datenpool ausgeführt, sodass ich sehr gut auf die informationen aus den slog verzichten kann,
und selbst wenn... ich verzichte lieber auf die letzten 30 Sekunden, als auf meine kompletten Daten.
Das ZFS scheint aber nach dem Motto zu handeln: Wenn nicht garantiert werden kann, dass ALLE Daten konsistent sind,
dann taugen auch ALLE Daten nichts und sind Schrott, den man nicht zu brauchen hat.
Ein Reparaturversuch mit dem logfix-Tool brachte ebenfalls nichts, da mir die GUID des alten slogs fehlt (die HDD tut ja inzwischen im IPCop Dienst, leider!).
Folgende Informationen kann ich noch liefern:
eee@opensolaris:~# zdb -e tank1
Configuration for import:
vdev_children: 2
version: 22
pool_guid: 5048704328421749681
name: 'tank1'
state: 0
hostid: 946038
hostname: 'opensolaris'
vdev_tree:
type: 'root'
id: 0
guid: 5048704328421749681
children[0]:
type: 'raidz'
id: 0
guid: 16723866123388081610
nparity: 2
metaslab_array: 23
metaslab_shift: 30
ashift: 9
asize: 7001340903424
is_log: 0
create_txg: 4
children[0]:
type: 'disk'
id: 0
guid: 6858138566678362598
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@0,0:a'
whole_disk: 1
DTL: 4345
create_txg: 4
path: '/dev/dsk/c7t5d0s0'
devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJ1BQ709050/a'
children[1]:
type: 'disk'
id: 1
guid: 16136237447458434520
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@1,0:a'
whole_disk: 1
DTL: 4344
create_txg: 4
path: '/dev/dsk/c7t0d0s0'
devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJDWQ317311/a'
children[2]:
type: 'disk'
id: 2
guid: 10876853602231471126
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@2,0:a'
whole_disk: 1
DTL: 4343
create_txg: 4
path: '/dev/dsk/c7t6d0s0'
devid: 'id1,sd@SATA_____Hitachi_HDT72101______STF604MH14S56W/a'
children[3]:
type: 'disk'
id: 3
guid: 2384677379114262201
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@3,0:a'
whole_disk: 1
DTL: 4342
create_txg: 4
path: '/dev/dsk/c7t3d0s0'
devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJ1NQ811135/a'
children[4]:
type: 'disk'
id: 4
guid: 15143849195434333247
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@4,0:a'
whole_disk: 1
DTL: 4341
create_txg: 4
path: '/dev/dsk/c7t1d0s0'
devid: 'id1,sd@SATA_____Hitachi_HDT72101______STF604MH16V73W/a'
children[5]:
type: 'disk'
id: 5
guid: 11627603446133164653
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@5,0:a'
whole_disk: 1
DTL: 4340
create_txg: 4
path: '/dev/dsk/c7t4d0s0'
devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJDWQ317308/a'
children[6]:
type: 'disk'
id: 6
guid: 15036924286456611863
phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@6,0:a'
whole_disk: 1
DTL: 4338
create_txg: 4
path: '/dev/dsk/c7t2d0s0'
devid: 'id1,sd@SATA_____Hitachi_HDS72101______JP2921HQ0KMEZA/a'
children[1]:
type: 'missing'
id: 1
guid: 0
Ich bin am Ende mit meinem Latein und meinen Nerven.
Kann mir jemand helfen, dem ZFS beizubringen das (fehlende) slog zu ignorieren (kann man die Abfrage nach der Vollständigkeit des Pools beim Import unterdrücken?),
ihm zu sagen, es hat keins, oder dem Pool zum Schein wieder ein slog unterzuschieben?
Vielleicht kann man den Pool auch unter einem anderen OS (Linux mit Fuse oder Kernelmodul, BSD), das nicht so pedantisch ist, kurz importieren, ihn "reparieren",
exportieren und dann unter OpenSolaris bzw. dem jetzigen OpenIndiana wieder importieren?
Vielen Dank für die Bemühungen und für's lesen des doch sehr langen Beitrags.
Viele Grüße
Ronny
:
