BackupZit

Cómo hacer copias de seguridad de las máquinas virtuales de Proxmox VE

Una guía completa: de un nodo Proxmox vacío a copias programadas, cifradas y deduplicadas de todas las VM y contenedores — con una copia externa, pruebas de restauración automáticas y una VM que arranca desde la copia en segundos cuando la necesita.

Qué va a configurar

BackupZit hace copias de las máquinas virtuales (QEMU) y contenedores (LXC) de Proxmox VE sin instalar nada dentro de los invitados. Un pequeño agente se ejecuta en cada nodo Proxmox, toma un snapshot temporal de cada invitado, lee sus discos y los guarda en el almacenamiento que elija. Una consola web programa los trabajos, guarda el historial y lanza las restauraciones.

Proxmox VE tiene sus propias herramientas de copia: vzdump y Proxmox Backup Server. Si solo usa Proxmox, son una buena opción gratuita. BackupZit merece la pena cuando quiere una sola consola para Proxmox y servidores Windows y Linux, VMware, Hyper-V, bases de datos y Microsoft 365, o funciones como copias probadas con arranque y réplicas en otro clúster.

Qué necesita

  • Uno o varios nodos con Proxmox VE 7, 8 o 9 (están basados en Debian, así que sirve el paquete Debian del agente).
  • Un sitio para la consola BackupZit: una pequeña VM Linux con 2 vCPU, 2–4 GB de RAM y un disco de 16–20 GB. La consola no guarda datos de copia, así que puede ejecutarse como VM en el mismo clúster.
  • Almacenamiento de copias fuera del nodo Proxmox — por ejemplo un servidor Linux o NAS por SFTP, un recurso compartido SMB, un bucket compatible con S3 o un repositorio reforzado de BackupZit (hardened repository). Los agentes escriben en él directamente.
  • Red: los agentes acceden a la consola por el puerto TCP 8443.

Paso 1 — Instalar la consola

Lo más rápido en Proxmox es la imagen de appliance lista backupzit-appliance.qcow2 de la página de descarga (Debian, PostgreSQL y la consola, ya configurados):

  1. Cree una VM sin disco: 2 vCPU, 2–4 GB de RAM, red VirtIO.
  2. Copie backupzit-appliance.qcow2 al nodo e impórtelo como disco de la VM (sustituya <vmid>):
    qm importdisk <vmid> backupzit-appliance.qcow2 local-lvm
  3. Conecte el disco importado como SCSI, conviértalo en disco de arranque y active el QEMU guest agent en las opciones de la VM.
  4. Inicie la VM. Su pantalla muestra la dirección de la consola web y la contraseña inicial del usuario admin. Abra https://<dirección>:8443, inicie sesión y cambie la contraseña.

En la pantalla de la VM puede iniciar sesión como bzadmin para fijar una dirección estática, el nombre del servidor y la zona horaria (el appliance arranca en UTC y las programaciones usan la zona horaria de la consola). ¿Prefiere un servidor Debian, Ubuntu, AlmaLinux o Rocky Linux existente? El script de instalación de una línea de la página de descarga hace lo mismo allí.

Paso 2 — Añadir un destino de almacenamiento

En la consola abra Almacenamiento y añada un destino. Opciones habituales para copias de Proxmox:

TipoAdecuado para
SFTPCualquier servidor Linux o NAS con SSH; la clave de host del servidor queda fijada.
Recurso SMBServidores de archivos Windows, NAS Synology o QNAP (SMB 2/3).
Compatible con S3Copias externas: AWS S3, Wasabi, Backblaze B2, MinIO, Ceph; inmutables con Object Lock.
Repositorio reforzadoUn servidor Linux con backupzit-repo: las copias no pueden borrarse antes de que termine su periodo de inmutabilidad.

Deje activado Cifrar las copias (AES-256) (predeterminado): todo se cifra con AES-256-GCM en el nodo antes de salir de él. La consola muestra entonces una clave de recuperación — imprima la hoja de recuperación o guarde la clave en un gestor de contraseñas, lejos de las copias. Con la clave, la ubicación del almacenamiento y sus credenciales puede restaurar aunque pierda la consola; sin la clave nadie puede leer las copias.

Paso 3 — Instalar el agente en cada nodo

  1. En la consola abra Agentes y haga clic en Crear token de registro. Obtiene un código de registro (BZ1-…) válido 7 días y para cualquier número de equipos.
  2. Descargue el paquete Agente Linux — Debian / Ubuntu desde la página Agentes al nodo y ejecute:
    apt install ./backupzit-agent_*.deb
    backupzit-agent enroll --code "BZ1-..."
    systemctl enable --now backupzit-agent
  3. En menos de un minuto el nodo aparece en la página Agentes con la etiqueta Proxmox VE · N guests.

El agente usa las herramientas del propio nodo (qm, pct, pvesm, LVM, ZFS, Ceph). En la consola no se guarda ningún token de API de Proxmox ni contraseña de root. En un clúster, instale el agente en cada nodo.

Paso 4 — Crear el trabajo de copia

  1. Abra Trabajos de copia, cree un trabajo y seleccione el agente del nodo.
  2. Elija Máquinas virtuales (Proxmox VE, Hyper-V, VMware) y luego Todas las VM (y contenedores) del host — los invitados creados después se incluyen automáticamente — o marque invitados concretos.
  3. Elija el destino de almacenamiento del paso 2.
  4. Defina una programación, por ejemplo cada día laborable a las 22:00. Los trabajos también pueden repetirse cada 15 minutos a 12 horas, ejecutarse una vez al mes o empezar tras otro trabajo.
  5. Defina la retención. Ejemplo: 3 más recientes, 7 diarias, 4 semanales, 6 mensuales mantiene unos seis meses de historial con unos 20 puntos de restauración.

Qué ocurre en cada ejecución:

  1. Se toma un snapshot temporal de Proxmox (backupzit_…); el invitado sigue funcionando.
  2. Cada disco se lee desde el snapshot en bloques de 1 MiB. Los bloques vacíos no se guardan y los bloques que ya están en el repositorio no se vuelven a subir — tras la primera copia solo viajan por la red los datos cambiados. Aun así, cada copia es un punto de restauración completo.
  3. Se elimina el snapshot. La configuración del invitado (CPU, memoria, red, discos) se guarda con la copia.

Como los datos sin cambios se guardan una sola vez, una retención larga cuesta poco espacio adicional.

Qué discos pueden copiarse con el invitado en marcha

Almacenamiento ProxmoxCopia de un invitado en marcha
LVM-thin (local-lvm)sí, desde un snapshot
ZFS (discos de VM / zvols)sí, desde un snapshot
Ceph RBDsí, desde un snapshot
Directorio, NFS, CIFS con qcow2sí, desde un snapshot
Directorio, NFS, CIFS con raw; LVM gruesono — detenga el invitado o mueva el disco

Los invitados detenidos pueden copiarse en todos ellos. Los discos marcados Backup: no (backup=0), los discos físicos en passthrough y los bind mounts se omiten y se avisan.

Paso 5 — Copias consistentes a nivel de aplicación

Si el QEMU guest agent se ejecuta dentro de una VM y está activado en sus opciones, Proxmox congela los sistemas de archivos de la VM para el snapshot, de modo que bases de datos y aplicaciones quedan en un estado limpio. Sin él la copia es consistente ante fallos — como tras un corte de luz.

En una VM Debian o Ubuntu:

apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

En las VM Windows instale las VirtIO guest tools. Después active el agente para la VM en el nodo (surte efecto tras la siguiente parada y arranque completos de la VM):

qm set <vmid> --agent enabled=1

La página de cada ejecución muestra, por invitado, qué discos se leyeron y cómo se capturó el invitado.

Paso 6 — Mantener una copia externa (3-2-1)

La regla 3-2-1: tres copias de sus datos, en dos soportes distintos, una de ellas fuera de las instalaciones. Añada un segundo trabajo del tipo Copia secundaria, con el trabajo de Proxmox como origen y un destino externo, como un bucket S3 con Object Lock o un repositorio reforzado en otro edificio.

  • El agente copia las copias existentes; las VM no se vuelven a leer.
  • Solo se envían los datos que aún no están en el destino, cifrados con la clave del destino.
  • Por defecto la copia se ejecuta tras cada copia del trabajo de origen; sirve cualquier programación, por ejemplo una vez por noche con una línea lenta.
  • La copia tiene su propia retención, por ejemplo 7 diarias en el NAS y 12 mensuales en la nube.

Las VM se restauran desde la copia igual que desde el original — VM completas, archivos sueltos y restauración instantánea. Más sobre copias inmutables en la protección contra ransomware.

Paso 7 — Demostrar que las copias arrancan

Que los bloques se puedan leer no demuestra que una VM aún arranque. En Configuración → Pruebas de restauración active la Prueba de arranque para copias de VM de Proxmox. La prueba de restauración arranca entonces cada VM de la copia más reciente, una tras otra, en el nodo del trabajo, directamente desde la copia, con un ID nuevo y las tarjetas de red desconectadas para no chocar con el original — y luego la elimina.

  • Una VM supera la prueba cuando su QEMU guest agent responde a tiempo, es decir, el sistema arrancó. Las VM sin guest agent la superan si siguen funcionando un minuto y se muestran como en marcha en lugar de arrancadas.
  • El nodo necesita memoria libre para una VM más durante la prueba.
  • Además, una comprobación de datos (mensual por defecto) lee todos los datos guardados y los verifica con su suma de comprobación, para detectar daños en el propio almacenamiento antes de necesitar la copia.

Restauración

Abra una ejecución de copia (desde la página del trabajo o desde Actividad) y elija Restaurar una VM o un contenedor.

VM o contenedor completo

  • Restaure en cualquier nodo con el agente — también en un nodo de otro clúster.
  • Como nuevo invitado con el siguiente ID libre (predeterminado) mientras el original sigue funcionando; la copia recibe direcciones MAC nuevas. O con el ID original después de borrar el invitado, sustituyendo opcionalmente uno existente.
  • Elija el nombre y el almacenamiento de los discos, y si el invitado debe arrancar tras la restauración.
  • Cada restauración da a las VM un nuevo ID de generación (vmgenid), para que los controladores de dominio de Windows detecten la vuelta atrás de forma segura.

Restauración instantánea: la VM funciona en segundos

Una restauración normal tarda lo que se tarda en copiar los discos. Con Al instante, ejecutándose desde la copia el agente sirve los discos en solo lectura desde la copia e inicia una VM nueva cuyas escrituras van a overlays locales. Cuando esté conforme, Finalizar mueve los discos al almacenamiento elegido mientras la VM sigue funcionando (qm disk move); Descartar VM borra la VM y sus cambios. La VM es tan rápida como el almacenamiento de copias, así que lo mejor es un repositorio en un disco local o un recurso de red rápido. La restauración instantánea es para VM, no para contenedores.

Archivos sueltos

Haga clic en Examinar archivos en la tabla de invitados de una ejecución. La consola lee el disco directamente desde la copia — no se restaura nada antes — y permite examinar NTFS, ext2/3/4 y XFS, también dentro de LVM. Descargue archivos (varios como ZIP) o restáurelos en una carpeta de cualquier agente. Examinar en la consola requiere una copia en almacenamiento de red (SFTP, S3, SMB, Azure o repositorio reforzado).

Réplicas para los invitados más importantes

En Avanzado dentro del trabajo, Mantener réplicas de las VM actualiza tras cada copia una copia detenida de cada invitado en otro nodo o clúster. Solo se escriben los bloques cambiados — normalmente unos segundos por copia. Si se pierde un invitado, Iniciar réplica lo arranca con los datos de la última copia, sin restauración.

Desde la línea de comandos

Todo funciona también sin la consola, por ejemplo para reconstruir un nodo tras un desastre:

backupzit-agent pve list
backupzit-agent pve show    --repo ... latest
backupzit-agent pve restore --repo ... --vmid 100 --new-vmid -1 --storage local-lvm --start latest

Copia del propio host Proxmox

Los invitados son solo la mitad de un nodo: definiciones de almacenamiento, red, usuarios, firewall, certificados y la configuración de cada VM y contenedor están en su configuración. Cópiela con una tarea normal de Archivos y carpetas en el agente del nodo, por ejemplo a diario, con las rutas /etc (incluye /etc/pve, la red y /etc/hosts) y /var/lib/pve-cluster (la base de configuración config.db). Para una copia totalmente coherente de la base mientras el nodo funciona, añada esto como Comando antes de la copia e incluya también /root/pve-config.db:

# one-time: apt install sqlite3
sqlite3 /var/lib/pve-cluster/config.db ".backup /root/pve-config.db"

Para reconstruir un nodo averiado: instale la misma versión de Proxmox VE con el mismo nombre de host y dirección, instale el agente, restaure /etc/network/interfaces y /etc/hosts, detenga el servicio del clúster (systemctl stop pve-cluster), restaure config.db en /var/lib/pve-cluster, vuelva a iniciar el servicio y después restaure los invitados. En un clúster, vuelva a unir el nodo reinstalado al clúster en lugar de restaurar config.db.

Límites que conviene conocer

  • Se admiten Proxmox VE 7, 8 y 9. XCP-ng no está soportado.
  • Los discos de contenedores en subvolúmenes ZFS aún no se admiten.
  • Los discos raw en almacenamiento de directorio, NFS o CIFS y los discos en LVM grueso solo pueden copiarse con el invitado detenido.
  • En un clúster, un trabajo copia los invitados de su propio nodo. Un invitado migrado a otro nodo se avisa — use Todas las VM (y contenedores) del host en cada nodo para que los invitados migrados sigan cubiertos.
  • Las unidades cloud-init no se guardan; se recrean a partir de la configuración al restaurar.

Siguientes pasos

BackupZit es gratuito y de código abierto (AGPLv3), sin límite de VM ni de nodos. Descárguelo, vea todas las funciones para Proxmox o lea el capítulo completo sobre Proxmox VE en la guía integrada en la consola. Las preguntas son bienvenidas en GitHub Discussions. Las empresas pueden contratar soporte comercial de MaxZit (solo en inglés).