Backup VPS 3-2-1: cómo implementarlo y restaurar tus datos

Para que tu backup de VPS sea realmente recuperable, sigue el esquema 3-2-1, utilizando herramientas como Restic o Borg, configura copias de seguridad automáticas y verifica su funcionalidad regularmente, desplegando los datos en un VPS de prueba con 2 GB de RAM y 20 GB de disco NVMe, al menos una vez por trimestre.

Los propietarios de VPS y servidores dedicados a menudo se enfrentan a una paradoja: tienen un backup, pero no pueden restaurar los datos a partir de él. Esto es especialmente crítico cuando se trata de proyectos comerciales, donde cada minuto de inactividad se traduce en pérdida de beneficios y reputación. Las estadísticas muestran que los problemas con los backups son una de las causas más frecuentes de pérdida de datos, y a menudo esto ocurre no por la ausencia de copias de seguridad, sino por su inoperatividad. Lamentablemente, muchos administradores y desarrolladores solo se dan cuenta de esto en el momento en que el servidor ya "ha caído" y necesitan restaurar los datos con urgencia. Y es precisamente en este momento crítico cuando se descubre que el backup está dañado, incompleto, o el procedimiento de restauración es tan complejo y poco claro que lleva horas o incluso días. En este artículo, analizaremos en detalle cómo construir un sistema de backup de VPS fiable que realmente funcione y no falle en el momento más crucial.

¿Por qué tu backup de VPS podría no funcionar?

La ilusión de seguridad: cuando el backup falla

Muchas empresas y desarrolladores individuales viven con una falsa sensación de seguridad, confiando en la existencia de alguna copia de seguridad. Configuraron un backup automático de VPS hace tiempo, el script se ejecuta correctamente cada noche y los registros muestran que todo fue exitoso. Sin embargo, la realidad puede ser mucho más dura. Imagina la situación: tu VPS principal ha fallado debido a un problema de hardware, un ciberataque o un error fatal de configuración. Intentas restaurar los datos desde el backup "funcional" y descubres que:

• El archivo está dañado o incompleto.
• La clave de cifrado se ha perdido o modificado, y los datos son inaccesibles.
• El backup se realizó solo en el mismo servidor, que ahora no está disponible.
• El script de backup está obsoleto y no incluye nuevas directorios o bases de datos.
• La consistencia de la base de datos está comprometida, y no se inicia después de la restauración.
• El proceso de restauración lleva mucho más tiempo de lo esperado debido a su complejidad o falta de documentación.

Cualquiera de estos escenarios convierte tu "backup" de un salvavidas en un ancla que arrastra el proyecto al fondo. Esto no es solo un inconveniente, es un golpe directo al negocio, la reputación y, en última instancia, pérdidas financieras. Por eso, la tesis principal de este artículo es: un backup que nunca ha sido restaurado, no es un backup.

El coste de la pérdida de datos: de la reputación a la bancarrota

Las consecuencias de la pérdida de datos pueden ser catastróficas. Para una pequeña empresa, esto puede significar la pérdida de clientes, multas por incumplimiento de obligaciones (por ejemplo, GDPR), y en el peor de los casos, el cese total de la actividad. Las grandes empresas pueden enfrentarse a pérdidas multimillonarias, caída de acciones y un grave daño a la marca. Incluso para proyectos personales, la pérdida de datos puede significar años de trabajo, fotografías o información importante perdidos. En 2023, el coste medio de inactividad debido a la pérdida de datos para pequeñas y medianas empresas fue de aproximadamente $5000 por hora, y para grandes empresas esta cifra es significativamente mayor. Por eso, la inversión en una estrategia de backup adecuada no es un gasto, sino un seguro.

¿Qué es el esquema de backup 3-2-1 y por qué es crucial para tu VPS?

El esquema de backup 3-2-1 es el estándar de oro en la industria de las copias de seguridad, proporcionando un alto grado de protección de datos contra una amplia variedad de amenazas. Es fácil de entender, pero requiere disciplina en su implementación. Este esquema es especialmente relevante para los VPS, donde un solo fallo puede llevar a la pérdida de toda la información en la máquina virtual.

Tres copias de datos: el principio fundamental

La primera regla del esquema 3-2-1 establece: debes tener un mínimo de tres copias de tus datos. Esto incluye los datos originales (la copia de trabajo en tu VPS) y al menos dos copias de seguridad. ¿Por qué tantas? Porque cualquier copia puede dañarse. Si solo tienes una copia de seguridad y resulta ilegible, lo perderás todo. Tres copias reducen significativamente este riesgo, proporcionando puntos de fallo adicionales.

Dos tipos de medios diferentes: diversificación

La segunda regla: almacena dos copias de tus datos en dos tipos de medios diferentes. Por ejemplo, si tu VPS principal utiliza discos NVMe, una copia de seguridad puede almacenarse en otro VPS con discos HDD, y la segunda en un almacenamiento en la nube (por ejemplo, compatible con S3). Los diferentes tipos de medios protegen contra fallos específicos. Por ejemplo, un problema con una tecnología de almacenamiento (digamos, un fallo de un modelo específico de SSD) no afectará a otra (por ejemplo, HDD tradicionales o cintas, si se trata de grandes volúmenes).

Una copia fuera de sitio (off-site): protección contra desastres

La tercera y, quizás, la regla más importante para el backup de servidores: una de las copias de seguridad debe almacenarse fuera de sitio (off-site). Esto significa que debe ubicarse en un lugar geográficamente distante de tu VPS principal. Si tu centro de datos principal sufre un desastre natural (incendio, inundación, terremoto) o un fallo masivo de energía, tu copia de seguridad local, almacenada en el mismo centro de datos, también se perderá. Almacenar una copia en otra región o incluso país garantiza que, incluso si el sitio principal es completamente destruido, podrás restaurar los datos.

Para implementar este punto, puedes utilizar otro VPS de Valebyte en un centro de datos diferente, almacenamiento en la nube o incluso un servidor físico en casa, si el volumen de datos lo permite.

¿Qué elementos específicos debes respaldar en tu VPS?

Antes de configurar un backup automático de VPS, es necesario definir claramente qué datos son críticamente importantes y deben ser respaldados. Errores en esta etapa pueden llevar a que la restauración sea incompleta o completamente inútil.

Archivos y configuraciones del sistema

Aunque el sistema operativo se puede reinstalar, la configuración manual de todos los servicios y archivos de configuración lleva mucho tiempo y es propensa a errores. Por lo tanto, es importante respaldar:

• Archivos de configuración de servicios: /etc/nginx/, /etc/apache2/, /etc/php/, /etc/ssh/, /etc/fail2ban/, /etc/systemd/, así como las configuraciones de VPN si las utilizas. Por ejemplo, para el backup automático de configuraciones de VPN existen particularidades.
• Configuraciones de usuario: /home/$USER/ (especialmente .bashrc, .profile, .ssh/ y otros archivos ocultos).
• Scripts y archivos ejecutables: /usr/local/bin/, /opt/, si allí se almacenan tus scripts o aplicaciones únicas.
• Lista de paquetes instalados: Aunque no son archivos, una lista de paquetes (por ejemplo, dpkg --get-selections para Debian/Ubuntu) ayudará a restaurar rápidamente el entorno.

Datos y aplicaciones de usuario

Esta es, por lo general, la parte más voluminosa y cambiante de los datos:

• Sitios web: /var/www/html/ u otros directorios donde se encuentran los archivos de tu sitio (CMS, archivos estáticos, medios subidos por los usuarios).
• Archivos de aplicaciones: Si tienes aplicaciones personalizadas, su código y datos.
• Subidas de usuarios: Todo lo que los usuarios suben a tu servidor.
• Registros (Logs): /var/log/. Aunque no es necesario respaldarlos constantemente, tener los de los últimos días puede ser útil para la depuración después de la restauración.

Bases de datos: el corazón de cualquier proyecto

Las bases de datos son, quizás, el componente más sensible de cualquier sistema. Su backup requiere un enfoque especial para garantizar la consistencia, especialmente bajo carga. Lo analizaremos con más detalle en una sección aparte, pero es importante recordar que la simple copia de los archivos de la base de datos (por ejemplo, /var/lib/mysql/) sin detener el SGBD o sin utilizar utilidades especiales casi siempre resulta en un backup inconsistente.

Cómo implementar un backup automático de VPS: Restic y Borg Backup

Para backups incrementales con deduplicación y cifrado, que son el estándar para el backup de servidores modernos, existen excelentes herramientas de código abierto. Entre ellas, destacan especialmente Restic y Borg Backup.

Restic: backups incrementales con deduplicación y cifrado

Restic es una herramienta moderna, rápida y segura para copias de seguridad. Soporta backups incrementales (copia solo las partes modificadas de los archivos), deduplicación de datos (no almacena bloques idénticos varias veces), cifrado de todos los datos y metadatos, así como múltiples backends para almacenamiento (disco local, SFTP, S3, Backblaze B2 y otros). Su facilidad de uso y alto rendimiento lo convierten en una excelente opción para el backup de VPS.

Comandos principales de Restic:

Inicialización del repositorio (una sola vez):

restic init --repo sftp:[email protected]:/path/to/repo

o para almacenamiento compatible con S3:

export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
restic init --repo s3:s3.amazonaws.com/your-bucket-name

Creación del backup:

restic backup /var/www/html /etc /home --repo sftp:[email protected]:/path/to/repo

Verificación de errores en el repositorio:

restic check --repo sftp:[email protected]:/path/to/repo

Limpieza de backups antiguos según una política (por ejemplo, los 7 últimos diarios, los 4 últimos semanales, los 12 últimos mensuales, 1 anual):

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 1 --prune --repo sftp:[email protected]:/path/to/repo

Puedes leer más detalles sobre la instalación y configuración de Restic en nuestro artículo Restic en VPS: instalación, configuración y mantenimiento.

Borg Backup: potencia y flexibilidad para el backup de servidores

Borg Backup (o simplemente Borg) es otra potente herramienta, similar a Restic, pero con una arquitectura y un conjunto de funciones ligeramente diferentes. También ofrece backups incrementales, deduplicación, compresión y cifrado. Borg destaca especialmente en el manejo de grandes volúmenes de datos y posee capacidades flexibles para la gestión de repositorios. A menudo se utiliza para el backup de servidores donde se requiere la máxima eficiencia en el uso del espacio en disco.

Comandos principales de Borg:

Inicialización del repositorio:

borg init --encryption=repokey-blake2 [email protected]:./repo

Creación del backup:

borg create --stats --compression lz4 [email protected]:./repo::"{hostname}-{now}" /var/www/html /etc /home

Lista de archivos:

borg list [email protected]:./repo

Limpieza de backups antiguos:

borg prune -v --list --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 1 [email protected]:./repo

Configuración de la programación con Cron

Para que el backup automático de VPS funcione regularmente, es necesario configurar un planificador de tareas. En Linux, para esto se utiliza con mayor frecuencia Cron. Abre crontab para editar:

crontab -e

Añade las líneas para el backup diario (por ejemplo, a las 3:00 de la mañana) y la limpieza semanal de archivos antiguos (por ejemplo, cada domingo a las 4:00):

0 3 * * * /usr/local/bin/backup_script.sh > /var/log/backup.log 2>&1
0 4 * * 0 /usr/local/bin/cleanup_backup_script.sh > /var/log/cleanup_backup.log 2>&1

No olvides crear los scripts ejecutables backup_script.sh y cleanup_backup_script.sh, que contendrán los comandos de Restic o Borg, así como la exportación de variables de entorno (por ejemplo, contraseñas para el repositorio, para no almacenarlas directamente en crontab). Asegúrate de proteger estos scripts y archivos con contraseñas del acceso no autorizado.

Backup consistente de bases de datos en el servidor: MySQL/PostgreSQL bajo carga

El backup de una base de datos en el servidor, especialmente una que está bajo carga constante, requiere una atención especial. La simple copia de los archivos de la base de datos puede llevar a un dump inconsistente que no podrá ser restaurado o contendrá datos corruptos.

Dumps de MySQL con mysqldump

Para MySQL, la forma más común y fiable de crear un dump consistente es la utilidad mysqldump. El parámetro clave para garantizar la consistencia bajo carga es --single-transaction. Este parámetro crea un dump que "ve" la base de datos en un momento determinado, incluso si se están produciendo cambios en ese momento. Esto se logra mediante el uso de transacciones y bloqueos a nivel de InnoDB.

mysqldump -u root -pYOUR_PASSWORD --single-transaction --databases db_name1 db_name2 > /path/to/backup/db_backup_$(date +%F).sql

Si quieres respaldar todas las bases de datos:

mysqldump -u root -pYOUR_PASSWORD --single-transaction --all-databases > /path/to/backup/all_db_backup_$(date +%F).sql

Después de crear el dump, este archivo .sql se puede comprimir (por ejemplo, con gzip) y añadir al repositorio de Restic o Borg.

mysqldump -u root -pYOUR_PASSWORD --single-transaction --all-databases | gzip > /path/to/backup/all_db_backup_$(date +%F).sql.gz

Backup de PostgreSQL con pg_dump

Para PostgreSQL se utiliza la utilidad pg_dump. También crea dumps consistentes, utilizando las capacidades de transacción de PostgreSQL. Por defecto, pg_dump funciona en un modo que garantiza la consistencia, por lo que no se requieren banderas adicionales como --single-transaction en MySQL.

pg_dump -U postgres db_name > /path/to/backup/pg_db_backup_$(date +%F).sql

Para el backup de todas las bases de datos:

pg_dumpall -U postgres > /path/to/backup/pg_all_db_backup_$(date +%F).sql

Al igual que con MySQL, se recomienda comprimir el archivo .sql resultante y luego incluirlo en el backup general de Restic/Borg.

pg_dump -U postgres db_name | gzip > /path/to/backup/pg_db_backup_$(date +%F).sql.gz

La importancia de la consistencia

Consistencia significa que los datos en el backup representan un conjunto de información lógicamente relacionado y completo, que puede ser restaurado y utilizado sin errores. Para las bases de datos, esto es críticamente importante: un dump inconsistente puede contener registros parciales, transacciones incompletas o índices dañados, lo que lo hará inútil. Utiliza siempre utilidades especializadas del SGBD para crear dumps, y no simplemente copiando los archivos de datos.

Almacenamiento y rotación de backups: ¿dónde y por cuánto tiempo?

La elección del lugar de almacenamiento y la política de rotación son aspectos clave en la implementación del esquema 3-2-1. Un almacenamiento adecuado garantiza la disponibilidad de los datos, y una rotación inteligente permite ahorrar espacio y tener puntos de restauración para diferentes períodos de tiempo.

Elección del lugar de almacenamiento: de S3 a otro VPS

Para almacenar copias de seguridad se pueden utilizar varias opciones, que cumplen con la regla de "dos tipos de medios diferentes y una copia fuera de sitio":

1. Otro VPS de Valebyte: Una excelente opción para implementar una copia off-site. Puedes alquilar un VPS económico con un gran volumen de disco HDD en otro centro de datos y configurar en él un servidor SFTP o un servidor Borg/Restic. Esto te da control total sobre los datos y la infraestructura. Sobre cómo elegir un servidor para almacenar datos, escribimos anteriormente.
2. Almacenamiento en la nube (compatible con S3): Muchos proveedores ofrecen almacenamientos compatibles con la API de Amazon S3 (por ejemplo, Backblaze B2, DigitalOcean Spaces, MinIO). Esta es una opción conveniente, escalable y relativamente económica para el almacenamiento off-site. Restic y Borg funcionan perfectamente con backends S3. También puedes considerar servicios de backup en la nube.
3. Servidor dedicado para backups (self-hosted backup target): Para grandes volúmenes de datos o requisitos de seguridad elevados, puedes alquilar un servidor dedicado para self-hosted backup target. Esto proporcionará el máximo rendimiento y control.
4. Disco local (para la primera copia): Se puede almacenar una copia del backup en el mismo VPS, pero en un volumen lógico o disco separado. Esto proporciona una rápida capacidad de restauración de archivos pequeños, pero no protege contra el fallo de todo el servidor. Importante: ¡esto no reemplaza una copia off-site!

Para almacenar copias de seguridad de hasta 500 GB, un VPS con 1 vCPU, 2 GB de RAM y un disco HDD de 500 GB es suficiente.

Volumen de datos para backup	vCPU	RAM	Disco	Puerto	Precio (aproximado, Valebyte)
Hasta 100 GB	1	1 GB	100 GB HDD	1 Gbps	desde $5/mes
Hasta 500 GB	1	2 GB	500 GB HDD	1 Gbps	desde $15/mes
Hasta 2 TB	2	4 GB	2 TB HDD	1 Gbps	desde $30/mes
Más de 2 TB (con deduplicación)	2-4	8 GB	4 TB HDD	1 Gbps	desde $50/mes

Política de rotación: Grandfather-Father-Son (GFS)

La política de rotación define cuántas versiones de backups se almacenan y por cuánto tiempo. Uno de los esquemas más populares y efectivos es Grandfather-Father-Son (GFS):

• Son (Diarios): Almacena los últimos 7-14 backups diarios. Esto permite restaurar a cualquier día de la última semana o dos.
• Father (Semanales): Almacena los últimos 4-8 backups semanales (generalmente el backup realizado el domingo). Esto permite volver al estado de los datos del último mes o dos.
• Grandfather (Mensuales/Anuales): Almacena los últimos 12 backups mensuales y varios anuales. Esto es útil para el almacenamiento a largo plazo de datos, auditorías o recuperación después de errores muy antiguos.

Herramientas como Restic y Borg tienen funciones integradas para implementar políticas similares a GFS mediante los comandos forget y prune.

Verificación del backup mediante restauración: simulacros regulares

Esta es la sección más importante del artículo. Como ya se mencionó, un backup que nunca ha sido restaurado no es un backup. La verificación regular de la funcionalidad de las copias de seguridad no es una opción, sino un requisito obligatorio para cualquier estrategia de backup fiable.

¿Por qué las verificaciones "en seco" no son suficientes?

Una verificación "en seco" (por ejemplo, restic check o borg check) confirma la integridad del repositorio de backups: que todos los bloques de datos están en su lugar, no están dañados y pueden ser descifrados. Este es un paso importante, pero no garantiza que a partir de esos datos se pueda construir un sistema funcional. La verificación no tiene en cuenta:

• La corrección de las rutas de los archivos después de la restauración.
• La consistencia de la base de datos, si no se realizó correctamente.
• La presencia de todos los archivos de configuración y dependencias necesarios.
• La funcionalidad de las aplicaciones después de la restauración.
• El tiempo necesario para una restauración completa.

Solo un despliegue completo del backup en un sistema limpio puede dar confianza en su funcionalidad.

Plan paso a paso para la restauración de prueba en un VPS limpio

Se recomienda realizar estos simulacros al menos una vez por trimestre. Para ello, necesitarás un VPS limpio, preferiblemente con una configuración similar a la del servidor principal, o con un sistema operativo parecido.

1. Preparación del VPS de prueba: Alquila un VPS nuevo y mínimo (por ejemplo, 1 vCPU, 2 GB de RAM, 20 GB de disco NVMe) por unas horas o días. Instala en él el mismo sistema operativo que en el servidor principal.
2. Instalación de las herramientas necesarias: Instala Restic o Borg, así como el SGBD (MySQL/PostgreSQL) y el servidor web (Nginx/Apache), si se utilizan.
3. Restauración de datos:
   • Conéctate al repositorio de backups.
   • Ejecuta el comando de restauración para los datos más recientes. Por ejemplo, para Restic:

     restic restore latest --target /tmp/restore --repo sftp:[email protected]:/path/to/repo

   • Descomprime e importa la base de datos:

     gunzip < /tmp/restore/path/to/db_backup.sql.gz | mysql -u root -pYOUR_PASSWORD restored_db_name

   • Copia los archivos restaurados a los directorios correspondientes (por ejemplo, /var/www/html/, /etc/).
4. Verificación de la funcionalidad:
   • Inicia todos los servicios (servidor web, SGBD, aplicaciones).
   • Verifica la disponibilidad del sitio web o API.
   • Intenta iniciar sesión en las aplicaciones, verifica la funcionalidad.
   • Asegúrate de que todas las configuraciones se aplicaron correctamente.
   • Verifica los registros en busca de errores.
5. Documentación: Documenta todo el proceso de restauración, incluyendo los comandos, el tiempo de ejecución y cualquier problema que haya surgido. Esta será tu "guía de supervivencia" en caso de una catástrofe real.
6. Destrucción del VPS de prueba: Después de una verificación exitosa, elimina el VPS de prueba para evitar gastos innecesarios y posibles vulnerabilidades.

Estos simulacros también pueden ayudarte a estimar el tiempo necesario para la restauración, lo cual es críticamente importante para la planificación del RTO (Recovery Time Objective).

Automatización de la verificación: ¿es posible?

Automatizar completamente la verificación del backup mediante restauración es complejo debido a numerosos matices (despliegue del SO, configuración de red, inicio de aplicaciones). Sin embargo, se puede automatizar parte del proceso:

• Scripts de despliegue: Utiliza Ansible, Docker u otras herramientas para desplegar rápidamente un entorno limpio e instalar dependencias en el VPS de prueba.
• Pruebas después de la restauración: Escribe scripts que verifiquen automáticamente la disponibilidad del servidor web, la funcionalidad de la base de datos (consultas simples) y la presencia de archivos clave.

Incluso una automatización parcial reducirá significativamente el tiempo y el esfuerzo necesarios para las verificaciones regulares. Esto también es útil para el backup y migración de 3x-ui a otro VPS.

Fallos comunes en el backup de VPS y cómo evitarlos

Incluso con una buena estrategia y herramientas, existen errores comunes que pueden anular todos los esfuerzos de copia de seguridad.

Disco lleno y .env olvidado

• Disco lleno: Uno de los problemas más frecuentes. Si el disco donde se almacenan los dumps temporales o el propio repositorio de backups se llena, los scripts de backup empiezan a fallar o a funcionar incorrectamente.
  • Solución: Monitorea regularmente el espacio libre en disco (por ejemplo, con Zabbix o Prometheus) y configura la rotación de backups con restic forget --prune o borg prune.
• .env u otras variables de entorno olvidadas: Muchas aplicaciones utilizan archivos .env para almacenar datos confidenciales (claves API, contraseñas de BD). Si solo haces backup del código de la aplicación, pero olvidas el .env, la aplicación no se iniciará después de la restauración.
  • Solución: Incluye todos los archivos de configuración críticamente importantes, incluido el .env, en la lista de directorios a respaldar. Asegúrate de que estén cifrados en el repositorio de backups.

Backup en el mismo servidor: falsa seguridad

Almacenar la única copia de backup en el mismo VPS que estás respaldando equivale a no tenerla. Si el servidor falla (problema de hardware, hackeo, eliminación), pierdes tanto los datos principales como su copia de seguridad.

• Solución: Ten siempre al menos una copia de backup fuera del servidor principal (off-site), como exige el esquema 3-2-1. Utiliza otro VPS, almacenamiento en la nube o un servidor dedicado para backups.

Clave de cifrado caducada o contraseña olvidada

El cifrado es excelente para la seguridad, pero solo si puedes descifrar los datos. Una contraseña/clave de cifrado perdida u olvidada hace que tus backups sean inútiles.

• Solución: Almacena la contraseña o clave de cifrado en un lugar seguro, separado del servidor (por ejemplo, en un gestor de contraseñas, en una unidad USB cifrada, impresa y guardada en una caja fuerte). Nunca la almacenes en el mismo servidor que los backups. Verifica regularmente la posibilidad de descifrar los datos, restaurando archivos pequeños.

Configuraciones y dependencias desactualizadas

Con el tiempo, las configuraciones del servidor cambian, aparecen nuevas versiones de software, se instalan nuevos paquetes. Si tu script de backup no se actualiza, puede omitir nuevos archivos importantes o respaldar configuraciones obsoletas.

• Solución: Revisa y actualiza regularmente los scripts de backup. Idealmente, utiliza sistemas de gestión de configuraciones (Ansible, Puppet, Chef) para incluir automáticamente nuevos directorios en el backup. Después de cada cambio significativo en el servidor (por ejemplo, la instalación de un nuevo servidor web o SGBD), realiza una restauración de prueba para asegurarte de que el nuevo componente se respalda y restaura correctamente.

Preguntas frecuentes

¿Qué volumen de disco se necesita para un backup de VPS?

El volumen de disco para un backup de VPS depende del tamaño de tus datos y de la política de rotación. Para un VPS con 100 GB de datos y el almacenamiento de 7 copias diarias, 4 semanales y 12 mensuales, considerando la deduplicación, podrías necesitar entre 150 GB y 300 GB de espacio en disco en un servidor remoto. Restic y Borg ahorran significativamente espacio gracias a la deduplicación, por lo que el volumen real será menor que la suma de todas las copias.

¿Con qué frecuencia se debe hacer un backup de la base de datos en el servidor?

La frecuencia del backup de la base de datos en el servidor se determina por tu RPO (Recovery Point Objective) — el volumen máximo tolerable de pérdida de datos. Para la mayoría de las aplicaciones web, se recomienda un backup diario, y para sistemas de alta carga con datos críticos, un backup cada hora o incluso continuo mediante replicación y archivado WAL. Por ejemplo, para una tienda online que procesa 1000 pedidos por hora, la pérdida de una hora de datos puede ser crítica.

¿Se puede usar Google Drive o Dropbox para almacenar backups?

Teóricamente sí, pero no es la mejor opción para un backup comercial de VPS. Las razones principales son: bajo rendimiento, falta de soporte directo para herramientas como Restic/Borg (requiriendo soluciones alternativas), y posibles problemas de confidencialidad de datos, ya que estos servicios no están diseñados para tales escenarios. Para uso profesional, es mejor elegir un almacenamiento compatible con S3 u otro VPS. Para necesidades personales y volúmenes pequeños (hasta 5 GB) podría ser aceptable.

¿Cuánto cuesta un VPS de prueba para verificar backups?

El coste de un VPS de prueba para verificar backups puede variar, pero suelen ser tarifas mínimas que se pueden alquilar por un corto período. En Valebyte, por ejemplo, un VPS básico con 1 vCPU, 2 GB de RAM y 20 GB de disco NVMe puede costar entre $5 y $10 al mes. Si lo alquilas solo por unas pocas horas para la verificación, los gastos totales serán mínimos, pero el beneficio de dicha verificación es incomparablemente mayor.

Conclusiones

Un backup de VPS fiable no es simplemente tener copias de datos, sino una estrategia completa que incluye el esquema 3-2-1, el uso de herramientas probadas como Restic o Borg, el backup consistente de bases de datos y, lo más importante, la verificación regular mediante restauración. Nunca confíes en un backup que nunca hayas desplegado en un servidor de prueba. Invierte tiempo y recursos en crear un sistema de copia de seguridad tolerante a fallos, y tu proyecto estará protegido contra la mayoría de los fallos inesperados.