Backups en VPS: la guía que nadie lee hasta que pierde sus datos

Por qué se pierden datos en un VPS (y el disco no es la causa principal)

Los datos se pierden por cuatro vías, y las estadísticas dicen que el fallo de hardware es la menos frecuente. Los discos duros modernos son muy fiables: según el informe Drive Stats 2025 de Backblaze, que analizó más de 344.000 discos en producción, la tasa anualizada de fallos fue del 1,36% en 2025 y del 1,30% considerando toda la vida de la flota. Eso significa que, en promedio, un disco de cada 74 falla en un año. Es un riesgo real, pero no es el que más te va a costar.

Estas son las cuatro causas ordenadas por lo que ocurre de verdad en el día a día:

• Error humano. Un rm -rf en el directorio equivocado, un DROP TABLE en producción creyendo que estabas en staging, un plugin que borra los adjuntos al desinstalarse, una migración que sobrescribe la tabla de pedidos. No hay antivirus contra esto: solo hay backups.
• Ransomware y compromisos de seguridad. Es la causa que más ha crecido y la que ataca directamente a tus copias. Según la investigación de Sophos sobre backups comprometidos, basada en una encuesta a 2.974 profesionales de TI, en el 94% de los ataques de ransomware los atacantes intentaron comprometer los backups, y lo consiguieron en el 57% de los casos. El Veeam Ransomware Trends Report 2025, con 1.300 organizaciones encuestadas, encontró que el 89% vio sus repositorios de backup atacados y que solo el 32% usaba repositorios inmutables.
• Fallo de hardware o del hipervisor. El disco NVMe del nodo, la controladora, el host físico completo. En infraestructura seria hay redundancia (RAID, replicación), pero la redundancia no es un backup: un RAID replica fielmente el archivo que acabas de borrar por error.
• Problemas con el proveedor. Una suspensión por impago, una disputa de facturación, una cuenta comprometida, un cierre del servicio. Tu servidor puede desaparecer sin que ningún disco haya fallado.

El dato más incómodo de la investigación de Sophos es económico: en las organizaciones cuyos backups fueron comprometidos, el coste mediano total de recuperación fue de 3 millones de dólares, frente a 375.000 dólares en las que conservaron sus copias intactas. Ocho veces más caro. A escala de una PyME los números son otros, pero la proporción se mantiene: la diferencia entre tener backups buenos y no tenerlos es la diferencia entre un mal día y un negocio cerrado.

El error más común: creer que el proveedor hace backups por ti

La suposición que más datos ha costado es esta: "mi proveedor de VPS ya hace copias". En la mayoría de los planes de VPS no gestionados, eso es falso o incompleto, y conviene saber exactamente en qué situación estás antes de necesitarlo.

Hay tres cosas que suelen confundirse:

• Un snapshot no es un backup. Un snapshot es una foto del disco virtual, guardada en la misma infraestructura del proveedor, y normalmente pensada para que puedas revertir una actualización que salió mal. Si el problema es la cuenta, el proveedor o la región, el snapshot desaparece con el servidor.
• La redundancia del almacenamiento no es un backup. Que tu VPS corra sobre almacenamiento replicado protege contra un disco roto, no contra un DELETE FROM pedidos sin WHERE. La replicación copia el error a la velocidad de la red.
• Un backup que nadie ha restaurado no cuenta como backup. Esto vale para las copias del proveedor tanto como para las tuyas. Si nunca has pedido una restauración, no sabes cuánto tarda, si incluye la base de datos ni si el archivo está completo.

Las preguntas concretas que hay que hacerle al proveedor, y cuya respuesta conviene tener por escrito, son: ¿hay backups incluidos en mi plan?, ¿con qué frecuencia se toman?, ¿cuántos días se retienen?, ¿puedo restaurar un archivo suelto o solo el servidor completo?, ¿cuánto tarda una restauración?, ¿la copia está en una infraestructura distinta a la del servidor? Si alguna respuesta es "no lo sé", asume que la responsabilidad es tuya y sigue leyendo.

En Terranode los VPS son de acceso root completo sobre virtualización KVM, pensados para que administres tu entorno como quieras. Si prefieres no montar tú el sistema de copias, nuestro equipo puede ayudarte a configurar backups externos hacia otro servidor o hacia almacenamiento de objetos; escríbenos desde la página de VPS.

La estrategia 3-2-1 aplicada a backups en VPS

La regla 3-2-1 dice: 3 copias de los datos, en 2 medios o sistemas distintos, con 1 copia fuera del servidor original. Se atribuye al fotógrafo Peter Krogh, que la formuló en su libro The DAM Book para proteger archivos fotográficos, y hoy es el estándar de facto en protección de datos. Aplicada a backups en VPS, se traduce en algo muy concreto:

La copia local es la que usarás el 90% de las veces, porque el 90% de los incidentes son "borré algo que no debía". La copia remota es la que salva el negocio el 10% restante. Las dos son necesarias y cuestan cosas distintas: la local ocupa disco de tu VPS, la remota ocupa dinero (muy poco) y ancho de banda.

La versión actualizada de la regla se llama 3-2-1-1-0: añade 1 copia inmutable o desconectada —que ni siquiera tú puedas borrar durante un periodo determinado— y 0 errores en las pruebas de restauración. Los dos añadidos responden directamente al ransomware: si el atacante entra con tus credenciales y las copias son borrables, no tienes backups, tienes archivos que el atacante también controla. En almacenamiento de objetos, la inmutabilidad se activa con Object Lock (bloqueo de objetos), que impide eliminar o modificar un archivo hasta que venza el plazo definido.

Qué respaldar primero: no todo vale lo mismo

Prioriza siempre en este orden: base de datos, archivos subidos por usuarios, configuración y secretos, y en último lugar el código. La razón es simple: el código se puede volver a desplegar desde Git en minutos; una base de datos perdida no se recupera de ninguna parte.

Dos exclusiones que ahorran mucho espacio y tiempo: no respaldes cachés ni dependencias reinstalables. node_modules, vendor de Composer, la carpeta de caché de tu framework y los logs rotados pueden ocupar más que todo lo demás junto y se regeneran con un comando. Excluirlos suele reducir el tamaño del backup a la mitad.

Y una inclusión que casi todos olvidan: el archivo .env y la lista de tareas de cron. Es frecuente restaurar un sitio completo y descubrir que nadie recuerda cuál era la clave de la pasarela de pago ni a qué hora corría el proceso de facturación.

Herramientas: rsync, restic y Borg comparadas

Para backups en un VPS Linux hay tres herramientas que cubren prácticamente todos los casos: rsync (sincronización simple), restic (snapshots cifrados y deduplicados hacia la nube) y BorgBackup (snapshots cifrados con compresión agresiva hacia SSH). Las tres son software libre y gratuito; lo que cambia es dónde guardan los datos y qué protección ofrecen.

La recomendación práctica: rsync para la copia local dentro del propio VPS (rápida y sin dependencias) y restic hacia Backblaze B2 o similar para la copia remota, porque es el que mejor combina cifrado, deduplicación y compatibilidad con almacenamiento barato. Si tu copia remota va a otro servidor Linux tuyo y quieres la máxima resistencia a ransomware, Borg en modo append-only es superior: con una clave SSH restringida, el servidor de origen puede añadir archivos pero no borrar el historial, así que un atacante que tome el VPS no puede destruir las copias anteriores.

Si vienes de rsync y quieres profundizar en sus opciones, rotación y modo simulación, lo cubrimos en detalle en la guía de backups automáticos en Linux con rsync y cron.

Paso a paso: backup diario con rsync a un segundo VPS

Este es el montaje más simple que cumple la regla 3-2-1: un script genera la copia local, y rsync la envía por SSH a un segundo servidor. Sirve perfectamente un VPS pequeño usado solo como almacén: solo necesita disco y acceso SSH.

Paso 1. Crear la clave SSH sin contraseña para que la tarea automática pueda conectarse sin intervención humana.

# En el servidor de origen, como el usuario que ejecutará el backup
ssh-keygen -t ed25519 -C "backup-vps-origen" -f ~/.ssh/id_backup -N ""
ssh-copy-id -i ~/.ssh/id_backup.pub backup@IP_DEL_DESTINO
ssh -i ~/.ssh/id_backup backup@IP_DEL_DESTINO 'echo conexion OK'

Paso 2. Restringir esa clave en el destino. Una clave sin contraseña que da acceso completo es un riesgo: si comprometen el origen, entran al almacén. En el servidor de destino, edita ~/.ssh/authorized_keys y antepón restricciones a la clave:

# En el DESTINO, en ~/.ssh/authorized_keys, antes de "ssh-ed25519 AAAA..."
from="IP_DEL_ORIGEN",no-agent-forwarding,no-port-forwarding,no-pty ssh-ed25519 AAAA...

Paso 3. El script de backup. Guárdalo en /usr/local/bin/backup-rsync.sh y dale permisos con chmod 700.

#!/usr/bin/env bash
# Backup diario: copia local + envío a servidor remoto por SSH
set -Eeuo pipefail

ORIGEN="/var/www"
LOCAL="/var/backups/sitio"
REMOTO="backup@IP_DEL_DESTINO:/backups/vps-produccion/"
LLAVE="/root/.ssh/id_backup"
LOG="/var/log/backup-rsync.log"
FECHA=$(date +%F)

log() { echo "[$(date '+%F %T')] $*" >> "$LOG"; }

log "=== Inicio del backup ==="

# 1) Copia local con historial: lo que cambia o se borra se mueve a old/FECHA
mkdir -p "$LOCAL/actual" "$LOCAL/old/$FECHA"
rsync -a --delete \
  --backup --backup-dir="$LOCAL/old/$FECHA" \
  --exclude='node_modules/' --exclude='vendor/' \
  --exclude='*.log' --exclude='cache/' \
  "$ORIGEN/" "$LOCAL/actual/" >> "$LOG" 2>&1
log "Copia local completada"

# 2) Envío al servidor remoto
rsync -az --delete \
  -e "ssh -i $LLAVE -o StrictHostKeyChecking=yes" \
  "$LOCAL/" "$REMOTO" >> "$LOG" 2>&1
log "Envío remoto completado"

# 3) Borrar historial local de más de 14 días
find "$LOCAL/old" -maxdepth 1 -type d -mtime +14 -exec rm -rf {} + 2>/dev/null || true
log "=== Backup finalizado con exito ==="

La primera línea de control, set -Eeuo pipefail, es la que convierte esto en un script serio: hace que el script se detenga en el primer error en vez de continuar y reportar éxito. Sin ella, si el rsync remoto falla, el script sigue, borra el historial antiguo y termina en silencio.

El par --backup --backup-dir es lo que impide que este montaje sea un simple espejo: los archivos que cambian o se borran no desaparecen, se mueven a una carpeta con la fecha del día. Ahí está el historial de 14 días que te permite recuperar el archivo que alguien borró el jueves pasado.

Paso a paso: backup cifrado con restic a Backblaze B2

Restic es la opción recomendada para la copia remota porque cifra con AES-256 antes de subir nada, deduplica a nivel de bloque —solo almacena los fragmentos nuevos de cada día— y gestiona el historial y la caducidad de las copias por sí solo. La versión estable actual es la 0.19.1, publicada el 5 de julio de 2026.

Paso 1. Instalar restic.

sudo apt update && sudo apt install restic -y
restic version

Paso 2. Crear el bucket y la clave de aplicación en Backblaze B2. En el panel de B2, crea un bucket privado (por ejemplo backups-vps-empresa) y una Application Key limitada a ese bucket. Anota el keyID y el applicationKey: la clave solo se muestra una vez. Si el bucket va a ser tu única copia remota, activa Object Lock para que las copias no se puedan borrar durante el plazo que definas.

Paso 3. Guardar las credenciales en un archivo protegido, nunca dentro del script ni en la línea de comandos, donde quedarían visibles para cualquiera que liste los procesos.

sudo mkdir -p /etc/restic
sudo tee /etc/restic/b2.env > /dev/null <<'EOF'
export B2_ACCOUNT_ID="tu_keyID"
export B2_ACCOUNT_KEY="tu_applicationKey"
export RESTIC_REPOSITORY="b2:backups-vps-empresa:vps-produccion"
export RESTIC_PASSWORD="una-frase-larga-y-unica-para-cifrar-el-repositorio"
EOF
sudo chmod 600 /etc/restic/b2.env

La RESTIC_PASSWORD es la llave del cifrado. Si la pierdes, el backup es inservible: no hay recuperación posible. Guárdala en un gestor de contraseñas y en un segundo lugar fuera del servidor. Es el único error de esta guía que no tiene arreglo.

Paso 4. Inicializar el repositorio (solo una vez).

source /etc/restic/b2.env
restic init

Paso 5. El script completo, en /usr/local/bin/backup-restic.sh con chmod 700. Este hace las tres cosas: volcar las bases de datos, subir el snapshot cifrado y aplicar la política de retención.

#!/usr/bin/env bash
# Backup cifrado a Backblaze B2 con restic: base de datos + archivos
set -Eeuo pipefail

source /etc/restic/b2.env

VOLCADOS="/var/backups/db"
LOG="/var/log/backup-restic.log"
exec >> "$LOG" 2>&1

echo "[$(date '+%F %T')] === Inicio ==="

# 1) Volcar las bases de datos a archivos comprimidos
mkdir -p "$VOLCADOS"
mysqldump --defaults-file=/root/.my.cnf --single-transaction --quick \
  --all-databases | gzip > "$VOLCADOS/mysql-$(date +%F).sql.gz"

# 2) Subir el snapshot: archivos web + volcados + configuración
restic backup \
  /var/www \
  "$VOLCADOS" \
  /etc/nginx \
  /etc/letsencrypt \
  --exclude='node_modules' \
  --exclude='vendor' \
  --exclude='*.log' \
  --exclude-caches \
  --tag diario

# 3) Retención: 7 diarios, 4 semanales, 6 mensuales. Borra el resto
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

# 4) Verificación rápida de la estructura del repositorio
restic check

# 5) Limpiar volcados locales de mas de 3 dias
find "$VOLCADOS" -name '*.sql.gz' -mtime +3 -delete

echo "[$(date '+%F %T')] === Fin correcto ==="

La política --keep-daily 7 --keep-weekly 4 --keep-monthly 6 conserva 17 puntos de restauración repartidos en seis meses, ocupando muchísimo menos que 17 copias completas: gracias a la deduplicación, cada snapshot solo añade los bloques que cambiaron ese día.

Para restaurar, el proceso es igual de directo:

source /etc/restic/b2.env
restic snapshots                                    # lista los puntos disponibles
restic restore latest --target /tmp/restauracion    # restaura el más reciente
restic restore a1b2c3d4 --target / --include /var/www/sitio  # una ruta concreta

Backups de MySQL y PostgreSQL: hazlo con volcados, no copiando archivos

Nunca respaldes una base de datos copiando sus archivos de datos con el servicio encendido. Copiar /var/lib/mysql mientras MySQL está escribiendo produce un respaldo inconsistente que puede negarse a restaurar justo el día que lo necesitas. La forma correcta es generar un volcado (dump): un archivo de texto con las instrucciones SQL necesarias para reconstruir la base entera.

MySQL y MariaDB:

# Volcado de todas las bases, sin bloquear tablas InnoDB, comprimido
mysqldump --defaults-file=/root/.my.cnf --single-transaction --quick \
  --routines --triggers --events --all-databases \
  | gzip > /var/backups/db/mysql-$(date +%F).sql.gz

# Restauración
gunzip < /var/backups/db/mysql-2026-10-09.sql.gz | mysql

--single-transaction genera una foto coherente sin bloquear el sitio mientras corre. --routines --triggers --events incluye procedimientos, disparadores y eventos programados, que el volcado por defecto no incluye y cuya ausencia se descubre siempre en el peor momento.

Las credenciales van en /root/.my.cnf con permisos 600, no en la línea de comandos:

sudo tee /root/.my.cnf > /dev/null <<'EOF'
[client]
user=root
password=tu_contraseña
EOF
sudo chmod 600 /root/.my.cnf

PostgreSQL:

# Una base concreta, en formato comprimido propio de Postgres
sudo -u postgres pg_dump -Fc miapp > /var/backups/db/miapp-$(date +%F).dump

# Todo el clúster, incluidos roles y permisos
sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-todo-$(date +%F).sql.gz

# Restauración del formato -Fc, con paralelismo
sudo -u postgres pg_restore -d miapp -j 4 /var/backups/db/miapp-2026-10-09.dump

El formato -Fc de pg_dump es preferible al SQL plano porque permite restaurar tablas sueltas y restaurar en paralelo con -j. Y pg_dumpall es necesario al menos una vez a la semana: pg_dump no guarda los roles ni las contraseñas de los usuarios de la base. Si quieres repasar los fundamentos del motor, tenemos una introducción a qué es MySQL y para qué sirve.

Cómo programar los backups con cron

Cron es el programador de tareas de Linux: ejecuta comandos a la hora que le indiques sin que nadie tenga que estar delante. Se edita con crontab -e y cada línea tiene cinco campos —minuto, hora, día del mes, mes, día de la semana— seguidos del comando.

sudo crontab -e

# ┌ minuto  ┌ hora  ┌ día del mes  ┌ mes  ┌ día de la semana (0=domingo)
# │         │       │              │      │
# Volcado de base de datos cada 6 horas
0 */6 * * * /usr/local/bin/volcado-db.sh

# Backup completo cifrado a B2, todos los días a las 03:15
15 3 * * * /usr/local/bin/backup-restic.sh

# Copia local con rsync, todos los días a las 02:00
0 2 * * * /usr/local/bin/backup-rsync.sh

# Verificación profunda del repositorio, los domingos a las 04:00
0 4 * * 0 /usr/local/bin/verificar-backup.sh

Tres detalles que marcan la diferencia entre un cron que funciona y uno que parece funcionar:

• Redirige la salida a un log con 2>&1. Cron envía la salida por correo local, que en un VPS recién instalado nadie lee. Sin 2>&1, los mensajes de error no llegan al archivo y un backup que falla cada noche parece exitoso. En los scripts de esta guía ya está resuelto con exec >> "$LOG" 2>&1.
• Usa rutas absolutas siempre. Cron corre con un PATH mínimo y sin las variables de tu sesión. Un script que funciona a mano y falla en cron casi siempre es esto.
• Evita que dos ejecuciones se solapen con flock. Si el backup de anoche todavía está subiendo cuando arranca el de hoy, tendrás dos procesos peleando por el repositorio:

15 3 * * * /usr/bin/flock -n /tmp/backup.lock /usr/local/bin/backup-restic.sh

Y la pieza que casi nadie pone: una alerta cuando el backup deja de correr. Un servicio de "dead man's switch" como Healthchecks.io te avisa si el ping no llega. Basta añadir una línea al final del script:

curl -fsS -m 10 --retry 3 https://hc-ping.com/TU-UUID > /dev/null

Si el script falla antes de llegar ahí —gracias a set -e— el ping no se envía y recibes el aviso. Es la diferencia entre enterarte hoy y enterarte el día del desastre.

Lo más importante: verificar que el backup funciona

Un backup que nunca se ha restaurado no es un backup: es una suposición con nombre de archivo. Esta es la parte que casi todo el mundo se salta, y es exactamente la que decide si el incidente dura una hora o termina el negocio. La prueba se hace una vez al mes, con calendario, y toma entre 15 y 30 minutos.

Verificación automática semanal (que corre sola y solo cuesta ancho de banda):

#!/usr/bin/env bash
# /usr/local/bin/verificar-backup.sh
set -Eeuo pipefail
source /etc/restic/b2.env

# 1) ¿Existe un snapshot de las últimas 26 horas?
ULTIMO=$(restic snapshots --json --latest 1 | grep -o '"time":"[^"]*"' | head -1)
echo "Último snapshot: $ULTIMO"

# 2) Verificar integridad estructural + leer el 10% de los datos reales
restic check --read-data-subset=10%

# 3) Restaurar un archivo conocido y comprobar que existe
restic restore latest --target /tmp/verificacion --include /etc/nginx/nginx.conf
test -s /tmp/verificacion/etc/nginx/nginx.conf && echo "Restauración OK"
rm -rf /tmp/verificacion

La opción --read-data-subset=10% es la clave: restic divide el repositorio en partes y descarga y verifica solo una fracción, comprobando que los datos almacenados no se han corrompido. Ejecutándolo cada semana, en diez semanas has verificado el repositorio completo sin descargarlo entero de una vez.

Prueba de restauración completa, una vez al mes. Lo anterior comprueba que los datos están íntegros; esto comprueba que el sitio vuelve a funcionar con ellos. El procedimiento:

1. 1 Levanta un VPS temporal o un contenedor limpio, con la misma versión del sistema operativo.
2. 2 Restaura el snapshot más reciente completo con restic restore latest --target /.
3. 3 Importa el volcado de la base de datos y arranca los servicios.
4. 4 Abre el sitio y comprueba datos concretos: que aparezca el último pedido, que las imágenes carguen, que se pueda iniciar sesión.
5. 5 Cronometra el proceso completo. Ese número es tu tiempo objetivo de recuperación (RTO), y es el dato que de verdad importa: no cuánto ocupa el backup, sino cuántas horas tardas en volver a estar en línea.
6. 6 Anota la fecha, quién la hizo, cuánto tardó y qué falló. La segunda prueba siempre es más rápida que la primera.

Dos conceptos que conviene tener claros y que rara vez se definen: el RPO (Recovery Point Objective, objetivo de punto de recuperación) es cuántos datos puedes permitirte perder, medido en tiempo —si respaldas cada 24 horas, tu RPO es de 24 horas—. El RTO (Recovery Time Objective, tiempo objetivo de recuperación) es cuánto puedes tardar en volver a funcionar. Definir estos dos números antes de diseñar el sistema evita tanto quedarse corto como gastar de más.

Y una regla que se aprende por las malas: los backups deben poder restaurarse sin el servidor original. Si tus notas de restauración, tus claves SSH y la contraseña de restic solo existen dentro del VPS que acaba de morir, no tienes un backup. Guarda el procedimiento y las credenciales fuera: en un gestor de contraseñas, en un documento compartido, en papel dentro de un sobre. Donde sea, menos ahí.

Cuánto espacio necesitas y cuánto cuesta

Para un VPS típico, los backups cuestan menos de lo que gastas en café. La cifra clave es que un repositorio deduplicado con un mes de historial suele ocupar entre 1,5 y 3 veces el tamaño de los datos originales, no 30 veces, porque solo se almacenan los bloques que cambian cada día.

Una estimación práctica para un VPS con 40 GB de datos reales (sitio web, uploads y base de datos), guardando 7 copias diarias, 4 semanales y 6 mensuales con restic:

Los precios de B2, Wasabi y S3 proceden de las páginas oficiales de cada proveedor y son los vigentes en septiembre de 2026; conviene confirmarlos antes de contratar. El precio del VPS corresponde al plan de entrada de Terranode, con 1 vCPU, 1 GB de RAM y 25 GB de disco NVMe.

La conclusión económica es contundente: guardar seis meses de historial de un VPS mediano cuesta menos de un dólar al mes en almacenamiento de objetos. Comparado con el coste de reconstruir una base de datos de clientes desde cero, o de simplemente no poder hacerlo, no hay discusión posible. La barrera nunca fue el precio: fue la hora que hay que dedicar a configurarlo.

Una nota honesta sobre lo que no necesitas: si tu VPS aloja un sitio estático generado desde un repositorio Git, sin base de datos ni contenido subido por usuarios, no necesitas montar nada de esto. Tu backup es el repositorio y tu restauración es un git clone seguido de un despliegue. Añadir restic y B2 ahí solo agrega complejidad. Los backups son proporcionales al dato irremplazable que tengas: si no lo hay, no hay problema que resolver.