Backups, snapshots y restauración en Proxmox sin perder datos

Un snapshot sirve para volver atrás con rapidez; un backup permite reconstruir un invitado desde otro destino. Diseñar ambos y ensayar la restauración evita descubrir demasiado tarde que una copia estaba incompleta.

---

1. Snapshot y backup no resuelven el mismo problema

Proxmox VE administra snapshots y copias de seguridad de máquinas virtuales y contenedores, pero sus nombres no deben confundirse. Un snapshot registra el estado de un volumen en un momento determinado mediante capacidades del almacenamiento. Suele permanecer ligado al disco y al backend originales. Es útil antes de una actualización arriesgada o un cambio de configuración que puedas revertir pronto.

Un backup creado con vzdump genera un archivo o un conjunto de datos de copia en un almacenamiento configurado. Puede trasladarse a otro sistema y restaurarse como invitado. Proxmox Backup Server, cuando se usa, añade un repositorio especializado con deduplicación, verificación y políticas propias.

Riesgo	Snapshot local	Backup en destino separado
Error de una actualización	Sí, para reversión rápida	Sí
Borrado de la VM	Puede desaparecer con ella	Sí
Fallo físico del almacenamiento	No	Sí, si está en otro equipo o medio
Pérdida del nodo	No por sí solo	Sí, con acceso a la copia
Corrupción previa no detectada	Puede contenerla	También; requiere historial

Un snapshot no es backup. Tampoco lo es un segundo directorio situado en el mismo disco físico. Si ese disco muere, ambas rutas dejan de existir. La estrategia debe contemplar copias separadas, varias edades y una prueba de recuperación.

Antes de definir tareas, clasifica los datos. Una VM reproducible desde código puede tolerar más pérdida que una base de datos familiar. Anota dos objetivos: cuánto tiempo máximo puede estar caído el servicio y cuántos cambios puedes permitirte perder. Esos límites determinan frecuencia, destino y método de consistencia.

2. Preparar un destino de backup correcto

Proxmox representa los destinos mediante su capa de almacenamiento. Un directorio, NFS, CIFS u otros backends pueden admitir contenido backup según la configuración. Proxmox Backup Server aparece como un tipo específico. El destino debe tener espacio, conectividad y permisos adecuados.

Consulta el estado con:

pvesm status

En la interfaz, abre Datacenter > Storage, añade el backend y marca el contenido de backup cuando corresponda. No modifiques /etc/pve/storage.cfg directamente salvo que entiendas su sintaxis y tengas acceso alternativo al nodo.

Para un homelab, un NAS o servidor de copias separado evita el punto único de fallo del disco principal. Si usas un disco USB, mantenlo identificado por una ruta estable, vigila montajes fallidos y considera desconectarlo cuando no haya tarea. Un directorio vacío después de fallar un montaje puede hacer que las copias llenen por accidente el disco raíz.

Destino	Ventaja	Riesgo que debes controlar
Disco local secundario	Simple y rápido	Sigue dentro del mismo equipo
NFS/CIFS en NAS	Separación física y capacidad	Red, permisos y disponibilidad
Proxmox Backup Server	Verificación y gestión especializada	Requiere desplegar y proteger otro servicio
Medio externo rotado	Puede mantenerse desconectado	Operación manual y custodia

Configura alertas de tareas y revisa el espacio antes de la primera copia. Cifrar el transporte no cifra necesariamente los datos en reposo; consulta las funciones del backend. Si además proteges archivos con Restic y cifrado, documenta dónde están las claves: una copia cifrada sin credenciales recuperables es inutilizable.

3. Modos de vzdump y consistencia

vzdump es la herramienta de Proxmox para copias completas de invitados. Puede ejecutarse desde Datacenter > Backup, desde el nodo o mediante tareas programadas. Sus modos principales equilibran disponibilidad y consistencia.

Modo	Comportamiento general	Cuándo considerarlo
snapshot	Copia con mínima interrupción usando capacidades disponibles	Servicios que deben seguir activos
suspend	Suspende temporalmente el invitado durante parte del proceso	Cuando se acepta una pausa
stop	Detiene el invitado para copiarlo	Máxima sencillez de consistencia a cambio de caída

La disponibilidad de ciertas técnicas depende del tipo de invitado y almacenamiento. No asumas que “snapshot” vuelve consistente cualquier aplicación. Un sistema de archivos puede quedar en un estado recuperable, mientras una base de datos conserva transacciones y buffers con reglas propias.

Para VM, instala y habilita QEMU Guest Agent cuando el sistema sea compatible. Proxmox puede coordinar operaciones dentro del invitado y congelar/descongelar sistemas de archivos en flujos soportados. Aun así, una base de datos debe usar sus herramientas de dump, réplica o hooks si requiere consistencia de aplicación.

Ejemplos manuales, usando un almacenamiento ya configurado:

vzdump 100 --storage backup-store --mode snapshot --compress zstd
vzdump 101 --storage backup-store --mode stop --compress zstd

El primer número es VMID o CTID. No pruebes comandos destructivos en el único entorno. Empieza con un invitado de laboratorio, lee el registro completo y verifica que el archivo aparece en el destino previsto.

4. Programar copias y políticas de retención

En Datacenter > Backup, crea una tarea, selecciona nodo, almacenamiento, calendario, invitados, modo y compresión. Puedes incluir todos los invitados o una selección explícita. Una selección fija exige añadir los nuevos invitados a la política; “todos” puede copiar recursos que no necesitas. Define la intención y revisa cambios.

No programes todas las tareas pesadas a la misma hora. Backups, scrubs, replicación y actualizaciones pueden competir por disco y red. Observa cuánto tarda una ejecución real y deja margen antes de la siguiente ventana.

La retención evita llenar el destino, pero también conserva estados anteriores a una corrupción silenciosa. Proxmox admite opciones como mantener el último número de copias, copias diarias, semanales, mensuales o anuales según el mecanismo utilizado. Un ejemplo conceptual podría conservar varias recientes, varias semanas y varios meses; el número correcto depende de capacidad y riesgo.

Puedes inspeccionar trabajos y tareas desde la interfaz. En shell, revisa el registro de una ejecución y el contenido reconocido por el almacenamiento:

pvesm list backup-store --content backup
journalctl --since today | grep vzdump

El segundo comando ayuda a localizar entradas, pero la tarea en la interfaz muestra un log más preciso. El éxito no se mide solo por “TASK OK”: comprueba tamaño razonable, duración, invitados incluidos y ausencia de exclusiones inesperadas.

Una política útil se expresa por escrito:

• frecuencia según pérdida máxima aceptable;
• destino separado y propietario;
• retención por edades;
• responsable de revisar fallos;
• calendario de restauraciones de prueba;
• ubicación de claves, contraseñas y documentación.

5. Usar snapshots sin convertirlos en deuda

Los snapshots son apropiados antes de actualizar un paquete, cambiar una aplicación o probar una migración. Ponles un nombre y una descripción que indiquen motivo y fecha. El nombre antes-cambio termina siendo ambiguo al mes siguiente.

Desde el nodo, una VM puede crear un snapshot con:

qm snapshot 100 pre-actualizacion --description "Antes de actualizar la aplicación"

Lista y elimina cuando ya no sea necesario:

qm listsnapshot 100
qm delsnapshot 100 pre-actualizacion

Para un contenedor:

pct snapshot 101 pre-actualizacion --description "Antes de actualizar la aplicación"
pct listsnapshot 101
pct delsnapshot 101 pre-actualizacion

Estas operaciones requieren un almacenamiento compatible. Un snapshot puede incrementar el consumo o afectar el rendimiento según el backend y el patrón de escrituras. No lo dejes indefinidamente ni lo uses como archivo histórico.

Volver a un snapshot descarta cambios posteriores en los discos cubiertos. Antes de hacer rollback, identifica qué datos nuevos perderás y crea un backup si necesitas conservarlos. Los volúmenes excluidos, discos pasados por hardware o bind mounts pueden no seguir la misma línea temporal. Lee la configuración del invitado y del almacenamiento.

Una secuencia prudente para un cambio es: backup verificado, snapshot de corta vida, cambio, pruebas funcionales, eliminación del snapshot cuando termina el periodo de observación. Si el cambio falla, evalúa si restaurar datos selectivos es mejor que retroceder toda la máquina.

6. Restaurar una máquina virtual

Restaurar es la única prueba convincente de que el backup es utilizable. Haz el primer ensayo antes de necesitarlo. Elige un VMID libre, una red aislada y almacenamiento con capacidad. No arranques una copia clonada en la misma LAN con la IP del servicio original: puede causar conflictos o procesar datos reales.

Desde la interfaz, selecciona el backup en el almacenamiento y pulsa Restore. Revisa VMID, destino y opciones. En la shell, qmrestore restaura copias de VM:

qmrestore /ruta/al/backup/vzdump-qemu-100.archivo 900 --storage local-lvm

La extensión y ruta dependen del formato y destino. No copies el marcador literalmente. El ID 900 es un ejemplo de prueba; verifica que esté libre:

qm list

Tras restaurar, desconecta temporalmente la interfaz de red o conéctala a un puente aislado. Inicia la VM, comprueba el arranque, el sistema de archivos, los servicios y una muestra de datos. Para bases de datos, ejecuta sus verificaciones propias y valida que el punto temporal sea el esperado.

Documenta:

Dato	Resultado a registrar
Copia usada	Fecha, invitado y destino
Tiempo de restauración	Desde inicio hasta servicio validado
Integridad	Arranque, aplicación y datos comprobados
Ajustes necesarios	Red, claves, DNS, almacenamiento
Fallos	Causa y corrección aplicada

Cuando la prueba termine, apaga y elimina solo el invitado de ensayo después de confirmar su VMID. No automatices la eliminación en el primer ejercicio.

7. Restaurar un contenedor LXC

Para LXC, la interfaz ofrece el mismo flujo general desde el contenido de backup. En shell se utiliza pct restore con un CTID libre:

pct restore 901 /ruta/al/backup/vzdump-lxc-101.archivo --storage local-lvm

Comprueba antes:

pct list
pvesm status

Los contenedores requieren atención especial a puntos de montaje. Los volúmenes administrados pueden incluirse según la configuración, mientras bind mounts y montajes de dispositivos tienen reglas distintas y suelen quedar fuera. Un backup que restaura el root filesystem pero no los datos enlazados desde el host puede arrancar con directorios vacíos.

Revisa la configuración original:

pct config 101

Identifica líneas mp0, mp1 y sucesivas, además de opciones de backup. Si los datos viven en un NAS montado por el host, documenta cómo volver a montar la ruta, sus permisos y los mapeos UID/GID de un contenedor no privilegiado.

Restaura el contenedor de ensayo sin red de producción, arráncalo y valida:

pct start 901
pct status 901
pct exec 901 -- systemctl --failed

El último comando depende de que el contenedor use systemd. Comprueba también la aplicación, propietarios de archivos y acceso a volúmenes. Un estado running no demuestra recuperación completa.

8. Evitar errores que destruyen una recuperación

El error más común es guardar las copias en el mismo medio que protegen. Le siguen la falta de espacio, retención mal ajustada, credenciales perdidas y restauraciones nunca probadas.

No borres el invitado original para “hacer sitio” antes de verificar la copia. No sobrescribas su VMID durante un ensayo. No conectes simultáneamente original y clon con la misma IP, hostname, identificadores de clúster o tareas programadas.

Otros puntos que conviene comprobar:

• las copias incluyen todos los discos necesarios;
• los jobs nuevos incluyen invitados creados después;
• los backups de bases de datos son coherentes a nivel de aplicación;
• el NAS no acepta ransomware o borrados desde una cuenta con privilegios excesivos;
• las claves de cifrado tienen una copia protegida y probada;
• el reloj y la zona horaria permiten interpretar correctamente las edades;
• la documentación puede abrirse aunque el nodo Proxmox esté apagado.

Configura alertas y observa capacidad. Un panel de monitoreo con Grafana y Prometheus puede avisar sobre espacio y disponibilidad del destino, pero no reemplaza revisar los logs de backup.

Aplica una estrategia con varias copias, medios distintos y al menos una copia fuera del equipo principal o desconectada. La formulación exacta importa menos que eliminar puntos únicos de fallo y verificar el camino de vuelta.

---

Conclusiones

Los snapshots facilitan retrocesos breves, mientras los backups protegen frente a pérdida del invitado o almacenamiento cuando residen en otro destino. Para datos importantes necesitas ambos con funciones claras, retención por edades y consistencia adaptada a la aplicación.

Una tarea con estado correcto todavía no es una recuperación. Restaura con otro ID, aísla la red, abre la aplicación y verifica datos. Ese ensayo convierte archivos almacenados en una estrategia de recuperación comprobada.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux