Cómo usar un VPS como destino de copias externo

Qué es realmente un destino de copias de seguridad externo

Un destino de copias de seguridad externo es una segunda máquina que conserva una copia de los datos y falla de forma independiente del original. Para la mayoría de los lectores, un VPS de otro proveedor es la opción más económica. Hay tres opciones realistas: Proxmox Backup Server ejecutándose en el VPS, un repositorio de restic accesible mediante SSH o S3, o un espejo rsync que extrae los datos desde el host de copias de seguridad. La opción adecuada depende de lo que necesite restaurar y de la rapidez con la que deba recuperarlo. El resto depende de quién tenga permiso para eliminar la copia.

Externo significa que pertenece a otro dominio de fallo. Esto implica usar otro proveedor y una cuenta que no comparta credenciales con la cuenta que ejecuta el servidor. Un segundo servidor en otra región del mismo proveedor sobrevive a un incendio en uno de los edificios. No sobrevive a una intrusión en la cuenta del panel de control, porque una sola cuenta controla ambas copias.

Un snapshot del proveedor no es esa segunda copia. Está protegido por la misma contraseña del panel, de modo que quien obtenga esa contraseña puede eliminar el servidor y sus snapshots en una sola sesión. Además, los servicios de snapshots cobran por gigabyte y mes, con tarifas muy superiores a las del almacenamiento en disco normal, por lo que mantenerlos durante noventa días resulta caro. Conviene leer La diferencia entre snapshots de VPS y copias de seguridad antes de confiar en cualquiera de las dos opciones.

Qué opción se adapta mejor a su caso

• Proxmox Backup Server (PBS): el origen es Proxmox VE (entorno virtual) y lo que se restaura es una máquina virtual completa. Realiza copias de seguridad a nivel de imagen de disco, y sus tareas de verificación vuelven a leer los datos almacenados en el destino.
• Un repositorio de restic: el origen es uno o varios hosts Linux y lo que se restaura es un directorio o un volcado de base de datos. Cifra los datos en el cliente y admite SSH y S3, además de su propio protocolo REST.
• rsync mediante SSH, iniciado por el host de copias de seguridad: quiere que los archivos estén en el destino como archivos normales, legibles con ls y cat, sin necesidad de instalar software en el cliente para recuperarlos.

Si no puede decidirse, use restic. Cifra los datos antes de que salgan del equipo y no necesita nada en el destino, salvo una cuenta SSH y espacio en disco. Configuración de copias de seguridad de restic en un VPS explica el lado del cliente con más detalle, y restic y BorgBackup en paralelo aborda la elección si ya utiliza Borg.

Calcular el objetivo: cuánto cuesta conservar un mes

La deduplicación explica por qué las cifras son menores de lo esperado. restic y PBS dividen los archivos en fragmentos de tamaño variable y calculan el hash de cada fragmento. Cada fragmento único se almacena una sola vez. La segunda copia de seguridad de un conjunto de datos de 500 GB no añade otros 500 GB. Añade los fragmentos que hayan cambiado.

Por tanto, el tamaño del repositorio depende de la antigüedad de la instantánea más antigua, no del número de instantáneas. Suponga 500 GB de datos y 5 GB de datos únicos nuevos al día. El repositorio contendrá los 500 GB iniciales, más aproximadamente 5 GB por cada día transcurrido desde la instantánea más antigua que conserve la política.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

La columna en dólares calcula el precio de ese repositorio a 10 dólares estadounidenses por TB al mes. Es un valor de referencia para hacer el cálculo, no una tarifa de ningún proveedor. Sustitúyalo por el precio real por TB del plan que esté considerando. Una semana de copias diarias ocupa aproximadamente 535 GB. Un año completo de historial ocupa 2,325 GB, lo que equivale a $23.25 al mes, frente a $5.35 por una semana. El historial es barato. Lo que está pagando es la copia inicial.

La deduplicación no sirve para los datos que ya llegan comprimidos o cifrados. Un volcado de base de datos comprimido con gzip cambia por completo en cada ejecución. Por eso, cada volcado se almacena como fragmentos nuevos y el repositorio crece en un volcado completo cada noche. Genere el volcado sin comprimir y deje que la herramienta de copias de seguridad lo comprima. restic admite repositorios comprimidos desde 0.14 y la versión 0.19 añadió los modos zstd fastest y better. Las bibliotecas de fotos y vídeos también se deduplican mal por el mismo motivo. Calcule su tamaño a partir de su tasa de crecimiento real, no de las filas anteriores.

Aquí está comprando capacidad de disco inactiva, no CPU. Es precisamente el caso en que un VPS de almacenamiento supera a un VPS normal.

Por qué el ancho de banda y el tiempo de restauración determinan el plan

El disco es la parte barata. La primera carga y la restauración posterior son las partes costosas. 500 GB son 4 billones de bits, por lo que dividir esa cantidad entre la velocidad del enlace indica el tiempo mínimo que puede tardar una restauración completa.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Son cifras a velocidad de línea y sin sobrecarga de protocolo, así que deben considerarse el mejor caso. A 100 Mbit/s, una restauración completa necesita 11.1 horas antes de que alguien pueda acceder a los datos. Con una velocidad de subida doméstica de 40 Mbit/s necesita 27.8 horas. En un puerto de 1 Gbit/s, la misma restauración tarda 1.1 horas. Muchos archivos pequeños hacen que la transferencia sea más lenta que el cálculo, porque la sobrecarga por archivo predomina cuando los archivos ocupan menos de unos cientos de kilobytes.

De aquí se derivan dos consecuencias. Si su objetivo de tiempo de recuperación (RTO), es decir, la interrupción que puede tolerar, es de cuatro horas, una restauración de 500 GB mediante un enlace de 100 Mbit/s ya incumple ese objetivo, y un disco más barato no lo soluciona. Además, la mayoría de los planes VPS contabilizan la transferencia saliente, por lo que una restauración completa consume 0.5 TB de la cuota mensual del host de copias de seguridad. Compruebe esa cuota y qué hace el proveedor cuando se supera antes de necesitar los datos.

La primera copia de seguridad contiene todo el conjunto de datos y es la ejecución más lenta que hará. Iníciela un viernes y limite su velocidad para que no sature el enlace ascendente del origen: restic acepta --limit-upload en KiB por segundo, y rsync acepta --bwlimit.

Forma 1: Proxmox Backup Server como almacén de datos remoto

PBS es adecuado cuando el origen es Proxmox VE y la unidad de restauración es una máquina virtual. Un VPS no puede arrancar la ISO de Proxmox, por lo que debe instalar PBS sobre Debian. La versión 4.2 es la actual en agosto de 2026 y está basada en Debian 13 (trixie).

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

Compare esa suma de comprobación con el valor publicado en la página de repositorios de paquetes de Proxmox. Un repositorio de apt sólo es tan fiable como la clave que haya verificado. Después, escriba /etc/apt/sources.list.d/proxmox.sources:

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
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Asigne al almacén de datos su propio sistema de archivos o su propio volumen. Un almacén lleno detiene las copias de seguridad, y un almacén que comparte el sistema de archivos raíz puede dejar fuera de servicio todo el servidor cuando se llena.

A continuación, cree la cuenta que usará el origen y asígnele un token en lugar de una contraseña.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

El secreto del token se muestra una sola vez y no se puede volver a leer, así que guárdelo cuando aparezca. El rol es tan importante como el token. DatastoreBackup puede crear y restaurar sus propias copias de seguridad, pero no tiene el privilegio Datastore.Prune, por lo que ese token no puede eliminar una instantánea que ya haya escrito.

La retención en PBS tiene dos partes, y la segunda suele omitirse. Prune elimina instantáneas. La recolección de basura elimina los fragmentos a los que ya no hace referencia ninguna instantánea conservada. El espacio libre aparece después de la recolección de basura, no después de prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Elimine --dry-run cuando la lista de instantáneas que planea eliminar sea correcta. La recolección de basura se ejecuta en dos fases: actualiza la hora de acceso de cada fragmento que aún está referenciado y después elimina los fragmentos cuya hora de acceso sea anterior al límite. Ese límite es 24 horas y 5 minutos antes del inicio de la ejecución. Este periodo de gracia evita que se elimine un fragmento que una copia de seguridad en curso todavía está escribiendo. Programe prune a diario y la recolección de basura una vez por semana en el almacén de datos. Añada también un trabajo de verificación para que el destino vuelva a leer sus propios fragmentos e informe de la corrupción en disco antes de que se produzca una restauración.

Si el origen es una instancia de PBS, el servidor externo puede extraer los datos en lugar de recibirlos mediante push.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Ejecute ese trabajo de sincronización en el VPS, con la dirección de extracción predeterminada. El VPS accede al almacén de datos local, por lo que el servidor local no conserva ninguna credencial que pueda modificar la copia externa.

Forma 2: un repositorio de restic mediante SSH o S3

Debian y Ubuntu incluyen restic en sus repositorios, pero ambas distribuciones van por detrás de la versión upstream. La versión 0.19.1 es la actual en agosto de 2026. Instale el binario oficial en el host de origen.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version muestra la versión y el compilador de Go con el que se compiló. Las actualizaciones posteriores se realizan con sudo restic self-update, que funciona con los binarios oficiales, pero no con una copia instalada mediante apt.

En el VPS de backup, cree una cuenta que no sea propietaria de ningún otro recurso y copie la clave pública del host de origen en /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Inicialice el repositorio desde el origen mediante SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Guarde esa contraseña en un lugar que no sea ni este servidor ni el destino de backup. Si la pierde, el repositorio será ilegible y no habrá ninguna forma de recuperarlo. Esa es la condición del cifrado del lado del cliente.

La retención se configura con un comando, y la segunda mitad es la que libera espacio en disco.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget elimina snapshots. prune elimina los archivos pack a los que sólo hacían referencia esos snapshots, y --prune lo ejecuta automáticamente cuando realmente se ha eliminado algo. Sin esta opción, el repositorio nunca reduce su tamaño. restic check comprueba la estructura del repositorio, y --read-data-subset=10% vuelve a leer y calcular el hash de una décima parte de los archivos pack. Esto detecta corrupción en el destino sin el coste de leerlo todo. La otra forma, --read-data-subset=1/10, comprueba siempre la misma décima parte. Por tanto, incrementar ese primer número cada semana permite cubrir todo el repositorio en diez semanas.

Si se termina una ejecución de forma forzada, la siguiente se detiene con repository is already locked exclusively by PID. Confirme que no haya ningún backup en ejecución y elimine ese estado con restic unlock.

Para el almacenamiento de objetos, la cadena del repositorio pasa a ser s3:https://s3.example.net/web1, con las credenciales en AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY. Todo lo demás es idéntico. Así es como restic se comunica con un almacenamiento de objetos MinIO autohospedado que se ejecuta en el mismo VPS.

Forma 3: rsync mediante SSH con una clave de solo extracción

La propiedad de seguridad de esta forma es la dirección de la conexión. El VPS de copias de seguridad se conecta al origen y lee. El origen no contiene ninguna clave ni tiene ninguna ruta hacia el host de copias de seguridad, por lo que un compromiso del origen no puede alcanzar las copias de seguridad.

Genere un par de claves en el VPS de copias de seguridad y, a continuación, instale la parte pública en el origen mediante un comando forzado.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync se incluye en el paquete rsync, en /usr/bin/rrsync, en Debian 13 y Ubuntu 24.04. -ro sólo permite leer e implica -no-del, por lo que esta clave no puede escribir en el origen ni eliminar nada en él. restrict desactiva las funciones de SSH que no se necesitan aquí, incluido el reenvío de puertos y el pty, por lo que la clave no se puede usar para iniciar una sesión interactiva. A partir de ese momento, las rutas son relativas al directorio que indicó, por lo que la ruta remota / significa /srv en el origen.

La extracción conserva el historial mediante enlaces físicos. Los archivos sin cambios del árbol nuevo son enlaces físicos al árbol anterior, por lo que consumen una entrada de directorio en lugar de una segunda copia.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

El cambio de nombre final es lo que hace fiable a un directorio fechado: el nombre sólo aparece después de que rsync termina con el código 0, por lo que una transferencia interrumpida nunca parece una instantánea terminada. Elimine los árboles antiguos con una sola línea y conserve treinta.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Sea claro sobre el coste de esta forma. Los enlaces físicos sólo deduplican archivos completos, por lo que cambiar un byte dentro de una imagen de disco de 4 GB copia los 4 GB completos; restic y PBS almacenarían unos pocos bloques modificados. Además, el destino contiene sus archivos en texto plano, por lo que cualquier persona con root en el VPS de copias de seguridad puede leerlos.

Cifrado en el cliente, para que el destino nunca vea texto plano

Trate el VPS de copias de seguridad como una máquina que no controla por completo. Tiene un proveedor, y ese proveedor tiene personal y discos averiados que salen del edificio.

restic cifra cada bloque en el origen antes de enviarlo, por lo que el repositorio contiene texto cifrado y metadatos sobre los tamaños y los tiempos. PBS hace que el cifrado sea opcional: cree una clave y pásela en cada copia de seguridad.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Imprima la clave en papel y guárdela en un lugar físico. La documentación de Proxmox es clara sobre lo que está en juego: sin esa clave, los archivos respaldados son inaccesibles. Mantenga la clave fuera del destino de las copias de seguridad, porque una clave almacenada junto al texto cifrado no protege nada.

Los espejos de rsync no tienen un equivalente. Los archivos llegan como archivos. Si los datos son confidenciales, acepte que el destino puede leerlos o use una de las otras dos opciones.

Impedir que un origen comprometido borre sus propias copias de seguridad

Un atacante que toma el control del origen busca las copias de seguridad a continuación, y la credencial que las carga está en ese mismo equipo. Si esa credencial también permite borrar, la utilizará.

PBS resuelve este problema mediante roles. Un token que sólo tiene DatastoreBackup puede escribir snapshots nuevos y restaurar los suyos, pero no puede ejecutar prune, porque eliminar un snapshot requiere el privilegio independiente Datastore.Prune. Ejecute la política de retención desde el lado de PBS y el origen nunca tendrá una credencial que pueda eliminar nada.

restic sobre SFTP no ofrece esta separación, porque la clave SSH que escribe en el repositorio también puede borrar contenido. La solución es el backend REST. Ejecute rest-server en el VPS de copias de seguridad con --append-only. Esta opción permite crear copias nuevas, pero impide eliminar o modificar las existentes. Después, configure el cliente para usar rest:https://backup.example.net:8000/web1 mediante RESTIC_REST_USERNAME y RESTIC_REST_PASSWORD. Un restic forget --prune ejecutado desde el origen fallará, que es el resultado previsto. La retención se ejecuta desde un segundo equipo con su propia credencial. El manual de restic también recomienda --keep-within en lugar de políticas basadas en cantidades en repositorios append-only, porque un atacante que inunde el repositorio con snapshots basura podría expulsar las copias reales de una ventana de --keep-last.

rsync resuelve el mismo problema de forma estructural mediante la extracción, porque el origen no tiene ninguna credencial para acceder al destino.

Una regla cubre las tres configuraciones: la credencial que puede eliminar copias de seguridad debe estar en un equipo distinto del que se está respaldando.

Programar el simulacro de restauración

Una copia de seguridad que nunca se ha restaurado es una hipótesis. Reserve una hora cada trimestre y pruébela.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r no mostrar nada significa que el árbol restaurado coincide con el árbol activo. En PBS, el mismo simulacro es proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, además de un trabajo de verificación programado que vuelve a leer los bloques en el destino e informa de los fallos de suma de comprobación.

El simulacro debe demostrar algo más que la integridad de los bytes.

• Restaure desde una tercera máquina, no desde el origen, porque el origen es precisamente lo que supone que se ha perdido. Esto significa que la contraseña del repositorio o la clave de PBS deben estar disponibles sin el origen.
• Mida el tiempo de restauración y anote el resultado. Después, compárelo con el RTO que declaró. El gráfico anterior muestra el límite mínimo de transferencia. El tiempo real también incluye descifrar y escribir en el disco, además del tiempo necesario para determinar qué snapshot quería restaurar.
• Restaure algo con estado, como un volcado de base de datos que después cargue en una instancia de prueba. Que un archivo tar se extraiga correctamente no demuestra que la aplicación se inicie.

El disco más barato del mundo no sirve de nada hasta que haya restaurado datos desde él al menos una vez.

FAQ

¿Un snapshot del proveedor de VPS es una copia de seguridad externa?

No. El snapshot del proveedor está en la misma cuenta, protegido por el mismo acceso al panel y en la misma factura que el servidor que copia. Quien obtenga esas credenciales puede eliminar el servidor y todos sus snapshots en una sola sesión. Los snapshots son útiles para revertir rápidamente el sistema antes de una actualización arriesgada, pero no constituyen una segunda ubicación. Una copia externa se almacena en otra cuenta, idealmente con otro proveedor, y usa credenciales que la máquina de origen no conserva.

¿Cuánto espacio de disco necesito para conservar copias de seguridad durante un mes?

Calcule el tamaño a partir de la antigüedad del snapshot más antiguo, no del número de snapshots. Una herramienta con deduplicación almacena cada bloque único una sola vez, por lo que el repositorio tiene aproximadamente el tamaño del origen más los datos únicos nuevos de cada día multiplicados por el número de días de conservación. Para 500 GB de datos que cambian 5 GB al día, una semana de copias diarias ocupa aproximadamente 535 GB y un año completo de historial ocupa 2,325 GB. Reserve espacio adicional, porque un disco lleno impide la siguiente copia de seguridad y prune de restic necesita espacio libre para volver a empaquetar los archivos pack antes de poder liberar espacio.

¿Puede un servidor comprometido eliminar sus propias copias de seguridad externas?

Sí, a menos que lo haya diseñado para impedirlo. En un repositorio SSH o SFTP normal, la clave que permite escribir también puede eliminar datos. Asigne al origen unas credenciales que no puedan eliminar datos: un token de API de PBS con sólo el rol DatastoreBackup, que no tiene el privilegio Datastore.Prune, o restic conectado a un rest-server iniciado con --append-only, que rechaza la eliminación y modificación de copias de seguridad existentes. Un diseño de extracción ofrece una protección adicional, porque el origen no conserva ninguna credencial del host de copias de seguridad. Ejecute la política de retención desde el lado que no es el origen.

¿Debo ejecutar Proxmox Backup Server o restic en el VPS de copias de seguridad?

Elija la herramienta según la unidad que necesite restaurar. Si el origen es Proxmox VE y quiere recuperar una máquina virtual completa, use PBS, porque realiza copias de seguridad en el nivel de imagen de disco y restaura una VM en un solo paso. Si el origen es un host Linux y quiere recuperar archivos y volcados de bases de datos, use restic, que sólo necesita una cuenta SSH en el destino y cifra los datos antes de enviarlos. Es normal ejecutar ambas herramientas: PBS para el hipervisor y restic para los servidores que no están alojados en él.

¿Cuánto tarda una restauración desde una copia de seguridad de VPS?

Divida el tamaño de los datos por la velocidad del enlace para obtener el tiempo mínimo y añada el tiempo de descifrado y escritura. 500 GB a través de un enlace de 100 Mbit/s tardan 11.1 horas a velocidad de línea, y la misma restauración a través de un puerto de 1 Gbit/s tarda 1.1 horas. Muchos archivos pequeños se transfieren más despacio de lo que indica ese cálculo por la sobrecarga de cada archivo. Cronometre una restauración real y use ese valor medido, porque es el único en el que puede basar su plan de recuperación.