Una estrategia práctica de copias de seguridad para VPS (regla 3-2-1)
Escrito por el equipo de ApexVPS • Última actualización: julio de 2026 • 7 min de lectura
Una estrategia de copias de seguridad para VPS confiable es la diferencia entre una recuperación de cinco minutos y una semana muy mala. Los servidores fallan, los discos se corrompen, los despliegues salen mal y un solo comando mal escrito puede borrar un directorio. El Centro de aprendizaje de Cloudflare y la mayoría de los equipos de infraestructura apuntan a la misma disciplina simple: la regla 3-2-1. Esta guía muestra cómo aplicarla a un servidor virtual real, qué herramientas usar y cómo programar y probar todo para que una restauración realmente funcione cuando la necesites.
Qué significa la regla 3-2-1
La regla 3-2-1 es un principio de copias de seguridad de décadas que sigue siendo cierto sin importar dónde viva tu servidor:
- 3 copias de tus datos: la copia en vivo más al menos dos copias de seguridad.
- 2 medios o sistemas de almacenamiento diferentes — de modo que un solo fallo no pueda eliminar ambas copias a la vez.
- 1 copia fuera del sitio — física o lógicamente separada de la máquina que estás protegiendo.
En un VPS, esto normalmente significa tu servidor en ejecución, un repositorio de copia de seguridad local y una copia cifrada enviada a un almacenamiento remoto en una ubicación diferente. El punto es la redundancia sin un único punto de fallo compartido.
Qué respaldar en un VPS
Respaldar todo el disco bloque por bloque es un desperdicio y lento. Un buen plan de copias de seguridad apunta a las tres cosas que son realmente difíciles de recrear.
Datos de aplicación y archivos
Archivos subidos, raíces de sitios web, volúmenes de contenedores y cualquier cosa que generen los usuarios. Las rutas típicas incluyen /var/www, /srv, /home y tu directorio de volúmenes de Docker. Si auto-alojas aplicaciones como un servidor de archivos o una wiki, aquí es donde vive tu contenido irreemplazable: consulta nuestra guía sobre ejecutar un VPS para auto-alojamiento para ver cómo suelen estar organizados esos directorios.
Bases de datos
Nunca copies archivos de bases de datos en vivo mientras el servicio está en ejecución; podrías capturar un estado corrupto o a medio escribir. En su lugar, exporta un volcado consistente. Para MySQL o MariaDB:
mysqldump --single-transaction --routines --triggers \
-u backup -p mydatabase > /srv/backups/mydatabase.sql
La bandera --single-transaction proporciona una instantánea consistente de las tablas InnoDB sin bloquearlas. Para PostgreSQL, usa pg_dump en su lugar:
pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump
Configuración del sistema y del servicio
Los archivos que hacen que tu servidor sea tuyo: /etc (nginx, unidades systemd, cron, configuración SSH), listas de paquetes, certificados TLS y reglas de firewall. Reconstruir estos de memoria después de un fallo es exactamente el trabajo tedioso que las copias de seguridad existen para evitar.
Elegir tus herramientas de copia de seguridad
Tres herramientas cubren casi todos los casos de VPS. Elige según cuánto valores la deduplicación y el cifrado.
restic — instantáneas cifradas y deduplicadas
restic es una herramienta de copia de seguridad moderna de un solo binario que cifra y deduplica por defecto. Inicializa un repositorio una vez y luego ejecuta copias de seguridad contra él:
# One-time: create an encrypted repository
restic init --repo /srv/backups/restic
# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql
# List what you have
restic -r /srv/backups/restic snapshots
BorgBackup — archivos deduplicados
BorgBackup ofrece deduplicación y compresión similares con un flujo de trabajo ligeramente diferente:
borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www
rsync — espejo de archivos simple
Cuando solo necesitas un espejo rápido de archivos a otro host, rsync a través de SSH es difícil de superar:
rsync -aAX --delete /var/www/ [email protected]:/backups/www/
Las banderas -aAX preservan permisos, ACL y atributos extendidos; --delete mantiene el espejo sincronizado con la fuente. rsync solo no versiona el historial, por lo que muchos equipos lo combinan con restic o borg.
Automatiza el horario con cron
Una copia de seguridad que tienes que recordar ejecutar es una copia de seguridad que no ocurrirá. Pon tus pasos en un script, hazlo ejecutable y prográmalo con cron. Edita tu crontab con:
crontab -e
Luego agrega líneas como estas:
# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh
# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh
Registra la salida y haz que el script salga con código distinto de cero en caso de fallo para poder conectarlo con las funciones de monitoreo y alertas que vienen con tu plan. Un fallo silencioso de copia de seguridad es peor que no tener copia de seguridad, porque parece seguro.
Mantén una copia real fuera del sitio
El "1" en 3-2-1 es la parte que la mayoría de la gente omite. Una copia de seguridad en el mismo servidor que protege desaparece con ese servidor. Envía una copia cifrada a algún lugar independiente: almacenamiento de objetos, un servidor SFTP remoto u otro proveedor. restic y borg escriben directamente en repositorios remotos, por ejemplo a través de SFTP:
restic -r sftp:[email protected]:/backups/restic backup /var/www
Debido a que restic y borg cifran antes de que los datos salgan de tu VPS, el host remoto nunca ve tu texto plano. Poda las instantáneas antiguas según una política para que el almacenamiento no crezca para siempre:
restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Prueba tus restauraciones — cada vez
Una copia de seguridad sin probar es un rumor. Programa una restauración periódica en una ubicación desechable y confirma que los archivos y las bases de datos vuelven intactos:
# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test
# Verify repository integrity
restic -r /srv/backups/restic check
# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql
Si la restauración tiene éxito y los datos coinciden, tienes una estrategia. Si no, acabas de aprenderlo un martes por la tarde en lugar de durante una caída real.
Las instantáneas son una capa, no toda la estrategia
Cada plan de ApexVPS incluye copias de seguridad automáticas: instantáneas diarias en Starter Pro y por horas en Business, y son realmente útiles para reversiones rápidas después de un despliegue fallido o un borrado accidental. Pero sé honesto sobre lo que son: una cómoda primera capa que vive en nuestra plataforma. No sustituyen a la copia externa, verificada de forma independiente, que exige la regla 3-2-1. Trata las instantáneas de la plataforma como tu punto de restauración local rápido y ejecuta tu propio trabajo de restic o borg para cumplir con las partes de la regla relativas a la copia externa y a la restauración probada. Ese enfoque en capas es lo que separa una configuración esperanzadora de una resiliente, ya sea que alojes aplicaciones como Nextcloud o que ejecutes una base de datos de producción.
Tu lista de verificación para la estrategia de copias de seguridad en VPS
Uniendo las piezas, una estrategia completa de copias de seguridad para un servidor virtual se ve así. Recórrela una vez, conviértela en script y deja que cron la continúe:
- Identifica lo que importa — archivos de aplicación, volcados de base de datos y la configuración bajo
/etc. - Elige una herramienta — restic o BorgBackup para copias cifradas, deduplicadas y versionadas; rsync para espejos simples.
- Vuelca las bases de datos de forma consistente —
mysqldump --single-transactionopg_dump, nunca una copia cruda de los archivos en vivo. - Automatízalo — programa el script con cron y alerta ante cualquier salida distinta de cero.
- Envía una copia fuera del sitio — cifrada, en almacenamiento independiente, con una política de retención sensata.
- Prueba las restauraciones regularmente — restaura a una ubicación temporal y confirma que los datos están intactos.
Haz estas seis cosas y la regla 3-2-1 dejará de ser teoría y se convertirá en un hábito en el que tu infraestructura pueda apoyarse. La hora inicial de configuración es trivial en comparación con el costo de descubrir, en medio de un incidente, que tu única copia estaba en el disco que acaba de fallar.
Preguntas frecuentes
¿Las instantáneas del proveedor cuentan como estrategia de copias de seguridad?
Las instantáneas son una capa útil, pero no una estrategia completa. Nuestras instantáneas diarias y por horas protegen contra la mayoría de los errores a corto plazo, pero viven en la misma plataforma que tu servidor. Una estrategia 3-2-1 completa aún necesita una copia independiente y externa que controles y restauraciones que hayas probado de verdad.
¿Con qué frecuencia debo hacer copias de seguridad de un VPS?
Ajusta la frecuencia a cuántos datos puedes permitirte perder. Los archivos estáticos y las configuraciones pueden respaldarse diariamente, mientras que las bases de datos activas a menudo justifican volcados por horas. Usa cron para automatizar el programa y que las copias nunca dependan de recordar ejecutarlas.
¿Cuál es la mejor herramienta para copias de seguridad en VPS?
restic y BorgBackup son excelentes: deduplican, comprimen y cifran las copias, y admiten repositorios externos. rsync sirve para reflejar archivos simples, y mysqldump o pg_dump gestionan las exportaciones de bases de datos. Muchas configuraciones combinan un volcado de base de datos con una ejecución de restic o borg.
¿Cómo sé que mis copias de seguridad funcionan de verdad?
Prueba las restauraciones según un programa. Restaura en un directorio temporal, verifica el contenido de los archivos y las sumas de verificación, e importa un volcado de base de datos en una base de datos de prueba. Una copia que nunca has restaurado es solo una suposición esperanzadora, no un plan de recuperación.