Copias de seguridad cifradas fuera de sitio: 3-2-1 en tu propio VPS offshore

Una instantánea no es una copia de seguridad

La instantánea de tu panel es algo genuinamente útil, y deberías tomar una antes de cualquier cambio arriesgado. También es cierto que no es una copia de seguridad, y la diferencia no es un capricho pedante —es la lista entera de situaciones que estás intentando sobrevivir. Una instantánea vive en el mismo host, dentro de la misma cuenta, detrás de las mismas credenciales que la máquina a la que protege. Responde bien a una sola pregunta: ¿cómo deshago los últimos veinte minutos? No responde a ninguna de las demás. Si la cuenta desaparece, la instantánea desaparece con ella. Si la región queda inalcanzable, también lo queda la reversión. Si un intruso llega al panel, también llega a las instantáneas. Y si los datos ya estaban corruptos en el momento de tomar la instantánea, has preservado esa corrupción con una fidelidad admirable.

Lo mismo se aplica a las dos cosas que la gente más a menudo confunde con copias de seguridad. RAID no es una copia de seguridad: protege frente a la muerte de un disco, y replica un rm -rf hacia el espejo a máxima velocidad. La replicación no es una copia de seguridad por el mismo motivo —está diseñada para que la segunda copia sea idéntica a la primera lo más rápido posible, incluso cuando la primera copia acaba de ser destruida. En un proveedor no-KYC, la rama de la cuenta en esa lista es más afilada que en cualquier otro sitio: el registro es un nombre de usuario, una contraseña y ocho códigos de recuperación, sin ningún correo electrónico ni documento en ningún punto del proceso, así que no hay ninguna vía de soporte a la que acudir si los pierdes. Eso es el producto funcionando tal como está diseñado. También significa que la copia que de verdad importa es la que no se puede alcanzar desde las credenciales que podrías perder.

3-2-1, reescrita para un servidor que nadie puede identificar

La regla clásica sigue siendo válida: tres copias de todo lo que te importa, en dos sistemas distintos, con una de ellas fuera de sitio. La extensión moderna que la gente escribe como 3-2-1-1-0 añade las dos cláusulas que más importan en 2026 —una copia que sea inmutable o esté offline, y cero errores al verificar. Trasladado a un solo servidor, se lee así: la copia uno son los datos en vivo; la copia dos es la instantánea del lado del proveedor o el complemento de copias de seguridad cifradas diarias, que resuelve el típico error de las dos de la madrugada sin ningún esfuerzo por tu parte; la copia tres es un repositorio cifrado en una segunda máquina, en una región distinta, que la primera máquina no tiene ninguna autoridad para borrar. Solo la tercera copia sobrevive a la pérdida de la cuenta de la primera máquina, y solo la tercera copia es tuya en el sentido de que a nadie más se le puede obligar a entregarla.

Sé deliberado con lo que significa "fuera de sitio". Otro rack en el mismo edificio no está fuera de sitio en ningún sentido que importe, y otra región bajo la misma ley solo es la mitad del camino —un único instrumento legal que alcanza una máquina no debería alcanzar automáticamente a las dos. Con 6 regiones donde elegir, esa es una decisión que tomas una vez en el momento del despliegue y no vuelves a revisar. Vale la pena decirlo con claridad, eso sí: dos servidores aquí siguen siendo dos servidores en un solo proveedor, lo cual es un riesgo correlacionado por buena que sea la separación. Si tu modelo de amenazas incluye de verdad perdernos a nosotros, la tercera copia pertenece a un lugar completamente distinto —una máquina en casa, el rack de un amigo, un proveedor distinto en otro continente. Todo en esta guía funciona de forma idéntica sin importar dónde viva el destino; lo único que cambia es la dirección de una variable de entorno.

Cifra antes de que salga de la máquina

El destino debería ser un lugar que almacene bytes que no puede leer. Eso no es una política que aceptas de un proveedor, es una propiedad que tú construyes: los datos se fragmentan en chunks, se comprimen, se cifran y se autentican en el origen, y lo que viaja por la red ya llega opaco. Los modos repokey y keyfile de Borg cifran cada chunk con AES-256 en modo contador y lo autentican, y las variantes -blake2 cambian HMAC-SHA256 por BLAKE2b, que es mensurablemente más rápido en las CPU de 64 bits actuales. El contenido de los ficheros, sus nombres, y el manifiesto del archivo que los enumera quedan todos cifrados; el destino solo guarda ficheros de segmento numerados y un índice que no puede interpretar. restic te da la misma forma con una fontanería distinta. En cualquier caso, el modelo mental correcto es que estás alquilando espacio en disco, no confianza.

Dos salvedades honestas. Primero, lo que sigue filtrándose: quien controle el disco de destino puede ver cuántos datos llegan y cuándo llegan. El tamaño del repositorio y el momento de las escrituras son visibles aunque el contenido no lo sea, algo irrelevante para la mayoría de la gente y no tan irrelevante para unos pocos. Segundo, el cifrado en reposo en el destino —LUKS en la máquina de copias de seguridad— defiende contra el disco saliendo del edificio, no contra el host en ejecución, así que complementa el cifrado en el cliente en lugar de sustituirlo. Y luego está la parte que hunde a la gente: con repokey el material de la clave vive dentro del repositorio, envuelto por tu frase de contraseña, así que perder el repositorio también pierde la clave; con keyfile vive solo en el origen, así que perder el origen pierde todos los archivos que hayas hecho jamás. Ninguno de los dos es seguro hasta que hayas exportado la clave y hayas puesto esa exportación en algún sitio que no sea ninguna de las dos máquinas. Haz eso en el paso tres, no "más tarde".

Borg, restic, rclone: elige uno y sabe por qué

Aquí hay dos herramientas que son respuestas correctas, y la elección depende de verdad del destino. Borg hace deduplicación a nivel de chunk, compresión y cifrado autenticado, y —el motivo por el que es el ejemplo desarrollado más abajo— trae de serie un auténtico modo append-only del lado del servidor, que consigues gratis sobre SSH normal y corriente, sin ningún daemon que ejecutar ni ningún puerto extra que abrir. Necesita tener borg instalado en ambos extremos y habla su propio protocolo. restic ofrece las mismas garantías siendo agnóstico respecto al backend: SFTP, almacenamiento de objetos compatible con S3, Backblaze B2, o su propio rest-server. En un destino SFTP normal no hace falta instalar nada, lo cual es cómodo, pero entonces el append-only depende de rest-server --append-only o de una política del bucket en lugar de depender de una restricción SSH. Regla general: Borg cuando el destino es un servidor que controlas, restic cuando es almacenamiento de objetos o cuando quieres una sola herramienta para muchos backends distintos.

Qué no usar, porque es la forma más habitual en que esto sale mal. rclone es una herramienta de sincronización. Su remoto crypt sí te da cifrado en el cliente, pero una sincronización propaga los borrados —el fichero que perdiste a las 03:00 se elimina fielmente del destino a las 03:15, que es exactamente el fallo que intentabas sobrevivir. Es excelente para empujar un repositorio ya terminado de Borg o restic hacia una tercera ubicación; no es una copia de seguridad. La misma objeción se aplica a un simple rsync --delete en cron, que es un espejo disfrazado de copia de seguridad. Un tar | gpg hacia una ruta remota sí es una copia de seguridad real, pero sin deduplicación, sin lógica de retención, y con una restauración que obliga a recorrer toda una cadena de incrementos para recuperar un solo fichero. Usa las herramientas diseñadas para esto; vienen empaquetadas en cualquier distribución mencionada en esta guía.

Append-only, o el intruso también borra tus copias de seguridad

He aquí el escenario que separa un sistema de copias de seguridad de un simple script de copias de seguridad. Alguien consigue root en tu máquina de producción —a través de la aplicación, de una dependencia, de una clave filtrada, da igual cómo. Lo primero que hace un ransomware competente, y lo primero que hace un humano competente, es buscar las copias de seguridad, porque una víctima con copias de seguridad que funcionan no paga y no entra en pánico. Tu tarea nocturna se ejecuta sin supervisión, así que sus credenciales están necesariamente en esa misma máquina. Si la tarea puede borrar archivos, el intruso puede borrar archivos, y te enteras justo en el momento en que los necesitas. Este no es un modo de fallo hipotético; es el normal.

El arreglo es pequeño y es la línea más importante de toda esta guía. En el destino, ata la clave automatizada a un único comando dentro de authorized_keys: command="borg serve --append-only --restrict-to-path /srv/borg",restrict. Esa clave ahora solo puede hacer exactamente una cosa —añadir datos a un repositorio bajo una ruta concreta. No puede conseguir una shell, no puede reenviar un puerto, no puede listar tu sistema de ficheros, y no puede borrar ni un solo archivo. La palabra clave restrict (OpenSSH 7.2 y posteriores) desactiva la asignación de pty y todo tipo de reenvío en una sola palabra, así que la restricción no se degrada a medida que se añaden opciones nuevas. Ahora la salvedad honesta que la mayoría de los tutoriales se saltan: mientras el append-only está en vigor, borg prune y borg compact parecen tener éxito pero en realidad no liberan nada —el borrado queda registrado en una transacción que la siguiente sesión append-only revierte. Por eso la retención necesita una segunda clave, sin restricciones, que uses a mano desde tu portátil y que nunca guardes en el origen. Dos claves, dos tareas: la nocturna solo puede escribir; la de mantenimiento puede borrar y vive en un sitio al que la máquina comprometida no puede llegar. Guarda esa clave a mano también para otro propósito —una tarea que muere a mitad de ejecución deja un bloqueo obsoleto, y borg break-lock es una escritura.

Dónde debería vivir la segunda copia

Las copias de seguridad son la única carga de trabajo en la que la latencia no importa, así que ignora el instinto habitual de poner la máquina cerca de tus usuarios y elige en función de la ley y la independencia en su lugar. Un país distinto al de producción es el mínimo; una familia legal distinta es mejor todavía. Cada una de nuestras regiones responde a una pregunta diferente —Rumanía es el buque insignia, donde los avisos DMCA sencillamente no se procesan; Suiza queda fuera de la UE, tras estatutos de protección de datos inusualmente estrictos; Islandia tiene el marco IMMI; Panamá no tiene ninguna ley de retención de datos obligatoria ni ningún carril rápido para peticiones extranjeras; Malasia deja una copia completamente fuera del alcance de Five Eyes; y los Países Bajos son el centro de peering. ¿Qué ubicación offshore deberías elegir? repasa estos compromisos como es debido; para un destino de copias de seguridad, la respuesta suele ser "donde sea que no esté producción". Los puertos no tienen límite de tráfico en ningún plan, así que la primera subida completa está limitada por la velocidad a la que el origen puede leer su propio disco, no por una cuota de transferencia que tengas que racionar.

El dimensionamiento es menos dramático de lo que la gente espera. La deduplicación más zstd hace que el repositorio sea normalmente una fracción del origen, y después de la primera ejecución solo cruzan la red los chunks que han cambiado —un servidor ajetreado de 40 GB con una tasa de cambio normal se estabiliza en unos pocos cientos de megabytes por noche, así que un año de archivos diarios cuesta mucho menos disco de lo que costaría un año de tarballs diarios. El plan más pequeño de la gama es un destino perfectamente válido; sube de plan solo si estás conservando un historial profundo de algo genuinamente grande, y consulta las especificaciones exactas en la página de planes en lugar de fiarte de una cifra escrita en una guía, donde acabaría quedando desactualizada. Una regla sobre la máquina en sí: no le des nada más que hacer. Sin servidor web, sin base de datos, sin ningún servicio público salvo SSH con clave. Un destino de copias de seguridad que además aloja un proyecto paralelo es un destino de copias de seguridad con la superficie de ataque de ese proyecto paralelo, y debería recibir el tratamiento completo de la primera hora antes de recibir un solo archivo.

Una copia de seguridad que no has restaurado es un rumor

Los sistemas de copias de seguridad rara vez fallan de forma ruidosa. Fallan porque un patrón de exclusión se tragó en silencio el directorio de datos, o porque una base de datos se copió fichero a fichero mientras había escrituras en curso y el volcado restaura en una tabla corrupta, o porque el temporizador lleva seis semanas fallando detrás de una actualización de la distribución y nadie lee el buzón de correo del sistema. La única prueba que detecta cualquiera de estos casos es una restauración. Hazla con regularidad: elige un archivo al azar, extráelo en un directorio temporal, compara con diff un puñado de ficheros contra producción, arranca la base de datos desde el volcado y ejecuta una consulta, y anota cuánto ha tardado todo el proceso. Ese número es tu tiempo de recuperación real —no el que suponías— y es la única cifra que merece la pena recitarte a ti mismo a las tres de la madrugada. Al menos una vez, haz el simulacro desde una máquina en blanco, porque ese es el escenario real: un VPS recién creado, una frase de contraseña de tu gestor de contraseñas, una clave exportada de dondequiera que la guardaras, y nada más.

La monitorización merece el mismo escepticismo que has aplicado al resto de la pila. El consejo estándar es un interruptor de hombre muerto de un tercero, al que tu tarea hace ping cuando tiene éxito, y que de paso le cuenta calladamente a un servicio externo tus nombres de host, tu calendario y cuándo tu infraestructura no está sana —algo raro de acoplar a una máquina que compraste deliberadamente sin dejar tu identidad en ningún sitio. No lo necesitas. La frescura se puede comprobar desde el destino sin necesidad de la clave en absoluto: el fichero de segmento más reciente del repositorio lleva una marca de tiempo, así que un cron de cinco líneas en la máquina de copias de seguridad que avise a gritos cuando no ha llegado nada en veinticinco horas no cuesta nada y no revela nada. La integridad también tiene una comprobación que no necesita clave —borg check --repository-only se ejecuta localmente en el destino y valida la estructura de los segmentos sin llegar a ver tus datos jamás. Ejecuta de vez en cuando el pase profundo --verify-data desde el origen con la clave de mantenimiento, que es donde esa clave pertenece.

Qué cuesta, y dónde encaja en la pila

La relación coste-beneficio no tiene comparación posible. Un segundo VPS desde $8.00/mes, financiado con el mismo saldo prepago y con recargas desde $30.00, en línea en cosa de 15 min, frente al coste de perder lo que sea que hubiera en la primera máquina. Hazlo funcionar junto a las copias de seguridad del lado del proveedor, no en su lugar: el complemento de copias de seguridad cifradas diarias resuelve el caso de haber borrado el directorio equivocado sin ningún trabajo por tu parte y sin tener que pensar a las tres de la madrugada, mientras que lo que has construido aquí es la copia que sigue siendo tuya cuando lo que desaparece es la cuenta, la región o el proveedor. Cubren fallos distintos y ninguna sustituye a la otra, que es precisamente el sentido de contar hasta tres.

Vale la pena terminar situando las copias de seguridad respecto a todo lo demás, porque son cuatro controles que fallan de forma independiente. Lo que el proveedor sabe de ti es el primero, y aquí es casi nada —un nombre de usuario y un saldo en cripto, el tema de pagar el hosting de forma anónima. Qué ley se aplica es el segundo, decidido por dónde está el hardware y no por dónde estás tú. Lo que permite la máquina es el tercero, que es la primera hora tras el despliegue y depende solo de ti configurarlo. Y lo que sobrevive a la máquina es el cuarto —el único que es una promesa que te haces a tu yo futuro, y el único del que nadie te va a recordar nada hasta el día en que ya sea tarde para empezar. Una hora esta noche, y un simulacro de restauración en el calendario. Eso es todo.

Paso a paso

1. 01

   Despliega el destino de las copias de seguridad y no le des nada más que hacer

   Despliega un segundo VPS en una región que no sea donde vive producción, y trátalo como una máquina de un único propósito. Aplícale la lista de comprobación estándar de la primera hora —SSH solo por clave, firewall de denegación por defecto en ambas familias de IP, actualizaciones de seguridad desatendidas— y no abras nada más. El único puerto entrante en esta máquina es SSH.

   ssh root@198.51.100.7
   apt update && apt full-upgrade -y
   hostnamectl set-hostname vault-01
   apt install -y borgbackup ufw unattended-upgrades
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp && ufw enable

2. 02

   Crea una cuenta borg restringida con dos claves

   Genera dos pares de claves en el origen: uno para la tarea nocturna (sin frase de contraseña —tiene que ejecutarse sin supervisión) y otro para mantenimiento, que guardas solo en tu portátil. En el destino, crea un usuario borg sin privilegios y ata cada clave a un comando forzado. La clave de la tarea recibe --append-only; la de mantenimiento no. Este único fichero es lo que impide que un intruso en el origen borre tu historial.

   # on the source
   ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_job -C "job@edge-01"
   # on your laptop
   ssh-keygen -t ed25519 -f ~/.ssh/borg_maint -C "maint@laptop"
   
   # on the target
   adduser --disabled-password --gecos "" borg
   install -d -m 700 -o borg -g borg /home/borg/.ssh /srv/borg
   cat > /home/borg/.ssh/authorized_keys <<'EOF'
   command="borg serve --append-only --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...job@edge-01
   command="borg serve --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...maint@laptop
   EOF
   chown borg:borg /home/borg/.ssh/authorized_keys
   chmod 600 /home/borg/.ssh/authorized_keys

3. 03

   Inicializa el repositorio y luego saca la clave de ambas máquinas

   Inicializa con la clave de mantenimiento, desde tu portátil —crear un repositorio no es un append. Un repositorio por host de origen mantiene la retención trivial y el radio de impacto pequeño. Después exporta la clave dos veces, en dos formatos, y lleva ambas exportaciones a algún sitio que no sea ni el origen ni el destino: un gestor de contraseñas, una memoria USB cifrada, una hoja de papel en un cajón. Un repositorio cuya clave solo existe dentro de sí mismo es jugárselo a cara o cruz.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   borg init --encryption=repokey-blake2
   
   borg key export :: /tmp/edge-01.borgkey
   borg key export --paper :: /tmp/edge-01.paper
   # move both off this machine, then shred the copies
   shred -u /tmp/edge-01.borgkey /tmp/edge-01.paper

4. 04

   Congela el estado de la aplicación antes de leer el disco

   Copiar fichero a fichero el directorio de una base de datos viva produce un fichero que parece una base de datos y que restaura como la escena de un crimen. Vuelca primero, haz copia de seguridad del volcado, y excluye el directorio de datos en bruto. La misma lógica se aplica a cualquier cosa con un formato en disco que no controlas: vuélcala, o deténla durante los segundos que tarda la instantánea.

   install -d -m 700 /var/backups/dumps
   mariadb-dump --single-transaction --quick --all-databases \
     > /var/backups/dumps/mariadb.sql
   # PostgreSQL:
   # sudo -u postgres pg_dumpall > /var/backups/dumps/pg.sql
   chmod 600 /var/backups/dumps/*.sql

5. 05

   Escribe la tarea de copia de seguridad y ponla en un temporizador

   Mantén el script aburrido y deja que falle de forma ruidosa. La frase de contraseña viene de un fichero en modo 600 a través de BORG_PASSCOMMAND, así que nunca aparece en la lista de procesos. Nombra los archivos con el host y una marca de tiempo ISO para que se ordenen solos. Fíjate en lo que no está en este script: ni prune, ni delete —la clave de la tarea no podría ejecutarlos de todas formas. Un temporizador con Persistent=true se pone al día después de un reinicio, y un retraso aleatorizado evita que todas tus máquinas suban a la vez en el mismo segundo.

   cat > /usr/local/sbin/borg-backup.sh <<'EOF'
   #!/bin/bash
   set -euo pipefail
   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i /root/.ssh/borg_job -o BatchMode=yes'
   export BORG_PASSCOMMAND='cat /root/.config/borg/passphrase'
   borg create --stats --compression zstd,6 --one-file-system \
     --exclude-caches --exclude '/var/cache/*' \
     --exclude '/var/lib/mysql' --exclude '/home/*/.cache' \
     ::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
     /etc /root /home /srv /var/www /var/backups/dumps
   EOF
   chmod 700 /usr/local/sbin/borg-backup.sh
   
   cat > /etc/systemd/system/borg-backup.service <<'EOF'
   [Unit]
   Description=Off-site Borg backup
   [Service]
   Type=oneshot
   Nice=10
   IOSchedulingClass=idle
   ExecStart=/usr/local/sbin/borg-backup.sh
   EOF
   
   cat > /etc/systemd/system/borg-backup.timer <<'EOF'
   [Unit]
   Description=Nightly off-site Borg backup
   [Timer]
   OnCalendar=*-*-* 03:17:00
   RandomizedDelaySec=900
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl daemon-reload
   systemctl enable --now borg-backup.timer

6. 06

   Poda con la clave de mantenimiento, compacta en el destino

   La retención no puede ejecutarse desde el origen, porque la clave del origen es append-only y sus borrados se revertirían en silencio. Ejecútala en su lugar desde tu portátil, con la periodicidad que te convenga —mensual es más que suficiente. prune decide qué archivos conservar; compact es lo que de verdad recupera el espacio en disco. Haz primero un --dry-run y lee la lista antes de dejar que borre nada.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   
   borg prune --dry-run --list \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg prune --list --stats \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg compact --progress

7. 07

   Haz el simulacro de restauración, y luego escribe el manual

   Restaura antes de necesitarlo. Extrae un archivo real en un directorio temporal, compara algunos ficheros con los originales, y carga el volcado de la base de datos en un esquema desechable. Después añade las dos comprobaciones que se ejecutan sin que tengas que prestarles atención: una alarma de frescura en el destino que no necesita clave, y un pase de integridad periódico. Por último, anota los tres datos que vas a querer tener en tu peor día —dónde vive la clave exportada, dónde vive la frase de contraseña, y los comandos exactos de abajo.

   borg list ::
   mkdir -p /var/tmp/drill && cd /var/tmp/drill
   borg extract --list ::edge-01-2026-08-31T03:17 etc/nginx
   diff -r etc/nginx /etc/nginx && echo 'restore OK'
   
   # on the target, no key needed:
   borg check --repository-only /srv/borg/edge-01
   find /srv/borg/edge-01/data -type f -mmin -1500 | head -1   # empty = stale