Cómo respaldar un VPS en almacenamiento offshore cifrado

Casi nadie configura copias de seguridad el día que despliega un servidor. Eso llega después — después de que un disco se llene durante una actualización, después de un borrado en el directorio equivocado, después de que una migración deje una base de datos que arranca limpia y responde mal, después de que alguien entre donde no debía. El hueco entre tener en marcha una máquina que importa y guardar una copia que le sobreviva es la ventana más peligrosa del autoalojamiento, y la mayoría de la gente vive en ella durante meses sin darse cuenta, porque nada falla durante mucho tiempo y luego falla todo a la vez. Cerrarla no es difícil ni caro. Lo que lo hace parecer difícil es que la palabra «copia de seguridad» se usa para cuatro cosas distintas, y solo una de ellas seguirá ahí el día malo.

Las cuatro cosas que no son una copia de seguridad

Cada una de estas cosas es genuinamente útil y merece la pena tenerla. Ninguna es una copia de seguridad, y creer lo contrario es la razón más común por la que la gente pierde datos que creía a salvo. La distinción no es pedantería — cada una de ellas falla exactamente en la situación en la que más necesitas una copia de seguridad.

• El RAID es tiempo de actividad, no una copia de seguridad. Un array sobrevive a un disco muerto sin caerse, que es la razón por la que nuestros servidores de almacenamiento corren en RAID-6 y toleran dos fallos a la vez. No sobrevive a un directorio borrado, una mala actualización, un árbol de archivos cifrado por otra persona o una tabla eliminada — cada una de esas cosas se escribe fielmente en todos los discos en el mismo instante.
• Las instantáneas son un deshacer, no una copia de seguridad. Viven en el mismo almacenamiento que los datos, normalmente son visibles para root en la misma máquina, y cualquier cosa que destruya el volumen o el host se lleva las instantáneas con él. Rápidas para volver atrás, inútiles cuando la máquina ha desaparecido.
• La sincronización es replicación, no una copia de seguridad. Una herramienta de sincronización existe para que el lado remoto coincida con el lado local, así que un borrado o una corrupción se propaga a la copia tan rápido como lo permita la red. Nextcloud, Dropbox y el sync de rclone se comportan así por diseño.
• El control de versiones y la papelera son comodidad, no una copia de seguridad. Son funciones de la aplicación, guardadas en la base de datos de la propia aplicación, con una ventana de retención medida en días. Cuando lo que se rompe es la aplicación, su propio historial se rompe con ella.
• Una copia en el mismo servidor no está fuera de sitio. Si el fallo es la máquina, la cuenta del proveedor, el hipervisor o una incautación, todos los archivos de esa máquina están en el mismo dominio de fallo, sin importar en qué directorio estén.

Una copia de seguridad es una copia separada en espacio, separada en tiempo y separada en control. Separada en espacio para que un incendio o una incautación no se lleve las dos. Separada en tiempo para que puedas volver a antes del daño en lugar de a una copia fiel de él. Separada en control para que unas credenciales robadas de la máquina en marcha no puedan alcanzarla. Cualquier cosa a la que le falte una de esas tres separaciones es una función de comodidad disfrazada de copia de seguridad.

La regla 3-2-1, y la versión que sobrevive a 2026

La regla clásica son tres copias de los datos, en dos tipos de almacenamiento distintos, con una de ellas fuera de sitio. Ha envejecido bien porque en realidad es una regla sobre fallos no correlacionados, no sobre cintas. Desde entonces se han ganado su sitio dos añadidos, y los dos existen por cosas que no pasaban habitualmente cuando se escribió la regla.

• Tres copias. Los datos en vivo, más otras dos. Dos copias significa estar a un fallo de distancia de un punto único de fallo, y los puntos únicos de fallo tienen la costumbre de fallar mientras todavía tienes intención de arreglar el primero.
• Dos tipos de almacenamiento. Hardware distinto, software distinto, idealmente un proveedor distinto. Dos volúmenes en el mismo host comparten hipervisor, panel de control y cuenta — lo que significa que comparten las formas en las que se pierde una cuenta.
• Una fuera de sitio. Físicamente en otro lugar, sobre infraestructura que no se cae cuando se cae la tuya. Esta es la copia que importa para un incendio, un robo, una incautación o una cuenta cerrada sin aviso.
• Una inmutable o desconectada. Tanto el ransomware como un root comprometido buscan primero las copias de seguridad, y un destino en el que tu servidor puede escribir es un destino que tu servidor puede borrar. Unas credenciales de solo anexado o un diseño de extracción convierten eso de una catástrofe en una simple molestia.
• Cero restauraciones sin verificar. Una copia de seguridad que nunca has restaurado es una hipótesis. Este es el añadido que más se salta la gente y el que más se lamenta después, porque una tarea de copia de seguridad que lleva dos años reportando éxito puede llevar dos años escribiendo archivos inutilizables.

Qué respaldar: el estado, no toda la máquina

El instinto es clonar el servidor entero con una imagen. Casi siempre es la forma equivocada: las copias de seguridad por imagen son grandes, lentas, incómodas de restaurar de forma selectiva, y la mayor parte de lo que contienen es un sistema operativo de fábrica que puedes reinstalar en un minuto. Lo que no puedes regenerar es el estado — las cosas que existen solo por lo que tú hiciste.

• Las bases de datos, volcadas en lugar de copiadas. El archivo de una base de datos en vivo, copiado mientras el motor está escribiendo, es un archivo capturado a mitad de una escritura que puede restaurar, puede restaurar mal, y no te va a decir cuál de las dos cosas pasó. Usa la propia herramienta de volcado del motor, o para el servicio, o toma una instantánea del sistema de archivos y vuelca desde ahí.
• Los directorios de datos de la aplicación. Archivos subidos, contenido multimedia, recursos generados — el árbol de archivos que señala la base de datos. Tiene que capturarse en el mismo instante que su base de datos, o restauras un índice que describe archivos que ya no están.
• La configuración y las cosas que editaste a mano. La configuración del servidor web y del proxy inverso, las unidades de systemd, las entradas de cron, las reglas del firewall, los veinte pequeños arreglos que hiciste a las dos de la madrugada y que no vas a recordar.
• Los secretos y las claves, tratados aparte y con más cuidado. Los certificados TLS y sus claves privadas, las claves de host de SSH, los tokens de API y, sobre todo, los archivos de monedero y las semillas. Todo esto merece su propia copia cifrada, que no esté solo en una máquina alquilada.
• Las definiciones de contenedores y sus volúmenes. Los archivos compose y los archivos de entorno, más los volúmenes con nombre — que son la parte que la gente olvida, porque los propios contenedores se recrean con trivialidad y sus volúmenes no.
• La lista de lo que está instalado, no la instalación en sí. Un inventario breve de paquetes, versiones y qué corre dónde restaura más rápido y ocupa menos que una imagen de todo el sistema de archivos raíz.

La línea divisoria es simple: si puedes regenerarlo con un script o un gestor de paquetes en diez minutos, no lo respaldes — apunta cómo se hace. Si existe solo por algo que hiciste tú o un usuario, necesita una copia. Ese principio se aplica igual a un sitio pequeño que a una instancia de BTCPay, donde el monedero y la base de datos lo son todo y el resto es reinstalable, o a un servidor Nextcloud, donde el árbol de archivos y su base de datos tienen que capturarse juntos o ninguno de los dos vale gran cosa.

Dimensionar el destino, y lo que cuesta en realidad

La gente sobreestima esto de forma considerable, normalmente calculando el precio de la primera copia completa y multiplicándolo por los días que piensa conservarla. Una herramienta de copia de seguridad moderna no funciona así. Divide los datos en fragmentos, guarda cada fragmento único una sola vez, y comprime lo que se deja comprimir — así que la segunda instantánea de un servidor que apenas ha cambiado cuesta casi nada, y treinta instantáneas diarias no se acercan ni de lejos a treinta veces el tamaño de la primera.

• Presupuesta aproximadamente el tamaño de tu estado en vivo, más entre un treinta y un cincuenta por ciento para el historial, para una política de retención típica en un servidor que cambia a un ritmo normal.
• La retención determina el crecimiento mucho más que la frecuencia. Unas instantáneas cada hora conservadas durante dos días salen más baratas que unas instantáneas diarias conservadas durante tres años. Decide cuánto tiempo atrás llegarías de verdad alguna vez, y poda automáticamente hasta ese límite.
• Los datos que ya están comprimidos no se comprimen otra vez. El vídeo, las fotos, los archivos comprimidos y los blobs cifrados acaban ocupando casi su tamaño original, así que un servidor cargado de multimedia necesita capacidad real, no ajustes ingeniosos.
• Las bases de datos deduplican mal entre volcados, porque un volcado comprimido de una base de datos ligeramente distinta es un flujo de bytes completamente diferente. Vuelca sin comprimir y deja que la herramienta de copia de seguridad se encargue de la compresión, y el coste de almacenamiento baja en picado.
• La primera subida es la única parte lenta. Después, una ejecución nocturna mueve solo el delta, que en la mayoría de los servidores son unos pocos megabytes. Aquí la transferencia no está medida, así que la primera pasada es una cuestión de paciencia, no de presupuesto.

En la práctica, este es el seguro más barato de todo tu stack. Un servidor de almacenamiento empieza en $7.99/mo por 1 TB en RAID-6, que es muchísimo más de lo que va a ocupar el estado de un puñado de instancias VPS, y STO-2 a $12.99/mo lo dobla. Las bibliotecas multimedia y la retención larga son donde la capacidad importa de verdad: STO-4 a $22.99/mo te da 4 TB, STO-8 a $39.99/mo te da 8 TB. El destino habla rsync, SFTP y una API compatible con S3, así que cualquier herramienta de copia de seguridad habitual habla con él sin necesidad de un plugin, y los volúmenes están cifrados en reposo con AES-256, con soporte para llevar tus propias claves — aunque, como argumenta la siguiente sección, deberías cifrar antes de que los datos salgan del origen de todas formas.

Elegir una herramienta, y para qué sirve realmente cada una

Aquí no hace falta agonizar. Tres herramientas cubren esencialmente todos los casos, las tres son gratuitas, y la diferencia entre ellas importa menos que la diferencia entre tener una y no tener ninguna. Elige según la forma de tu problema, no según un benchmark.

• restic — la recomendación por defecto para la mayoría de los servidores. Cifrado del lado del cliente, con deduplicación, un único binario estático sin demonio, y escribe de forma nativa a SFTP, endpoints compatibles con S3 y directorios simples. Su modo de solo anexado es la vía más fácil hacia un destino que un servidor comprometido no puede borrar.
• BorgBackup — deduplicación y compresión excelentes, muy eficiente sobre enlaces lentos, maduro y sobradamente probado. Necesita su propio agente disponible en el destino para los repositorios remotos, una restricción pequeña a cambio de ser notablemente más ligero con el almacenamiento.
• rclone — la herramienta correcta cuando el trabajo consiste en mover datos entre almacenes de objetos, o cuando lo que quieres es un espejo en lugar de un historial con versiones. Combínalo con su capa crypt si lo usas directamente, y recuerda que una sincronización simple propaga los borrados.
• Las herramientas nativas de volcado, siempre, para las bases de datos. mysqldump, pg_dump y sus equivalentes producen una copia lógica consistente que el motor puede leer de vuelta sin ninguna duda. Vuelca a un archivo, y luego deja que restic o Borg recojan ese archivo — no intentes sustituir el volcado por una copia ingeniosa a nivel de archivo.
• Las instantáneas del proveedor, solo como una capa local rápida. Tómalas para poder revertir deprisa alrededor de actualizaciones arriesgadas, y no las cuentes nunca como una de tus tres copias.

Paso a paso: una copia de seguridad cifrada funcionando en una sola sesión

1. 01Despliega el destino y ciérralo bienUn servidor de almacenamiento en una región distinta de la de los servidores que protege. SSH solo con clave, su propio usuario, y ninguna reutilización de credenciales de las máquinas que van a escribir en él.
2. 02Decide la lista del estado antes de tocar ninguna herramientaApunta cada ruta y cada base de datos que tiene que sobrevivir. Diez minutos con un archivo de texto ahora evitan la restauración en la que descubres el único directorio que nadie apuntó.
3. 03Inicializa un repositorio cifradoGenera una contraseña fuerte para el repositorio, inicialízalo sobre SFTP o S3, y guarda esa contraseña en algún sitio que no sea el servidor al que le estás haciendo la copia. Un repositorio cuya clave solo existe en la máquina muerta no es recuperable.
4. 04Vuelca las bases de datos primero, luego archivaUn script envoltorio que vuelca cada base de datos a un directorio intermedio y después ejecuta una sola pasada de copia de seguridad sobre los volcados y el árbol de archivos juntos. Ese orden es lo que hace que la base de datos y sus archivos sean consistentes entre sí.
5. 05Ejecuta la primera copia de seguridad y espera a que termineLa primera pasada es la larga. Ejecútala en un multiplexor de terminal para que una conexión cortada no la mate, y anota cuánto ha tardado — ahora también conoces tu ventana de restauración.
6. 06Configura la retención y poda de forma automáticaAlgo así como siete instantáneas diarias, cuatro semanales y seis mensuales le sienta bien a la mayoría de los servidores. Configura la poda en la misma tarea, o el repositorio crecerá hasta el día en que deje de funcionar.
7. 07Prográmala, y luego haz que el fallo sea ruidosoUn timer nocturno o una entrada de cron, más una alerta cuando la tarea no reporte éxito. Una tarea de copia de seguridad silenciosa es indistinguible de no tener ninguna copia de seguridad, durante los meses que hagan falta para darte cuenta.
8. 08Restaura algo hoy, desde la copia de seguridad, en una máquina distintaNo un listado del archivo — una restauración de verdad de un archivo real y una base de datos real sobre un servidor desechable. Hasta que no hayas hecho esto una vez, tienes un script de copia de seguridad, no una copia de seguridad.

Hacer que la copia sobreviva a lo que mató al servidor

Esta es la parte que separa una copia de seguridad de verdad de un simple estorbo para un atacante. Si el servidor guarda credenciales que pueden borrar las copias de seguridad, entonces un root comprometido, una pasada de ransomware o un script equivocado alcanzan las dos copias en el mismo minuto. El arreglo es estructural, no una cuestión de contraseñas más fuertes.

• Usa credenciales de solo anexado desde el origen. restic y Borg admiten los dos un modo en el que la máquina que escribe puede crear instantáneas nuevas pero no puede borrar ni podar las que ya existen. La poda entonces se ejecuta desde otro sitio, según un calendario, con una clave separada.
• Prefiere un diseño de extracción siempre que puedas. Un destino que entra en el origen y recoge los datos, en lugar de un origen que los empuja, significa que el origen nunca llega a tener credenciales del archivo.
• No reutilices nunca claves SSH ni contraseñas de repositorio entre servidores. Una máquina comprometida te debería costar las copias de seguridad de esa máquina, no todo el parque.
• Mantén al menos una copia en una jurisdicción distinta y un dominio de fallo distinto. La diversidad de región no es paranoia — es la diferencia entre un incidente de hardware y una pérdida total.
• Guarda la clave del repositorio completamente fuera de la infraestructura. Un gestor de contraseñas, un token hardware, papel en una caja fuerte. En cualquier sitio menos en las máquinas que protege el repositorio.
• Vigila las copias de seguridad que de repente empiezan a tener éxito sospechosamente rápido. Una tarea que antes tardaba veinte minutos y ahora tarda cuarenta segundos normalmente está respaldando un directorio vacío o desmontado, y seguirá reportando éxito mientras lo hace.

Aquí elegir la región es una decisión real, no un detalle, porque tu copia de seguridad y tu servidor de producción no deberían poder incautarse en la misma acción. Si eso importa para lo que ejecutas, elegir la ubicación de forma deliberada vale unos minutos, y poner el destino bajo un régimen legal distinto al del origen es precisamente el objetivo del ejercicio.

Restaurar: la parte que nadie ensaya

Las restauraciones fallan por razones aburridas, y fallan en el peor momento posible porque ese es el único momento en el que la mayoría de la gente intenta una. Cada uno de los fallos de abajo se descubre en minutos durante un simulacro, y en horas durante una caída real.

• La contraseña del repositorio solo estaba en el servidor que murió, así que los archivos están intactos y son permanentemente ilegibles.
• La base de datos se restauró bien, pero el árbol de archivos venía de una ejecución tres horas más tarde, así que la aplicación muestra registros cuyos archivos no existen.
• La copia de seguridad capturaba un directorio que había dejado de estar montado en silencio, así que archivó fielmente una carpeta vacía todas las noches durante un año.
• Nadie sabía el orden de restauración — primero la base de datos o primero los archivos, el servicio parado o en marcha — y hubo que tirar el estado a medio restaurar y empezar otra vez.
• La restauración tarda once horas por el enlace disponible, algo que nadie había medido, y el plan de recuperación asumía que tardaría una.
• La propiedad y los permisos de los archivos volvieron mal, así que todo está presente y la aplicación se niega a arrancar.
• Solo se probó nunca la instantánea más reciente, y la corrupción de la que se intenta recuperar empezó hace seis semanas.

Un simulacro dos veces al año lo arregla todo. Despliega un VPS desechable, restaura en él desde el repositorio real, arranca el servicio, mira los datos, destruye la máquina. Cuesta un par de dólares y una hora, y convierte todo el sistema de copias de seguridad de una creencia en un hecho. Hazlo una vez con el runbook abierto y corrige el runbook en cada punto donde te haya mentido.

La capa de privacidad: una copia de seguridad puede deshacer tu anonimato

Esta parte es específica de operar offshore, y solo es fácil hacerla bien si la piensas antes de la primera subida y no después. Una copia de seguridad es una copia completa, indexada y de larga vida de tu infraestructura, sentada en otro sitio — lo que la hace exactamente tan sensible como el original y considerablemente más fácil de olvidar.

• Los nombres de archivo y la estructura de directorios son metadatos incluso cuando el contenido está cifrado. El cifrado del lado del cliente en restic y Borg también cubre los nombres; un espejo de rsync simple no lo hace, y un listado de directorio suele bastar para identificar qué es un servidor y quién lo lleva.
• La cuenta del destino es parte de la historia. Una bóveda de copias de seguridad alquilada con una tarjeta a tu nombre legal ata ese nombre a todo lo que guarda la bóveda, por muy cuidadosamente limpia que hayas mantenido la máquina de origen.
• El tráfico de copia de seguridad es un enlace persistente, programado y de alto volumen entre dos direcciones. Es uno de los patrones más legibles que produce un servidor, y señala hacia el destino todas y cada una de las noches.
• Las instantáneas antiguas sobreviven a las decisiones que las crearon. Algo que dejaste de guardar hace un año sigue en el archivo si la retención nunca lo podó, lo cual es una buena propiedad para la recuperación y una mala para la exposición.
• Los logs y el historial de la shell se arrastran junto con todo lo demás. El archivo contiene con frecuencia las direcciones IP, los comandos y las credenciales con los que tuviste cuidado en la máquina en marcha.

Los arreglos son sencillos. Usa una herramienta que cifre tanto los nombres como el contenido. Alquila el destino de la misma forma en que alquilaste el origen — en un host que nunca preguntó quién eres, financiado desde un saldo en cripto, con una recarga en Monero si además quieres cerrar el rastro del pago. Enruta la transferencia a través de un túnel WireGuard si el patrón en sí te preocupa. Y aplica el mismo endurecimiento de los primeros diez minutos a la caja de almacenamiento que le aplicaste a producción, porque una máquina que guarda una copia de todo no es un objetivo de menor valor que el original — con frecuencia es uno mayor.

Errores que le cuestan a la gente sus datos

• Confiar en el RAID, las instantáneas o una carpeta sincronizada como si fueran la copia de seguridad, y descubrir en qué categoría estaban de verdad el día que importaba.
• Guardar la única copia en el mismo servidor, la misma cuenta o el mismo proveedor que aquello que se supone que protege.
• Copiar el archivo de una base de datos en vivo en lugar de volcarla, y restaurar un archivo que está sutil y silenciosamente mal.
• Respaldar el árbol de archivos y la base de datos en momentos distintos, de modo que ninguno coincide con el otro al restaurar.
• Guardar la contraseña del repositorio en la misma máquina que protege el repositorio.
• Darle al origen permisos completos de borrado sobre el destino, de modo que un solo compromiso se lleva los archivos por delante.
• No podar nunca, hasta que el destino se llena y la tarea nocturna lleva semanas fallando en silencio.
• Respaldar cientos de gigabytes de datos públicos de la cadena de bloques mientras el archivo del monedero no está en ninguno de los archivos.
• Configurar alertas para el fallo pero nunca para la ausencia, de modo que una tarea que ha dejado de ejecutarse por completo no reporta absolutamente nada.
• Probar solo la instantánea más reciente, y descubrir durante un incidente real que la corrupción es anterior a ella.

Las copias de seguridad son lo menos interesante que vas a configurar, y lo único cuya ausencia es irrecuperable. Todo lo demás en un servidor se puede reconstruir con un gestor de paquetes y una tarde; el estado no. Dedícale una sola sesión: apunta lo que tiene que sobrevivir, vuelca las bases de datos, manda un archivo cifrado a un servidor de almacenamiento en otro país, poda según un calendario, activa una alerta ante el silencio, y restaura algo real antes de cerrar la terminal. Después déjalo tranquilo. La medida de un buen sistema de copias de seguridad es que te olvidas de que existe, hasta la mañana en la que convierte una catástrofe en una hora un poco molesta.