Una estrategia de backup nunca se pone a prueba la noche en que el servidor muere. Se pone a prueba semanas antes, en tres decisiones silenciosas que nadie apunta: dónde va la copia, quién puede borrarla y si alguien ha llegado a leerla de verdad.
Un alojamiento que nunca pidió tu identidad renuncia a algo a cambio, y este es el lugar honesto para decirlo. No hay gestor de cuenta al que llamar, ni ticket que resucite un volumen borrado, y nuestra propia política de retención es tajante sobre el motivo: los datos del servidor se destruyen en las 24 horas siguientes a la cancelación, los discos se borran criptográficamente en lugar de formatearse, y no se conservan copias de seguridad. Es la misma característica que hace que la plataforma merezca la pena, vista desde el otro lado. Todo lo que quieras recuperar tras una mala noche ya tiene que estar en otro sitio, y eres tú quien lo pone ahí.
Qué destruye realmente un servidor
Casi nadie pierde un servidor de la forma en que se lo imagina. El fallo catastrófico de hardware es real pero poco frecuente, y es el único caso para el que un buen proveedor ya está preparado. Las pérdidas que ocurren de verdad son más aburridas, y cada una derrota a un tipo distinto de copia, por eso «tengo un backup» no es una respuesta hasta que dices a cuál de estas sobrevive.
| Qué sale mal | Cómo suele ocurrir | Qué te salva |
|---|---|---|
| Tu propia mano | Un rm -rf con una variable de shell vacía, una migración apuntando a producción, un despliegue que borró la tabla equivocada | Cualquier copia fuera de la máquina de antes del error, lo que implica que la retención debe llegar más atrás del tiempo que tardas en darte cuenta |
| Corrupción silenciosa | Un NVMe que se está muriendo, una escritura truncada durante un reinicio, una base de datos que lleva una semana escribiendo filas dañadas | Copias versionadas con suficiente profundidad para llegar a un punto en buen estado. Una única copia espejo refleja fielmente el daño |
| Compromiso | Una clave robada, una aplicación sin parchear, una dependencia envenenada... y luego, de forma deliberada, tus backups | Una copia que la máquina comprometida no tenía forma de borrar. Aquí no vale nada más |
| Un incidente del proveedor o del país | Pérdida de hardware, una acción legal en el centro de datos, una cuenta o token al que ya no puedes acceder | Una copia que no está en ese proveedor ni bajo esa jurisdicción |
| Perder la clave | Una frase de contraseña olvidada, un keyfile borrado junto con el servidor que protegía, una cabecera LUKS que nadie exportó | Nada. Es la única fila sin columna de recuperación, y es más común que el fallo de hardware |
Lee esta tabla como una lista de comprobación, no como una lista de miedos. Una copia nocturna a un segundo disco en la misma máquina responde a la primera fila y a nada más. Un snapshot en el mismo panel responde a las filas uno y dos. Solo una copia guardada en algún sitio al que el servidor no puede llegar, bajo una clave que aún conservas, responde a las cinco.
Un snapshot no es un backup, y tu proveedor tampoco
Los snapshots son excelentes en lo suyo: deshacen una actualización que salió mal, en segundos y sin transferir nada. Lo que no pueden hacer es sobrevivir a lo que se llevó al servidor, porque comparten con él todos los dominios de fallo: el mismo proveedor, la misma cuenta, el mismo token de facturación, el mismo país, a menudo el mismo clúster de almacenamiento. Un snapshot te protege de ti mismo. Un backup te protege de todo lo demás.
La distinción importa más aquí que en un proveedor convencional, porque las redes de seguridad habituales se quitaron a propósito. Nadie entra en los servidores de los clientes, así que nadie se da cuenta de que tu tarea de backup lleva fallando desde marzo. No hay identidad ligada a la cuenta, así que no existe la vía humana de «demuestra quién eres y te lo restauramos». Y la cancelación es terminal de verdad: un saldo vencido es un evento de pérdida de datos, no un evento de facturación.
La cláusula de las 24 horas es todo el argumento. En esta plataforma, los datos de un servidor cancelado se destruyen en menos de un día, y los discos se borran criptográficamente en lugar de formatearse. No hay deshacer el borrado, no hay un nivel silencioso de almacenamiento en frío, no hay un resultado de soporte que termine en «encontramos una copia antigua», porque conservar una significaría guardar tus datos después de pedirnos que no lo hiciéramos. La red de seguridad y la privacidad son el mismo trato, hecho una sola vez.
3-2-1, reescrita para gente que nunca enseñó su identificación
La regla clásica dice tres copias, en dos tipos de soporte, una de ellas fuera del sitio. Se escribió para una era de cinta y disco duro, y la cláusula del soporte ha dejado de significar nada en silencio: tu disco de producción es NVMe, el disco de tu destino de backup es NVMe, y llamar a eso «dos soportes» es un cuento que te cuentas a ti mismo. La cláusula que merece la pena conservar es la de la distancia, y en infraestructura offshore la distancia no se mide en kilómetros.
Reescríbela como tres copias, dos proveedores, dos jurisdicciones. Los fallos que se llevan las dos copias a la vez casi nunca son físicos: son una cuenta a la que perdiste el acceso, un proveedor que tuvo una mala semana o un instrumento legal que llega a un país y no tiene alcance en otro. Dos servidores en el mismo rack son una sola copia con pasos extra; dos servidores bajo el mismo régimen legal apenas son mejores. Nuestra guía de jurisdicciones explica cómo elegir una segunda que no se limite a copiar la exposición de la primera.
En la práctica esto sale barato. Un destino de backup no necesita núcleos, y apenas necesita red: necesita disco y una dirección. El plan de VPS más pequeño en una de nuestras otras siete ubicaciones es un destino perfectamente competente para restic o Borg, y para archivos medidos en terabytes, un servidor dedicado con discos reales cuesta menos por terabyte que cualquier almacenamiento de objetos. Cuando los datos son realmente grandes y se leen poco, la economía favorece al metal desnudo por un margen amplio.
Algo que la gente hace bien en producción y mal en el destino del backup: pagarlo de la misma manera. Un segundo servidor comprado con una tarjeta a tu nombre vuelve a vincular, en silencio, la identidad que te esforzaste en quitar de la primera máquina, y ahora ese segundo servidor guarda una copia completa de todo lo que hay en ella. Si el servidor de producción se paga en Monero, el servidor de backup merece el mismo trato.
La tercera copia es la que casi todo el mundo se salta, y es la única inmune a todos los fallos remotos a la vez: un disco que tienes físicamente, actualizado de vez en cuando y mantenido offline. Una vez al mes es suficiente para la mayoría. Cuesta la atención de un café y es la copia que sobrevive a los escenarios que comparten las otras dos.
Push, pull, y el error que deja que una mala noche se coma las dos copias
Este es el montaje que casi todo el mundo construye primero. Una tarea en el servidor de producción se ejecuta cada noche, guarda una clave o un token para el destino del backup, se conecta y empuja los datos (push). Funciona, es sencillo, y tiene una propiedad que solo se hace visible el peor día de la vida del servidor: quien controla la máquina de producción controla también los backups.
Esto no es hipotético. Borrar o cifrar los backups de la víctima antes de anunciarse es práctica habitual entre quienes hacen esto de forma profesional: las credenciales están en una tarea cron o en un archivo de entorno, y encontrarlas lleva alrededor de un minuto. Una copia que tu atacante puede borrar no es una segunda copia. Es un espejo de la primera con retraso.
Hay dos soluciones limpias, y combinan bien con el endurecimiento básico que ya deberías haber hecho.
- Destinos append-only. Las dos herramientas principales admiten un modo en el que un cliente puede añadir datos pero no puede eliminarlos. Borg lo consigue fijando la clave SSH del destino a
borg serve --append-only; restic lo consigue con un servidor REST iniciado con--append-only. El servidor de producción escribe cada noche y es estructuralmente incapaz de destruir el histórico. La poda de snapshots antiguos ocurre entonces en el destino, en una sesión que la máquina de producción no puede iniciar. - Pull en lugar de push. Invierte la dirección: el host de backup se conecta a producción, lee y almacena. Producción no guarda ninguna credencial para el destino, así que no hay nada que robar. Restringe la clave que usa en el lado de producción con
restricty uncommand=forzado, para que una clave de backup robada no pueda convertirse en una shell.
Pull es el modelo más sólido y cuesta un poco más de trabajo mantener; append-only es casi gratis si ya usas Borg o restic. Cualquiera de las dos convierte «el atacante borró mis backups» de un hecho consumado en un simple intento. Si te llevas una sola cosa de esta guía, que sea esta sección.
Cifra en el origen y luego decide quién guarda la clave
Las dos herramientas serias cifran en la máquina que se está respaldando, antes de que nada cruce la red. El destino almacena bloques que no puede interpretar, y eso es precisamente lo que hace segura la copia entre proveedores. Tu segundo host no necesita ser de confianza, ni siquiera amistoso; necesita ser alcanzable y tener disco. Esa única propiedad es lo que convierte «un servidor en un país del que no sé nada» de un riesgo en infraestructura.
Es un mecanismo distinto al de cifrar el propio disco del servidor, y ambos responden a preguntas diferentes; nuestra guía de cifrado de disco completo en un VPS explica qué protege y qué no protege el cifrado de disco mientras la máquina está encendida. El cifrado del backup es el más fácil y el más valioso de los dos, porque su modelo de amenaza es honesto: los datos están en reposo, en un hardware que no controlas, y la clave nunca llega hasta allí.
Lo cual traslada todo el riesgo a la custodia de la clave. La frase de contraseña es ahora un único punto de pérdida total, y es un punto único peor de lo que la gente espera, porque perderla es silencioso: nada se rompe, los backups siguen ejecutándose, y te enteras justo en el momento en que los necesitabas. Tres hábitos lo arreglan:
- Guarda la frase de contraseña en el servidor solo como un archivo legible únicamente por root, referenciado con
--password-file, para que nunca aparezca en una lista de procesos ni en el historial de la shell. - Guarda una copia legible por humanos fuera de todas las máquinas implicadas. El papel en un cajón supera de verdad a un gestor de contraseñas que sincroniza con una cuenta a la que también podrías perder el acceso.
- Añade una segunda clave al repositorio, con
restic key addo exportando una clave de Borg, para que una frase de contraseña olvidada sea solo una molestia y no el fin del archivo.
La regla que subyace a las tres: si la única copia de la clave vive en la máquina que el backup existe para sustituir, no tienes un backup. Tienes un montón de bloques cifrados y una historia sobre ellos.
Elegir una herramienta, en una tabla
La elección de la herramienta importa menos que la dirección de la conexión y el estado de tu clave, por eso aparece en sexto lugar y no en el primero. Dicho esto, las diferencias son reales, y elegir la forma equivocada para el trabajo genera más trabajo después.
| Herramienta | Cifra antes de salir | Deduplica | Destino append-only | Dónde encaja |
|---|---|---|---|---|
| restic | Sí, todo el repositorio | Sí | Sí, mediante su servidor REST | La opción por defecto. Habla SFTP, almacenamiento de objetos y su propio servidor, así que el destino puede ser casi cualquier cosa |
| BorgBackup | Sí, todo el repositorio | Sí, la mejor del grupo | Sí, de forma nativa por SSH | Un destino Linux al que se accede por SSH. Insuperable cuando los datos son grandes y repetitivos |
| rsync con rotaciones | No: el destino ve todo | Parcial, mediante hardlinks | No | Reflejar en una máquina que controlas por completo, cuando las restauraciones parciales instantáneas importan más que la privacidad |
| rclone | Solo con rclone crypt | No | Depende del proveedor de almacenamiento | Mover un archivo que ya existe hacia almacenamiento de objetos, o entre proveedores |
| Replicación ZFS | Solo con un dataset cifrado | Sí, a nivel de bloque | Mediante permisos de snapshot | Replicar entre dos máquinas ZFS. Muy rápido, muy rígido en ambos extremos |
| tar con age o GPG | Sí, si cifras el archivo | No | No aplica | Archivos pequeños, ocasionales y de conservación indefinida, donde la simplicidad gana a la eficiencia |
Para un solo servidor, restic hacia un segundo VPS es el camino más corto hacia algo correcto. Para un seedbox, un archivo multimedia o cualquier cosa con muchos archivos grandes y similares, la deduplicación de Borg marca la diferencia entre un disco lleno y uno cómodo; la guía de seedbox trata con más detalle el lado del almacenamiento de esa carga de trabajo.
Todo lo que está en ejecución no es un archivo
El backup corrupto más común del mundo es una copia de archivo directa de una base de datos en marcha. Termina sin ningún error, pesa lo que debe pesar, y al restaurarla obtienes una tabla que el motor se niega a abrir. La base de datos estaba a mitad de una escritura cuando pasó la copia; lo que guardaste es la foto de una página en el momento de pasarla.
Tres salidas, en orden creciente de esfuerzo. Volcarla: mysqldump --single-transaction da un volcado consistente de InnoDB sin bloquear a los que escriben, y pg_dump hace lo mismo con PostgreSQL. Hacerle un snapshot: congela el sistema de archivos o toma un snapshot de LVM o ZFS, copia desde ahí y libéralo; así se gestionan los conjuntos de datos demasiado grandes para volcar cada noche. O pararla: para un servicio pequeño, dos minutos de inactividad a las 04:00 es una estrategia de consistencia perfectamente respetable, y es la única sin casos límite.
La misma lógica va más allá de las bases de datos. La capa escribible de un contenedor es desechable, pero sus volúmenes no lo son, y tampoco lo son el archivo docker compose ni el entorno que lo acompaña; un backup que restaura los datos pero no la definición te deja reconstruyendo el stack de memoria. Las colas de mensajes, Redis con persistencia activada y un spool de correo que un MTA está escribiendo merecen el mismo trato: pausar, hacer snapshot o volcar, pero nunca copiar directamente y esperar lo mejor.
Qué respaldar, y las partes que todo el mundo olvida
La mayoría respalda lo obvio (la base de datos y el directorio de la aplicación) y reconstruye el resto a mano, bajo presión. Es en la reconstrucción donde se van las horas. Un backup que te devuelve a un sistema funcionando, y no a un montón de datos correctos, incluye también la capa aburrida:
/etccompleto, además de las unidades y timers de systemd que escribiste, y cualquier crontab que viva fuera de él.- Los certificados TLS y sus claves privadas, o como mínimo la clave de cuenta ACME, para que los certificados se renueven en lugar de empezar de cero.
- Las reglas del firewall y la lista de paquetes, que juntas reconstruyen la forma de la máquina más rápido que cualquier recuerdo de ella.
- Los secretos de la aplicación y los archivos de entorno: los que excluiste deliberadamente de tu repositorio de código, y que por tanto no existen en ningún otro sitio.
- Los registros DNS exportados como texto, incluidas las entradas de DNS inverso y PTR, que viven en el proveedor y no en el servidor.
Algunas claves no son datos: son identidad. La clave privada de un servicio onion de Tor es la dirección: si la pierdes, el sitio no puede volver con el mismo nombre .onion, sin importar qué más hayas restaurado. La clave de un servidor WireGuard implica reemitir todas las configuraciones de cliente que hayas entregado. La clave DKIM de un servidor de correo implica un nuevo selector y empezar de cero en la entregabilidad. La semilla y el estado de canales de un nodo Lightning pueden significar fondos, no archivos; la guía de alojamiento de nodos es explícita al respecto. Copia estas claves por separado, mantenlas offline, y trátalas como más valiosas que los datos que protegen.
Una restauración que no has probado es un rumor
El software de backup informa sobre sí mismo, y lo hace con honestidad sobre lo que no importa. «Snapshot completado» significa que se escribieron datos en un repositorio. No dice nada sobre si ese repositorio se puede leer en una máquina que no es esta, por una persona que no recuerda lo que configuró hace once meses.
Empieza por las comprobaciones de integridad baratas: restic check --read-data-subset=5% o borg check --verify-data con una programación regular, y entiende que verifican el archivo, no tu capacidad de usarlo. El simulacro real es distinto y lleva una tarde, una sola vez. Pide un servidor nuevo por horas en una ubicación que normalmente no usas. Restaura en él con nada más que la dirección del repositorio, la frase de contraseña y tus propias notas. Levanta el servicio. Cronometra todo el proceso. Luego destruye la máquina. Coste total: unos pocos dólares, y es el único ejercicio que produce un número en el que puedes confiar.
Lo que expone de forma fiable nunca son los datos. Es el paquete que falta y que nadie apuntó, la configuración que vivía fuera de las rutas respaldadas, la frase de contraseña que solo existió en el historial de shell del servidor que intentas reemplazar, y la versión de la herramienta que sabe leer el formato de tu repositorio. Cada uno de esos problemas es trivial de arreglar de antemano y espantoso de descubrir durante una caída.
Apunta los dos números que te da el simulacro: cuánto tardó la restauración y cuánto trabajo puede perder tu programación. Esa es la política de backup. Todo lo anterior es un detalle de implementación al servicio de esos dos números.
Automatizarlo para que siga pasando
Ejecuta la tarea desde un timer de systemd en lugar de cron. Obtienes los registros en un solo sitio, un historial real de la última ejecución y una programación que sobrevive a los reinicios; nada de eso te lo da cron sin trabajo extra. Mantén la frase de contraseña fuera del propio archivo de unidad, que cualquiera con acceso a la shell puede leer directamente con systemctl cat.
Después resuelve el modo de fallo que de verdad atrapa a la gente, que no es un error sino el silencio. Un backup que dejó de ejecutarse hace seis semanas parece exactamente igual que uno que fue perfecto, porque ninguno de los dos produce salida. Alerta ante la ausencia, no ante el fallo. Haz que la tarea avise a un monitor cuando tiene éxito, y deja que el monitor se queje cuando el aviso no llega; y coloca ese monitor en cualquier sitio menos en el servidor que vigila, porque una máquina caída no puede informar de que está caída.
Fija la retención de forma deliberada y no por defecto. Algo como --keep-daily 7 --keep-weekly 4 --keep-monthly 6 cubre los errores que notas esta noche y la corrupción que notas en primavera, sin crecer para siempre. Ejecuta la poda en el lado del destino si ya has pasado a append-only, que es precisamente el sentido de haberlo hecho. El volumen de transferencia rara vez es la limitación en nuestra red (el ancho de banda es ilimitado en todos los planes), así que programa pensando en la consistencia y no en una cuota, y ajusta el horario a tus propias horas tranquilas. Los hábitos más amplios en torno a todo esto se tratan en la guía de OpSec del servidor.
La versión corta
Si no haces nada más con esta página, haz estas seis cosas, más o menos en este orden:
- Pon una copia en un segundo proveedor, en una segunda jurisdicción, pagada con la misma privacidad que la primera.
- Haz que esa copia sea append-only, o extráela desde el destino, para que un servidor comprometido no pueda destruirla.
- Deja que la herramienta cifre en el origen, y mantén la clave fuera de las dos máquinas implicadas.
- Vuelca las bases de datos y detén o haz snapshot de todo lo que esté en ejecución; nunca copies directamente un estado en vivo.
- Respalda las claves de identidad por separado (onion, WireGuard, DKIM, semillas de nodo), porque esas no se pueden regenerar.
- Restaura una vez en un servidor desechable, cronométralo y apunta lo que faltaba.
Nada de esto es exótico, y nada de esto lleva un fin de semana. Es una tarde de configuración y un simulacro, contra una categoría de pérdida que acaba con proyectos. En una plataforma que deliberadamente no guarda nada sobre ti, la copia que hiciste tú mismo es la única que existe, y ese es el coste del trato, uno justo. Levanta un segundo servidor en una jurisdicción que no sea la primera, y dale a tu backup de esta noche un lugar donde caer.