Hice algo muy estúpido hoy al intentar agregar un tercer espejo a un zpool de Linux existente llamado backup. Baste decir que cometí un par de errores porque realmente no hago mucha administración con mi ZFS aparte de cambiar discos cada dos años. Y al intentar corregirlos, leí mal los consejos en línea para recrear el grupo y creé un nuevo grupo con el nombre, backupdestruyendo así el grupo existente. (Sí, usé la -fopción después de que se quejara. Sí, soy un idiota. Ahora sé que no volveré a hacer eso nunca más. Sigamos adelante).
Por lo que leí en línea, backupes probable que el grupo original que "creé" sea irrecuperable. Lo cual está bastante bien, porque su nombre backupse debe a una razón: en su mayoría solo alberga mis copias de seguridad que se remontan a hace aproximadamente 15 años. Sin embargo, hay algunas cosas que sería bueno recuperar (algunos datos no esenciales que moví allí temporalmente) y algunas cosas que me tomará unos días configurar nuevamente y que tienen que ver con la configuración de respaldo que residía en ese volumen. (Ahora sé que debo hacer una copia de seguridad de todo eso en otro lugar, por lo que será una experiencia de aprendizaje).
Pero tengo una copia de seguridad de mis copias de seguridad: hoy estaba reemplazando un tercer espejo por una unidad que había quitado hace unos meses durante otra actualización de mi sistema (junto con una actualización del sistema operativo). Esa unidad en realidad no falló, pero era vieja y había comenzado a acumular un par de sectores defectuosos, así que pensé que sería mejor sacarla en lugar de esperar a que se corrompiera o algo así.
De todos modos, todavía tengo ese disco antiguo, así que pensé que podría volver a colocarlo en mi sistema y recuperar los datos del grupo desde allí. Sólo me faltarían los datos de respaldo de los últimos meses. Ahora bien, nunca había exportado oficialmente el grupo en esa unidad ni nada por el estilo. Y desde entonces actualicé mi sistema operativo, por lo que no esperaba que detectara automáticamente esa unidad. (No sé si está conectado al mismo puerto SATA o no, ya que moví algunas unidades).
Pero el zpool importcomando no parece encontrar nada automáticamente. Al jugar con algunas opciones, zpool importve la segunda versión (ahora destruida) del backupgrupo, pero ese es solo el grupo vacío que creé accidentalmente en otras dos unidades.
¿Algún consejo sobre cómo podría intentar leer los datos de este tercer disco? Hasta donde puedo recordar, era un espejo perfectamente funcional y actualizado del grupo ZFS antes de que lo sacara de la caja hace unos meses. En particular:
- ¿El hecho de que haya un grupo destruido llamado
backuppotencialmente interfiere con la capacidad de detectar e intentar recuperar/importar este grupo antiguo? ¿Hay alguna manera de evitar eso? - Todavía tengo la instalación del sistema operativo antiguo en mi servidor que creo que se estaba ejecutando cuando usaba el disco antiguo. Intenté iniciarlo solo para ver si podía detectar el grupo ZFS, pero no fue así. (Nuevamente, es posible que la unidad no esté conectada al mismo lugar). Pero, ¿hay algún archivo de registro ZFS u otras cosas que pueda recuperar y que puedan contener metadatos en ese grupo antiguo o el número de identificación o algo que pueda ¿Podría usarse para obligar a ZFS a importar lo que debería ser un espejo intacto en esta unidad?
- Simplemente supongo que mi grupo en los dos primeros discos fue destruido mediante el
create -fcomando. Pero si alguien tiene una idea de cómo podría recuperar el primer grupo directamente allí, obviamente sería genial. - ¿Hay alguna otra razón por la que ZFS no detecte el tercer espejo antiguo como un disco de grupo ZFS? Si es así, ¿alguna otra sugerencia? ¿Otras herramientas de recuperación puedo probar?
Gracias por cualquier ayuda o sugerencia.
EDITAR: Aquí está el resultado de zdb -l /dev/sdb1(que es la tercera unidad)
------------------------------------
LABEL 0
------------------------------------
version: 5000
name: 'backup'
state: 0
txg: 0
pool_guid: 3936176493905234028
errata: 0
hostid: 8323329
hostname: [omitted]
top_guid: 14695910886267065742
guid: 17986383713788026938
vdev_children: 1
vdev_tree:
type: 'mirror'
id: 0
guid: 14695910886267065742
whole_disk: 0
metaslab_array: 34
metaslab_shift: 33
ashift: 12
asize: 1000197324800
is_log: 0
create_txg: 4
children[0]:
type: 'disk'
id: 0
guid: 17914838236907067293
path: '/dev/sdd1'
whole_disk: 0
DTL: 143
create_txg: 4
children[1]:
type: 'disk'
id: 1
guid: 17986383713788026938
path: '/dev/sdb1'
whole_disk: 0
DTL: 141
children[2]:
type: 'disk'
id: 2
guid: 1683783279473519399
path: '/dev/sdc1'
whole_disk: 0
DTL: 145
create_txg: 4
features_for_read:
com.delphix:hole_birth
com.delphix:embedded_data
create_txg: 0
labels = 0 1 2 3
Si interpreto esto correctamente, el estado 0 significa que el grupo debería estar intacto. Pero cuando intento importar incluso usando el GUID del grupo zpool import 3936176493905234028, aparece el error "no se puede importar... no hay dicho grupo disponible". (Supongo que debería usar pool_guid, pero también intenté usar guid y top_guid y nada parece funcionar).
EDITAR2: recuperé el archivo zpool.cache del sistema operativo original en el que este grupo estaba activo y lo probé zpool import -c zpool.cache, lo que dio esto:
pool: backup
id: 3936176493905234028
state: UNAVAIL
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
see: http://zfsonlinux.org/msg/ZFS-8000-5E
config:
backup UNAVAIL insufficient replicas
mirror-0 UNAVAIL insufficient replicas
sdd1 FAULTED corrupted data
sdc1 FAULTED corrupted data
Lo cual es algo de esperar. Esos son los dos discos donde mi comando de creación sobrescribió el grupo. Sin embargo, sdb1 no aparece como una unidad potencial allí, probablemente porque lo eliminé del grupo después de sacar el disco. Sin embargo, creo que tengo una copia intacta de los datos reflejados antiguos en sdb1 y zdb está de acuerdo. ¿Por qué no importa?