Saltar al contenido
sudoquest@root
Proxmox

Copias

vzdump y sus modos, los trabajos de cada noche y su retención, un Proxmox Backup Server, restaurar sin pisar lo que funciona y podar.

45 min de lectura

La Clínica Sonrisa es una clínica dental con recepción, dos gabinetes y un cuarto técnico. En su servidor con Proxmox van dos invitados: la agenda de citas (la VM 100) y la facturación (el contenedor 101). Si mañana se rompe el disco, o alguien borra lo que no debe, la clínica no puede abrir. Hasta hoy nadie hacía copias. Toca hacerlas, guardarlas fuera del servidor y saber sacarlas cuando haga falta.

root@pve1:~# qm list; pct list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID       
     100 agenda               running    2048               8.00 1001      
VMID       Status     Lock         Name                
101        running                 facturas

Una copia: vzdump

vzdump hace la copia de un invitado: su configuración y sus discos, en un archivo (un almacén de archivos como local) o en un servidor de copias. En la web es el Backup de cada invitado ▸ Backup now. Tiene tres modos:

  • snapshot: sin pararlo. En un contenedor, una snapshot de LVM de su disco el momento de copiarlo; en una VM, QEMU copia el disco mientras sigue en marcha. Lo normal.
  • suspend: un contenedor se copia primero en marcha (rsync), se congela un momento para copiar lo que cambió y sigue. Más lento y más espacio.
  • stop: lo apaga, lo copia y lo vuelve a encender. Lo más consistente, pero se para.

Parado, da igual el modo: siempre es stop. Y la compresión: zstd (rápida y buena, la de siempre), gzip (algo más pequeña, mucho más lenta) o lzo (rápida, más grande).

root@pve1:~# vzdump 101 --storage local --mode snapshot --compress zstd --protected 1
INFO: starting new backup job: vzdump 101 --storage local --mode snapshot --compress zstd --protected 1
INFO: Starting Backup of VM 101 (lxc)
INFO: Backup started at 2026-10-08 08:47:47
INFO: status = running
INFO: CT Name: facturas
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
freeze guest filesystem
Logical volume "snap_vm-101-disk-0_vzdump" created.
thaw guest filesystem
INFO: creating vzdump archive '/var/lib/vz/dump/vzdump-lxc-101-2026_10_08-08_47_47.tar.zst'
INFO: Total bytes written: 584908800 (558MiB, 69MiB/s)
INFO: archive file size: 159MB
INFO: marking backup as protected
INFO: cleanup temporary 'vzdump' snapshot
Logical volume "snap_vm-101-disk-0_vzdump" successfully removed.
INFO: Finished Backup of VM 101 (00:00:08)
INFO: Backup finished at 2026-10-08 08:47:55
INFO: Backup job finished successfully
INFO: notified via target `mail-to-root`

Un contenedor se copia como un tar (.tar.zst); una VM, como un vma (.vma.zst). En local van a /var/lib/vz/dump/, con su registro (.log), sus notas (.notes, si las lleva) y, si está protegida, una marca (.protected): una copia protegida no se borra ni se poda hasta quitarle la protección (en la web, con la copia elegida, Change Protection).

root@pve1:~# ls -l /var/lib/vz/dump/
total 163708
-rw-r--r-- 1 root root       785 Oct  8 08:47 vzdump-lxc-101-2026_10_08-08_47_47.log
-rw-r--r-- 1 root root 167630179 Oct  8 08:47 vzdump-lxc-101-2026_10_08-08_47_47.tar.zst
-rw-r--r-- 1 root root         0 Oct  8 08:47 vzdump-lxc-101-2026_10_08-08_47_47.tar.zst.protected

Los 558 MiB de la facturación quedan en 159 MB con zstd. Una VM con el disco casi vacío ocupa muy poco: lo que son ceros no se copia (backup is sparse). pvesm list las enseña como volúmenes del almacén, con su volid (local:backup/…), que es como las nombran las demás órdenes:

root@pve1:~# pvesm list local --content backup
Volid                                                   Format  Type           Size VMID
local:backup/vzdump-lxc-101-2026_10_08-08_47_47.tar.zst tar.zst backup    167630179 101

Ejercicio

Una copia antes de la auditoría

Mañana viene la auditoría y quieren una copia de hoy de la facturación (el contenedor 101) que nadie pueda borrar sin querer. Hazla en local, sin pararla (snapshot), comprimida con zstd y protegida.

Encendiendo el nodo…

Las de cada noche: los trabajos

Nadie se acuerda de pulsar Backup now cada día. Un trabajo de copia (Datacenter ▸ Backup ▸ Add) dice qué se copia (unos invitados, todos, o todos menos algunos), cuándo (su Schedule), dónde, con qué modo y compresión, y cuántas guardar. Se guardan en /etc/pve/jobs.cfg:

root@pve1:~# cat /etc/pve/jobs.cfg
vzdump: copias-noche
comment cada noche
schedule 21:00
compress zstd
enabled 1
mode snapshot
prune-backups keep-daily=7,keep-weekly=4
storage local
vmid 100,101

El horario es un evento de calendario, como los de systemd: 21:00 es cada día a las nueve de la noche; mon..fri 22:30, de lunes a viernes; sat 02:00, los sábados. La rejilla de la web enseña cuándo toca la próxima (Next Run). Lo que no entiende, lo dice:

root@pve1:~# pvesh create /cluster/backup --id mal --schedule "cada dia" --storage local --vmid 100
400 Parameter verification failed.
schedule: invalid format - invalid calendar event 'cada dia' - unable to parse calendar event at 'cada' - Context("weekday")


pvesh create <api_path> [OPTIONS] [FORMAT_OPTIONS]

Un invitado nuevo que no entra en ningún trabajo se queda sin copias sin que nadie se entere: el botón Guests without backup job (en la API, /cluster/backup-info/not-backed-up) los lista. Para que entre, se edita el trabajo (Edit) y se marca en su lista; con All, entran todos, también los que se creen después.

La retención

Sin límite, las copias llenan el almacén. La retención (la pestaña Retention del trabajo, o la del almacén) dice cuáles se quedan, de la más nueva a la más vieja:

  • keep-last 3: las 3 últimas.
  • keep-daily 7: la última de cada uno de los 7 últimos días que tengan copia.
  • keep-weekly 4, keep-monthly, keep-yearly: igual, por semana, mes y año.

Se suman: con keep-daily=7,keep-weekly=4 quedan las de la última semana y, de antes, una por semana del último mes. Las protegidas ni cuentan ni se van.

Ejercicio

Las copias de cada noche

Cada noche a las 21:00, cuando cierra la clínica, tiene que hacerse una copia de la agenda (la VM 100) y de la facturación (el contenedor 101) en local. Y que no se acumulen: que se queden las de los últimos 7 días y una por semana de las 4 últimas.

Encendiendo el nodo…

Fuera del servidor: Proxmox Backup Server

Las copias en local están en el mismo disco que los invitados. Si ese disco muere, o alguien cifra el servidor, se pierden con todo lo demás. Por eso las copias tienen que salir del servidor. Se puede usar un NAS (tema 2), pero lo mejor es un Proxmox Backup Server (PBS): otra máquina, con su propia web, que guarda las copias en un datastore troceadas en bloques y deduplicadas: la segunda copia de la facturación solo sube lo que cambió.

Para añadirlo como almacén (Datacenter ▸ Storage ▸ Add ▸ Proxmox Backup Server) hacen falta su dirección, el datastore, un usuario con su contraseña y la huella (fingerprint) de su certificado, la que enseña su panel. Sin ella, Proxmox no se fía del servidor y lo dice:

root@pve1:~# pvesm add pbs pbs --server 192.168.90.20 --datastore clinica --username copias@pbs --password Copias-2026
create storage failed: pbs: error fetching datastores - fingerprint '5C:2E:91:D7:4A:B0:13:F8:6E:A5:27:C9:0D:84:3B:E2:71:5F:C6:98:2D:4B:E0:A7:36:19:F1:8C:52:D3:0B:6A' not verified, abort!

Con la contraseña mal, 401 Unauthorized. Con todo bien, entra en storage.cfg. La contraseña no va ahí: va aparte, en /etc/pve/priv/storage/, que solo lee root:

root@pve1:~# cat /etc/pve/storage.cfg; ls -l /etc/pve/priv/storage/
…
pbs: pbs
datastore clinica
server 192.168.90.20
fingerprint 5c:2e:91:d7:4a:b0:13:f8:6e:a5:27:c9:0d:84:3b:e2:71:5f:c6:98:2d:4b:e0:a7:36:19:f1:8c:52:d3:0b:6a
username copias@pbs

total 1
-rw------- 1 root www-data 12 Oct  8 08:48 pbs.pw

Una copia al PBS ya no es un archivo: es un snapshot del servidor de copias (ct/101/2026-10-08T08:48:13Z). La primera sube todo; la siguiente, solo lo nuevo:

root@pve1:~# vzdump 101 --storage pbs --mode snapshot
…
INFO: creating Proxmox Backup Server archive 'ct/101/2026-10-08T08:49:02Z'
…
INFO: Downloading previous manifest (Thu Oct  8 08:48:13 2026)    
…
INFO: root.pxar: had to backup 0 B of 524.068 MiB (compressed 0 B) in 24.01 s (average 0 B/s)
INFO: root.pxar: backup was done incrementally, reused 524.068 MiB (100.0%)
…
INFO: Backup job finished successfully

Ejercicio

El servidor de copias

En el cuarto técnico hay un servidor de copias (un Proxmox Backup Server) en 192.168.90.20: su almacén es clinica, su usuario copias@pbs (contraseña Copias-2026) y la huella de su certificado, la de su pantalla: 5c:2e:91:d7:4a:b0:13:f8:6e:a5:27:c9:0d:84:3b:e2:71:5f:c6:98:2d:4b:e0:a7:36:19:f1:8c:52:d3:0b:6a. Añádelo como almacén y haz en él una copia de la facturación (el contenedor 101).

Encendiendo el nodo…

Con el PBS dentro, lo lógico es que el trabajo de cada noche guarde en él (con la compresión del PBS: la suya no se pone). Y una copia que no se ha probado no es una copia: Run now lanza el trabajo en el momento.

Ejercicio

Las de cada noche, fuera del servidor

Si se rompe el disco del servidor, las copias de local se van con él. El servidor de copias ya está añadido (pbs): haz que el trabajo de cada noche (copias-noche) guarde en él, y lánzalo ahora para ver que funciona.

Encendiendo el nodo…

Restaurar

Restaurar es crear un invitado a partir de una copia: qmrestore para una VM y pct restore para un contenedor (en la web, la copia ▸ Restore). Vuelve tal como estaba al copiarlo: su configuración, sus discos y lo que tenían dentro. La pregunta importante es dónde:

  • En un VMID nuevo: lo de ahora sigue como está y, al lado, aparece el de la copia. Para sacar algo que se borró sin perder lo que se hizo después.
  • Encima del que existe (--force): lo de ahora se pierde. Proxmox no lo deja sin --force, ni con el invitado encendido:
root@pve1:~# qmrestore local:backup/vzdump-qemu-100-2026_10_07-21_00_00.vma.zst 100
unable to restore VM 100 - VM 100 already exists on node 'pve1'
root@pve1:~# qmrestore local:backup/vzdump-qemu-100-2026_10_07-21_00_00.vma.zst 102 --storage local-lvm
restore vma archive: zstd -q -d -c /var/lib/vz/dump/vzdump-qemu-100-2026_10_07-21_00_00.vma.zst | vma extract -v -r /var/tmp/vzdumptmp1002.fifo - /var/tmp/vzdumptmp1002
CFG: size: 366 name: qemu-server.conf
DEV: dev_id=1 size: 8589934592 devname: drive-scsi0
CTIME: Wed Oct  7 21:00:01 2026
Logical volume "vm-102-disk-0" created.
Logical volume pve/vm-102-disk-0 changed.
new volume ID is 'local-lvm:vm-102-disk-0'
map 'drive-scsi0' to '/dev/pve/vm-102-disk-0' (write zeros = 0)
progress 1% (read 85917696 bytes, duration 0 sec)
…
progress 100% (read 8589934592 bytes, duration 0 sec)
total bytes read 8589934592, sparse bytes 8589934592 (100%)
rescan volumes...

La 102 se llama igual que la 100 y lleva la misma MAC: si se enciende a la vez en la misma red, chocan. Unique (--unique 1) le da otra MAC (y a una VM, otro UUID). Antes de restaurar, Show Configuration (pvesm extractconfig) enseña lo que guarda la copia:

root@pve1:~# pvesm extractconfig local:backup/vzdump-lxc-101-2026_10_07-21_05_00.tar.zst
arch: amd64
cores: 1
features: nesting=1
hostname: facturas
memory: 512
net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:BA:B3:68,ip=dhcp,type=veth
ostype: debian
rootfs: local-lvm:vm-101-disk-0,size=4G
swap: 512
unprivileged: 1

Ejercicio

Las citas que se borraron

Esta mañana alguien borró sin querer citas de la agenda (la VM 100). La copia de anoche (vzdump-qemu-100-2026_10_07-21_00_00.vma.zst, en local) las tiene. Sácala en una VM nueva (otro VMID) para que la recepción copie las citas de ahí, sin tocar la agenda que está funcionando: las citas de hoy solo están en ella.

Encendiendo el nodo…

Podar lo viejo

Podar (prune) aplica una retención a las copias que ya hay: en la web, Prune group en una copia del almacén; en la shell, pvesm prune-backups. Con --dry-run 1 solo enseña lo que haría, sin borrar nada:

root@pve1:~# pvesm prune-backups local --vmid 101 --keep-last 3 --dry-run 1
NOTE: this is only a preview and might not be what a subsequent
prune call does if backups are removed/added in the meantime.

Backup                                                         Backup-ID Prune-Mark
local:backup/vzdump-lxc-101-2026_10_01-21_00_00.tar.zst          lxc/101     remove
local:backup/vzdump-lxc-101-2026_10_02-21_00_00.tar.zst          lxc/101  protected
local:backup/vzdump-lxc-101-2026_10_03-21_00_00.tar.zst          lxc/101     remove
local:backup/vzdump-lxc-101-2026_10_04-21_00_00.tar.zst          lxc/101     remove
local:backup/vzdump-lxc-101-2026_10_05-21_00_00.tar.zst          lxc/101       keep
local:backup/vzdump-lxc-101-2026_10_06-21_00_00.tar.zst          lxc/101       keep
local:backup/vzdump-lxc-101-2026_10_07-21_00_00.tar.zst          lxc/101       keep

La del día 2 está protegida: ni cuenta para las 3 ni se borra. Sin --dry-run, borra las marcadas (con su registro y sus notas):

root@pve1:~# pvesm prune-backups local --vmid 101 --keep-last 3
removing backup 'local:backup/vzdump-lxc-101-2026_10_01-21_00_00.tar.zst'
removing backup 'local:backup/vzdump-lxc-101-2026_10_03-21_00_00.tar.zst'
removing backup 'local:backup/vzdump-lxc-101-2026_10_04-21_00_00.tar.zst'

Ejercicio

local, lleno de copias

local se está llenando de copias de la facturación (el contenedor 101): una por noche desde el día 1. Deja solo las 3 últimas. La del día 2 es la de la auditoría y está protegida: esa no se toca.

Encendiendo el nodo…

Resumen

  • vzdump copia un invitado (snapshot, suspend o stop; zstd, gzip o lzo) a un archivo en un almacén (/var/lib/vz/dump) o a un servidor de copias. Una copia protegida no se borra ni se poda.
  • Un trabajo (Datacenter ▸ Backup, jobs.cfg) hace las copias solo: qué, cuándo (un evento de calendario), dónde y con qué retención (keep-last, keep-daily, keep-weekly…). Guests without backup job dice quién se queda fuera.
  • Las copias tienen que salir del servidor: un Proxmox Backup Server (con su huella) guarda copias deduplicadas e incrementales.
  • Restaurar en un VMID nuevo no toca lo de ahora; encima (--force) lo borra. Antes, Show Configuration dice lo que guarda la copia.
  • Podar aplica la retención a lo que ya hay; con --dry-run, primero se mira.