Backups que funcionan: la regla 3-2-1

El backup que existe y el backup que salva

Hacer una copia es fácil. Que esa copia te devuelva los datos intactos el día que arde el disco es otra cosa, y es la única que cuenta. Entre ambas hay un espacio lleno de detalles que solo se ven cuando ya es tarde: el volcado que se cortó a medias y nadie miró, la copia que vivía en la misma máquina que se murió, el fichero cifrado cuya contraseña se fue con el portátil anterior.

La regla 3-2-1 es un resumen viejo y probado de cómo evitar casi todos esos finales. No es una ley ni un producto: es una forma de contar las copias para localizar el punto débil antes de que lo localice el incidente.

Qué dice la regla, y qué dice de verdad

Tres copias de los datos, en dos tipos de soporte distintos, con una guardada fuera del lugar principal. Contadas con honestidad, el original en producción ya es la primera copia; así que en la práctica son los datos vivos más dos copias.

Un montaje típico y suficiente para la mayoría: los datos en el servidor, una copia automática en un disco aparte —un soporte distinto, mejor físicamente separado y no solo otro volumen del mismo sistema— y una tercera que sale fuera, a otra máquina en otro sitio o a un almacenamiento remoto. Lo de «dos soportes» evita que un mismo fallo (un controlador de disco, un sistema de ficheros corrupto) se lleve original y copia juntos. Lo de «una fuera» evita que un problema del sitio —un incendio, un robo, un borrado en cascada, un proveedor que tiene un mal día— arrastre todo lo que está bajo el mismo techo.

Por qué la copia en la misma máquina no cuenta

Es la trampa más común: se programa una copia y se deja en otra carpeta del mismo servidor. Da sensación de estar cubierto, y cubre un caso —el borrado accidental de un fichero—, pero solo ese.

Piensa en lo que realmente tumba un servidor. Un disco que muere se lleva sus particiones, la de datos y la de la copia por igual. Un cifrado malicioso que entra por una credencial filtrada cifra todo lo que la cuenta pueda escribir, y la carpeta de backups suele estar en esa lista. Un comando de borrado lanzado con root en el directorio equivocado no distingue entre datos y copia. En los tres casos la copia local desaparece en el mismo instante que el original.

La copia de fuera es la que rompe esa cadena, precisamente porque está en otro sitio y, bien hecha, fuera del alcance de la misma cuenta que administra el servidor.

La rotación: guardar historia sin reventar el disco

Una sola copia que se sobrescribe cada noche tiene un agujero enorme: si el problema entró hace tres días y no te enteras hasta hoy, tu única copia ya es una copia del problema. Por eso se guarda un histórico —varias generaciones— y se van podando las viejas para que el disco no se llene. A eso se le llama rotación.

Una cadencia sensata guarda muchas copias recientes y cada vez menos según se alejan en el tiempo: unas cuantas diarias, unas cuantas semanales, quizá alguna mensual. Suficiente para volver a un punto anterior al desastre aunque tardaras días en detectarlo, sin acumular años de volcados que nadie va a abrir.

El pseudocódigo de abajo resume el gesto completo: copiar, sacar fuera, podar el histórico y —la línea que se suele dejar fuera— comprobar de vez en cuando que una copia restaura.

# cada noche: copia + poda del históricocopiar datos a copia-localcopiar copia-local a destino-fuera   # la que de verdad salvaconservar 14 diarias, 8 semanales; borrar el resto# una vez al mes: probar que restaura de verdadrestaurar copia-del-dia en sitio-apartesi los datos cuadran → ok; si no → avisar

Mira dos cosas. La copia que salva no es la local, sino la que sale fuera. Y la poda tiene un orden —conservar lo definido, borrar el resto— para que un fallo de espacio no acabe borrando lo que no debía.

Restaurar de prueba: el gesto que casi nadie hace

Un backup que nunca se ha restaurado no es un backup: es una hipótesis. Puede que el volcado esté corrupto, que le falte una tabla, que el proceso llevara semanas fallando en silencio porque nadie leía el aviso. Nada de eso se ve mirando el tamaño del fichero. Se ve al intentar recuperarlo.

La prueba no consiste en sobrescribir producción con la copia —eso sería jugársela—. Consiste en restaurar en un sitio aparte, un entorno de usar y tirar, y comprobar que los datos cuadran: que el número de registros tiene sentido, que un puñado de valores conocidos están donde deben, que la aplicación arranca contra ellos. Un checksum o un recuento rápido responden a la única pregunta que importa: ¿esto vale?

Conviene fijarlo como rutina, no como algo que se hace «cuando haya tiempo». Una vez al mes es un punto de partida razonable para la mayoría; cuanto más críticos los datos, más a menudo. Y merece la pena cronometrarlo: el día real no querrás descubrir que recuperar lleva seis horas cuando el negocio aguantaba dos.

Cuánto puedes perder y cuánto puedes esperar

Dos preguntas fijan casi todo lo demás. La primera: si algo falla ahora mismo, ¿cuántas horas de datos te puedes permitir perder? Si la respuesta es «una mañana entera no», una copia diaria no basta y hay que copiar más a menudo. La segunda: cuando toque restaurar, ¿cuánto tiempo puedes estar caído? De ahí sale cómo de rápido tiene que ser el proceso y dónde conviene tener la copia más a mano.

Poner número a esas dos cosas, aunque sea a ojo, ordena el resto del diseño: la frecuencia de las copias, cuántas generaciones guardar y si la copia de fuera basta con que llegue en horas o tiene que estar lista en minutos.

Cifrado, y una copia que nadie pueda tocar

Si las copias contienen datos personales o de clientes, viajan y se guardan cifradas. No es solo por cumplir la ley: una copia sin cifrar en un sitio remoto es una filtración esperando a pasar. El precio de cifrar es que la clave pasa a ser tan valiosa como los datos —perderla es perder la copia igual que perder el disco—, así que la clave se guarda aparte, en un sitio del que también haya respaldo, y nunca junto a la única copia que protege.

Hay un escalón más para quien puede permitírselo: que al menos una copia sea inmutable o esté desconectada, de modo que ni una credencial robada con todos los permisos pueda borrarla o cifrarla. Es la respuesta directa al chantaje por cifrado: si la copia buena no se puede tocar desde el servidor comprometido, el chantaje se queda sin palanca.

Señales de que tus copias no valen tanto como crees

Sin auditar nada a fondo, hay síntomas que delatan una estrategia frágil:

• Nadie sabe decir cuándo se restauró por última vez, o la respuesta es «nunca».
• La única copia está en el mismo servidor, o en el mismo proveedor y bajo la misma cuenta.
• Los avisos de fallo van a un correo que nadie lee, o directamente no hay aviso.
• No hay histórico: la copia de hoy pisa la de ayer.
• Se sabe que «hay backups», pero nadie sabe qué incluye la copia ni qué se queda fuera.

Cualquiera de esos puntos convierte una copia de seguridad en una falsa sensación de seguridad, que es peor que no tener nada porque relaja la guardia.