Todos los productos 
Copias de seguridad de un VPS: estrategias y herramientas
En un VPS las copias de seguridad son cosa tuya, aunque el plan diga «copias incluidas». Vemos qué hay que copiar exactamente, por qué no basta con la instantánea del proveedor, cómo configurar restic o BorgBackup en media hora y cómo asegurarte de que de verdad se puede restaurar desde la copia.
Uno suele acordarse de la copia en el momento en que la necesita: una actualización ha roto la base de datos, alguien ha borrado la carpeta de la web, el disco del proveedor ha fallado o han entrado en el servidor. En todos estos casos no te salva cualquier copia, sino una que está en otro lugar, es reciente y desde la que ya has restaurado al menos una vez. A continuación, cómo montar una copia así en un servidor Linux normal.
La instantánea del proveedor todavía no es una estrategia
Muchos proveedores ofrecen instantáneas del disco (snapshot) y copias automáticas en el panel. Es útil, pero una copia así tiene tres puntos débiles.
- Está en el mismo proveedor. Un problema de pago, el cierre de la cuenta, una avería en el centro de datos o una contraseña robada del área de cliente se llevan a la vez el servidor y todas sus instantáneas.
- Hay pocas copias y son poco frecuentes. A menudo son una o dos copias recientes, una vez al día o a la semana. Si el fallo se descubre al cabo de unos días, puede que ya no quede ninguna versión sana.
- La base de datos de la instantánea no siempre está íntegra. La instantánea captura el disco en un momento cualquiera, como si el servidor se hubiera apagado de golpe. InnoDB y PostgreSQL suelen recuperarse de eso, pero no hay garantía, y las tablas MyISAM pueden quedar dañadas.
La instantánea es cómoda como punto de restauración rápido antes de una actualización. Las copias principales conviene hacerlas con tus propios medios y guardarlas aparte.
La regla 3-2-1
El esquema clásico dice así: tres copias de los datos, en dos soportes o sistemas distintos, y una de ellas en otro lugar. En un VPS suele quedar así:
- Los datos de trabajo en el propio servidor.
- Una copia en otro servidor o en un almacenamiento de objetos S3 de otro proveedor, o al menos en otro centro de datos.
- Una copia más: instantáneas en el panel del proveedor, un segundo servidor de copias o una descarga a un almacenamiento doméstico.
Conviene añadir una regla: al menos una copia no debe poder borrarse desde el propio servidor de trabajo. Si un atacante obtiene root, también ve las contraseñas del almacenamiento de copias. Cómo conseguirlo se explica más abajo, en el apartado sobre la protección contra el borrado.
Qué copiar
Normalmente no hace falta copiar el sistema entero: un servidor limpio se levanta desde una plantilla en minutos. Lo valioso son los datos y la configuración.
| Qué | Dónde suele estar | Cómo copiarlo |
|---|---|---|
| Archivos de las webs y subidas de los usuarios | /var/www, /home | Como archivos |
| Bases de datos | /var/lib/mysql, /var/lib/postgresql | Solo con un volcado, no como archivos |
| Configuración del sistema y de los servicios | /etc | Como archivos, junto con los certificados de /etc/letsencrypt |
| Tareas programadas | /etc/cron.d, crontab -l de los usuarios | Como archivos o exportadas a texto |
| Datos de contenedores | Volúmenes de Docker, normalmente /var/lib/docker/volumes | Como archivos con el contenedor detenido o con un volcado de la base de datos que contiene |
Excluye cachés, archivos temporales, logs y node_modules: inflan la copia y se regeneran solos.
Bases de datos: solo con un volcado
No se pueden copiar los archivos de una base de datos en funcionamiento: cambian mientras se copian y la copia queda incoherente. El camino correcto es un volcado. Para MySQL y MariaDB:
mysqldump --single-transaction --routines --triggers shop | gzip > /var/backups/shop-$(date +%F).sql.gzLa opción --single-transaction hace un volcado coherente de las tablas InnoDB sin detener la escritura. Esta opción no protege las tablas MyISAM: si las tienes, pásalas a InnoDB o haz el volcado con --lock-all-tables. En Debian y Ubuntu root entra en MariaDB sin contraseña a través del socket, así que el comando funciona tal cual como root; para otro usuario, pon el nombre de usuario y la contraseña en ~/.my.cnf con permisos 600.
Para PostgreSQL:
sudo -u postgres pg_dump -Fc shop > /var/backups/shop-$(date +%F).dump
sudo -u postgres pg_dumpall --globals-only > /var/backups/pg-globals.sqlEl segundo archivo guarda los roles y permisos, que no están en el volcado de una base concreta. Un volcado así se restaura con el comando pg_restore -d shop archivo.dump. Si la base pesa decenas de gigabytes y el volcado tarda demasiado, mira la copia física: mariabackup o Percona XtraBackup para MySQL, pgBackRest para PostgreSQL.
Guarda los volcados en una sola carpeta, por ejemplo /var/backups, e inclúyela en la copia de archivos: así todo va al almacenamiento con un solo comando.
Herramientas: rsync, restic, BorgBackup
| rsync | restic | BorgBackup | |
|---|---|---|---|
| Versiones de las copias | Solo a mano con --link-dest | Sí, instantáneas | Sí, archivos |
| Cifrado | No, solo durante la transferencia por SSH | Siempre, en el servidor de origen | Sí, opcional al crear el repositorio |
| Deduplicación | No | Sí | Sí, y además compresión |
| Dónde guardar | Disco, SSH | Disco, SFTP, S3, servidor REST propio | Disco, SSH con borg en el otro extremo |
| Modo «solo añadir» | No | Con rest-server | Con borg serve --append-only |
rsync: un espejo, no una copia
rsync sincroniza carpetas rápido, pero por sí solo no es una copia: un archivo borrado o dañado en el servidor se borrará o se dañará igual en el espejo en la siguiente ejecución. Puedes tener versiones con la opción --link-dest: cada ejecución crea una carpeta nueva, y los archivos sin cambios son enlaces duros a la anterior, así que solo se gasta espacio en los cambios. Es más cómodo ejecutarlo en el servidor de copias, que recoge él mismo los datos del servidor de trabajo:
rsync -a --delete --link-dest=/backup/web/2026-10-30 root@web.example.com:/var/www/ /backup/web/2026-10-31/Para una sola web es suficiente, pero rsync no ofrece cifrado ni comprobación de integridad.
restic
restic es un único programa sin dependencias. Cifra los datos antes de enviarlos, guarda solo los fragmentos nuevos de los archivos y puede escribir por SFTP, en un almacenamiento compatible con S3 o en su propio rest-server. El repositorio se crea una vez, y después la copia se hace con un solo comando:
export RESTIC_REPOSITORY=sftp:backup@storage.example.com:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /var/www /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic checkEl comando forget conserva 7 instantáneas diarias, 4 semanales y 6 mensuales, y --prune libera el espacio del resto. Sin la contraseña de /root/.restic-pass el repositorio no se puede descifrar de ninguna manera, así que guarda una copia de ella fuera del servidor, por ejemplo en un gestor de contraseñas.
BorgBackup
Borg se parece a restic, pero suele comprimir mejor y trabaja más rápido con muchos archivos pequeños. Guarda el repositorio en un disco o en otro servidor por SSH, donde también debe estar instalado borg; no admite S3 directamente. La rama estable en 2026 es la 1.4; la versión 2.0 sigue en beta y no se recomienda para copias de producción. Comandos para 1.4:
export BORG_REPO=ssh://backup@storage.example.com/./web1
export BORG_PASSCOMMAND="cat /root/.borg-pass"
borg init --encryption=repokey-blake2
borg create --stats --compression zstd ::'{hostname}-{now}' /etc /var/www /var/backups
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compactDesde la 1.2, el espacio tras prune solo se libera con el comando compact. En el modo repokey la clave se guarda en el propio repositorio, protegida con la contraseña; por si acaso, expórtala con borg key export y guárdala fuera del servidor.
Si en el servidor hay un panel de control, mira sus copias integradas: en ISPmanager, FASTPANEL y aaPanel se configuran desde la interfaz y pueden enviar los archivos a un almacenamiento externo. Selecciones de planes con paneles: ISPmanager, FASTPANEL, aaPanel.
Dónde guardar las copias
- Un VPS aparte en otro proveedor. Para las copias no hace falta un procesador rápido, sino un disco grande. Estos planes están en las selecciones VPS para almacenamiento de datos, VPS con HDD y VPS para copias de seguridad.
- Almacenamiento de objetos S3. Pagas por los gigabytes ocupados, y restic escribe ahí directamente. Si el almacenamiento admite versiones de objetos o bloqueo del borrado durante un plazo, eso además protege contra el borrado.
- Un almacenamiento en casa o en la oficina. Va bien como tercera copia: el servidor de copias recoge él mismo los datos por SSH, y desde fuera no es posible conectarse a él.
Si en la base de datos hay datos personales de ciudadanos rusos, ten en cuenta la ley rusa 152-FZ: también las copias es mejor guardarlas en servidores en Rusia. Selección: VPS para la ley 152-FZ.
Protección contra el borrado
La situación más desagradable es cuando un atacante o un script erróneo borra tanto los datos como las copias. Hay tres maneras de evitarlo.
- Recoger en lugar de enviar. El servidor de copias se conecta él mismo al servidor de trabajo y recoge los datos. El servidor de trabajo no tiene ningún acceso a las copias.
- Modo «solo añadir». Para borg, en el servidor de copias se asigna un comando a la clave del servidor de trabajo en
authorized_keys:command="borg serve --append-only --restrict-to-path /srv/borg/web1",restrict ssh-ed25519 AAAA…. Se pueden añadir archivos nuevos, pero no borrar los antiguos. Para restic, lo mismo lo hace rest-server ejecutado con la opción--append-only. En ese caso, la limpieza de copias antiguas se lanza desde una máquina de confianza con otra clave. - Versiones y bloqueo del borrado en S3. El propio almacenamiento conserva las versiones anteriores de los objetos durante el plazo definido.
Programación y frecuencia de las copias
La frecuencia depende de cuántos datos estés dispuesto a perder. Para un blog basta con una copia al día. Para una tienda en la que entran pedidos todo el día, conviene volcar la base de datos cada hora y copiar los archivos una vez al día. Lanza la copia de noche con cron o un temporizador de systemd, por ejemplo con el archivo /etc/cron.d/backup y la línea 30 3 * * * root /usr/local/bin/backup.sh.
Una copia que ha dejado de hacerse sin avisar es peor que no tener copia: crees que estás protegido. Al final del script envía una señal a una monitorización externa (un simple curl a la dirección de comprobación), y si la señal no llega a tiempo, la monitorización te avisará.
Comprueba la restauración
Una vez al mes, restaura una copia en un servidor limpio y comprueba que la web se abre y que los datos están en su sitio. Para esto es práctico el pago por horas: el servidor de prueba solo se paga por las horas que está funcionando.
restic restore latest --target /tmp/restore --include /var/www/site
restic check --read-data-subset=10%
borg extract ::web1-2026-10-31T03:30:00 var/www/site # nombre del archivo: de borg list
borg check --verify-dataEl segundo y el cuarto comando leen los propios datos del repositorio, no solo su índice, y encuentran los fragmentos dañados. Apunta el procedimiento de restauración en un archivo aparte fuera del servidor: en plena avería no hay tiempo para recordar comandos. Cómo preparar el servidor nuevo en el que vas a restaurar se describe en Primeros 10 pasos tras comprar un VPS: seguridad, y el traslado completo de una web, en Cómo migrar una web del hosting compartido a un VPS.