¿Es posible desconectar y volver a conectar un disco ZFS sin necesidad de una resistencia completa?

10

Tengo un grupo reflejado ZFS con cuatro unidades totales. Dos de las unidades están destinadas a ser utilizadas para realizar copias de seguridad fuera del sitio. Mi expectativa era que después de la recuperación inicial podría detachy luego attachun disco y hacer que solo haga una recuperación incremental; sin embargo, en las pruebas parece realizar una recuperación completa independientemente de si el disco que se está conectando ya contiene casi todo el grupo contenido.

¿Usar un enfoque offline/ onlineme daría el resultado deseado de solo actualizar el disco, en lugar de reconstruirlo por completo? ¿O para que este trabajo funcione como se espera, tendré que hacer algo completamente diferente, como usar cada disco de respaldo como un grupo de 1 disco e sendincorporarle las instantáneas más nuevas cada vez que sea necesario actualizarlo?

zfs zpool backup

— STW
fuente

55

-1 No desconecte / conecte unidades para la copia de seguridad, use los comandos enviar / recibir como los diseñadores de ZFS pretendían

— Chris S

2

@ChrisS en lugar de un -1, ¿qué tal escribir una respuesta con algunas citas? Parece que dice que las únicas opciones para las copias de seguridad son un grupo en línea en otro lugar, lo que sería bueno saber si es cierto, pero sospecho que no es el caso.

— STW

1

Lo siento, no pretendo ser un imbécil arrogante, pero se supone que la falla del servidor es solo para administradores de sistemas profesionales (et al). El método de copia de seguridad de los espejos de ruptura es tan inmanejable, propenso a errores y poco profesional que no debería considerarse un método de copia de seguridad viable. Lo que sugiero es que formatee las dos unidades de copia de seguridad con el sistema de archivos que desee y utilice el zfs sendcomando para tomar secuencias de copia de seguridad completas o incrementales guardadas en los discos de copia de seguridad, o use zfs recvpara crear un disco duplicado. Recomiendo encarecidamente utilizar algún tipo de software para administrar este proceso.

— Chris S

Creo que sus puntos son válidos, lo votaré como respuesta. Estoy considerando reescribir mi pregunta para centrarme menos en mi escenario específico (que surge de un presupuesto reducido para un servidor interno no crítico, pero importante) y más en el núcleo "¿puedo volver a conectar una unidad sin requerir un completo ¿Resistente?

— STW

14

No siga el camino de romper la matriz ZFS para "rotar" los discos fuera del sitio. Como ha visto, el tiempo de reconstrucción es alto y el proceso de recuperación leerá / verificará el tamaño utilizado del conjunto de datos.

Si tiene la capacidad, las instantáneas y el envío de datos a un sistema remoto es un enfoque limpio y no intrusivo. Supongo que podría pasar por el proceso de tener un grupo de un solo disco dedicado, copiarlo y exportar / importar zpool ... pero no es muy elegante.

— ewwhite
fuente

Desafortunadamente, no puedo usar un enfoque de instantánea-> envío ya que no tengo el hardware o el ancho de banda para ejecutar un segundo servidor ZFS fuera del sitio. Sin embargo, parece que el uso fuera de línea / en línea funcionará, con el compromiso de que el estado informa como degradado. Veré cómo va la próxima semana más o menos.

— STW

1

Entendido. Pero extraer discos en ejecución de un sistema como una forma de respaldo no es una solución sólida. Su riesgo aumenta drásticamente cuando hace esto.

— ewwhite

Buen punto, mi plan es desconectarlos, suspenderlos, desmontar su bandeja de intercambio en caliente y luego darle un minuto para garantizar una parada completa antes de tirar por completo

— STW

1

¿Se puede operar un segundo servidor en el sitio (o incluso una segunda matriz ZFS en el mismo servidor)? Coloque sus bahías de hotswap en él, sincronice entre él y el principal, y luego gire toda la matriz ZFS de respaldo dentro / fuera del servidor como una unidad.

— Dan está tocando el violín el

11

Después de más experimentación, he encontrado una solución justa, sin embargo, viene con una importante compensación. Los discos que se han offlinedesconectado pero no se pueden desconectar más tarde se pueden volver a poner en línea con solo una operación de recuperación incremental (" Cuando un dispositivo se pone en línea, los datos que se han escrito en el grupo se vuelven a sincronizar con el nuevo dispositivo disponible "). En mis pruebas, esto reduce el tiempo de recuperación para un espejo de 3 discos de 28 horas a poco más de 30 minutos, con aproximadamente 40 GB de datos delta.

La compensación es que cualquier grupo con un disco fuera de línea se marcará como degradado. Siempre que haya al menos dos discos en línea (en un grupo reflejado), esto es efectivamente una advertencia: la integridad y la redundancia permanecen intactas.

Como otros mencionaron, este enfoque general dista mucho de ser ideal: enviar instantáneas a un grupo remoto sería mucho más adecuado, pero en mi caso no es factible.

Para resumir, si necesita eliminar un disco de un grupo y luego agregarlo nuevamente sin requerir una recuperación completa, entonces el enfoque que recomendaría es:

desconectado el disco en el grupo: zpool offline pool disk
girar hacia abajo el disco (si se va a tirar físicamente): hdparm -Y /dev/thedisk
dejar la piscina en un estado degradado con la unidad desconectada
para volver a agregar el disco al grupo: zpool online pool disk

Y, dado que esto aún no se ha probado, existe el riesgo de que la operación de recuperación delta no sea precisa. El grupo "en vivo" y / o los discos sin conexión pueden experimentar problemas. Actualizaré si eso me sucede, pero por ahora experimentaré con este enfoque.

— STW
fuente

1

Si el resilver va a introducir errores de datos, estos se van a sanar automáticamente con el tiempo o con un exfoliante zpool.

— the-wabbit

Me he dado cuenta del valor de un exfoliante; Espero hasta después de un fregado exitoso para desconectar y eliminar el disco de respaldo

— STW

2

Solo una actualización rápida: durante el año pasado, este enfoque ha funcionado lo suficientemente bien. Las pruebas de restauración mensuales de la copia de seguridad externa han sido exitosas y consistentes. Girar una matriz (en lugar de un solo disco) sería mejor para proporcionar un nivel de redundancia en la copia externa, y recomendaría hacerlo si es posible. En general, este sigue siendo un enfoque agresivo y presenta algunos riesgos, pero ha proporcionado una copia de seguridad de nuestros datos fuera del sitio razonablemente segura y económica.

— STW

Yo argumentaría en contra de rotar todas las unidades en la matriz, ya que el transporte puede dañarlas lentamente. No haría la rotación incluso si las unidades permanecen en el sitio.

— Costin Gușă

2

Actualización el 15 de octubre de 2015: hoy descubrí el zpool splitcomando, que divide un nuevo grupo (con un nuevo nombre) fuera de un grupo existente. splites mucho más limpio que offliney detach, ya que ambos grupos pueden existir (y eliminarse por separado) en el mismo sistema. El nuevo grupo también se puede limpiar (y correctamente) export[ed]antes de desconectarse del sistema.

(Mi publicación original sigue a continuación).

¡Advertencia! Varios comentarios en esta página implican que es (o podría ser) posible a zpool detachuna unidad, y luego de alguna manera vuelva a conectar la unidad y acceder a los datos que contiene.

Sin embargo, de acuerdo con este hilo (y mi propia experimentación) zpool detachelimina la "información del grupo" de la unidad separada. En otras palabras, a detaches como un reformateo rápido de la unidad . Después detachde que aún haya muchos datos en la unidad, será prácticamente imposible volver a montar la unidad y ver los datos como un sistema de archivos utilizable.

En consecuencia, me parece que detaches más destructivo que destroy, ya que creo que zpool importpuede recuperar las piscinas destruidas.

A nodetach es a , ni a , ni a .umountzpool exportzpool offline

En mi experimentación, si primero tengo zpool offlineun dispositivo y luego zpool detachel mismo dispositivo, el resto del grupo olvida que el dispositivo existió alguna vez. Sin embargo, debido a que el dispositivo en sí estaba offline[d]antes de lo que estaba detach[ed], nunca se notifica al dispositivo detach. Por lo tanto, el dispositivo en sí todavía tiene la información de su grupo y se puede mover a otro sistema y luego import[ed](en un estado degradado).

Para mayor protección contra detachusted, incluso puede desconectar físicamente el dispositivo después del offlinecomando, pero antes de emitir el detachcomando.

Espero usar esto offline, luego detach, luego importprocesar para hacer una copia de seguridad de mi grupo. Al igual que el póster original, planeo usar cuatro unidades, dos en un espejo constante y dos para copias de seguridad mensuales, rotativas, fuera del sitio (y fuera de línea). Verificaré cada copia de seguridad importándola y limpiándola en un sistema separado, antes de transportarla fuera del sitio. A diferencia del póster original, no me importa reescribir la unidad de copia de seguridad completa cada mes. De hecho, prefiero reescrituras completas para tener bits nuevos.

— mpb
fuente

0

En la misma máquina, ¿ha intentado crear un nuevo grupo con las 2 unidades en un espejo? A continuación, cree una instantánea en su grupo de trabajo y luego envíe esa instantánea al nuevo grupo, repita, luego el siguiente envío de instantánea será incremental. Esto no es lo mismo con "enviar datos a un sistema remoto" ya que se trata de un grupo dentro del mismo sistema / servidor / máquina. Con esta configuración, aún puede aplicar zpool split / offline / detach / attach pero solo lo hace en el segundo grupo (copia) y no en el grupo fuente.

— soyayix
fuente