← Todas las funciones

Copia de Proxmox VE (vista previa)

Por Lucas Flores, IT Systeme Flores UG. Última actualización: 2026-10-29

Restow respalda las máquinas virtuales y los contenedores de Proxmox VE 8.4 y posteriores mediante la Backup Provider API de Proxmox. Es una vista previa, disponible desde la 0.3.1 y en todas las ediciones, Community incluida. Todavía no se recomienda como única copia: los límites figuran más abajo, junto a la función.

Cómo se copian las VM y los contenedores

Los discos de las VM van por NBD con dirty bitmaps, de modo que solo se suben los bloques modificados de 4 MiB. Los contenedores pasan por restic. Las copias se guardan en un repositorio que usted elija, véase almacenamiento.

El lado del nodo tiene dos partes: un shim de plugin de almacenamiento, que es una obra aparte bajo AGPL-3.0-or-later, y el asistente restow-pve, que es Apache-2.0. Los invitados (las VM y los contenedores) cuentan en la preparación para restaurar, en las advertencias y en las alertas de copias atrasadas (backup.overdue), salvo los que un administrador excluyó a propósito (desde la 0.4.7, véase excluir un invitado).

Restauración

Una restauración crea una VMID nueva en el pool restow-restore. Las reglas generales de restauración están en la página de restauración.

Restaurar un contenedor funciona en el Proxmox VE actual desde la 0.4.6: antes, una restauración de contenedor, una prueba de arranque de un contenedor y «Restaurar como invitado nuevo» de un contenedor fallaban en el Proxmox VE actual con Can't use string ("restow") as a HASH ref, porque pasa el ID del almacenamiento al proveedor de copias antes del hash de información; las VM no se veían afectadas. La corrección está en el complemento de restow-pve: actualice restow-pve en cada nodo antes de fiarse de las restauraciones de contenedores o de las pruebas de arranque. Para los puntos de restauración de contenedores que dicen «No arrancó» o tienen una comprobación de restauración fallida de antes de la 0.4.3, ejecute «Probar arranque ahora» o «Comprobar ahora» cuando el nodo esté actualizado.

Conectar un nodo

Desde la 0.3.2, un comando conecta un nodo, con el token de inscripción incluido. El instalador del nodo configura por sí mismo el usuario restow@pve, los roles y el pool de restauración, crea su propio token de API, comprueba sus privilegios antes de instalar nada y elige por sí mismo el almacenamiento thin para el fleecing. En su lugar puede usarse un token de API de Proxmox VE ya existente. Restow guarda su id y su secreto cifrados solo hasta que el nodo se ha inscrito con ellos o caduca el token de inscripción, y se los entrega una vez a ese nodo. La opción de comando para otro nodo añade el siguiente nodo.

Desde la 0.4.0, restow-pve se actualiza por sí mismo mientras no hay copia ni restauración en curso; restow-pve update en el nodo lo hace a mano. Desde la 0.4.2 la actualización del servidor arrastra a los nodos, y desde la 0.4.3 «Actualizar nodos y agentes ahora» inicia ese paso a mano, véase los nodos siguen una actualización del servidor.

Nodos, VM y contenedores en el inventario

Desde la 0.3.3, cada nodo de Proxmox VE aparece en Servidores y equipos, Inventario, como una fila desplegable. Muestra el estado en línea del nodo y recuentos: protegidos, fallidos, sin trabajo, aún sin copia y, desde la 0.4.7, excluidos («Excluido: N»; en la interfaz en inglés, «Excluded: N»). Desplegada, cada VM y contenedor muestra su estado, su trabajo de copia y el estado de la copia y, cuando la última copia falló, por qué, con enlace a la página del propio invitado. El inventario es para administradores, una vez conectado un clúster. La página VMs y contenedores indica cuándo una copia espera al nodo y cuándo está en curso.

Desde la 0.3.4, las copias de contenedores sin privilegios en ext4 ya no fallan por la carpeta lost+found, y una copia de contenedor que restic no pudo leer por completo (código de salida 3) conserva su punto de restauración y nombra los elementos ilegibles.

Qué contiene cada copia

Desde la 0.3.5, VMs y contenedores y el inventario tienen una columna «Copia». Indica lo que contiene el punto de restauración más reciente y lo que añadió su ejecución, por ejemplo «9,4 GB en la copia, +2,5 MB nuevos», y mostraba la primera copia al pasar el cursor. Desde la 0.4.7 la columna del inventario muestra dos líneas más como texto en la fila del invitado, no solo al pasar el cursor, de modo que se pueden leer y copiar: el tamaño de la primera copia del invitado («Primera copia el <fecha>: <tamaño> guardados») y lo que añade de media una copia posterior («Media por copia posterior: +<tamaño> (últimas N copias)»); en la interfaz en inglés, «First backup on» y «Average per follow-up backup». La antigua columna «Tamaño» se llama ahora «Disco». En la página propia de un invitado, los puntos de restauración muestran su tipo (primera copia, incremental o lectura completa), lo que contienen y lo que añadieron. La primera copia de la cadena de copias nueva de un contenedor se llama desde la 0.4.6 «Primera copia», no «Incremental». Desde la 0.4.3 la columna de VMs y contenedores dice otra cosa, véase pestañas, filtros y un panel de detalle.

Una copia de contenedor que restic no pudo leer por completo aparece como «Correcta con lagunas» («Última copia incompleta» en la página del invitado), con el número de elementos ilegibles, y cuenta como «Incompleta» en el inventario.

«Copiar ahora» y la restauración indican que el nodo inicia la tarea en su próxima consulta periódica (check-in). Un segundo clic indica que ya hay una copia en espera, y las páginas se actualizan cada 5 segundos mientras un invitado espera a su nodo o se está copiando.

Proteger invitados desde el inventario

Desde la 0.3.6, los invitados pueden protegerse sin salir del inventario. En un nodo desplegado, cada VM y contenedor tiene su trabajo de copia como una elección: un trabajo existente, «Sin trabajo de copia» o un trabajo nuevo. «Copiar ahora» inicia una copia de ese invitado.

Para actuar sobre varios invitados a la vez, márquelos uno a uno, marque la casilla del encabezado para tomar todos los del nodo o use el botón junto al aviso de que varias VM y contenedores no tienen trabajo de copia para tomar con un clic todos los que no tienen trabajo. Después añada la selección a un trabajo o cópielos juntos con «Copiar ahora». Con un trabajo nuevo se abre el diálogo del trabajo y la selección pasa al trabajo nuevo. El nodo inicia una copia solicitada en su próxima consulta periódica (check-in), normalmente en menos de un minuto.

La columna de protección del inventario se llama ahora «Protección»; antes compartía el encabezado «Copia» con la columna que muestra lo que contiene el punto de restauración más reciente.

Excluir un invitado de la copia a propósito

Muchos invitados de un clúster no están pensados para copiarse, como las VM de prueba o los invitados que se copian en otro sitio. Un invitado sin ningún trabajo de copia cuenta en las vistas generales como «Sin trabajo de copia» e impide que el inquilino esté en verde, salvo que un administrador lo haya excluido a propósito (desde la 0.4.7). Pueden excluir una VM o un contenedor los administradores del inquilino y los administradores del equipo del proveedor: «Excluir de la copia» («Exclude from backup») está en la página del invitado y, para una selección de los invitados de un nodo, en el inventario; «Incluir de nuevo» («Include again») lo devuelve, en la página y en la fila del invitado en el inventario. Nada se excluye automáticamente. Como el resto de la copia de Proxmox VE, es una vista previa, en todas las ediciones, Community incluida.

• Ningún trabajo lo copia, ni siquiera el trabajo de todos los invitados, y el trabajo recomendado lo deja fuera. Su propio trabajo sigue registrado, de modo que al incluirlo de nuevo recupera lo que tenía. Excluir retira sus copias en cola; «Copiar ahora» y poner el invitado en un trabajo se rechazan hasta que se incluya de nuevo.
• No cuenta como desprotegido en ningún sitio: ni en las vistas generales, la preparación para restaurar, los avisos, backup.overdue, las estadísticas ni la vista del proveedor (ni en el aviso de que varias VM y contenedores no tienen trabajo de copia), y nunca impide que un inquilino esté en verde. Los recuentos de invitados lo cuentan como excluido, y el inventario muestra «Excluido: N» por nodo. En VMs y contenedores figura como «Excluido» («Excluded»; gris, nunca un problema) y tiene un filtro de estado propio.
• Sus puntos de restauración se quedan. Siguen siendo restaurables, y la retención los trata como antes. La comprobación semanal de su punto de restauración más reciente continúa; la comprobación mensual de restauración del trabajo y las pruebas de arranque ya no lo abarcan.

El cambio queda en el registro de auditoría como pve.guest.excluded; la ruta de la API es PUT /api/v1/pve/guests/:id/excluded. restow-pve no necesita actualización para esto. Los rótulos en español son una traducción: el producto no tiene textos en español.

VMs y contenedores: pestañas, filtros y un panel de detalle

Desde la 0.4.3, VMs y contenedores tiene tres pestañas con recuentos: Invitados (la predeterminada), Trabajos de copia y Nodos.

• Búsqueda y filtros. La tabla de invitados busca por ID y nombre y filtra por nodo, tipo (VM o contenedor), trabajo de copia (también «Sin trabajo de copia») y estado. «Solo problemas» muestra los invitados que piden atención: una ejecución fallida, avisos o lagunas, una comprobación de restauración que falló o no pudo ejecutarse, la espera de un nodo desconectado o con la cola en pausa, o ninguna copia. Las columnas se pueden ordenar (ID, nombre, nodo, última copia, tamaño de la copia, estado), las páginas admiten de 25 a 250 invitados y la tabla indica cuántos invitados dejan los filtros. La pestaña, la búsqueda, los filtros, el orden, la página y el invitado abierto van en la dirección, así que un enlace abre la misma vista.
• Un estado por fila. Una fila muestra un solo distintivo de estado, elegido por prioridad, con una pequeña barra de progreso mientras corre su copia o «+N» cuando se aplican más estados. El verde queda reservado para la prueba: solo una comprobación de restauración que releyó el punto de restauración más reciente es verde («Comprobación de restauración superada»), y una copia que solo terminó bien es un simple «Copia realizada».
• Panel de detalle. Un clic en una fila (o en su nombre) abre un panel con todos los estados del invitado, el error completo y los avisos de la última ejecución en un bloque desplazable que se puede copiar, la comprobación de restauración con lo que encontró, los tamaños, el trabajo de copia, las ejecuciones más recientes y las acciones: «Copiar ahora», «Detener», «Retirar», «Comprobar ahora» y abrir la página del invitado.
• La columna «Copia» dice, por ejemplo, «Primera: 32 GB el 3 oct · Última: +210 MB»: cuánto ocupó la primera copia (completa) y lo que añadió la última copia posterior. Lo que contiene el punto de restauración más reciente aparece al pasar el cursor, y el panel muestra los datos nuevos de cada una de las últimas 30 copias como pequeñas barras.
• Sin saltos. Las tablas de invitados y de trabajos mantienen anchos de columna fijos y una sola altura de fila, los textos largos se cortan en una línea, y «Copiar ahora», «Detener», «Retirar» y «Deteniendo…» comparten el mismo tamaño de botón, de modo que la página ya no se mueve mientras se ejecutan copias. Los textos de error ya no salen en rojo bajo una fila, y los avisos ya no se ven solo al pasar el cursor.

La pestaña Nodos muestra por nodo el latido, la versión de restow-pve con «Actualizar a …» cuando el servidor ofrece una versión más reciente, la versión de Proxmox VE, cuántos invitados tiene, su cola y sus problemas. El control de la cola y la revocación están en el menú de la fila. La nota de que el propio host de Proxmox VE no se copia (sus archivos propios los copia el agente de Restow instalado en el host) es una línea de esta pestaña y se puede ocultar. Los rótulos en español son una traducción: el producto no tiene textos en español.

Progreso, registro de ejecución y trabajos

Desde la 0.4.0, VMs y contenedores, el inventario y la página de un invitado muestran el progreso de una copia en curso, por ejemplo «34 % · 3,2 GB de 9,4 GB · 85 MB/s». Necesita restow-pve 0.4.0 en el nodo; desde la 0.4.1, una copia en un nodo más antiguo dice que el progreso necesita restow-pve 0.4.0 en ese nodo y qué versión tiene, en lugar de «Todavía no se ha comunicado progreso» durante toda su ejecución. Las líneas propias del asistente llegan ahora al registro que Restow guarda de la ejecución: el id de la ejecución, lo que restic añadió, lo que no pudo leer y el commit del punto de restauración. Una copia que terminó bien con lagunas nombra los primeros 20 elementos que restic no pudo leer.

Los trabajos de Proxmox VE están en Servidores y equipos, Trabajos, junto a los trabajos de equipos, con una columna Tipo: los invitados de cada trabajo, la planificación, la última y la próxima ejecución, «2 de 5 invitados terminados» mientras corre una ronda, y una copia iniciada a mano como una fila «Copia manual» hasta que termina. «Nuevo trabajo» es un menú con una entrada por tipo. Junto a cada aviso «sin trabajo», «Crear el trabajo recomendado» muestra una vista previa de lo que crea o amplía el clic, y luego crea un trabajo por tipo (para Proxmox VE: un trabajo, a diario a las 22:00 en modo instantánea); un segundo clic amplía el mismo trabajo en lugar de crear otro. Es para administradores y queda en el registro de auditoría. La página de un invitado muestra también lo que añade de media una copia posterior.

Una copia que se ejecuta mientras se actualiza Restow ya no falla: el nodo (restow-pve 0.4.0) sigue intentándolo durante cinco minutos, donde antes se rendía a los 30 segundos, y una ejecución de copia cuyo final nunca llegó al servidor se cierra cuando el nodo ya no la comunica, en lugar de figurar «en ejecución» durante 48 horas. restow-pve se actualiza ahora por sí mismo: pregunta dos minutos después de arrancar (desde la 0.4.1) y luego cada seis horas, y se actualiza mientras no hay copia ni restauración en curso; restow-pve update lo hace a mano. Los asistentes antiguos siguen funcionando sin progreso, sin el reintento de cinco minutos y sin la lista de ejecuciones activas.

Desde la 0.4.2, la programación de un trabajo de Proxmox VE ofrece las cadencias de un trabajo de correo: cada pocas horas, a diario, en los días de la semana elegidos, cada mes o con una expresión cron, en una zona horaria y no más a menudo que cada hora. Una copia que vzdump termina con avisos (por ejemplo «TASK WARNINGS: 1») después de confirmar su punto de restauración cuenta como «Correcta con avisos» («Succeeded with warnings»), en ámbar, no como fallida; restow-pve 0.4.2 tampoco pide ya notas a vzdump, que era lo que producía esos avisos.

Detener una copia

Desde la 0.4.2 una copia se puede detener desde la aplicación web, sin SSH en el nodo. Quien puede iniciar una copia puede detenerla, cada parada pregunta antes y queda en el registro de auditoría.

• «Detener copia» («Stop backup») está en la tabla VMs y contenedores, en la página del invitado y en el panel de ejecución. Una copia que todavía espera a su nodo se retira al instante («Retirar»): el nodo nunca la ve, y el historial muestra una ejecución «Cancelada por <usuario>». Una que el nodo ya recibió, o que está en curso, recibe una petición de cancelación, y la página dice «Cancelando…» hasta que el nodo la ha detenido.
• Cómo la detiene el nodo. restow-pve 0.4.2 mantiene su latido mientras se ejecuta una copia, cada 15 segundos, y recibe con él la orden de cancelación. En una copia que pidió Restow, el nodo detiene la tarea de vzdump mediante la API de Proxmox VE; vzdump termina la copia del invitado y elimina su instantánea y la imagen de fleecing. Una copia iniciada en el propio Proxmox VE, por un trabajo de copia de Proxmox VE con varios invitados, se detiene solo para ese invitado, y vzdump sigue con los demás.
• Cómo termina. La ejecución termina como cancelada, no como fallida: sin alerta de fallo, sin «Última copia fallida», la última copia del invitado queda como estaba, y de la ejecución detenida no se confirma nada, así que los puntos de restauración existentes no se tocan.
• Por nodo y por inquilino. «Pausar la cola» en un nodo no le entrega copias nuevas hasta que se reanude; una copia en curso sigue, y las copias programadas esperan (y caducan a las 12 horas, como siempre). «Cancelar todas las pendientes» retira cada copia que aún no ha empezado, para un nodo o para todo el inquilino.

Detener una copia en curso necesita restow-pve 0.4.2 en el nodo. Un nodo anterior a la 0.4.2 termina una copia cancelada en su siguiente subida, porque el servidor rechaza toda subida de una ejecución cancelada.

Los nodos siguen una actualización del servidor

Desde la 0.4.2, cuando el servidor ejecuta una versión nueva, las ejecuciones nuevas siguen en pausa mientras los nodos de Proxmox VE y los agentes la instalan (entonces están libres), hasta que todos los alcanzables notifican la versión nueva o pasan 15 minutos. Instalación › Actualizaciones muestra el progreso y, para un nodo que no se alcanzó, el comando para actualizar a mano (/opt/restow-pve/bin/restow-pve update, como root). «Actualizar a <versión>» en un nodo, en la tabla de nodos junto a su versión, pide la actualización en cualquier momento; el nodo instala la versión firmada en cuanto queda libre y se reinicia. Restow nunca actualiza el propio Proxmox VE.

Desde la 0.4.3, «Actualizar nodos y agentes ahora» («Update nodes and agents now») en la tarjeta de nodos y agentes de Instalación › Actualizaciones inicia a mano ese paso. Sirve para un servidor que ejecuta una versión más reciente que sus nodos y agentes aunque ninguna actualización haya llevado al paso en que lo siguen: el servidor se actualizó a mano, o se perdió la respuesta al anuncio de una actualización. Los nodos y agentes que van por detrás aparecen como «Actualización disponible». Lo inicia un administrador con acceso a todos los inquilinos; las ejecuciones nuevas se pausan como máximo 15 minutos, los nodos y agentes alcanzables instalan la versión en cuanto quedan libres, y la pausa termina cuando han acabado. Queda auditado. Un falso «El actualizador no está en ejecución» tras anunciar una actualización, que además omitía este paso, está corregido: el servidor espera ahora hasta un minuto la respuesta del actualizador.

restow-pve reinicia ahora los daemons de Proxmox VE que cargan su plugin de almacenamiento (pvedaemon, pveproxy, pvestatd y pvescheduler) después de actualizarse a sí mismo, como hace el instalador; restow-pve update reinicia además el servicio restow-pve. Un nodo que un restow-pve anterior actualizó reinicia los daemons una vez por sí mismo cuando arranca la versión nueva. Los nodos con restow-pve 0.4.1 no reaccionan ni a «actualizar ahora» ni al paso de seguimiento: se actualizan con su propia consulta (dos minutos después de arrancar el servicio y luego cada seis horas) o a mano, en cuanto no hay copia ni restauración en curso en el nodo. Ejecute como root /opt/restow-pve/bin/restow-pve update y después systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler.

Dónde acaban las copias, y una cadena de copias nueva

La página del invitado, su diálogo «Copiar ahora», el diálogo del trabajo y el de conexión nombran el repositorio principal efectivo del inquilino, con el valor por defecto de la instalación en el disco local del servidor resaltado, y avisan «Las copias acaban en el propio disco del servidor» cuando el repositorio principal es un directorio en un disco del propio servidor de Restow (véase almacenamiento).

El repositorio restic de un contenedor está solo en el repositorio principal. Desde la 0.4.2, antes de que una copia de un contenedor reciba su credencial de restic, el servidor comprueba una vez por ejecución que el repositorio está allí:

• Está allí: la copia se ejecuta como siempre.
• Solo en otro destino del inquilino, por ejemplo un repositorio principal retirado tras «Mantener las copias existentes donde están»: la copia se rechaza con un mensaje que dice que hay que trasladar las copias con un «traslado» del almacenamiento o restablecer el repositorio. No se crea nada.
• En ninguna parte: empiezan un repositorio nuevo y una cadena de copias nueva. La página del invitado dice «Nueva cadena de copias iniciada el <fecha>: el repositorio anterior no se encontró en <destino>», los puntos de restauración anteriores muestran «No disponible» (ya no se pueden restaurar, explorar ni comprobar, la preparación de recuperación ya no los cuenta y la retención los deja en paz), y el registro de auditoría lo anota. Un almacenamiento que no responde no es «ausente»: la copia falla.

«Restablecer repositorio» en la zona de peligro del invitado (solo contenedores) hace lo mismo a petición, para un repositorio dañado o uno en un destino que ya no existe: se escribe el nombre del invitado, hace falta un inicio de sesión reciente y queda auditado. Cada punto de restauración del contenedor pasa a no estar disponible al instante, y la siguiente copia empieza una cadena nueva. Antes de la 0.4.2, todos los contenedores con un repositorio existente fallaban con «repository does not exist» tras un cambio del repositorio principal con «Mantener las copias existentes donde están»; esa elección se rechaza ahora mientras haya contenedores con repositorios de restic, y un «traslado» se los lleva.

La VM del propio servidor de Restow

Copiar con el propio Restow la VM en la que se ejecuta Restow puede acabar en un bloqueo: la copia congela o hace una instantánea del servidor que la recibe, y restaurarla necesita justo el servidor que se está restaurando. Desde la 0.4.2 Restow reconoce esa VM por su UUID de SMBIOS (restow-pve 0.4.2 lo notifica con el inventario), o un administrador marca «Este es el servidor de Restow» en la página del invitado, algo necesario cuando Restow se ejecuta en un contenedor, en otro host o detrás de un nodo anterior a la 0.4.2. El invitado muestra entonces «Servidor de Restow» en las listas y el editor de trabajos, ningún trabajo planifica una copia suya, el trabajo recomendado lo deja fuera, y «Copiar ahora» o incluirlo en un trabajo exige una confirmación que nombra el riesgo. Copie esa VM con la copia de Proxmox VE (vzdump) en otro almacenamiento y conserve los volcados de la base de datos de Restow.

Archivos de un contenedor o de una VM (vista previa en las VM)

Servidores y equipos, Restauración de archivos enumera cada contenedor con un punto de restauración en el grupo «Contenedores de Proxmox VE», y cada VM con un punto de restauración en el grupo «VM de Proxmox VE», marcado como vista previa. La página de un invitado enlaza allí sus puntos de restauración («Explorar archivos»). Se explora un punto de restauración y se descargan archivos y carpetas como un ZIP. Las lecturas y descargas quedan en el registro de auditoría, y una descarga preparada se puede iniciar una vez, en diez minutos, por el administrador que la preparó.

• Los contenedores los lee el servidor del repositorio restic del contenedor; las rutas son las del propio contenedor.
• Las VM muestran una carpeta por sistema de archivos legible de los discos de la VM: particiones de discos GPT y MBR y volúmenes lógicos LVM lineales con ext2, ext3, ext4 (el journal se reproduce en memoria), XFS, NTFS o FAT12, FAT16, FAT32. El servidor de Restow lee los discos del almacén de fragmentos del inquilino con lectores propios en un proceso hijo de vida corta y restringido; no se monta nada, ni en el servidor ni en el nodo. Los archivos que no se pueden leer se nombran en _not-restored.txt dentro del ZIP.

No legibles en una VM: btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker y LUKS, archivos comprimidos por NTFS y EFS. El registro de XFS y el de NTFS no se reproducen, así que un punto de restauración coherente ante fallos puede carecer de las últimas escrituras: compare un archivo restaurado importante con el original antes de fiarse de él. Los archivos se descargan, no se devuelven a un invitado en ejecución; para eso, restaure el invitado entero como invitado nuevo. Los operadores de restauración también pueden explorar y descargar archivos de contenedores y VM.

Pruebas de arranque

Un trabajo de Proxmox VE puede arrancar el punto de restauración más reciente de cada invitado, cada semana o tras cada copia. Está desactivado por defecto, con un límite de memoria (8 GiB por defecto) y una espera al agente invitado (cinco minutos por defecto), y «Probar el arranque ahora» en un punto de restauración pide una a mano. El nodo del invitado restaura el punto de restauración como invitado nuevo en el pool restow-restore, lo aísla antes de arrancarlo (cada interfaz de red desconectada o en un puente aislado; dispositivos passthrough, puertos serie, bind mounts y el script de hook eliminados), lo arranca, espera al agente invitado de QEMU (en un contenedor: su init) y destruye el invitado de prueba en cualquier caso; los restos se eliminan al arrancar el servicio. Se ejecuta una prueba por nodo a la vez, nunca junto a una copia, y solo con memoria y almacenamiento suficientes.

El resultado es verde cuando el agente invitado respondió, amarillo cuando la VM solo arrancó y nada respondió (instale el agente invitado de QEMU para tener una prueba), y rojo cuando falló la restauración, el arranque o el inicio. La preparación de recuperación valora el punto de restauración más reciente por su prueba de arranque donde la hay, y dos eventos, boot_test.failed y boot_test.unproven, pueden avisarle. Necesita restow-pve 0.4.0 en el nodo, y la página del invitado dice cuándo su nodo no puede. No comprueba puertos ni aplicaciones dentro del invitado, Windows sin agente invitado es amarillo como mucho, y un invitado que necesita hardware passthrough para arrancar puede suspender la prueba, porque ese hardware se elimina para ella.

Desde la 0.4.6, una prueba de arranque que no arrancó muestra el mensaje del nodo bajo su distintivo, en la página del invitado y en Preparación de recuperación, y los textos de error tras un distintivo o una línea cortada (la prueba de arranque, la comprobación de restauración de una VM o un contenedor) se abren al pasar el ratón o con el foco del teclado en una tarjeta con el texto completo, seleccionable y con un botón Copiar, en lugar de una información emergente del navegador.

Comprobaciones de restauración tras cada copia

Desde la 0.4.2 el servidor relee una muestra de los bloques de datos de cada punto de restauración nuevo en minutos tras su copia y la compara con el SHA-256 registrado (en un contenedor, una comprobación restic de un 5 % de los datos). La pasada del worker se ejecuta cada cinco minutos y toma como máximo 20 comprobaciones solicitadas por pasada, la solicitud más antigua primero, de modo que un gran lote de copias espera su turno («Comprobación en cola»). El ajuste «Comprobar cada punto de restauración nuevo justo después de la copia» («Check every new restore point right after the backup»; Instalación › Proxmox VE, propietario) viene activado; desactivado, un punto de restauración nuevo espera a la comprobación semanal. El punto de restauración más reciente de cada invitado se comprueba de todos modos al menos cada semana, y no hay ajuste por inquilino.

En Preparación de recuperación, «Comprobar ahora» comprueba el punto de restauración más reciente de un invitado y «Comprobar todos los no verificados» el más reciente de cada invitado que ninguna comprobación ha leído todavía. En la página de un invitado, «Comprobar ahora» en un punto de restauración comprueba exactamente ese, también uno más antiguo. Desde la 0.4.6, tras «Comprobar ahora» la fila dice «Comprobación en cola» bajo la última comprobación, y la página del invitado lo dice sobre el resultado anterior, hasta que llega el resultado; ambas se actualizan cada pocos segundos mientras tanto. Una comprobación en rojo muestra el error que encontró (el de restic, por ejemplo) bajo su distintivo en la lista de invitados, en Preparación de recuperación y en la página del invitado, en lugar de solo «los bloques no coincidían o no se pudieron leer». Es una relectura por muestras desde el almacenamiento: no es una prueba de arranque ni una restauración en su nodo.

Un repositorio bloqueado no es una comprobación fallida

Justo después de la copia de un contenedor, la comprobación de restauración nueva podía chocar con el bloqueo que otra ejecución aún tenía sobre el repositorio restic del contenedor, normalmente la propia copia del invitado, cuyo bloqueo había dejado una cancelación o un reinicio de la API. Mostraba entonces una «Comprobación de restauración fallida» en rojo, aunque no se había ejecutado nunca. Desde la 0.4.3, una comprobación que un bloqueo deja fuera no es una comprobación fallida:

• Se reintenta. La comprobación se pospone diez minutos y el resultado anterior se mantiene mientras tanto. El invitado muestra «Comprobación de restauración pospuesta», y su página, «Comprobación pospuesta: repositorio bloqueado».
• Tras dos horas el punto de restauración aparece como «No se pudo comprobar: repositorio bloqueado» («Could not check: repository locked»): amarillo (atención) en Preparación de recuperación, nunca rojo ni verde, con el informe de restic sobre quién tiene el bloqueo. Entonces no se sabe nada del punto de restauración, así que no es una prueba. La comprobación semanal vuelve a intentarlo con el invitado al cabo de un día, y la comprobación de la siguiente copia, «Comprobar ahora» o «Comprobar todos los no verificados», antes. Una comprobación que restic dejó parada antes de terminar aparece igual como «No se pudo comprobar: comprobación interrumpida».
• Menos bloqueos en el camino. El worker elimina los bloqueos obsoletos de restic (solo los que ninguna ejecución viva renueva) antes de la comprobación y antes de la retención, y restic espera hasta dos minutos un bloqueo durante la comprobación. Un invitado no se comprueba mientras corre una ejecución suya o su nodo ha aceptado una copia suya, y un punto de restauración nuevo se comprueba dos minutos después de su commit como pronto. Desde la 0.4.3, restow-pve espera hasta 15 minutos el bloqueo del servidor durante la copia de un contenedor.

Las comprobaciones de restauración que un bloqueo hizo fallar antes de la actualización siguen en rojo hasta la siguiente comprobación del invitado: elija «Comprobar ahora» en el invitado o en VMs y contenedores. Véase también verificación.

Comprobación mensual de restauración, opcional

Un trabajo de copia de Proxmox VE tiene la opción «Comprobación mensual de restauración (restaura un invitado en el pool restow-restore y lo borra después)» (en la interfaz en inglés, «Monthly restore check», «restores one guest into the pool restow-restore and deletes it again»), con un segundo campo, «Almacenamiento para la comprobación de restauración» («Storage for the restore check»), para el almacenamiento donde se restaura el invitado de prueba. Está desactivada por defecto y necesita capacidad libre en ese almacenamiento. Cuando está activada, la pasada de mantenimiento del servidor, que se ejecuta cada cinco minutos, toma un invitado del trabajo que tenga un punto de restauración y no haya tenido ninguna comprobación de restauración en 30 días, restaura su punto de restauración más reciente como un invitado nuevo en el pool restow-restore sin arrancarlo, y lo borra después. Los contenedores privilegiados quedan excluidos. Esas ejecuciones se rotulan «Comprobación de restauración» («Restore check»). Los rótulos en español son una traducción: el producto no tiene textos en español.

Comprueba la vía de restauración en su propio nodo de Proxmox VE. Se suma a la comprobación por muestreo, que relee del almacenamiento bloques de datos del punto de restauración más reciente de cada invitado y los compara con el SHA-256 registrado (en los contenedores, una comprobación restic de un 5 % de los datos); esa se ejecuta cada semana y, desde la 0.4.2, tras cada copia nueva, no necesita capacidad en su nodo de Proxmox VE y se ejecuta tanto si activa la mensual como si no.

Límites indicados, no ocultos

• Proxmox VE es una vista previa y todavía no se recomienda como única copia.
• Se probó con qemu-nbd, qemu-img y restic y, para la incorporación de nodos, con simulaciones de las herramientas del nodo.
• La exclusión de un invitado de la copia (desde la 0.4.7) se probó con las suites de pruebas de la versión, no se ejecutó con un nodo real de Proxmox VE. Excluir una selección de invitados en el inventario envía una solicitud por invitado, porque no hay una ruta masiva; si una falla, los invitados anteriores siguen excluidos y la lista se actualiza.
• La comprobación de restauración tras cada copia es una muestra releída del almacenamiento, no una prueba de arranque. Detener una copia en curso necesita restow-pve 0.4.2 en el nodo. Una comprobación que un repositorio bloqueado deja fuera aparece como «No se pudo comprobar» en amarillo y no demuestra nada.
• La corrección que permite restaurar un contenedor en el Proxmox VE actual (desde la 0.4.6) se probó con pruebas en Perl del complemento, la restauración con y sin el ID del almacenamiento, y no se ejecutó contra un nodo real de Proxmox VE antes de la versión.
• Un recurso compartido cuyo repositorio ha desaparecido tras un cambio de almacenamiento todavía no se repara con una cadena de copias nueva, como ocurre con un contenedor; está previsto.
• La página VMs y contenedores, rediseñada desde la 0.4.3, se probó con pruebas del DOM, no visualmente en un navegador con miles de invitados.
• Las filas de nodo del inventario todavía no muestran cuándo una copia espera al nodo o está en curso; VMs y contenedores sí.
• El progreso, las líneas del asistente en el registro de ejecución, las pruebas de arranque, la restauración de archivos de VM, el reintento de cinco minutos, detener una copia, la comprobación de restauración tras cada copia, su reintento cuando un repositorio está bloqueado y la cadena de copias nueva se probaron con el nodo simulado de las suites de pruebas (y un almacén S3 simulado), no con un clúster real de Proxmox VE ni un proveedor real de S3. Los archivos de VM y contenedores se descargan como ZIP; restaurar archivos sueltos en el invitado en ejecución no está desarrollado. No se pueden copiar las plantillas de VM, no es posible una restauración en vivo, y Restow no puede restaurar contenedores con privilegios.

Véase la hoja de ruta para lo que viene después y, en inglés, el registro de cambios para lo que cambió cada versión.

Preguntas frecuentes

Copia de servidores y equipos con un agente →

Más en Aprender: copias completas, incrementales y completas sintéticas comparadas →