Manual

Copias de seguridad

Una tarea de copia selecciona VM, programación, retención y un Remote. El Remote almacena datos de recuperación independientes; una ejecución registra el trabajo y un punto identifica el estado restaurable. Antes de programar copias, prepare capacidad accesible en un dominio de fallo distinto y mantenga un motor hv en ejecución para procesar la cola.

Configurar un remote y una tarea

Abra Sistema, Copias de seguridad. Incluye Tareas, Ejecuciones, Puntos de restauración, Remotes y Retención. Cree un Remote y una regla de retención; después, cree la tarea con la selección de VM y horario previstos.

Este ejemplo usa un directorio preparado en la máquina del motor, no en el equipo de la CLI:

hv backup remote add backup-disk --kind local_dir --path /srv/hv-backups
hv backup retention set weekly --last 7
hv backup job create nightly --mode full --pool POOL --vm VM --remote backup-disk --retention weekly --schedule '0 2 * * *'
hv backup job show nightly
hv backup job run nightly
hv backup run list --job nightly
hv backup run show RUN_ID

Revise la selección y la siguiente ejecución antes de dejarla programada. Los horarios utilizan expresiones cron de cinco campos en UTC. La CLI también configura Remotes NFS y S3. Para S3, indique la referencia de la credencial almacenada al configurar el Remote. Compruebe el acceso al destino antes de asignarlo a una tarea programada.

Elegir modo y retención

Las copias completas transfieren todos los datos del disco. Las Delta usan seguimiento de bloques modificados y vuelven a una copia completa si este se reinicia. Las instantáneas rotativas conservan puntos en el Pool sin una copia de disco independiente. La replicación continua mantiene una réplica de destino; la recuperación ante desastres combina copia en Remote y replicación. Mirror copia puntos de catálogo entre Remotes. Las copias de metadatos protegen el estado de gestión, no los discos de las VM.

La retención debe conservar las dependencias de los puntos Delta retenidos. Nunca borre VHD padres individuales para liberar espacio. Eliminar una tarea suele conservar los puntos; las opciones de purga los eliminan deliberadamente. Inspeccione dependencias antes de borrar un Remote.

Restaurar y probar

En Puntos de restauración, seleccione el origen y abra la restauración. Elija con cuidado Proyecto, Pool, SR y red de destino. Para una prueba, use una red aislada que evite conflictos con la VM original.

hv backup points --remote REMOTE_ID --server https://hv.example.com:8443
hv backup restore POINT_ID --kind full --pool DESTINATION_POOL --sr DESTINATION_SR_UUID --network ISOLATED_NETWORK_UUID --name restore-test --server https://hv.example.com:8443
hv task show TASK_ID --server https://hv.example.com:8443

Autentíquese como indica CLI y API. La restauración requiere modo remoto; aquí SR y red son UUID. La red elegida se aplica a todas las NIC restauradas. Espere a la tarea, inspeccione los discos, arranque la VM recuperada de forma aislada y compruebe los datos de la aplicación.

La restauración de archivos lee contenidos ext2/3/4 o NTFS admitidos y genera un archivo, sin sobrescribir la VM en ejecución. Pueden rechazarse funciones de sistemas de archivos no compatibles. Recuperar metadatos exige además el material de claves original protegido y restaurar coordinadamente la base de datos; una reversión de raíz A/B no lo hace.

Copiar y recuperar web-01

Suponga que web-01 pertenece a production y ejecuta una aplicación cuyos datos deben sobrevivir a la pérdida del Host. Primero decida cuánto trabajo reciente puede perderse y cuánto puede durar la recuperación. Use esos requisitos para elegir programación y retención; el horario nocturno y los siete puntos del ejemplo son ilustrativos, no una garantía de que una semana de historial resulte suficiente.

Prepare backup-disk en almacenamiento que siga disponible si falla el Host de la VM. Un directorio en el mismo disco averiado no cumpliría ese objetivo, aunque la copia hubiera terminado correctamente. Compruebe que el motor puede escribir en él y que hay capacidad para el modo elegido. La referencia de la CLI explica cómo consultar la tarea programada y sus ejecuciones.

Cree nightly con web-01 como VM seleccionada y revise la configuración guardada antes de ejecutarla. Compruebe los identificadores del Pool y de la VM, no solo el nombre. Ejecútela manualmente una vez y espere a que termine. Revise el diagnóstico y confirme que aparece un punto de recuperación antes de depender del horario. Si falla la primera ejecución, resuelva la causa antes de añadir más tareas.

Para la prueba, elija un punto de esa ejecución y restáurelo como restore-test. Seleccione un SR con espacio suficiente y una red aislada. No conecte el invitado restaurado a producción mientras el original siga activo: el sistema operativo puede conservar su dirección e identidad de servicio. La red elegida se aplica a todas las NIC restauradas, por lo que conviene revisar especialmente los invitados con varias interfaces.

Cuando termine la tarea de restauración, revise los discos de la VM recuperada y arránquela aislada. Inicie sesión desde la consola y compruebe los datos de la aplicación correspondientes al momento elegido. Que el sistema operativo arranque no demuestra que la aplicación pueda recuperarse. Anote el punto utilizado, los datos comprobados y el tiempo empleado. Elimine la VM de prueba solo tras confirmar que no contiene datos que deba conservar.

Mantener la capacidad de recuperación

Revise los puntos después de cambiar la selección de VM, el almacenamiento o la retención. Una tarea que ya no incluya web-01 no protegerá sus cambios futuros. Del mismo modo, una copia solo de metadatos no sustituye la copia de discos que necesita este ejemplo. Mantenga el material de recuperación de la gestión separado de los informes de soporte y disponible para los administradores responsables de la recuperación ante desastres.

Si una restauración falla después de crear objetos de destino, revíselos antes de repetirla. Determine si pertenecen a la prueba fallida o a otra carga y conserve los detalles del error. No elimine el punto de copia durante el diagnóstico; puede ser la única copia independiente disponible.

Problemas habituales

Una ejecución en cola necesita un motor funcional, no otra tarea duplicada. Un fallo de transferencia exige revisar conectividad, permisos y capacidad del Remote. Inspeccione objetos de destino que queden tras una restauración fallida antes de repetirla. Debe revisarse una réplica promovida antes de seguir replicando: su protección evita sobrescribir una VM de recuperación que podría estar funcionando. Una prueba de restauración permite comprobar si los datos guardados sirven para recuperar el servicio.