Sin restauración no hay copia de seguridad

Todo el mundo está de acuerdo con el título. Casi ningún panel lo refleja.

La razón no es la pereza. Es que tres pruebas genuinamente distintas llegan por la misma tubería, se guardan en columnas contiguas y acaban dibujadas como una sola marca verde. Una vez que son una sola marca, la afirmación más fuerte del grupo toma prestada en silencio la credibilidad de la más barata, y un cliente lee «protegido» cuando lo que ocurrió de verdad fue que un trabajo terminó con código cero.

Dedicamos una ronda a separar esas tres cosas en nuestro propio esquema, y una segunda ronda a medir un Proxmox Backup Server real para averiguar cuáles de ellas puede darnos de verdad. Esto es lo que quedó.

Tres pruebas, y no son intercambiables

La primera es la más barata y es la que enseña todo producto. Vale exactamente lo que dice: un proceso terminó. Las garantías que hay detrás de cada modo de vzdump hablan de lo que ese proceso podía y no podía prometer sobre el estado del invitado, y ninguna de esas garantías sobrevive al contacto posterior con un almacén de fragmentos corrupto.

La segunda es evidencia real y es fácil leer en ella más de lo que dice. Más sobre esto abajo.

La tercera es la única que responde a la pregunta que el cliente está haciendo de verdad, y es la única que obliga a construir algo en lugar de a leer algo. Esa asimetría es la razón de que normalmente falte.

Qué afirma realmente una verificación verde

Proxmox Backup Server puede verificar una instantánea: relee los fragmentos y los contrasta con el manifiesto. Cuando eso ha ocurrido, el listado de instantáneas lleva un objeto verification con un estado dentro.

Eso es algo genuinamente útil de saber, y es más estrecho de lo que parece. Dice que los bytes de ese almacén de datos son los bytes que se escribieron. No dice que la máquina vaya a arrancar. No dice que la aplicación de dentro vaya a iniciarse. No dice que la base de datos estuviera en un estado coherente en el instante de la instantánea. Y si la copia está cifrada en el lado del cliente, no dice que alguien conserve todavía la clave: una comprobación de integridad sobre texto cifrado pasa perfectamente cuando la clave ya no está.

Así que el estado vive en su propia columna de nuestro esquema, y está documentado en el código como perteneciente a la prueba dos, para no mezclarse nunca con «restauración demostrada». La prueba tres tendrá su propia tabla el día que alguien la construya. Añadir un cuarto valor a un enum existente habría sido medio día de trabajo y una fuente permanente de confusión.

Un campo ausente no es un fallo

Nuestra columna tiene tres valores: correcto, fallido y desconocido. El del medio no es el interesante.

Medido contra un Proxmox Backup Server 4.2 vivo con instantáneas reales: una instantánea que nunca ha pasado por una tarea de verificación sencillamente no tiene clave verification. El campo está ausente. Eso es distinto de una verificación que se ejecutó y falló, y juntarlas cuesta caro en ambas direcciones. Al ponerlo por defecto en correcto, toda instantánea sin comprobar pasa a estar comprobada. Al ponerlo por defecto en fallido, toda instantánea histórica de la base de datos está de pronto ardiendo. El tercer valor existe para decir lo único cierto: no se sabe nada.

Un almacenamiento normal de Proxmox no rellena nunca esa columna, porque su listado de contenido no lleva ningún concepto de verificación. Eso no es una carencia de nuestra integración. Eso es la respuesta.

Un detalle honesto más, porque es de los que se redondean. El objeto verification que medimos lleva un estado y un identificador de tarea, y ninguna marca de tiempo. Así que el momento de «verificado el» que registramos es el momento en que nosotros vimos ese estado por primera vez, que es una pregunta distinta de «cuándo verificó esto el almacenamiento». Responde a «desde cuándo se sabe esto». Si una versión futura publica el instante real, la columna debería pasar a llevarlo y el comentario que explica todo esto debería borrarse.

Vacío tiene que significar vacío

Aquí está la regla más afilada de toda esta zona, y no tiene nada que ver con la verificación.

Cualquier sistema que liste puntos de restauración de forma periódica acaba deduciendo algo de la ausencia de una instantánea: estaba aquí la semana pasada, ahora no está, luego se podó o se borró. Esa inferencia carga peso, y solo es válida si un listado vacío correcto está genuinamente vacío.

Así que medimos qué responde de verdad un servidor de copias cuando un listado va mal, porque «un array vacío» y «un error que parece un array vacío» tienen que poder distinguirse. Cuatro casos, todos medidos contra esa misma instancia 4.2 viva:

• un espacio de nombres vacío responde 200 con un array vacío;
• un espacio de nombres que no existe responde 400 con un error de no encontrado, y no con una lista vacía;
• un almacén de datos que el token no puede auditar responde 403;
• un token incorrecto responde 401.

Tres de esos cuatro tienen que convertirse en errores concretos y no en resultados. Si a alguno se le permite llegar a la lógica de reconciliación como «el listado funcionó y ahí no hay nada», entonces una errata en el nombre de un espacio de nombres marca como desaparecido todo el historial de copias de un cliente. El modo de fallo no es una caída. Es una pantalla que deja de mencionar en silencio que existen copias de seguridad.

Esta es la misma clase de trampa que un hipervisor que responde 200 antes de que el trabajo haya empezado: el código de respuesta está bien, y no es la respuesta a la pregunta.

La credencial no debería poder romper nada

La decisión de seguridad más útil de todo esto es también la más aburrida.

El token que un cliente crea para un destino de copias necesita leer instantáneas y el estado del almacén de datos. No necesita borrar, olvidar, podar ni verificar. Esas son operaciones aparte que pertenecen a quien sea dueño del almacenamiento, en su propia planificación, con su propia identidad.

Construimos la integración sin ningún comando de escritura, lo que convierte la afirmación en estructural y no en aspiracional, y luego lo comprobamos desde el otro lado: con un token que solo tiene derechos de auditoría, un borrado sobre una instantánea responde 403. Esa es la forma a la que hay que apuntar. Una integración de solo lectura cuya credencial es capaz de podar es una integración de solo lectura exactamente hasta que alguien escribe un bucle con un error de una unidad dentro.

Hay un corolario que los proveedores de hosting fallan en la dirección contraria. Si la plataforma elimina un servidor, la cuestión de la retención es una decisión que tiene que tomar el cliente, no un valor por defecto que elige el código. Quitar la única copia que quedaba de los datos de alguien como efecto secundario de ordenar una fila es algo que le ha pasado a empresas reales.

Qué tiene que ser una prueba de restauración, si se construye

La prueba tres es donde está el trabajo, y merece la pena escribir las restricciones antes de escribir el código, porque casi todas van de no provocar un incidente con la propia prueba.

Una prueba de restauración necesita un sitio aislado donde restaurar: una red sin ruta a producción, identificadores temporales, direcciones temporales, direcciones de hardware temporales. Nunca la dirección de producción, y nunca la dirección de hardware de producción, porque un duplicado en una red viva es una caída provocada por uno mismo mientras comprobaba que podía recuperarse de una caída. Necesita cuotas estrictas, porque restaurar la máquina más grande de una flota dentro de un grupo de pruebas es un evento de capacidad. Necesita un plazo y una limpieza garantizada, ya que la máquina a veces no llegará a levantarse y algo tiene que eliminarla igualmente. Y necesita no enviar notificaciones, porque una alerta de monitorización procedente de una copia de prueba que se hace pasar por el sistema real va a despertar a alguien.

También necesita una política de finalización explícita, y aquí es donde todo el asunto se gana el nombre. Arrancada es un nivel. Alcanzable es otro. El agente de invitado respondiendo es otro. Los sistemas de ficheros montados son otro. Una aplicación respondiendo a una comprobación de salud definida por el cliente es el nivel que coincide con lo que un cliente quiere decir con «recuperable». Hay que elegir uno, registrar cuál se eligió junto al resultado, y no dejar nunca que un nivel inferior se muestre con la etiqueta de uno superior.

Solo entonces puede un servidor mostrar «restauración demostrada», y debería llevar la fecha, el punto de restauración exacto, el entorno en el que se ejecutó, las comprobaciones que pasaron y cuánto tiempo se conserva la evidencia. Cualquier cosa menor y la expresión es decoración.

Lo que dejaríamos por escrito

1. 01Nombrar las tres pruebas por separado en el esquema, antes de tener las tres. Las nuestras son columnas separadas y una tabla que todavía no existe, lo cual se lee mejor que una sola columna con un comentario que pide disculpas.
2. 02Guardar «desconocido» como un valor real. Cualquier valor por defecto que no sea «desconocido» es una mentira sobre al menos una de las filas.
3. 03Hacer que un listado vacío demuestre que está vacío, y convertir cualquier otra respuesta en un error distinto antes de que llegue a nada que reconcilie.
4. 04Dar a la integración una credencial que no pueda borrar, y comprobar después desde fuera que no puede.
5. 05Escribir qué tendría que significar «restauración» en cada caso, a qué nivel de finalización, antes de que nadie ponga una marca verde al lado.

Nuestro propio estado, dicho con claridad: las dos primeras pruebas están construidas y medidas, y no tenemos prueba de restauración. La función de copias de seguridad está detrás de una bandera y no está a la venta. Esa es la diferencia entre un plan y una afirmación, y es la misma diferencia de la que va todo este artículo.

La integración que hay detrás de estas mediciones se construyó para Provibr. La cuestión de tiempos relacionada, qué pasa cuando una copia tarda más que el plazo que se le dio, está en un tiempo de espera no es un botón de parada; el lado de los contenedores en las copias de Proxmox está en máquina virtual o contenedor en Proxmox.