Probar la restauración de la copia de un cliente: procedimiento

La guía sobre la estrategia 3-2-1 con Restic y S3 describe un control automático: un archivo centinela restaurado cada semana, que avisa cuando la cadena de copias se rompe. Es útil y conviene conservarlo. Pero responde a "¿se puede leer el repositorio?", no a "¿vuelve a funcionar el sitio del cliente y en cuánto tiempo?". Restaurar un archivo de unos pocos bytes no dice nada de una base de datos, de los archivos subidos, de la versión de PHP esperada ni de los secretos ausentes.

El ejercicio de esta guía restaura un sitio completo, a mano, en una máquina nueva, y extrae tres mediciones: una duración, la antigüedad de los datos y una lista de anomalías. Los dos mecanismos no compiten. El control automático detecta el fallo cada semana; el ejercicio trimestral demuestra la recuperación, con firma y fecha. Esa es la prueba que un cliente, una licitación o una auditoría acaba pidiendo.

Tampoco debe confundirse con el control de restauración de la lista de auditoría mensual de un VPS de cliente: ese verifica cada mes que se restaura un archivo o una base de datos; el ejercicio trimestral de esta guía vuelve a poner en marcha un sitio entero, cronómetro en mano.

Elija un sitio por cliente y por trimestre, alternando perfiles: un sitio apoyado en una base de datos, otro con archivos subidos voluminosos, un tercero con tareas programadas. Antes de empezar, reúna tres elementos fuera del servidor del sitio: el acceso al repositorio, la contraseña o la clave que lo abre y la lista de secretos de la aplicación.

A continuación alquile un VPS de prueba desechable, con el mismo sistema que producción, y prevea destruirlo al final de la sesión. En cuanto al esfuerzo, cuente como orden de magnitud editorial media jornada por trimestre para un sitio tipo, más para un repositorio voluminoso, menos cuando el procedimiento está rodado. Anote la hora de inicio antes del primer comando, nunca después.

El RTO constatado es la hora en que termina la restauración verificada menos la hora de inicio de la prueba. El RPO constatado es la diferencia entre la hora del incidente simulado y la marca de tiempo de la instantánea restaurada. Tomemos un ejemplo ficticio: incidente simulado a las 14:00, última instantánea tomada a las 03:00 del mismo día, es decir 11 horas de datos perdidos. Si el contrato promete 24 horas, es conforme; si promete 4, no lo es, y el registro debe escribirlo tal cual.

Un RTO medido en una prueba sigue siendo un suelo optimista: máquina nueva, nadie esperando, sin presión. Aun así vale más que un cálculo a ojo, sobre todo con un repositorio voluminoso: con un caudal modesto, el tiempo de descarga basta para volver irreal un RTO teórico. Mida el caudal real durante la restauración y anótelo en el registro.

Fatal: wrong password or no key found — Restic no encuentra ninguna clave que se abra con la contraseña proporcionada. Causas frecuentes que descartar una a una: contraseña con caracteres especiales alterados por el shell, contraseña leída de la entrada estándar, URL de repositorio S3 con el estilo equivocado, archivo de clave dañado. Pruebe --password-file o la variable RESTIC_PASSWORD, compruebe la URL del repositorio y después restic key list. Si la contraseña está realmente perdida, los datos del repositorio se pierden con ella: regístrelo como anomalía crítica.

Ningún punto de restauración reciente — restic snapshots no lista nada de la última semana: el trabajo de copia se detiene en silencio. Corrija el temporizador y añada una alerta.

pg_restore termina con errores ignorados — por defecto continúa y muestra un recuento al final. Repita con --exit-on-error para detenerse en el primer error, y léalo antes de dar la prueba por buena.

Los archivos están pero el sitio devuelve 403 — la restauración como root dejó los archivos con el propietario equivocado. Devuélvaselos al usuario del servidor web.

El registro cabe en una página: encabezado con cliente, sitio y fecha; tabla de los ocho campos; conclusión de una frase, conforme o no con los objetivos de RPO y RTO; plan correctivo fechado; firma. Reserve un recuadro final "No probado en este ejercicio": buzones de correo y entregabilidad, DNS y delegación, certificados TLS, servicios de terceros como el pago o un CRM, y cualquier otro sitio de la cuenta.

Un registro que no escribe sus límites se lee como "todo está respaldado", y es una promesa que nadie puede cumplir. Conserve los registros de cada trimestre: una sola prueba demuestra un día, una serie demuestra una práctica. Anote también la versión de PHP de cada sitio, como en la guía sobre el inventario de versiones de una cartera de clientes: es la trampa más frecuente al repetir la restauración.

Una cláusula útil nombra siete puntos: el alcance (archivos, bases de datos, configuración), la frecuencia, la retención, los objetivos de RPO y de RTO, la frecuencia y la prueba de los ensayos, la responsabilidad si la restauración falla y la persona que posee los accesos al repositorio. No es asesoramiento jurídico: haga revisar el texto por un abogado. Y no prometa nunca lo que la infraestructura subyacente no garantiza.

En este punto, las copias de ServOrbit.com son semanales en la gama de entrada, diarias en Pro y en todas las ofertas de hosting para revendedores. El RPO mínimo se deduce de esa frecuencia: hasta siete días con una copia semanal, hasta un día con una diaria. Un RPO inferior a un día exige, por tanto, una copia de aplicación propia de la agencia, además. En cuanto a la duración de la restauración, de una frecuencia no se deduce ningún compromiso: se mide, con el ejercicio anterior.

La objeción es conocida: el cliente no lo pide y el tiempo no se factura. Dos respuestas. Incluya en el plan de mantenimiento una línea "prueba de restauración trimestral, registro entregado", o facture aparte la media jornada. Y trate el registro como un entregable: tras un incidente muestra lo que se había probado y corregido; en la fase de venta responde a "demuéstrenlo" antes de que se haga la pregunta.

Para mantener el ritmo en una cartera, prevea una rotación: un sitio por cliente y por trimestre, con el calendario fijado a principios de año. El VPS de prueba se alquila y se destruye a demanda; las condiciones figuran en la página de la oferta.