Backup y restauración en VPS — 3-2-1 en servidores root

Separa el estado de lo reconstruible, guarda tres copias en dos soportes y prueba la restauración. Recetas de Borg y Restic para servidores root desde $4.80/mes anual.

Traza la línea del estado antes que nada

La restauración más rápida es la que nunca toca la mayor parte del disco, y por eso la planificación del backup empieza por eliminar en vez de copiar. En un servidor root típico, el conjunto irremplazable es pequeño: las bases de datos, los archivos subidos, las claves privadas TLS y las configuraciones que te costó una semana dejar perfectas. El sistema operativo en sí es reproducible. Para cada ruta del servidor, hazte una pregunta antes que nada: si esto desapareciera a las 3 de la madrugada, ¿lo reescribirías o lo reconstruirías? Si la respuesta honesta es reconstruir, no pertenece a tu repositorio.

Esa línea divide el trabajo en dos artefactos: lo que es estado recibe copias, y lo que es reconstruible recibe un script. Un playbook de Ansible o un archivo cloud-init que actualizas de verdad le gana a una imagen dorada que olvidaste que existía, porque un script es revisable, versionable y probado en un servidor de repuesto antes de que importe. El dividendo es la velocidad de restauración: extraer 3 GB de estado real desde un repositorio lleva minutos, mientras que reinstalar y reajustar un servidor construido a mano se come con seguridad una jornada laboral. Automatizar la reconstrucción es de donde sale de verdad la velocidad de restauración, y es la hora más barata que invertirás en todo este proyecto.

Haz el inventario con rutas reales en lugar de intuiciones. /etc guarda las configuraciones y las claves de WireGuard, /var/lib/postgresql o /var/lib/mysql guardan el estado de las bases de datos, /home guarda las claves de usuario y los repositorios, y /srv o /var/www guardan las subidas y las raíces de los sitios. Mide cada una con du -sh y anota los números; en un servidor con disco NVMe de 80 GB el total del estado suele quedar en single digits de gigabytes. Ese número decide el tamaño de todo lo que viene después: el repositorio, el servidor de destino, el ancho de banda de la primera sincronización y los minutos que tardará una restauración cuando de verdad importe.

Dos errores se comen esta etapa. El primero es archivarlo todo cada noche por si acaso: el repositorio se hincha, cada ejecución se vuelve más lenta y el estado que realmente necesitabas queda escondido dentro de ruido que jamás vas a restaurar. El segundo es la imagen dorada, una instantánea de un servidor ajustado que se pudre en silencio mientras los paquetes y los kernels avanzan, de modo que la única vez que restauras desde ella, la propia imagen falla. Un script de build que ejecutas cada mes se mantiene fiel al servidor; una imagen que no has reconstruido en un año es una suposición con extensión de archivo, y las suposiciones fallan en la peor hora.

Una vez trazada la línea y anotados los números, el patrón 3-2-1 te dice dónde viven las copias y para qué sirve cada una. El patrón es viejo porque funciona, y porque la mayoría de sus fallos son autoinfligidos: la siguiente sección asigna a cada copia el desastre al que responde, y muestra por qué una de ellas debe poder sobrevivir al propio servidor.

Tres copias, dos soportes, una restauración que hayas ejecutado de verdad

La regla 3-2-1 suena a folclore, pero en realidad es un mapa de dominios de fallo: existen tres copias porque tres cosas distintas se pueden romper. Los datos en vivo son la copia uno, y por definición ya están fallando en el momento en que necesitas esta regla. La copia dos es una instantánea en el propio servidor para retroceder a nivel de segundos, ese despliegue malo que quieres eliminar en dos minutos. La copia tres es el backup fuera del servidor que sobrevive al propio servidor, la única que responde a un proveedor caído, un rack caído o un evento de cifrado. Cada copia tiene un trabajo; los problemas empiezan cuando se le pide a una sola copia que haga los tres.

Los dos soportes importan igual: NVMe local para una recuperación medida en segundos, más una copia en un almacenamiento genuinamente separado, ya sea otra cuenta, otro proveedor o un almacenamiento frío que montas bajo demanda. Restaurar desde el NVMe local está a un cp de distancia; bajar un repositorio por un puerto sin límite de tráfico de 1 Gbps es un evento de toda la noche para un dataset grande y un café para uno pequeño. La separación de soportes es lo que impide que un solo fallo de controladora, o un único proceso de ransomware corriendo con las credenciales del propio servidor, alcance ambas copias en el mismo minuto.

La tercera, una restauración probada, es la única línea de la regla que alguien recuerda bajo presión. Prográmala: una ejecución que restaura a un directorio temporal y compara contra el origen, en el calendario, cada trimestre. Los backups sin probar fallan en silencio, de formas que solo se ven cuando el diff dice que los 40 GB que creías tener son en realidad 4, o cuando el único archivo que necesitas fue podado hace tres semanas por una política de retención que nadie revisó. La prueba de restauración es la auditoría; todo lo demás de la regla es contabilidad que la alimenta.

El error clásico aquí es el halago aritmético: contar un espejo RAID 1 como segunda copia, o contar una instantánea en el servidor como si estuviera fuera de él. Ambas viven dentro del mismo dominio de fallo contra el que te estás asegurando, el mismo disco, la misma controladora, el mismo hipervisor y a veces el mismo rack. Dos copias en un proveedor es 2-1-1, y un solo evento de ransomware con acceso al almacenamiento montado lo colapsa a 1-1-1 antes de que te enteres. Guarda la tercera copia donde este servidor no pueda llegar usando las credenciales que él mismo guarda, y la regla empieza a hacer su trabajo.

Con los tres roles nombrados, las herramientas encajan solas: Borg y Restic producen la pata fuera del servidor con cifrado y deduplicación integrados, y el complemento de snapshots de la plataforma cubre el rol de rollback rápido. Las dos se confunden constantemente, y la siguiente sección traza la línea entre ellas antes de que la confusión te cueste una restauración.

Una snapshot es un rollback, no un backup

Las snapshots de la plataforma parecen backups porque ambos devuelven archivos, pero responden a desastres distintos. Una snapshot vive en la misma plataforma que el servidor en vivo, a menudo en el mismo pool de almacenamiento, el mismo clúster, la misma empresa. Es exactamente la herramienta correcta para el fallo que te causas a ti mismo: un despliegue roto, una actualización de modpack desastrosa, una edición de configuración que no arranca. Es la herramienta equivocada para el fallo que causa la plataforma, y la equivocada para el fallo que llega cifrado, porque ambos pueden tumbar la capa de snapshots junto con la de producción.

En VPSbit, las snapshots viajan con los planes VPS como complemento en el checkout, y ese es su alcance honesto: perfectas para el rollback previo a un cambio, demasiado poco profundas para llamarlas estrategia por sí solas. La pata fuera del servidor es donde una segunda máquina se gana el alquiler: un repositorio Borg o Restic en un destino que tú controlas mantiene las copias dentro de los mismos rieles de solo cripto y sin KYC que el origen, y el destino nunca contiene texto plano, algo que la siguiente sección convierte en permanente. Las dos capas cuestan juntos minutos al mes y responden a fallos que ninguna podría responder sola.

Dimensiona el destino con los números de estado que anotaste en la primera sección: pide un Core a $6/mes de lista — $4.80/mes en el plazo anual — mientras el repositorio quepa en 80 GB de NVMe, y sube al Titan a $24 de lista, $19.20 anual efectivo, cuando el historial deduplicado quiera los 320 GB y el puerto sin límite de tráfico de 10 Gbps para sincronizaciones iniciales más rápidas. Una sola factura lo cubre, y las doce ciudades te permiten poner la copia en una jurisdicción distinta a la del origen si la copia debe quedar fuera del alcance legal del origen.

Dos trampas específicas de las snapshots cierran esta sección. Primera, la mayoría de las implementaciones restauran discos enteros, no archivos: retroceder para rescatar una configuración revierte todas las bases de datos del servidor al mismo minuto, y por eso el pipeline de bases de datos que viene después en esta guía importa incluso con snapshots activadas. Segunda, la retención: las snapshots se guardan en generaciones, así que un mes de backups pueden ser tres generaciones de profundidad y no decirlo. Snapshot para velocidad; backup para sobrevivir; y deja que la prueba de restauración de la séptima sección mantenga honestas a las dos, porque ninguna va a confesar sus límites por sí sola.

El destino que acabas de alquilar nunca leerá lo que le envías, si configuras el cifrado en el origen como es debido. Ese único ajuste convierte un repositorio robado en un non-evento, y es el tema de la siguiente sección.

Cifra en el origen, para que el destino nunca sea un pasivo

La máquina más temible de tu diseño de backups es la que guarda todas las copias, salvo que no pueda leer ninguna. El cifrado del lado del cliente cambia el modelo de amenazas por completo: Borg y Restic cifran antes de que un solo byte salga del origen, así que el destino guarda texto cifrado, un destino comprometido no es una brecha, y un curioso con root en el destino ve ruido. Por eso mismo la pata fuera del servidor nunca debería ser un rsync plano sin cifrar a un directorio, por cómodo que parezca el primer día.

Ambas herramientas hacen que el camino por defecto sea el correcto. borg init --encryption=repokey crea un repositorio cuya clave se deriva de tu frase de contraseña y se guarda dentro del propio repo; restic init hace lo equivalente en el primer backup, y ambos están documentados sin rodeos en la documentación de Borg y el manual de Restic. Las frases de contraseña viajan por variables de entorno, BORG_PASSPHRASE y RESTIC_PASSWORD, que es lo que hace posibles las ejecuciones nocturnas desatendidas sin un humano frente al prompt. El modo keyfile, en cambio, divide la clave en un archivo bajo ~/.config/borg/keys/, lo cual es más estricto pero añade un segundo artefacto que perder. Elige un modo, escribe la decisión en el runbook y mantenlo durante la vida del repositorio.

Luego cierra la paradoja: la clave de cifrado es ahora la única pieza de estado irrecuperable de todo el diseño. Un repositorio sin su frase de contraseña es ruido aleatorio, Borg y Restic no van a hacer fuerza bruta por ti, y no existe ticket de soporte que repare una frase olvidada. Así que la clave misma recibe el tratamiento 3-2-1: la frase en un gestor de contraseñas, una copia impresa en un cajón si tu modelo de amenazas lo permite, y una línea en el runbook que diga qué modo usa el repo. Perder la clave pierde todas las copias a la vez, y es el único punto único de fallo que aún puedes crear en esta etapa.

Los fallos recurrentes son operativos, no matemáticos. Una frase pegada en .bashrc para que cron funcione significa que todo lo que lea tus dotfiles lee tu identidad de backup. Un repokey creado el viernes con la frase apuntada en una nota adhesiva que muere con un portátil convierte cuatro años de historial en ruido. Y el sutil: la clave funciona hoy porque está cacheada en tu shell, pero la prueba de restauración en una sesión limpia pide una frase que nadie recuerda. Cada uno de estos lo atrapa la prueba trimestral de restauración, y por eso mismo está programada y no se deja al heroísmo.

Archivos, configuraciones y claves ahora viajan cifrados y deduplicados. Las bases de datos necesitan una capa más encima, porque su estado cambia en mitad de la copia y una instantánea a nivel de archivo de un motor en marcha es una lotería, cosa que la siguiente sección arregla con un pipeline propio.

Las bases de datos quieren su propio pipeline

Copiar el directorio de una base de datos en marcha no es un backup; es una lotería de corrupción con pasos extra. Un motor como PostgreSQL o MySQL reparte los datos entre muchos archivos y bufferiza las escrituras en memoria, así que una copia byte a byte tomada en pleno vuelo pierde transacciones que existen en un archivo pero no en otro. La copia puede restaurar limpia, puede restaurar a medias o puede negarse a arrancar, y no sabrás cuál hasta la prueba de restauración que aún no has ejecutado. Las bases de datos se ganan un pipeline dedicado porque su consistencia vive en los límites de transacción, no en los límites de archivo.

El suelo es un volcado lógico consistente: pg_dump -Fc toma una instantánea consistente en un límite de transacción, comprimida y restaurable con pg_restore. MySQL responde con mysqldump --single-transaction, que hace lo equivalente para tablas InnoDB sin bloquear a los lectores. Ejecuta el volcado antes de la pasada a nivel de archivos, envía el archivo del volcado con todo lo demás, y el suelo diario se mantiene: las bases de datos obtienen archivado continuo donde la plataforma y el motor lo soportan, y volcados diarios como red de seguridad que sigue siendo mejor que nada.

El archivado continuo es la mejora, y PostgreSQL lo documenta sin rodeos: pon wal_level=replica, apunta archive_command a un destino de copia, y cada segmento de write-ahead se envía fuera del servidor según se llena, tal como describe el capítulo de archivado continuo. Reproduce el base backup más los segmentos archivados y llegas a cualquier punto en el tiempo, no solo a la noche anterior, lo que convierte un error de las 15:00 en una restauración a las 14:59 en lugar de perder el día entero. Esa es la diferencia entre una política de backup y una capacidad de recuperación, y cuesta una línea de configuración más el disco para guardar los segmentos entre envíos.

Los errores típicos son la versión y la deriva. Un volcado restaurado en una versión mayor más nueva puede funcionar; en una más antigua no, así que registra la versión del motor junto al volcado o convierte pg_dump --version en parte del nombre del archivo. Segundo, sincronizar por rsync /var/lib/postgresql mientras el servidor corre, porque el trabajo nocturno de archivos lo hace parecer gratis hasta que la restauración no arranca. Tercero, volcados que nunca se han restaurado: un archivo que pasa pg_restore --list ha demostrado que se parsea, no que se restaura. La prueba trimestral de la siguiente sección es lo que demuestra lo segundo, que es lo que importa.

Con el estado capturado de forma consistente y enviado cifrado, lo que queda es aritmética: cada cuánto ejecutar, cuánto conservar y cuánto historial necesita el repositorio. Los horarios y la retención vienen a continuación, y ambos se fijan con números en lugar de con estados de ánimo.

Horarios y retención, fijados por matemáticas y no por humor

¿Cada cuánto deberías hacer backup? Es la pregunta equivocada, porque la respuesta honesta depende de dos números que aún no has anotado: cuántos minutos de trabajo puedes permitirte perder y cuánto tiempo puedes permitirte estar caído. El primero fija el horario; el segundo moldea el diseño. Para la mayoría de los servidores las respuestas son más sobrias de lo esperado, archivos diarios y bases de datos continuas y una ruta de restauración ensayada, y por eso el suelo a lo largo de esta guía es diario en lugar de horario, y por eso lo horario rara vez sobrevive a su propia factura de ancho de banda.

Los archivos reciben una ejecución diaria como suelo; las bases de datos reciben archivado continuo donde se soporta, según el pipeline de arriba. La retención se convierte entonces en una escalera: borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 conserva siete diarias, cuatro semanales y seis mensuales, un por defecto 7-4-6 que encaja con la mayoría de las cargas. Restic habla la misma gramática con restic forget --keep-daily 7, y ambos comandos de prune pertenecen a la misma familia de entradas de crontab que el propio backup, ya que el formato de cron hace triviales las ejecuciones recurrentes. El repositorio no crece una copia completa cada noche, porque la deduplicación solo guarda los bloques cambiados, y el estado con mucho texto suele comprimir a una fracción de su tamaño bruto.

La aritmética del ancho de banda mantiene el horario honesto. Un empuje inicial de 80 GB por un puerto sin límite de tráfico de 1 Gbps son unos once minutos a velocidad de línea, en la práctica una tarde una vez que la sobrecarga del protocolo y los límites del disco dicen lo suyo; los deltas nocturnos posteriores son de segundos a minutos. Sin límite de tráfico importa aquí: un trabajo de backup es exactamente la carga que hace impredecible la facturación medida, y una copia fuera del servidor que te saltas para ahorrar ancho de banda es una copia que no tienes. Presupuesta la primera sincronización como un proyecto y las ejecuciones diarias como un reflejo.

Los modos de fallo son todos de sincronización. Podar antes de comprobar hace que un evento de corrupción de la noche anterior pueda podar la última generación buena, así que ejecuta borg check o restic check antes de podar, no después. Dos ejecuciones de cron solapadas corrompen el lockfile y entrelazan escrituras; envuelve el trabajo en flock o pásalo a un timer que rechace solapamientos. Y una retención demasiado ajustada, siete diarias sin nada detrás, significa que la corrupción lenta que descubres hoy ya rotó fuera del repositorio. La escalera existe precisamente para los fallos que tardan semanas en notarse.

El horario ya corre desatendido, y precisamente por eso la última pieza debe programarse con la misma disciplina: la prueba de restauración que decide si todo esto fue un backup o una afición. Es la séptima sección, y es la que importa.

La prueba trimestral de restauración es la única auditoría que cuenta

Un backup sin probar es una esperanza, no un backup, y la esperanza es exactamente lo que falla a las 4 de la madrugada. La prueba de restauración no es una actividad de emergencia; es una ejecución programada, trimestral, que restaura a un directorio temporal y compara. Su resultado no es una sensación de seguridad sino dos números: cuánto tardó la restauración y cuántos bytes diferían. Todo lo demás de esta guía es preparación para la mañana en que esos dos números aparecen en una invitación de calendario en lugar de en un canal de incidentes, y la diferencia entre esas dos mañanas es el rendimiento íntegro de esta disciplina.

La mecánica es aburrida a propósito. mkdir /srv/restore-test, luego borg extract o restic restore del último archivo dentro, luego diff -r contra las rutas de origen y comprobaciones puntuales con sha256sum en los archivos que pagan las facturas. Las bases de datos tienen su propio terreno de prueba: pg_restore a un clúster desechable, ejecutar la comprobación de esquema de la aplicación contra él y contar filas en las dos o tres tablas que el negocio lee de verdad. Anota el tiempo transcurrido, porque ese número es tu objetivo real de tiempo de recuperación, y pertenece al runbook y no a tu memoria.

Una vez al año, sube la apuesta: una reconstrucción completa en una VM de plástico usando el playbook de Ansible, el repositorio y nada más. Esa ejecución demuestra el runbook, no solo el repositorio, y es el único ensayo del desastre real: el servidor se ha ido, el reemplazo está en blanco, y las únicas entradas son el script y las copias. Una hora de ensayo al año es barata frente a un día de improvisación en el peor momento posible, y el ensayo suele encontrar el único paso que nadie escribió.

Dos maneras de que las pruebas mientan. Probar en el mismo servidor con credenciales cacheadas demuestra el repositorio pero no el runbook, porque la frase de la variable de entorno no es la frase que llevas en la cabeza. Y probar solo la extracción demuestra bytes, no servicio: una aplicación web restaurada en /srv/restore-test que nunca se ha arrancado puede cargar suposiciones de estado que el diff no ve. Programa la prueba como el backup, trimestral, con la misma disciplina de cron, porque las restauraciones sin probar fallan en silencio y el silencio es exactamente para lo que sirve la entrada del calendario.

Línea de estado, copias, cifrado, pipeline de bases de datos, retención, prueba: seis piezas móviles que se sostienen juntas o no. La sección final las ensambla en un único orden de operaciones que puedes ejecutar de principio a fin, en un solo servidor nuevo, en una sola sentada.

La rutina de backup 3-2-1, en el orden de ejecución

Empieza por la línea. Recorre el servidor, lista las rutas de estado, /etc, los directorios de bases de datos, /home, /srv — y mídelas con du -sh, anotando los números porque dimensionan el destino y predicen la restauración. En la misma sentada, actualiza el script de reconstrucción: el playbook de Ansible o el archivo cloud-init que convierte una imagen en blanco en este servidor. Si el script está obsoleto, actualizarlo ahora es parte del trabajo de backup y no una tarea aparte, porque el día que lo necesites no es el día para descubrir que referencia paquetes que ya no existen.

Segundo, alquila el destino e inicializa el repositorio. Una segunda máquina como destino de Borg o Restic mantiene la pata fuera del servidor sobre rieles en los que ya confías; inicialízala con cifrado el primer día, borg init --encryption=repokey o su equivalente en Restic, y pon la frase de contraseña en un sitio que sobreviva a un portátil muerto. Tercero, cablea el pipeline de bases de datos antes que cualquier otra cosa, porque tiene los requisitos de consistencia más estrictos: pg_dump -Fc como mínimo, archivado WAL si el motor y el horario lo soportan, y el volcado de transacción única para InnoDB. El paso de la base de datos va primero porque todo lo demás puede tolerar una copia a nivel de archivo, y esto no.

Cuarto, programa el trabajo diario de archivos con la escalera de retención adjunta, borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6, envuelto en flock para que las ejecuciones no se solapen, con las comprobaciones ordenadas antes de la poda. Quinto, pon la snapshot de la plataforma en el calendario como el ritual previo a los cambios: snapshot antes de actualizaciones de modpack y despliegues arriesgados, para que la pata de rollback rápido esté siempre fresca — la guía de servidores de juego muestra el ritual en acción. Las dos patas responden a fallos distintos, y el orden importa: la copia fuera del servidor te protege de la plataforma, la snapshot protege a la plataforma de ti.

Sexto, ejecuta la primera prueba de restauración la misma semana en que el horario entre en marcha, no en el trimestre en que teóricamente toca: extrae a /srv/restore-test, diff -r contra el origen, restaura la base de datos en un clúster de plástico y arranca la aplicación contra él. Luego pon la recurrencia trimestral en el calendario con el tiempo transcurrido anotado al lado. Cierra la sentada escribiendo el runbook: ubicación de la frase, copias de los keyfiles, modo del repo y los dos números de recuperación, para que la siguiente persona, que no eres tú, pueda ejecutarlo a las 4 de la madrugada.

A partir de ahí la rutina se mantiene sola: los trabajos diarios podan, las pruebas trimestrales demuestran, y la única tarea humana recurrente es mantener el script de reconstrucción fiel al servidor a medida que evoluciona. Cuando el estado crezca más allá del disco del destino, redimensiona primero el destino y segundo el repositorio, nunca al revés, porque un repositorio que no cabe es un repositorio que poda su propio historial en silencio.