Cerramos el simulador con el tema que separa a un laboratorio de un entorno de producción real: una estrategia de respaldo. Aquí vas a programar trabajos, ejecutarlos y restaurar — usando el mismo motor que Proxmox real, vzdump.
No hace falta un servidor dedicado para empezar a respaldar: cualquier storage con contenido tipo Backup (como local, que ya tienes desde la instalación) sirve como destino. La otra opción es agregar un Proxmox Backup Server (PBS) — un producto hermano de Proxmox VE, pensado específicamente para guardar backups con deduplicación a nivel de bloque, lo que significa que un segundo backup casi idéntico al primero ocupa una fracción del espacio.
| Storage local (dir) | Proxmox Backup Server | |
|---|---|---|
| Dónde vive | En un disco del mismo nodo (o red compartida) | En un servidor separado, dedicado |
| Deduplicación | No | Sí, a nivel de bloque |
| Ideal para | Empezar rápido, labs, backups ocasionales | Producción, retención larga, muchos backups incrementales |
zstd es el default moderno (buen balance velocidad/tamaño), gzip y lzo son alternativas más viejas.
Por detrás, Proxmox corre vzdump para cada VM/CT seleccionada, y el resultado es un archivo con un nombre predecible: vzdump-qemu-<vmid>-<fecha>.vma.zst para VMs, o vzdump-lxc-<vmid>-<fecha>.tar.zst para contenedores. El simulador genera exactamente ese formato de nombre, y esos archivos quedan visibles tanto aquí como en la pestaña "Contenido" del storage elegido, en el módulo de Almacenamiento.
Un backup que nunca probaste restaurar no es un backup, es una esperanza. Restaurar un archivo recrea la VM/CT si ya no existe, o la sobrescribe (dejándola detenida) si seguía existiendo — en ambos casos el simulador te pide confirmación antes, porque es una acción destructiva sobre lo que hubiera en ese momento.
↓ Practica todo esto en el simulador de abajo ↓