Proxmox Backup Server en un VPS: guía práctica

Qué ofrece realmente Proxmox Backup Server en un VPS

Proxmox Backup Server (PBS) en un VPS es un destino externo que utiliza el mismo protocolo que ya usa el clúster de Proxmox VE (entorno virtual). Por eso, después de la primera copia, todas las copias son incrementales, se deduplican entre los invitados, se cifran antes de salir de sus instalaciones y se pueden verificar después. Alquila un VPS con un volumen de bloques, instala PBS en Debian 13, crea un datastore en ese volumen y lo añade en Proxmox VE como un almacenamiento de tipo pbs. La instalación tarda diez minutos. Todo lo que viene después —los espacios de nombres, la recolección de basura, la custodia de las claves y una restauración que haya ejecutado realmente— es lo que determina si la copia seguirá siendo útil dentro de un año.

La razón para usar PBS en lugar de copiar archivos vzdump a un disco alquilado es el almacén de fragmentos. El cliente divide el disco de cada invitado en fragmentos de aproximadamente 4 MiB, calcula sus hashes y carga sólo los fragmentos que el datastore todavía no contiene. En una máquina virtual en ejecución, QEMU registra los bloques modificados en un mapa de bits de cambios después de la primera copia. Por eso, la siguiente ejecución sólo lee esos bloques del disco local. Un invitado de 200 GB que cambia 3 GB al día envía aproximadamente 3 GB al día. Esto permite que una conexión de subida doméstica y un volumen alquilado funcionen juntos. Por eso un VPS como destino externo de copias de seguridad es mejor que un disco adicional en casa de un amigo. Si todavía está decidiendo dónde debe ejecutarse el propio hipervisor, Proxmox en casa frente a un VPS alquilado aborda esa cuestión por separado.

Dimensione el volumen antes de alquilarlo

El dimensionamiento se calcula con sus propios valores. Tome el espacio que usa realmente cada guest, no el tamaño de su disco virtual, y añada lo que cambia cada día multiplicado por el número de días de retención. La compresión y la deduplicación mejoran esa cifra, por lo que debe tratar el resultado como un límite superior, no como un objetivo.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Esas filas son un ejemplo calculado, no una medición. Lea el espacio usado desde df -h dentro de cada guest y obtenga el cambio diario a partir del tamaño del segundo y el tercer backup en el registro de tareas de PBS, cuando ya existan.

El guest de correo del ejemplo usa 120 GB y cambia aproximadamente 3.0 GB al día, por lo que treinta snapshots diarios necesitan aproximadamente 210 GB: una copia completa más treinta días de cambios. Sume la última columna para los 3 guests y el total será de unos 619 GB. Añada una quinta parte para los índices, los metadatos y el espacio que necesita la recolección de basura, lo que apunta a un volumen de 1 TB.

El resto del plan es sencillo. PBS funciona con 2 GB de RAM y trabaja con comodidad con 4 GB, porque el trabajo costoso se realiza en el lado del clúster: el nodo de Proxmox VE lee los discos de los guests y realiza la división en chunks y el cálculo de hashes. El VPS escribe los chunks y ejecuta los dos trabajos pesados: la recolección de basura y la verificación. Alquile el datastore como un volumen de bloques independiente en lugar de usar un único disco raíz grande, porque después puede ampliar un volumen sin reconstruir el servidor.

Instalar Proxmox Backup Server en Debian 13

A fecha de agosto de 2026, la combinación actual es Proxmox Backup Server 4 con Debian 13, cuyo nombre en clave es trixie. Las guías antiguas combinan PBS 2 con Debian 11, y el nombre en clave forma parte de la definición del repositorio. Por eso, si copia el nombre de una suite antigua, apt muestra un error sobre un archivo de versión inexistente. Empiece con una imagen limpia de Debian 13. Ejecute todo lo siguiente como root o con sudo tal como está escrito.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

La suma debe ser 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Si no coincide, deténgase. Un keyring incorrecto significa que está a punto de instalar paquetes firmados por una entidad que no ha comprobado.

Escriba /etc/apt/sources.list.d/pbs.sources con el repositorio no-subscription, que es el adecuado para un servidor sin contrato de soporte:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

La interfaz web responde en el puerto HTTPS 8007. Inicie sesión como root@pam con la contraseña de root del sistema, porque PBS autentica ese usuario mediante PAM (módulos de autenticación conectables), las mismas cuentas que utiliza el sistema operativo. El certificado es autofirmado y el navegador lo indicará. La huella digital de ese certificado es el valor que Proxmox VE fija posteriormente, por lo que la advertencia es esperada y no requiere corrección.

El puerto 8007 expone un formulario de inicio de sesión en Internet, así que no debe dejarlo abierto a todo el mundo. Un solo archivo de nftables cubre este caso. Escribir /etc/nftables.conf vacía el ruleset actual, así que omita este paso si otro componente ya administra el firewall de este equipo.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Aplíquelo con sudo systemctl enable --now nftables y mantenga abierta una segunda sesión SSH mientras lo hace: policy drop más un error tipográfico en la regla de SSH puede dejarle sin acceso a su propio servidor. Sustituya 203.0.113.7 por la dirección desde la que se conecta al clúster. Si esa dirección es dinámica, amplíe la regla al rango de su proveedor o termine la conexión en un túnel. Recuerde que la mayoría de los paneles de VPS tienen un firewall de red independiente delante de la máquina y este también debe permitir el mismo puerto.

Coloque el almacén de datos en su propio volumen

El almacén de datos no debe residir en el sistema de archivos raíz. Cuando un almacén de datos llena un sistema de archivos raíz compartido, la copia de seguridad falla y también fallan todos los demás servicios del equipo, incluidos los registros que necesita para determinar la causa. Conecte el volumen de bloques, formatéelo, móntelo y sólo después cree el almacén de datos dentro del punto de montaje.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Obtenga el nombre del dispositivo de lsblk. En la mayoría de las imágenes KVM es /dev/vdb y en otras es /dev/sdb; nunca debe darlo por supuesto. Añada el montaje a /etc/fstab mediante la etiqueta, para que un cambio de nombre del dispositivo después de un reinicio no pueda dirigir el almacén de datos al disco incorrecto:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt debe mostrar el dispositivo, la ruta y opciones que incluyan rw,relatime. Esa línea puede ocultar dos fallos. Si el montaje no existe y crea el almacén de datos de todos modos, PBS escribe en el sistema de archivos raíz situado debajo del punto de montaje. El siguiente montaje correcto oculta esos datos sin eliminarlos: el almacén de datos parece vacío y el sistema de archivos raíz sigue lleno. Si las opciones indican noatime, PBS no funciona, porque comprueba la seguridad de los tiempos de acceso al crear el almacén de datos y de nuevo durante cada recolección de basura.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Esto crea un directorio .chunks que contiene 65536 subdirectorios, denominados 0000 a ffff. Un almacén de datos contiene cientos de miles de archivos pequeños, no unos pocos archivos grandes. De ello se derivan dos consecuencias. Copiar un almacén de datos con una herramienta normal de copia a nivel de archivo es tan lento que resulta inútil. Además, una instantánea del volumen del proveedor tomada mientras se ejecutan copias de seguridad no es una copia coherente del almacén, por la misma razón por la que las instantáneas no sustituyen a las copias de seguridad en ningún otro caso.

Los namespaces evitan conflictos entre dos hosts

Un almacén de datos es plano de forma predeterminada. Las copias de seguridad se llaman vm/100, ct/101 y host/<name>. Dos clústeres que tienen un guest con el ID 100 escriben en el mismo grupo, sus snapshots se intercalan y una regla de retención escrita para uno cuenta también los snapshots del otro. Los namespaces proporcionan a cada origen su propio árbol dentro de un único almacén de datos.

Créelos en el host de PBS. El argumento --repository tiene el formato [[auth-id@]server[:port]:]datastore, por lo que un namespace local se escribe root@pam@localhost:store1, y el comando solicita la contraseña de root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

La deduplicación no se ve afectada por esta separación. Los chunks se comparten en todo el almacén de datos, por lo que diez guests Debian distribuidos entre tres namespaces siguen almacenando una sola copia del sistema base. Esa es la razón para usar un almacén de datos con namespaces en lugar de un almacén por host: los almacenes separados tienen pools de chunks separados, y eso implica pagar varias veces por la misma instalación de Debian.

Asigne a cada origen su propia cuenta y restrínjala a su propio namespace. Un token de API (interfaz de programación de aplicaciones) es una credencial que pertenece a un usuario y tiene sus propios permisos. Es lo que necesita en una máquina que podrían robar.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

El comando del token muestra el secreto exactamente una vez:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Cópielo ahora, porque PBS no conserva ninguna forma del secreto que pueda mostrarle de nuevo. Revise dos veces el comando de control de acceso. Este nombra el token, backup@pbs!pve-home, y no al usuario, porque los permisos del token se calculan únicamente a partir de las entradas que nombran al propio token. Una entrada para backup@pbs por sí sola deja al token sin ningún acceso, y la primera copia de seguridad falla por permisos, no por un problema visible en la red. La ruta también importa: un token restringido a /datastore/store1/pve-home no puede leer ni eliminar nada del namespace de la oficina, por lo que un clúster comprometido no puede destruir el historial de otro sitio.

Añadir el VPS como almacenamiento de copias de seguridad en Proxmox VE

Lea primero la huella digital del certificado en el host PBS.

sudo proxmox-backup-manager cert info | grep Fingerprint

Después, en cualquier nodo del clúster:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Pegue el valor cert info que se muestra en lugar del marcador de posición de la tercera línea. Si pasa --password sin ningún valor, pvesm lo solicita de forma interactiva, por lo que el secreto del token no queda en el historial del shell. Se almacena en /etc/pve/priv/storage/pbs-offsite.pw, y la definición del almacenamiento se guarda en /etc/pve/storage.cfg. Esta definición se replica en todos los nodos del clúster, por lo que sólo debe configurarla una vez para todo el clúster.

--prune-backups keep-all=1 indica a Proxmox VE que no elimine nada. La retención se configura en el lado de PBS, como se explica más adelante, por un motivo importante: así, el token no necesita permisos de eliminación. Si un clúster queda cifrado por ransomware, no podrá conectarse al almacenamiento externo y eliminar el historial que debe permitir su recuperación.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status muestra active en la columna de estado, junto con el espacio total y usado del datastore. inactive significa que el nodo no pudo completar una sesión TLS (seguridad de la capa de transporte) en el puerto 8007. Es un problema del firewall o de la huella digital, no de las credenciales.

La primera copia de seguridad carga todos los datos, por lo que debe hacer los cálculos antes de iniciarla. 200 GB son 1600 gigabits, y una conexión ascendente de 100 Mbit transporta 0.1 gigabit por segundo. Por tanto, el tiempo mínimo es de unas cuatro horas y media, y en la práctica será mayor. Iníciela cuando no necesite ese ancho de banda. En las ejecuciones posteriores sólo se envían los fragmentos nuevos.

Cifrado del lado del cliente y ubicación de la clave

El VPS es un equipo que no le pertenece. Cifre en el cliente y el almacén de datos contendrá fragmentos que el proveedor no puede leer.

sudo pvesm set pbs-offsite --encryption-key autogen

Esto escribe una clave nueva en /etc/pve/priv/storage/pbs-offsite.enc, legible únicamente por root, y la replica junto con el resto de /etc/pve. A partir de la siguiente copia de seguridad, el cliente cifra cada fragmento antes de enviarlo. El servidor todavía puede enumerar las instantáneas y sus tamaños, pero no puede leer su contenido.

Aquí está la parte que convierte esto en una copia de seguridad y no en un riesgo. Una clave generada no tiene frase de contraseña y sólo existe en el clúster que protege. Si alguien roba ese clúster o lo cifra, el VPS contendrá datos que nadie podrá abrir. Copie la clave fuera del clúster el mismo día que la cree.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey imprime la clave como un documento pensado para imprimirse en papel y conservarse en otro lugar. Trate el archivo como el secreto que es, porque cualquiera que lo tenga puede descifrar todas las copias de seguridad creadas con él. En una instalación más grande, PBS también admite una clave maestra: un par de claves RSA (Rivest Shamir Adleman) creado con proxmox-backup-client key create-master-key. Cada copia de seguridad almacena su propia clave de cifrado cifrada con la mitad pública, mientras la mitad privada permanece fuera de línea para la recuperación.

Conviene conocer una consecuencia del diseño antes de empezar y no después. En las copias de seguridad cifradas, el resumen del fragmento se calcula a partir del contenido en texto plano unido a la clave de cifrado. Por eso, dos fragmentos idénticos cifrados con claves diferentes producen resúmenes diferentes y nunca se deduplican entre sí. Cambiar la clave hace que la siguiente copia de seguridad vuelva a cargarlo todo. Los fragmentos antiguos permanecen allí hasta que sus instantáneas se depuran y se recopilan. Decida si usará cifrado antes de la primera carga.

Las marcas de pruning y la recolección de basura recuperan espacio

Esta es la sección que suele omitirse, y es la que termina llenando el volumen. El pruning de un snapshot elimina sus metadatos: el manifest, los índices, el log y las notas. No elimina ningún chunk. Los chunks se comparten entre snapshots, por lo que no se puede saber que un chunk ya no se usa hasta leer todos los índices restantes. Esa es la tarea de la recolección de basura. Un datastore con una programación de pruning, pero sin una programación de recolección de basura, sólo crece.

Configure ambas tareas. Primero la retención, con un trabajo por namespace:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Después, configure la programación de recolección en el datastore, unas horas después del trabajo de pruning y fuera de la ventana de backup:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Compruebe una vez esta separación en el host de PBS:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Ejecute el trabajo de pruning y después df. La cantidad usada no cambiará. Ejecute la recolección de basura y vuelva a ejecutar df. Esta vez sí cambiará.

La recolección de basura se ejecuta en dos fases. En la primera, recorre todos los índices del datastore y actualiza la hora de acceso de cada chunk al que hacen referencia esos índices. En la segunda, elimina los chunks cuya hora de acceso es anterior al límite. Este límite es 24 horas y 5 minutos antes del inicio de la ejecución, o el inicio del backup más antiguo que todavía se está escribiendo, lo que ocurra antes. Este margen existe porque Linux monta los sistemas de archivos con relatime de forma predeterminada. Esta opción actualiza la hora de acceso aproximadamente una vez al día, en lugar de hacerlo con cada lectura. Por eso, un chunk escrito hace una hora nunca se elimina aunque todavía no tenga referencias. El espacio liberado por un pruning aparece en la primera recolección que se ejecute más de un día después del último acceso al chunk. Si un datastore parece no haber recuperado espacio, normalmente todavía está dentro de ese intervalo.

En un VPS pequeño, este es el trabajo más pesado que ejecuta el sistema, porque obtiene el estado de cada archivo de chunk del volumen. El log de la tarea termina con un resumen de lo que se eliminó y de lo que sigue pendiente debido al periodo de gracia. Si hay muchos elementos pendientes, vuelva a ejecutar la tarea al día siguiente. PBS expone gc-atime-safety-check y gc-atime-cutoff como opciones de ajuste del datastore. Ambas deben dejarse sin cambios. Existen para almacenamiento que no puede registrar horas de acceso. Desactivar la comprobación de seguridad en un sistema de archivos montado con noatime es la forma de perder chunks a los que todavía hacen referencia snapshots activos.

La verificación demuestra que los bloques siguen siendo legibles

Una copia de seguridad que se cargó correctamente puede quedar ilegible un año después. La verificación vuelve a leer los bloques y los compara con las sumas de comprobación almacenadas en el índice. Así, los daños se detectan según una programación y no durante una restauración.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Mantenga bajos los recuentos de hilos en un VPS pequeño. La verificación está limitada por el disco y la CPU. De lo contrario, competirá con las demás tareas del servidor. Para programarla, use la pestaña Verify Jobs del almacén de datos en la interfaz web. Un trabajo semanal que omita las instantáneas ya verificadas y vuelva a verificar las que tengan más de 30 días cubre todo el almacén con el tiempo sin repetir trabajo.

Una instantánea que no supera la verificación se marca como fallida en la vista del almacén de datos. No la ignore. Los bloques se comparten. Por eso, un solo bloque dañado de una imagen base suele hacer que fallen todas las instantáneas que lo referencian. La reparación consiste en olvidar las instantáneas fallidas y ejecutar una copia de seguridad nueva. Esta vuelve a cargar los bloques que faltan. Si los fallos siguen apareciendo, sospeche del almacenamiento subyacente al almacén de datos y configure la supervisión del estado del disco en el VPS para que la unidad le avise antes que el trabajo de verificación.

Probar una restauración y después probarla sin el clúster

No sabrá si una copia de seguridad funciona hasta restaurarla. Estas dos pruebas comprueban aspectos diferentes.

Invitado completo en el clúster:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

La primera columna de pvesm list es el ID del volumen, y la marca de tiempo forma parte de él. Copie el suyo en lugar de escribir el ejemplo. Restaure en un ID de invitado que no esté en uso y en otro almacenamiento. Después, inícielo con la interfaz de red desconectada. Nunca restaure sobre un invitado en ejecución para comprobar que las copias de seguridad funcionan. Si la restauración falla a mitad del proceso, también perderá la copia operativa.

La segunda prueba es la que nadie ejecuta. Suponga que el edificio donde está el clúster ha desaparecido y restaure desde una máquina que nunca formó parte de él. En cualquier equipo con Debian 13, añada el repositorio que sólo contiene el cliente como /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Rellene los tres marcadores entre comillas con sus propios valores y tome el nombre del archivo en la última línea de lo que haya mostrado snapshot files. Esto demuestra lo que la primera prueba no puede demostrar: que la copia del archivo de clave descifra datos reales y que puede controlar el cliente desde una máquina que nunca ha tenido la configuración del clúster. Anote los cuatro valores que necesitó: la cadena del repositorio, el secreto del token, la huella digital y el archivo de clave. Guárdelos juntos en el lugar indicado por su plan de recuperación ante desastres.

Qué hace y qué no hace la deduplicación con el consumo de disco

La deduplicación es real y funciona en todo el datastore. Diez guests Debian comparten una copia del sistema base, por lo que almacenar el segundo guest idéntico cuesta casi nada. También ahorra ancho de banda de subida, porque el cliente envía un checksum en lugar de los datos de cualquier chunk que el servidor ya tenga.

Conviene dejar claro lo que no hace.

• No reduce los datos que cambian. Una base de datos que reescribe grandes partes de sus archivos cada noche produce chunks nuevos cada noche, y la retención los multiplica.
• No atraviesa el límite de una clave de cifrado, como se explicó arriba.
• No atraviesa el límite de un datastore, que es precisamente el motivo para usar namespaces.
• No impide que un volumen se llene. Cuando el datastore está lleno, las copias de seguridad fallan, y las únicas soluciones son usar un volumen mayor o reducir la retención.

No añada otra capa de deduplicación por debajo. Los chunks llegan ya deduplicados y comprimidos por el cliente, por lo que la deduplicación de ZFS bajo un datastore consume RAM para buscar coincidencias que se eliminaron antes de escribirse. En este caso, la opción adecuada es usar ext4 o xfs sin deduplicación en el volumen.

La interfaz web muestra un factor de deduplicación para el datastore. Ese número describe sus guests y es el único que conviene usar para planificar, porque los ratios publicados describen los datos de otras personas. Si también necesita copias de seguridad a nivel de archivo de máquinas que no son guests de Proxmox, ejecútelas en paralelo en el mismo VPS: PBS es un destino compatible con hipervisores para guests completos, mientras que restic y BorgBackup apuntan a directorios, y las copias de seguridad de restic en un VPS son adecuadas para los portátiles y servidores independientes que PBS nunca tuvo previsto cubrir.

Modos de fallo y lo que verá

El almacenamiento aparece inactivo. pvesm status --storage pbs-offsite muestra inactive cuando el nodo no puede completar una sesión TLS con el puerto 8007. Compruebe el firewall del VPS, después el firewall de red independiente del proveedor y, por último, la huella digital. Una huella digital que ya no coincide con el certificado produce el mismo resultado visible que un puerto bloqueado y cambia cada vez que se sustituye ese certificado.

La primera copia de seguridad falla por permisos. La entrada de control de acceso debe especificar el token, no el usuario, y debe cubrir el espacio de nombres al que apunta el almacenamiento. Confirme ambos datos en la pestaña de permisos del datastore, en la interfaz web, antes de revisar cualquier otro elemento.

La recolección de basura no se inicia. La comprobación de seguridad del tiempo de acceso ha fallado. Casi siempre significa que el sistema de archivos del datastore está montado noatime. Ejecute findmnt -no OPTIONS /mnt/datastore/store1 para confirmarlo, corrija la opción en /etc/fstab y vuelva a montar el sistema de archivos. No desactive la comprobación para superar este error.

El datastore sólo crece. Los trabajos de depuración se ejecutan, pero no se libera espacio. Puede que no exista una programación de recolección de basura o que todas las recolecciones se ejecuten dentro del periodo de gracia de 24 horas porque se inician justo después de las copias de seguridad. Compruebe la programación con proxmox-backup-manager datastore show store1.

Una copia de seguridad que antes era rápida tarda horas. Un guest que se detuvo, se migró o se restauró pierde su mapa de bloques modificados. Por eso, la siguiente ejecución lee el disco completo en el lado del clúster, aunque cargue muy pocos datos. El registro de la tarea muestra una duración prolongada y una cifra de carga pequeña. La ejecución siguiente vuelve a ser rápida. Si todos los trabajos del VPS son lentos, la causa suele estar fuera del datastore. Lo primero que debe medir es el tiempo de steal de CPU causado por un vecino ruidoso.

FAQ

¿Por qué sigue creciendo el datastore de Proxmox Backup Server cuando se ejecuta el trabajo de pruning?

Porque pruning sólo elimina los metadatos de los snapshots: el manifest, los índices, el log y las notas. Los chunks permanecen en el disco hasta que garbage collection elimina los que ya no tienen referencias en ningún índice. Asigne un horario al datastore con proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' y compruébelo ejecutando df -h en la ruta del datastore antes y después de proxmox-backup-manager garbage-collection start store1. Espere un retraso de al menos un día, porque la segunda fase sólo elimina los chunks cuyo tiempo de acceso es anterior a 24 horas y 5 minutos.

¿Cuánto espacio de disco necesita una VPS con Proxmox Backup Server?

Sume el espacio que realmente usa cada guest y, después, añada el cambio diario de cada guest multiplicado por el número de días de retención. Ese total es un límite superior, porque la compresión y la deduplicación reducen el espacio necesario. Añada aproximadamente una quinta parte para los índices y el margen de trabajo. Después, redondee al alza hasta alcanzar el tamaño de volumen que pueda contratar. Vuelva a comprobarlo después de dos semanas con el uso real en la vista del datastore, porque una estimación hecha antes del primer backup siempre se desvía en una dirección u otra.

¿Dónde se debe almacenar la clave de cifrado del backup?

En cualquier lugar, salvo únicamente en el cluster que protege. Proxmox VE la mantiene en /etc/pve/priv/storage/<storage>.enc, que se replica en todos los nodos y, por tanto, se pierde junto con el cluster. Cópiela fuera desde el primer día, imprímala con proxmox-backup-client key paperkey y conserve esa copia en otro edificio. Tenga en cuenta también que la clave participa en el digest de los chunks, por lo que sustituirla más adelante hará que el siguiente backup vuelva a cargarlo todo.

¿Necesito un datastore por cada host de Proxmox o debo usar namespaces?

Use un datastore y un namespace por cada host o cluster de origen. La deduplicación funciona dentro de un datastore, no entre datastores. Por tanto, separar los hosts almacena varias veces las mismas imágenes base. Los namespaces mantienen separados los grupos de backup, de modo que dos hosts que tengan un guest con ID 100 no pueden colisionar. Además, una ruta de control de acceso con el formato /datastore/store1/pve-home limita el token de API de cada host a su propio namespace.

¿Una VPS pequeña podrá funcionar como servidor de backup de Proxmox?

Normalmente sí, en un homelab, porque el chunking y el hashing se realizan en el nodo de Proxmox VE, no en el servidor de backup. La VPS escribe los chunks y ejecuta los dos trabajos pesados: garbage collection y verification. Asígnele 4 GB de RAM y mantenga bajos los recuentos de hilos de verification. Programe ambos trabajos fuera de la ventana de backup. Si aun así tardan mucho más de lo que debería requerir el disco, mida el steal time antes de contratar un plan más grande.