Una copia que nunca has restaurado no es una copia

¿Por qué una copia que nunca has restaurado no cuenta como copia?

Una copia de seguridad son dos cosas y normalmente solo se hace la primera: guardar y recuperar. Guardar se configura una tarde y se olvida. Recuperar no se configura, se demuestra. Mientras no lo hayas demostrado no tienes una copia: tienes un fichero que pesa mucho y una suposición. Entre una cosa y otra hay mucho que puede estar roto sin que nadie lo note. El volcado se cortó a mitad. El cifrado funciona perfecto y la clave estaba en el servidor que se ha muerto. La copia es de una versión del motor que ya no existe. Ninguno de esos problemas da la cara al hacer la copia. Todos la dan el día que la necesitas.

• La copia se descarga entera con las credenciales que tendrías ese día.
• La aplicación arranca con esos datos en un sistema limpio, no solo la base de datos.
• Un dato reciente aparece en pantalla: un pedido, una factura, un cliente.

Mi copia se hace sola, ¿cómo voy a saber si lleva meses sin ejecutarse?

Las copias automáticas dejan de ejecutarse por motivos aburridos. Se rota una contraseña y la tarea ya no entra. Caduca un token. Se llena el disco y el volcado se queda a medias. Se migra el servidor y la tarea no se copió. En ninguno de esos casos suena una alarma: los sistemas avisan cuando algo falla ruidosamente, no cuando algo deja de pasar, y el silencio se lee como que todo va bien. Hay que vigilar la ausencia: que te avise cuando la copia no llega, no cuando llega.

• Que aparezca un fichero nuevo en el plazo esperado, con aviso automático si no llega.
• Que pese lo que tiene que pesar. Un fichero de tres kilobytes suele ser un mensaje de error comprimido.
• Que el aviso llegue a una persona con nombre, y a un sitio que esa persona mira.

Mi copia guarda la base de datos, pero no los ficheros subidos

Casi ninguna aplicación guarda todo su estado en la base de datos. La base guarda filas, y esas filas apuntan a ficheros que viven en otro sitio: fotos de producto, PDF de facturas, adjuntos, documentos que sube el cliente. Si copias solo la base, restauras un catálogo con las imágenes rotas y facturas que no se abren. Los datos están y el negocio no funciona. Para saber qué te falta, monta la copia en una máquina vacía y apunta todo lo que tienes que escribir a mano para que aquello arranque. Eso es justo lo que no estás copiando.

• Ficheros subidos y generados: imágenes, PDF, exportaciones, adjuntos.
• Configuración y secretos: claves de API, credenciales de pasarelas, variables de entorno. Suelen vivir solo en el servidor.
• Tareas programadas, colas, certificados y el dominio.
• Lo reconstruible y lo que no: un índice de búsqueda se regenera, un adjunto de hace tres años no.

¿Sirve de algo tener la copia en el mismo servidor que el original?

Una copia solo sirve si sobrevive a lo que le pase al original. Si está en el mismo disco, el mismo servidor o la misma cuenta, comparte destino con él. No hablo solo de hardware roto. Un borrado hecho con las credenciales correctas se lleva el original y la copia. Un cifrado malicioso recorre las unidades montadas, y la carpeta de copias suele estarlo. Una cuenta suspendida se lleva todo lo que hay dentro. Por eso la idea clásica de tres copias, en dos soportes y una fuera de tu sitio sigue valiendo. Lo importante es que exista al menos una copia que la aplicación no pueda tocar.

• Credenciales separadas: la clave que usa la web para funcionar no debería poder borrar copias.
• Varias fechas hacia atrás. Si sobreescribes cada noche, el día que algo se corrompe copias el problema encima de lo bueno.
• Otra cuenta u otro proveedor, y saber quién tiene acceso, porque una copia mal guardada también es una fuga.

La restauración tarda ocho horas y mi negocio no aguanta ocho horas parado

El tiempo forma parte del diseño y casi nunca se mide. Restaurar no es copiar un fichero. Es descargar por una línea que no da más de sí, importar, reconstruir índices, levantar servicios y apuntar el dominio. Con prisa y sin documentación delante. Si eso son ocho horas y pierdes ventas cada hora, el problema ya no es la copia: es que la estrategia no encaja con lo que aguanta el negocio. Puedes bajar el tiempo con una réplica ya encendida, con instantáneas del disco en vez de un volcado lógico, o con un entorno de reserva esperando. O puedes bajar el daño: una página de solo lectura, un modo consulta, un cuaderno para seguir tomando pedidos. Decídelo antes del incidente, no durante.

Cuánto puedo permitirme perder y cuánto puedo permitirme estar parado

Solo hay dos preguntas, y son de negocio, no de informática. Primera: cuánto trabajo puedes permitirte perder. Esa cifra es la distancia entre el incidente y la última copia buena. Si copias a las tres de la madrugada y se rompe a las seis de la tarde, pierdes el día entero. Ponle contenido: cuarenta albaranes que hay que volver a meter, o pedidos que ni sabrás identificar. Segunda: cuánto tiempo puedes estar parado sin que te haga daño de verdad. Con esos dos números la estrategia se decide sola. Si puedes perder un día, la copia diaria vale. Si no puedes perder una hora, necesitas copias continuas del registro de transacciones o una réplica, y eso es otro presupuesto. Si aguantas dos días parado, restaurar a mano sirve. Si no aguantas dos horas, hace falta algo levantado esperando. Y no todos tus sistemas valen lo mismo.

• Qué se puede rehacer a mano y qué información es irrecuperable.
• Quién decide restaurar, y quién decide si esa persona no está.

Cómo hacer un simulacro de restauración paso a paso

Un simulacro es una tarde de trabajo y cambia lo que sabes de tu sistema. Se hace así.

• Elige un sistema y una fecha. Mejor no la de anoche: coge una de hace dos semanas, que es donde aparecen los agujeros.
• Escribe antes lo que crees que va a pasar: cuánto tardarás y qué necesitarás. Ese pronóstico vale tanto como la prueba.
• Restaura en un sitio aparte: una máquina nueva, un entorno de pruebas, tu portátil. Nunca encima de producción.
• Arranca el cronómetro cuando empiezas a buscar la copia, no cuando ya la tienes. Buscar credenciales cuenta como tiempo de caída.
• Antes de levantar la aplicación, corta sus salidas: correo, pasarela de pago, avisos, sincronizaciones. Una copia con las integraciones vivas puede mandar mensajes reales o cobrar de verdad.
• Levanta la aplicación entera, no solo la base: ficheros, configuración, tareas.
• Verifica con datos concretos elegidos de antemano: el último pedido, una factura con su PDF, la foto de un producto, el número de filas de una tabla.
• Apunta lo que te ha faltado: la clave que no estaba, el paso que nadie había escrito, el fichero que no venía.
• Arregla eso y repite. La segunda vuelta es la que demuestra algo.
• Deja el procedimiento escrito donde puedas leerlo con el sistema caído, y pon fecha al siguiente con una persona asignada.
• Que lo haga alguien que no montó el sistema. Si solo sabe restaurar quien lo construyó, no tienes un procedimiento: tienes una dependencia.

Preguntas frecuentes