Publicar · Criterio KATA
Snapshots, hashes y vuelta atrás
Una copia que nunca se ha restaurado no es una copia: es una esperanza. La diferencia se descubre el peor día posible.
Cómo se ha elaborado esta guía
Qué estás leyendo
Describe el criterio de preservación de KATA y cómo lo comprobamos. Es método propio, no una norma del sector.
Qué es criterio propio y qué es estándar externo
- Criterio propio: La secuencia, el orden y los umbrales que se describen son decisiones metodológicas de KATA.
- Experiencia observada: Lo aprendido en los proyectos de KATA. No se presenta como dato estadístico ni se cuantifica.
- Estándar externo: Cuando se cita un hecho de un tercero se identifica su fuente oficial, con entidad y fecha.
La metodología completa está en el Método KATA.
Respuesta directa
Se preserva antes porque después ya no se puede. En el momento en que algo falla, el estado anterior o existe o no existe: no hay forma de crearlo retroactivamente.
En KATA la preservación tiene tres partes inseparables: una copia, un hash por archivo y una restauración probada. Las tres, o no cuenta.
Qué aporta cada parte
| Parte | Qué resuelve | Qué NO resuelve por sí sola |
|---|---|---|
| Copia | Permite volver a un estado anterior. | No dice si la copia está íntegra ni si se puede restaurar. |
| Hash por archivo | Detecta corrupción silenciosa: mismo tamaño, contenido distinto. | No repara nada; solo avisa. |
| Restauración probada | Demuestra que la vuelta atrás funciona de verdad. | No garantiza que funcione con otro volumen de datos. |
La corrupción silenciosa es el caso que se escapa
El fallo que más cuesta detectar no es el borrado: es la alteración. Un archivo con el mismo nombre, la misma fecha y el mismo tamaño, pero con bytes distintos, pasa desapercibido en cualquier comprobación visual.
Por eso la preservación de KATA registra SHA-256 por archivo. No es rigor decorativo: es la única forma de distinguir una copia buena de una copia que parece buena.
Cómo se prueba una restauración de verdad
Nuestro criterio es que una prueba de restauración sin daño real no prueba nada. En KATA se provoca el daño a propósito, sobre una copia, y se comprueba que la vuelta atrás lo repara.
- Se borra un directorio completo de contenido.
- Se borra un recurso crítico del que depende la presentación.
- Se trunca a cero un archivo de gobierno.
- Se corrompen bytes sin cambiar el tamaño, para verificar que el hash lo detecta.
- Se borra un binario, que no aparece en ninguna comparación de texto.
- Se restaura y se verifica hash a hash.
- Se comprueba que lo restaurado funciona, no solo que coincide: se ejecutan sus pruebas y su build.
El error que vemos con más frecuencia
Copias que viven en el mismo disco que aquello que protegen. Distinto directorio, mismo hardware. Un fallo físico o un cifrado por programa malicioso se lleva las dos.
Es un error que no da síntomas hasta el día en que importa, y por eso sobrevive tanto tiempo en tantos proyectos.
Dónde este criterio NO aplica
- Sistemas con base de datos transaccional en uso continuo: la copia de archivos no basta y el criterio se amplía con el volcado consistente de la base.
- Volúmenes muy grandes, donde el tiempo de restauración deja de ser despreciable y hay que medirlo, no suponerlo.
- Infraestructuras con instantáneas a nivel de almacenamiento, que resuelven parte de esto de otra manera.
- Este criterio describe la preservación de archivos y repositorio. No sustituye a una política de continuidad de negocio.
Preguntas frecuentes
¿Cada cuánto hay que probar la restauración?
Nuestro criterio: antes de cada cambio material en producción, y siempre que cambie el procedimiento o el destino de las copias. Una restauración probada hace seis meses sobre un sistema que ha cambiado no demuestra nada sobre el sistema de hoy.
¿No basta con comparar fechas y tamaños?
No. Es exactamente el caso que se escapa: una alteración puede conservar nombre, fecha y tamaño. Un hash criptográfico es lo único que distingue el contenido.
Práctica propia · revisada el 14 de septiembre de 2026
Una copia que permite volver atrás
Antes de una entrega guardamos los archivos anteriores y su configuración privada fuera de la carpeta pública. El manifiesto identifica qué archivos se sustituyen y cuáles se incorporan.
Tras publicar, comparamos el contenido servido con el paquete previsto y desactivamos las utilidades temporales. La recuperación y la comprobación posterior forman parte del mismo cambio.
Este ejemplo describe el procedimiento de KATA, no una certificación ni un resultado comercial.
Siguiente decisión
Continúa con una pregunta concreta
Dominio, DNS, hosting y HTTPS
Una lectura relacionada dentro del mismo método.
Dominio, DNS, hosting y HTTPS →
Webs corporativas y transaccionales
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Webs corporativas y transaccionales →
Ilustraciones conceptuales; no son fotografías de clientes.