Toda copia de seguridad funciona hasta el día en que hace falta. La snapshot está en la plataforma que acaba de caerse. El tarball nocturno lleva fallando en silencio desde que un disco se llenó en marzo. El volcado de la base de datos era una copia de archivo tomada a mitad de escritura, y no restaura nada. Las copias de seguridad son la única parte de un servidor que no puedes juzgar mirándola — solo restaurándola. Esto es cómo construir una que sobreviva a un fallo de hardware, a tus propias manos y a que otra persona tenga tus credenciales, sin entregar una copia legible de la máquina a quien la almacene.
Cuatro cosas destruyen un servidor, y cada una necesita algo distinto
Diseña la copia de seguridad en torno al fallo, no en torno a la herramienta. Cuatro escenarios explican, en esencia, cualquier pérdida real, y cada uno exige algo distinto de la copia que conservas. Una configuración que cubre uno de ellos parece completamente adecuada hasta que se topa con otro.
Fallo de hardware o del host
Se pierde el disco, el nodo o el centro de datos. Cualquier copia guardada en otro lugar te recupera. Este es el único fallo que una snapshot en la misma plataforma cubre de forma fiable, y es exactamente por eso por lo que tanta gente cree que las snapshots bastan.
Tus propias manos
Un flag equivocado, un script de migración apuntado a producción, una limpieza que borró más de lo previsto. El daño se replica al instante en cualquier réplica o espejo, así que lo que te salva es el historial — una versión de antes del error, no una copia actual de después de él.
Compromiso y ransomware
Un atacante con root tiene exactamente el mismo alcance que tu tarea de copias de seguridad: las mismas credenciales, el mismo destino, el mismo calendario. Si el servidor puede borrar sus propias copias de seguridad, las borrará. La supervivencia depende de que la copia sea append-only o esté completamente fuera de su alcance.
Perder la cuenta, no el servidor
Un impago, una cuenta suspendida, una retirada de servicio en la jurisdicción equivocada. El hardware está intacto y, sencillamente, no puedes acceder a él. Aquí solo ayuda una copia bajo un proveedor distinto, con una vía de pago distinta.
Anota contra cuál de los cuatro te estás defendiendo realmente antes de elegir nada. Una copia nocturna a un segundo directorio en el mismo disco cubre exactamente uno de ellos — el menos probable — mientras da toda la sensación de ser una copia de seguridad. La mayoría de las configuraciones que fallan en producción fallan porque nadie llegó a nombrar el escenario.
Las snapshots no son copias de seguridad
Las dos palabras se usan indistintamente, y describen objetos distintos con dominios de fallo distintos. Saber cuál de los dos tienes decide si realmente tienes algo o no.
Usa las snapshots para aquello en lo que son genuinamente excelentes: un deshacer de cinco segundos antes de tocar el kernel, el gestor de arranque o el esquema de una base de datos. Crea una, haz lo arriesgado, bórrala cuando funcione. Lo que nunca debes hacer es dejar que "hay una snapshot" se convierta en la razón de que no haya copia de seguridad — una snapshot comparte el destino de la plataforma que la aloja, y una cuenta suspendida se lleva a las dos a la vez.
3-2-1, y los dos números que todo el mundo se salta
La vieja regla sobrevive porque describe independencia, no un sistema de archivado: tres copias de los datos, en dos tipos de almacenamiento distintos, una de ellas en otro lugar. Dos añadidos cubren fallos que eran raros cuando se escribió la regla y hoy son habituales.
- Tres copias. Los datos en vivo más dos copias de seguridad. Dos copias significa que estás a una restauración fallida de quedarte sin ninguna.
- Dos soportes, o dos proveedores. En infraestructura alquilada, "soporte" en realidad significa independencia administrativa — una segunda copia bajo la misma cuenta, en la misma plataforma, pagada desde el mismo saldo, es una sola copia con pasos de más.
- Una externa. Edificio distinto, red distinta, jurisdicción distinta si eso te importa. /locations es la versión práctica de esto: elige una región que falle de forma independiente a la que estás protegiendo.
- Una inmutable o desconectada. Una copia que el propio servidor no pueda borrar, porque quien controla el servidor controla también sus credenciales.
- Cero restauraciones sin verificar. Una copia de seguridad que nunca has restaurado es una hipótesis. El número que cuenta es cuántas restauraciones has completado, no cuántas tareas informaron de éxito.
Haz una copia de seguridad de los datos, reconstruye el resto
El instinto es crear una imagen de todo. Es caro, lento de restaurar, y preserva fielmente el binario comprometido, el estado roto de los paquetes y la deriva de configuración que ya ni recuerdas haber creado. Un servidor contiene tres tipos de contenido, y solo uno de ellos pertenece a la copia de seguridad.
- Incluye /etc, /home, /root, /srv, la raíz de tu sitio web, el directorio de estado de tu aplicación, los volúmenes de contenedor con nombre, y un directorio con volcados recientes de la base de datos.
- Incluye la propia receta de despliegue — archivos compose, scripts de Ansible o de shell, las notas que escribiste a las 2 de la madrugada. Guárdala también en control de versiones, pero pon una copia en la copia de seguridad, para que la recuperación nunca dependa de que un segundo servicio esté accesible.
- Excluye /proc, /sys, /dev, /run y los directorios temporales. Son interfaces del kernel y espacio de trabajo temporal; copiarlos malgasta tiempo o directamente cuelga la tarea.
- Excluye las cachés de paquetes, los directorios de build, los árboles de dependencias y los virtualenvs — cualquier cosa que un paso de compilación regenere. En un servidor de aplicación típico, esto es la mayor parte del disco.
- Excluye los archivos en vivo de la base de datos si estás volcándola correctamente. Hacer copia de seguridad de ambos hace que la copia más grande e inútil sea la que alguien restaure a las tres de la madrugada.
- No excluyas los archivos ocultos. La mitad de lo que importa en una máquina Linux empieza con un punto.
Las bases de datos no sobreviven a una copia de archivo
Esta es, con diferencia, la razón más habitual por la que falla una restauración. Una base de datos en marcha mantiene estado en memoria y escribe fuera de orden; copiar sus archivos mientras funciona captura un estado incompleto, a medio escribir, que puede que restaure, puede que restaure corrupto en silencio, o puede que no restaure en absoluto. Haz un volcado como es debido, y luego haz una copia de seguridad del volcado.
- PostgreSQL: pg_dump por cada base de datos, o pg_dumpall para todo el clúster, roles incluidos. Cuando perder un día es inaceptable, añade archivado de WAL para poder recuperar a un punto concreto en el tiempo en lugar de a la noche anterior.
- MySQL o MariaDB: mysqldump con --single-transaction da una snapshot consistente en InnoDB sin bloquear las escrituras. En MyISAM no — una razón más para no usar MyISAM. Para conjuntos de datos grandes, una herramienta física como mariabackup restaura mucho más rápido que reproducir un volcado.
- SQLite: nunca copies el archivo. Usa el comando .backup o VACUUM INTO, que sí toman el bloqueo correctamente. Copiar una base de datos con un write-ahead log activo es una apuesta que tarde o temprano perderás.
- Redis: dispara un guardado en segundo plano y haz una copia de seguridad del archivo de snapshot resultante, o ejecútalo en modo append-only y haz una copia de seguridad del log. Copiar una snapshot en vivo a mitad de escritura te deja un archivo truncado que carga como un conjunto de datos vacío.
- Contenedores: el volumen es el dato. Detén el stack durante los segundos que tarda una copia, o ejecuta la herramienta de volcado dentro del contenedor — pero no metas en un tar el volumen de una base de datos en marcha y lo llames copia de seguridad.
- Cualquier otra cosa con un proceso persistente — índices de búsqueda, colas de mensajes, daemons de ledger — tiene su propio comando de exportación consistente. Encuéntralo ahora, no durante la caída.
Las snapshots de sistema de archivos resuelven esto desde el otro lado: LVM, ZFS y btrfs congelan una vista consistente del volumen en milisegundos, y tú haces la copia de seguridad de esa vista congelada mientras la base de datos sigue sirviendo. Esa es la respuesta correcta para conjuntos de datos donde un volcado tarda horas. No es una razón para saltarte el volcado en una base de datos de 200 MB, donde el volcado es más simple, portable entre versiones del motor, y legible por una persona cuando algo se ha puesto raro.
Elegir una herramienta
Cuatro herramientas cubren casi todos los casos. La propiedad que más importa es dónde ocurre el cifrado. Si los datos se cifran solo en tránsito, y luego en reposo por parte del proveedor de almacenamiento, el proveedor de almacenamiento puede leerlos — y la copia de seguridad se ha convertido, sin que nadie se dé cuenta, en el punto más débil de un sistema que blindaste en todo lo demás.
Elijas lo que elijas, la frase de contraseña o la clave debe existir en algún lugar que no sea el servidor del que estás haciendo copia de seguridad. Esta es la trampa en la que cae la gente cuidadosa: la clave del repositorio guardada en /root, fielmente incluida en la copia de seguridad dentro del propio repositorio que desbloquea. Imprímela, o guárdala en un gestor de contraseñas que puedas abrir desde una máquina que siga viva. Un repositorio que no puedes descifrar es indistinguible de no tener copia de seguridad en absoluto.
Dónde debería vivir la segunda copia
El destino es tanto una jurisdicción y una relación de facturación como un espacio en disco. Cuatro opciones, en un orden aproximado según lo independientes que son del servidor que estás protegiendo.
Un segundo servidor en otra región
La respuesta directa: una instancia barata en otro país, accesible por SSH, sin ejecutar nada más que sshd y un repositorio. Un plan /vps de 1 GB aguanta las copias de seguridad de una pequeña flota, y la cuenta se puede restringir a un único comando forzado para que una clave robada no abra ninguna shell.
Disco de tipo almacenamiento
En cuanto el conjunto de datos llega a cientos de gigabytes, la capacidad HDD sobre un enlace ascendente sin límite de tráfico cuesta mucho menos por terabyte que NVMe, y las escrituras de copias de seguridad no necesitan la latencia de un NVMe. /storage está pensado para esto: disco de nivel terabyte protegido con RAID, root completo, sin inspección de contenido.
Almacenamiento de objetos compatible con S3
Cómodo, con precio por gigabyte, y a menudo con soporte de bloqueo de objetos que da una inmutabilidad real. Lee la tarifa de salida de datos antes de confiar en él — recuperar un terabyte en una emergencia es un mal momento para descubrir lo que cuesta la recuperación.
Hardware propio
Un disco externo o una máquina en casa: se extrae (pull), no se envía (push). Más lento y manual, y la única copia de esta lista que ningún proveedor, orden judicial o disputa de facturación puede tocar. Vale la pena mantenerla para datos que de verdad no puedes recrear, aunque vaya una semana por detrás.
Haz que las propiedades de privacidad de la copia de seguridad correspondan a las del servidor. Cifrar un disco con LUKS y luego enviar cada noche copias de seguridad en texto plano a un bucket registrado con tu tarjeta deshace todo el ejercicio: los datos ahora son legibles, y están archivados a tu nombre. Si el servidor merecía pagarse de forma anónima, la copia también lo merece — cifra del lado del cliente, y compra el destino de la misma forma en que compraste el origen.
Construirla, paso a paso
- 1
Decide primero los dos números
Cuánto dato te puedes permitir perder — el hueco entre ejecuciones — y cuánto tiempo te puedes permitir estar caído. Todo lo demás se deriva de esas dos respuestas. Las copias de seguridad cada hora de un sitio estático son puro teatro; las copias de seguridad nocturnas de una base de datos de pedidos son una decisión que hay que tomar de forma deliberada, no heredar de un tutorial.
- 2
Crea el destino
Una segunda instancia en otra región con su propia clave SSH y un usuario dedicado sin privilegios cuyo home sea el repositorio. Ahí no se ejecuta nada más. Restringe la clave a un comando forzado para que una credencial robada solo pueda anexar copias de seguridad, nunca abrir una shell.
- 3
Genera la clave y guárdala en otro lugar
Una frase de contraseña larga y aleatoria, anotada en algún lugar que sobreviva a la pérdida del servidor. Inicializa el repositorio, y luego demuestra que puedes listar su contenido desde una tercera máquina usando solo lo que anotaste. Si no puedes, arréglalo antes de escribir una sola copia de seguridad.
- 4
Vuelca las bases de datos primero
Un script corto que escribe volcados consistentes en un directorio de staging y termina con código distinto de cero si alguno falla — que se ejecute antes de la copia de seguridad de archivos, no en paralelo con ella. Una tarea que sigue adelante después de un volcado fallido es como la gente termina con treinta días de archivos de cero bytes.
- 5
Haz una copia de seguridad de las rutas que importan
Apunta la herramienta a la lista de inclusión, aplica las exclusiones, y comprueba con sentido común la primera ejecución. Si un repositorio recién creado de un servidor de 40 GB se queda en 300 MB, algo se está saltando en silencio; si llega a 38 GB, tus exclusiones no están funcionando.
- 6
Programa la tarea y haz que el fallo sea ruidoso
Un timer de systemd con un retraso aleatorio, o cron si esa es la costumbre. Luego haz que la tarea informe: una señal de vida a un monitor cuando tiene éxito, y una alerta cuando esa señal deja de llegar. El fallo silencioso es el modo de fallo normal de las copias de seguridad, porque nada se rompe de forma visible cuando dejan de funcionar — hasta que se rompe todo.
- 7
Define la retención y poda de verdad
Cada hora durante un día, diaria durante quince días, semanal durante un par de meses, mensual durante un año. Luego ejecuta la poda y confirma que el repositorio deja de crecer. Una retención que está configurada pero nunca se ejecuta llena el destino y se lleva las copias de seguridad por delante.
- 8
Restaura algo hoy mismo
No una tarea de prueba — un archivo real, a un directorio provisional, abierto y comprobado. Luego pon una fecha en el calendario para la máquina completa. La primera restauración completa siempre saca algo a la luz: una ruta que falta, un permiso, un certificado, un usuario de base de datos que solo existió en la máquina antigua.
Enviar la copia de seguridad desde el servidor hacia fuera (push) significa aceptar que cualquiera con root en él puede destruir todas las copias. Hazlo al revés — que sea el host de copias de seguridad quien se conecte, extraiga los datos (pull) y se desconecte — y un servidor comprometido no puede alcanzar el repositorio en absoluto, porque no tiene ninguna credencial para ello. El modelo pull cuesta más trabajo de configurar, y es la mejora más grande que puede hacer la mayoría de las configuraciones.
La retención, y por qué más tiempo sale más barato de lo que parece
La retención normalmente se fija según lo que quepa en el disco, y luego se olvida. Merece una reflexión deliberada, porque decide qué errores son recuperables. Una ventana de siete días atrapa un archivo borrado el martes. No atrapa una corrupción que empezó hace seis semanas y salió a la luz cuando un informe dio un resultado extraño, ni a un intruso que estuvo quieto en la máquina durante un mes antes de actuar.
La deduplicación hace que esto sea mucho más barato de lo que sugiere la tabla: la segunda ejecución contra un servidor que apenas ha cambiado solo guarda lo que cambió, así que un año de puntos de restauración mensuales en una máquina de 40 GB normalmente cuesta unos pocos gigabytes en lugar de medio terabyte. Define la política según de qué necesitas poder recuperarte, y luego mira la factura. Normalmente descubrirás que te puedes permitir la versión generosa.
Inmutabilidad: la parte que detiene al ransomware
Todo lo anterior asume que el adversario es la entropía. Si el adversario es una persona con root, una tarea de copias de seguridad corriente es un manual de instrucciones — las credenciales están en la máquina, el destino está en la configuración, y el repositorio se borra antes de que empiece el cifrado. Cuatro mecanismos rompen esa cadena, y cualquiera de ellos cambia el resultado.
- Repositorios append-only. El modo append-only del lado del servidor de Borg, o el servidor REST de restic en modo append-only, aceptan datos nuevos y rechazan los borrados. El servidor puede escribir; solo tú, desde otro lugar, puedes podar.
- Copias de seguridad por extracción (pull). El host de copias de seguridad inicia la conexión y es quien tiene las únicas credenciales. El servidor de producción no tiene clave, ni dirección de destino, ni ninguna ruta hacia el repositorio.
- Bloqueo de objetos. Almacenamiento compatible con S3 con un periodo de retención impuesto a nivel de bucket, donde la propia capa de almacenamiento rechaza el borrado, sin importar lo que las credenciales permitirían de otro modo.
- Credenciales separadas por host. Una máquina comprometida no debería exponer el historial de todas las demás. Claves distintas, rutas distintas, restricciones distintas.
- Una copia que esté genuinamente desconectada. Un disco desenchufado es inmune a cualquier ataque remoto jamás escrito. Pasado de moda, e invicto.
El simulacro de restauración
Una restauración es un procedimiento, y un procedimiento que nadie ha ejecutado nunca es ficción. Haz esto una vez ahora y una vez cada seis meses, y anota lo que aprendas — las notas terminan siendo tan valiosas como los propios datos.
- 1
Despliega una instancia en blanco
La misma versión de sistema operativo, sin nada más instalado. Un VPS de corta duración es suficiente, y todo el ejercicio cuesta menos que un almuerzo.
- 2
Restaura usando solo lo que anotaste
La dirección del repositorio, la frase de contraseña, los comandos. Si necesitas algo que solo existe en el servidor que estás fingiendo que está muerto, acabas de encontrar el fallo — en un día en el que encontrarlo no cuesta nada.
- 3
Recupera los datos antes que la aplicación
Carga el volcado de la base de datos, pon los archivos donde deben ir, y luego arregla la propiedad y los permisos. La propiedad es la sorpresa habitual: los ID numéricos de usuario de la máquina antigua rara vez coinciden con los de la nueva.
- 4
Arranca el servicio y úsalo de verdad
No un comando de estado — inicia sesión, carga una página, ejecuta una consulta, envía un mensaje. Un servicio que arranca no es lo mismo que un servicio que funciona.
- 5
Cronométralo, y anota el número
¿Cuánto tardó todo el proceso? Ese es tu tiempo de recuperación real, y casi siempre es varias veces la estimación. Guarda las notas junto a la frase de contraseña, y actualiza ambas cada vez que cambie el stack.
Lo que cuesta, sinceramente
La copia de seguridad es el seguro más barato que existe en infraestructura, y aun así se salta habitualmente por precio. Algunas cifras concretas para un servidor pequeño, asumiendo que los datos comprimen y deduplican como lo hacen los datos normales.
Compara cualquiera de esas cifras con el coste de la caída que evitan. El objetivo es precisamente poner el número sobre la mesa — el argumento contra las copias de seguridad nunca es realmente sobre dinero en cuanto el dinero queda anotado.
Dónde encaja el proveedor
Un plan de copias de seguridad tiene las mismas dos dependencias que el servidor al que protege: un lugar independiente donde poner la copia, y una forma de pagarlo que no cree un nuevo rastro de quién eres. Las dos importan aquí incluso más que en el origen, porque la copia de seguridad es una copia completa de todo lo que el origen estaba protegiendo.
Todos los planes /vps y /storage de aquí se despliegan desde un saldo prepago en cripto sin KYC, en quince regiones recogidas en /locations — de modo que la segunda copia puede quedar bajo una jurisdicción distinta de la primera sin un segundo control de identidad en ningún punto de la cadena. Todas las instancias incluyen snapshots instantáneas para el deshacer de cinco segundos, el ancho de banda ilimitado significa que ni la primera subida ni la restauración de emergencia son un evento medido, y /storage añade disco de nivel terabyte protegido con RAID desde $8.99/mo sin inspección de contenido. /pay-with cubre las monedas aceptadas, /offshore-hosting explica qué es lo que la jurisdicción realmente cambia, y /guides tiene las piezas complementarias sobre cifrado de disco y sobre qué puede ver un proveedor de una máquina y qué no.
La checklist
- Nombra el fallo contra el que te estás defendiendo antes de elegir una herramienta.
- Trata las snapshots como un botón de deshacer, nunca como la copia de seguridad.
- Haz una copia de seguridad de los datos y la configuración; reconstruye el sistema operativo desde un script.
- Vuelca cada base de datos con su propio comando de exportación consistente, y haz una copia de seguridad del volcado.
- Cifra del lado del cliente, antes de que nada salga de la máquina.
- Guarda la frase de contraseña del repositorio en algún lugar que sobreviva a la pérdida del servidor.
- Pon al menos una copia bajo un proveedor, una región y una vía de pago distintos.
- Haz que una copia sea append-only, por extracción (pull) o esté desconectada, para que un root comprometido no pueda borrarla.
- Genera una alerta ante la ausencia de una ejecución exitosa — los fallos son silenciosos, y el silencio es el síntoma.
- Restaura un archivo hoy mismo, y la máquina completa dos veces al año. Cronométralo y anótalo.
¿Bastan por sí solas las snapshots del proveedor?
No, y este es el hueco más habitual en configuraciones que por lo demás son cuidadosas. Una snapshot vive en la misma plataforma que el volumen que copia, así que no sobrevive a un fallo a nivel de plataforma, a una suspensión de cuenta o a un impago — tres de los escenarios en los que más la necesitas. Además, normalmente conserva solo un historial corto, así que no recuperará un archivo borrado el mes pasado ni una corrupción que empezó hace seis semanas. Las snapshots son excelentes como un deshacer de cinco segundos antes de un cambio arriesgado: consérvalas, úsalas a diario, y mantén una copia de seguridad de verdad en otro lugar.
¿restic o Borg — cuál debería usar?
restic si el destino es almacenamiento de objetos o una cuenta SSH sencilla, porque no necesita nada instalado en el extremo remoto y habla S3 de forma nativa. Borg si el destino es una máquina Linux que controlas y quieres su modo de servidor append-only y una compresión ligeramente más ajustada. Los dos deduplican, los dos cifran y autentican del lado del cliente, los dos son maduros y están ampliamente desplegados, y cualquiera de los dos es una elección defendible. La respuesta equivocada es pasarte un mes comparándolos mientras el servidor no tiene copia de seguridad alguna — elige uno esta misma tarde y cambia de opinión más adelante si alguna vez importa.
¿Con qué frecuencia debería hacer copia de seguridad de un VPS?
El intervalo es, sencillamente, la cantidad máxima de trabajo que estás dispuesto a rehacer. Para un sitio estático, semanal es honesto. Para cualquier cosa en la que escriban los usuarios, diario es el mínimo, y cada hora sale barato en cuanto la deduplicación hace su trabajo — la segunda ejecución del día normalmente guarda solo unos pocos megabytes. Sopesa el valor de un día de datos frente al coste de almacenar veinticuatro puntos de restauración en lugar de uno, y la respuesta suele ser evidente.
¿Debería hacer copia de seguridad de todo el disco, o solo de mis datos?
Datos y configuración, en casi todos los casos. Una imagen completa del disco restaura la máquina exactamente como estaba, incluido el compromiso del que te estás recuperando y el estado de paquetes que ya no entiendes, y es más lenta tanto de crear como de restaurar. Una copia de seguridad a nivel de archivo de /etc, los datos de tu aplicación y los volcados de tu base de datos, combinada con un script que reconstruye el sistema operativo, restaura más rápido y más limpio. Crea una imagen del disco cuando necesites preservación forense exacta a nivel de bit, o cuando la máquina sea una caja negra que construyó otra persona.
Mi proveedor dice que los discos están cifrados — ¿está cifrada mi copia de seguridad?
No en ningún sentido que te sirva de algo. El cifrado del lado del proveedor protege frente a que se saque un disco de un rack; el proveedor tiene la clave, así que los datos siguen siendo legibles por el proveedor y por cualquiera que pueda obligar al proveedor a entregarlos. El cifrado del lado del cliente — restic, Borg, la capa crypt de rclone, o un archivo cifrado — significa que lo que llega al destino no tiene ningún sentido sin una frase de contraseña que nunca salió de tu máquina. Para un stack en el que la privacidad es crítica, esta distinción lo es todo, porque la copia de seguridad es una copia completa de todo lo que el servidor estaba protegiendo.
¿Cómo evito que el ransomware cifre también mis copias de seguridad?
Da por hecho que cualquier cosa que el servidor pueda alcanzar, un atacante con root puede destruirla — las credenciales, el destino y el calendario están todos ahí, en la propia máquina. Rompe ese alcance de una de estas tres formas: un repositorio append-only que acepta escrituras pero rechaza los borrados, un modelo pull en el que el host de copias de seguridad se conecta hacia dentro y el servidor no tiene ninguna credencial en absoluto, o almacenamiento de objetos con un bloqueo que impone la propia capa de almacenamiento. Después añade una retención larga, para que un compromiso lento y silencioso no salga simplemente de la ventana de retención antes de que alguien lo note, y mantén una copia desconectada, donde ningún ataque remoto pueda alcanzarla.
