(Danke für den Hinweis fireon.)
Ich wollte heute morgen /dev/sda(2) nochmal "ordentlich" rebuilden. Leider ging das ziemlich daneben, obwohl ich dachte, alles "nach Anleitung" gemacht zu haben. Im Moment fahr ich auf "Notstrom" und musste 2/4 Platten aus dem RAID-Z2 abziehen, damit Proxmox überhaupt noch bootet.
Ich bitte im Voraus um Entschuldigung: ich habe meine Eingaben und die Ausgaben protokolliert, weswegen der Post jetzt etwas länger wird, was aber hoffentlich zumindest hilft, um einen Hinweis zu bekommen, wie ich den Karren jetzt wieder aus dem Dreck ziehen könnte.
Zur Erinnerung: los ging es mein damit, dass ich beim ersten Rebuild statt
Code:
zpool replace rpool 13327852728749845485 /dev/sda2
fälschlicherweise
Code:
zpool replace rpool 13327852728749845485 /dev/sda
genommen hatte. Der Status war also:
Code:
# zpool status -v
pool: rpool
state: ONLINE
scan: scrub repaired 0B in 18h27m with 0 errors on Sun Feb 11 18:51:27 2018
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
sdd2 ONLINE 0 0 0
errors: No known data errors
Nun habe ich entsprechend
Wiki versucht, /dev/sda so zu ersetzen versucht als wäre /dev/sda tatsächlich defekt, also in Reihefolge der eingegebenen Befehle:
Code:
# zpool offline rpool /dev/sda && zpool status -v
pool: rpool
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: scrub repaired 0B in 18h27m with 0 errors on Sun Feb 11 18:51:27 2018
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sda OFFLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
sdd2 ONLINE 0 0 0
errors: No known data errors
# dd if=/dev/urandom of=/dev/sda bs=64K status=progress
1047789568 bytes (1.0 GB, 999 MiB) copied, 23 s, 45.6 MB/s ^C
16267+0 records in
16266+0 records out
1066008576 bytes (1.1 GB, 1017 MiB) copied, 25.622 s, 41.6 MB/s
# shutdown -h now
(Bevor die Frage kommt, was das dd-Kommando sollte: bei meinem ersten rebuild-Versuch damals meckerte ZFS, dass die Platte nicht ZFS-formatiert sei (was zum damaligen Zeitpunkt auch stimmte), weswegen mir damals half, ein bisschen Datenmüll auf der Platte zu verteilen, damit ZFS sie annimmt - ist jetzt hier nur der Vollständigkeit aufgeführt, da ich den Befehl noch "im Kochbuch" und deswegen auch hier (wahrscheinlich unsinnig) genutzt hatte)
Jedenfalls: jetzt habe ich die Platte "hinter" /dev/sda (Platte 1von4) aus dem Server gezogen, diesen wieder hochgefahren und die Platte 1von4 wieder eingeschoben.
Code:
# sgdisk --replicate=/dev/sda /dev/sdb
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
# sgdisk --randomize-guids /dev/sda
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
Etwas verwundert über die Warnungen hatte ich mich an dieser Stelle vergewissert, dass die Zuordnungen so waren wie erwartet, was dem Anschein nach auch so war:
Code:
# zdb | less
rpool:
version: 5000
name: 'rpool'
state: 0
txg: 426942
pool_guid: 9973961061107860467
errata: 0
hostid: 656640
hostname: 'proxmox-server'
com.delphix:has_per_vdev_zaps
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 9973961061107860467
children[0]:
type: 'raidz'
id: 0
guid: 10834227445461462896
nparity: 2
metaslab_array: 128
metaslab_shift: 36
ashift: 12
asize: 12002313371648
is_log: 0
create_txg: 4
com.delphix:vdev_zap_top: 66
children[0]:
type: 'disk'
id: 0
guid: 3746872896469901947
path: '/dev/sda1'
devid: 'ata-WDC_WD30EFRX-68EUZN0_WD-WCC4ND0PVXEA-part1'
phys_path: 'pci-0000:01:00.0-ata-1'
whole_disk: 1
DTL: 28
create_txg: 4
com.delphix:vdev_zap_leaf: 26
offline: 1
children[1]:
type: 'disk'
id: 1
guid: 1020653270431596650
path: '/dev/sdb2'
whole_disk: 0
DTL: 79
create_txg: 4
com.delphix:vdev_zap_leaf: 68
children[2]:
type: 'disk'
id: 2
guid: 1321917959934574704
path: '/dev/sdc2'
whole_disk: 0
DTL: 78
create_txg: 4
com.delphix:vdev_zap_leaf: 69
children[3]:
type: 'disk'
id: 3
guid: 14728949233396094063
path: '/dev/sdd2'
whole_disk: 0
DTL: 31
create_txg: 4
com.delphix:vdev_zap_leaf: 70
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
Da ich laut zdb-Ausgabe davon ausging, dass alle 4 Platten vom Server an die richtige Stelle verortet wurden, wollte ich nun mit dem Rebuild von /dev/sda2 fortfahren, was ZFS leider mit folgenden Fehlermeldungen permanent verweigerte:
Code:
# zpool replace rpool 3746872896469901947 /dev/sda2
invalid vdev specification
use '-f' to override the following errors:
/dev/sda2 is part of active pool 'rpool'
Wahrscheinlich habe ich dann mit folgendem Befehl einen kritischen Fehler begangen. Ich wollte entsprechend der vorigen Fehlermeldung sicherstellen, dass /dev/sda2 wirklich offline ist. Fragt mich nicht, warum ich vorher nicht nochmal "zpool status" aufgerufen habe. Jedenfalls:
Code:
# zpool offline rpool /dev/sda2
# zpool replace rpool 3746872896469901947 /dev/sda2
invalid vdev specification
use '-f' to override the following errors:
/dev/sda2 is part of active pool 'rpool'
# zpool replace -f rpool 3746872896469901947 /dev/sda2
invalid vdev specification
the following errors must be manually repaired:
/dev/sda2 is part of active pool 'rpool'
# zpool replace rpool /dev/sda2
invalid vdev specification
use '-f' to override the following errors:
/dev/sda2 is part of active pool 'rpool'
# zpool replace -f rpool /dev/sda2
invalid vdev specification
the following errors must be manually repaired:
/dev/sda2 is part of active pool 'rpool'
"zpool status" kam mir leider zu spät in den Sinn, wahrscheinlich war die Zuordnung der Platten doch nicht so wie erwartet:
Code:
# zpool status -v
pool: rpool
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: resilvered 196K in 0h0m with 0 errors on Mon Feb 12 09:23:16 2018
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sda OFFLINE 0 0 0
sda2 OFFLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
"zdb" gab ab diesem Zeitpunkt entsprechend auch etwas anderes aus als beim ersten Mal:
Code:
# zdb | less
rpool:
version: 5000
name: 'rpool'
state: 0
txg: 427286
pool_guid: 9973961061107860467
errata: 0
hostid: 656640
hostname: 'proxmox-server'
com.delphix:has_per_vdev_zaps
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 9973961061107860467
children[0]:
type: 'raidz'
id: 0
guid: 10834227445461462896
nparity: 2
metaslab_array: 128
metaslab_shift: 36
ashift: 12
asize: 12002313371648
is_log: 0
create_txg: 4
com.delphix:vdev_zap_top: 66
children[0]:
type: 'disk'
id: 0
guid: 3746872896469901947
path: '/dev/sda1'
devid: 'ata-WDC_WD30EFRX-68EUZN0_WD-WCC4ND0PVXEA-part1'
phys_path: 'pci-0000:01:00.0-ata-1'
whole_disk: 1
DTL: 28
create_txg: 4
com.delphix:vdev_zap_leaf: 26
offline: 1
children[1]:
type: 'disk'
id: 1
guid: 1020653270431596650
path: '/dev/sda2'
whole_disk: 0
DTL: 79
create_txg: 4
com.delphix:vdev_zap_leaf: 68
offline: 1
children[2]:
type: 'disk'
id: 2
guid: 1321917959934574704
path: '/dev/sdb2'
whole_disk: 0
DTL: 78
create_txg: 4
com.delphix:vdev_zap_leaf: 69
children[3]:
type: 'disk'
id: 3
guid: 14728949233396094063
path: '/dev/sdc2'
whole_disk: 0
DTL: 31
create_txg: 4
com.delphix:vdev_zap_leaf: 70
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
In der Hoffnung, eine dev-Zuordnung entsprechend der physischen 4 HDD-Slots (sda-sdd) wieder zu erlangen, habe ich den Server nun runtergefahren, Platte 1von4 herausgezogen, den Server wieder gestartet, worauf mich "grub rescue" begrüßte:
Code:
error: checksum verification failed.
Entering rescue mode...
grub rescue>_
Da auf dem Server ein Matrix-Node für meine Familie läuft, konnte ich ihn jetzt nicht Mitten am Tag länger offline nehmen und hab im Vertrauen auf RAID-Z2 den Server runtergfahren, Platte 1von4 und 2von4 abgezogen, worauf Proxmox zumindest wieder bootete:
Code:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2.7T 0 disk
├─sda1 8:1 0 1007K 0 part
├─sda2 8:2 0 2.7T 0 part
└─sda9 8:9 0 8M 0 part
sdb 8:16 0 2.7T 0 disk
├─sdb1 8:17 0 1007K 0 part
├─sdb2 8:18 0 2.7T 0 part
└─sdb9 8:25 0 8M 0 part
zd0 230:0 0 7G 0 disk [SWAP]
zd16 230:16 0 4.5G 0 disk
zd32 230:32 0 8G 0 disk
├─zd32p1 230:33 0 243M 0 part
├─zd32p2 230:34 0 1K 0 part
└─zd32p5 230:37 0 7.8G 0 part
zd48 230:48 0 4.5G 0 disk
zd64 230:64 0 4.5G 0 disk
zd80 230:80 0 3.5T 0 disk
zd96 230:96 0 4.5G 0 disk
zd112 230:112 0 4.5G 0 disk
zd128 230:128 0 8G 0 disk
├─zd128p1 230:129 0 243M 0 part
├─zd128p2 230:130 0 1K 0 part
└─zd128p5 230:133 0 7.8G 0 part
# zpool status -v
pool: rpool
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: resilvered 196K in 0h0m with 0 errors on Mon Feb 12 09:23:16 2018
config:
NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sda OFFLINE 0 0 0
sda2 OFFLINE 0 0 0
sda2 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
errors: No known data errors
# zdb | less
rpool:
version: 5000
name: 'rpool'
state: 0
txg: 427286
pool_guid: 9973961061107860467
errata: 0
hostid: 656640
hostname: 'proxmox-server'
com.delphix:has_per_vdev_zaps
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 9973961061107860467
children[0]:
type: 'raidz'
id: 0
guid: 10834227445461462896
nparity: 2
metaslab_array: 128
metaslab_shift: 36
ashift: 12
asize: 12002313371648
is_log: 0
create_txg: 4
com.delphix:vdev_zap_top: 66
children[0]:
type: 'disk'
id: 0
guid: 3746872896469901947
path: '/dev/sda1'
devid: 'ata-WDC_WD30EFRX-68EUZN0_WD-WCC4ND0PVXEA-part1'
phys_path: 'pci-0000:01:00.0-ata-1'
whole_disk: 1
DTL: 28
create_txg: 4
com.delphix:vdev_zap_leaf: 26
offline: 1
children[1]:
type: 'disk'
id: 1
guid: 1020653270431596650
path: '/dev/sda2'
whole_disk: 0
DTL: 79
create_txg: 4
com.delphix:vdev_zap_leaf: 68
offline: 1
children[2]:
type: 'disk'
id: 2
guid: 1321917959934574704
path: '/dev/sdb2'
whole_disk: 0
DTL: 78
create_txg: 4
com.delphix:vdev_zap_leaf: 69
children[3]:
type: 'disk'
id: 3
guid: 14728949233396094063
path: '/dev/sdc2'
whole_disk: 0
DTL: 31
create_txg: 4
com.delphix:vdev_zap_leaf: 70
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
Aktuell vermute ich Folgendes:
Platte 1von4 und 2von4 (die, die mal /dev/sda und /dev/sdb waren) hab ich wohl irgendwie zerschossen.
Hätte jemand einen Hinweis, wie ich jetzt vorgehen sollte, damit nicht nur die Zurodnung (Platte 1von4 = /dev/sda, Platte 2von4 = /dev/sdb) wieder stimmt, sondern auch das RAID-Z2 komplett wiederhergestellt wird?
Danke für jeden Hinweis und Verzeihung für die lange Fehlerbeschreibung!