Mi experiencia con ZFS en general ha sido quesimplemente funciona, así que espero que la respuesta sea: no es un problema, pero tengo un conjunto de datos que arruinará mi enero si falla, así que quiero volver a verificar.
Esta es una pregunta que podría surgir en dos situaciones diferentes que involucren un conjunto de datos separado. Ahora mismo me ocupo de lo primero, pero también me he preguntado sobre lo segundo:
- El almacenamiento del disco del sistema (es decir, el que contiene
rpool) falla, pero el almacenamiento del grupo de datos está bien, por lo que desea restaurar el disco del sistema a partir de las copias de seguridad pero continuar con el almacenamiento activo del grupo de datos. - Tiene Solaris ejecutándose en una máquina virtual y desea retroceder a una instantánea que tomó el hipervisor (nouna instantánea ZFS de
rpool), pero el grupo de datos se almacena en discos que están en modo "independiente", RDM, etc., por lo que no se revertirá.
En ambas situaciones, cuando se reinicie Solaris, verá un grupo de datos que conoce pero que se encuentra en un estado en el que nunca (hasta donde recuerda) lo había puesto.
Principalmente solo me preocupa el caso en el que el sistema se apagó limpiamente antes de rebobinar el disco del sistema, y en el que el sistema se apagó limpiamente antes de la imagen en la que se rebobina. Esperaría que cambiar entre estados de ejecución pudiera ser un poco más complicado.
Tenga en cuenta también que en mi caso particular, la geometría de almacenamiento del grupo y las rutas al almacenamiento no han cambiado. Nuevamente, esperaría que esto fuera más complicado si lo hubieran hecho.
Ni siquiera preguntaría esto con Windows y NTFS porque es un sistema desacoplado comparativamente simplista, por lo que es difícil ver por quéno lo haríatrabajar. Sin embargo, parece que Solaris guarda algún tipo de metadatos del grupo.fuera de banda, como lo demuestra el hecho de que se supone que debes zpool exportmover zpool importgrupos entre sistemas (algo que nunca he hecho de esa manera gracias a VMware). Mi conocimiento de estos metadatos y su propósito es limitado, por lo que me resulta difícil razonar sobre el impacto en esta situación. (¡Una explicación de esto sería genial!)
De hecho, todavía tengo acceso al sistema de pre-reversión. Está ubicado en un almacén de datos VMFS respaldado por un HP SmartArray que arrojó una advertencia POST 1716 después de un desafortunado cambio de disco de mantenimiento preventivo (que perdió datos porque SmartArray es más tonto que ZFS). Todas las máquinas virtuales importantes todavía parecen estar bien y los análisis de sus sistemas de archivos no encontraron errores, pero planeo restaurar la matriz desde una copia de seguridad muy reciente de todos modos porque tengo motivos para sospechar que ESXiPone a cero silenciosamente los sectores defectuosos en lugar de pasar los errores a los invitados., así que no quiero correr el riesgo de que algún sector puesto a cero aceche en algún lugar y me muerda el trasero más tarde.
Para la máquina virtual Solaris, no tengo que preocuparme por los sectores puestos a cero, porque ZFS los detectaría, pero la mayoría de las otras máquinas virtuales usan sistemas de archivos tontos. Sin embargo, la copia de seguridad es una imagen de todo el almacén de datos de VMware, por lo que arreglarla también revertirá la máquina virtual Solaris. En realidad, revisé rpoolesta máquina virtual y no encontró errores, así que, si quisiera, podría simplemente guardar su VMDK en otro lugar y copiarlo nuevamente después de la reversión, y luego toda esta pregunta sería discutible. Supongo que eso es lo que haré si nadie responde, jajaja. Pero es algo que me pregunto desde hace tiempo, así que seguiré preguntando.
Entonces, la pregunta es,¿Puedo simplemente seguir adelante, revertir el almacenamiento del disco del sistema y terminar de una vez? ¿O tendría que exportar el grupo desde el sistema de reversión previa, revertirlo, eliminarlo antes de adjuntar su almacenamiento, luego adjuntar el almacenamiento e importar el grupo? No me gusta el sonido de este último, en parte porque hay CIFS e iSCSI desde ese grupo y no recuerdo cómo los configuré o incluso cómo hacerlo, así que si se rompen, Estaré enojado. (¿Se nota que no tenemos un administrador de sistemas a tiempo completo? jajaja)
La máquina virtual ejecuta una versión anterior, Solaris 11.0.
(Por cierto, es más antiguo en parte debido a la misma pregunta. Quería tomar una instantánea de la VM antes de intentar una actualización en caso de que lo hiciera mal, pero luego me preocupaba cómo podría reaccionar un sistema revertido al grupo independiente, así que simplemente Lo dejé en paz. Y sí, me doy cuenta de que también podría tomar una instantánea del archivo rpool, pero eso no brinda el mismo nivel de comodidad para alguien que no trabaja con Solaris a diario).
Respuesta1
Esta es una de esas respuestas del tipo "zfs simplemente funciona"...
Los metadatos del grupo en realidad se almacenan en el grupo, no en el sistema operativo local. Entonces, por ejemplo, si un sistema falla y no se apaga limpiamente, los metadatos dentro del grupo saben que el grupo no se "exportó" limpiamente. Si intentara importar este grupo a un nuevo sistema, recibiría quejas de que no se exporta y pertenece a otro sistema. En ese punto, simplemente haría zpool import -f (force) y quedará limpio.
Entonces, específicamente para su grupo de datos, los datos que contiene estarán seguros, sin importar cuándo o dónde intente importar el grupo nuevamente. Si iniciara en un rpool "restaurado", el sistema operativo en ese rpool conocería los grupos que se supone que debe importar y simplemente importaría el grupo de datos. No realiza un seguimiento de si un grupo se exportó o no, aparte del hecho de que una vez que se exporta un grupo, el sistema operativo ya no lo sigue en absoluto.
Ahora, con respecto a la cuestión del rpool. Restaurarlo desde una instantánea de VM, una copia de seguridad en cinta o lo que sea no cambiará la forma en que maneja el grupo de datos, a menos que la copia de seguridad se haya realizado antes de que el grupo de datos se creara o importara inicialmente. Si ese fuera el caso, simplemente importaría el grupo una vez que se restaure el sistema operativo. Los datos del grupo de datos estarán seguros, sin importar la condición del grupo.
Espero que eso ayude.
Además, menciona su renuencia a actualizar Solaris porque no estaba seguro de cómo reaccionaría ante el conjunto de datos. No te preocupes por eso. Una actualización preservará los grupos conocidos y los importará según sea necesario.
También tenga en cuenta que las actualizaciones del sistema operativo Solaris son independientes en "entornos de arranque (BE)" individuales. Entonces, cuando realiza una actualización del sistema operativo, en realidad se crea una instalación del sistema operativo completamente independiente que contiene la nueva versión... todo mientras su sistema operativo aún está en funcionamiento. Luego, cuando reinicies, aparecerá en el nuevo sistema operativo. Si hay problemas con el nuevo sistema operativo, es decir. cambios en las bibliotecas, etc. que no esperaba: simplemente puede reiniciar nuevamente y acceder a la versión 11.0 original y estará exactamente en el mismo estado que tenía antes de actualizar. ¡Es una manera increíble de realizar actualizaciones del sistema operativo!