La página 2 de este tutorial de la comunidad cambia la decisión de «¿cómo ejecuto dd?» a «¿qué vale realmente la pena proteger?». El usuario ya tenía un NVMe grande en uso y le preocupaba mucho más perder DATA que perder el sistema operativo arrancable. El consejo de gelbuilding fue evitar reparticionar el NVMe de arranque en uso, proteger primero DATA/AppData y conservar un clon sin procesar del sistema solo si el beneficio en tiempo de recuperación justifica el espacio adicional de copia de seguridad.
Esta prioridad encaja con la arquitectura actual de ZimaOS. El sistema operativo tiene ranuras de sistema A/B para una recuperación rápida, mientras que los datos de usuario irremplazables, AppData y los metadatos de almacenamiento se encuentran fuera de esas imágenes de sistema inmutables. Un clon de disco completo puede devolver la máquina a un punto exacto rápidamente, pero no sustituye a las copias de seguridad independientes y versionadas de DATA.
dd clona todo el dispositivo, no solo las pequeñas ranuras del sistema operativo
El tutorial original utiliza un concepto de comando como el siguiente:
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzSi el sistema se encuentra en un NVMe de 1 TB, el proceso de creación de la imagen sin procesar sigue leyendo todo el dispositivo de bloques. La compresión puede reducir el tamaño del archivo, pero el destino y el proceso de copia de seguridad dependen de la disposición física del disco, no solo de los pocos gigabytes utilizados por las particiones del sistema de ZimaOS.
No reparticiones un sistema activo y saludable solo para hacer más pequeño dd
gelbuilding calificó la repartición del NVMe de arranque en uso como de alto riesgo, porque un error puede causar tiempo de inactividad o pérdida de datos. Si la disposición actual funciona, crea copias de seguridad de datos verificadas antes de cambiar los límites de las particiones.
Protege DATA y AppData antes que el clon del sistema operativo
Si tu prioridad es la capacidad de recuperación, haz copias de seguridad de lo siguiente:
- archivos de usuario y grupos de almacenamiento;
- AppData, bases de datos y configuraciones que no puedan recrearse fácilmente;
- exportaciones importantes específicas de las aplicaciones;
- metadatos de almacenamiento de ZimaOS, como
local-storage.db, cuando corresponda; - y, después, opcionalmente, el disco completo del sistema.
La guía actual de ZimaOS sobre la regla 3-2-1 admite copias de seguridad programadas en destinos independientes y puntos de restauración versionados.
Utiliza el modelo actual de copias de seguridad 3-2-1 de ZimaOS.
ZimaOS ya cuenta con recuperación de sistema A/B
ZimaOS utiliza dos ranuras de sistema de aproximadamente 6 GB cada una. Si una ranura falla, la guía de recuperación actual permite al usuario arrancar desde la ranura alternativa mediante GRUB.
Utiliza la ruta actual de recuperación del sistema A/B.
Una reinstalación limpia puede recrear el sistema operativo, pero no automáticamente tu configuración exacta
Como señaló constgen, un sistema operativo inmutable a menudo puede simplemente reinstalarse. El argumento contrario de gelbuilding fue el tiempo de recuperación: un clon de disco puede devolver exactamente las aplicaciones, la configuración y el estado del sistema tal como se capturaron, mientras que una reinstalación puede requerir volver a asignar AppData, reinstalar aplicaciones y reconectar los metadatos de almacenamiento.
Ambas son estrategias de recuperación válidas; optimizan aspectos diferentes.
Un disco de arranque dedicado y pequeño simplifica la clonación del disco completo
gelbuilding recomendó trasladar ZimaOS con el tiempo a un dispositivo dedicado pequeño de 32-64 GB y mantener el almacenamiento grande NVMe/RAID para DATA/AppData. El mínimo exacto para la instalación actual de ZimaOS es de al menos 25 GB.
Esto separa el sistema operativo prescindible del almacenamiento de datos grande y hace que una imagen completa del sistema sea mucho más pequeña.
Los comandos de restauración sin procesar son destructivos
Restaurar una imagen de dd escribe directamente sobre el disco de destino. Seleccionar el destino /dev/... equivocado puede destruir otra unidad. El tutorial original se compartió explícitamente con fines de prueba, y estos comandos solo deben utilizarse después de identificar los discos por modelo y número de serie, y de conservar DATA en otro lugar.
Prueba la ruta de recuperación, no solo la creación de la copia de seguridad
Una copia de seguridad solo es útil si sabes cómo restaurarla. Para DATA, restaura archivos representativos. Para una imagen de sistema sin procesar, prueba el procedimiento en un medio de repuesto si es posible, en lugar de descubrir supuestos sobre dispositivos o rutas durante una interrupción real.
Preguntas frecuentes sobre clones y copias de seguridad de ZimaOS
¿Es necesario clonar todo el disco del sistema para proteger los datos de ZimaOS?
No. Las copias de seguridad de DATA/AppData y los metadatos de almacenamiento son independientes de las particiones de sistema A/B y tienen mayor prioridad cuando se trata de información irremplazable.
¿Por qué conservaría de todos modos un clon del sistema operativo sin procesar?
Puede acortar el tiempo de recuperación al restaurar exactamente la configuración capturada del sistema y de las aplicaciones, en lugar de reconstruirla manualmente.
¿Debería reparticionar un NVMe en uso solo para hacer más pequeño el clon?
La recomendación original fue no hacerlo: crea primero una copia de seguridad de DATA y evita cambios innecesarios en las particiones activas.
