Tu backup resucita en silencio a los usuarios que borraste

Todo backup incremental hace la misma suposición silenciosa: para respaldar lo que cambió, busca las filas que cambiaron. En un almacén clave-valor como Azure Table Storage o DynamoDB, "lo que cambió" significa "las filas cuyo timestamp de última modificación es más reciente que mi última marca de agua". Recorre la tabla, toma todo lo más nuevo, escríbelo. Rápido, barato, correcto.

Correcto para las escrituras. Ahora borra una fila.

La fila no recibe una marca de "borrada". No recibe un timestamp más nuevo. No se mueve a una papelera de reciclaje. Simplemente deja de existir. Estos almacenes no tienen marcadores de borrado ni un feed de cambios para las eliminaciones, así que una fila borrada no deja atrás absolutamente nada. Tu backup incremental, que encuentra los cambios escaneando timestamps más recientes, pasa de largo por el espacio vacío donde antes estaba la fila y no encuentra nada. No hay nada que encontrar. El borrado es invisible.

Lo que significa que tu backup todavía contiene la fila. Y aquí es donde una historia de pérdida de datos se convierte en una historia de seguridad.

Piensa en lo que suele significar un borrado en un sistema de autenticación. No borraste a ese usuario por diversión. Diste de baja a un empleado. Eliminaste una cuenta cuya contraseña apareció en un volcado de brecha. Revocaste un permiso OAuth después de que se filtrara un token. Retiraste el acceso de un administrador el día en que se fue. Cada una de esas es una decisión de seguridad, y ninguna sobrevive a un backup que no puede ver los borrados.

Así que restauras. Quizá por un desastre real, quizá solo a un clon de staging. El backup hace exactamente lo que le pediste: vuelve a poner cada fila que conoce. El empleado dado de baja vuelve a ser usuario. La contraseña comprometida vuelve a ser válida. El permiso revocado vuelve a funcionar. El administrador retirado vuelve a tener admin. Tu restauración no perdió datos. Revirtió tus decisiones de seguridad, en silencio, y te entregó un sistema que parece sano y está calladamente comprometido. Un backup que olvida un borrado es peor que no tener backup, porque confías en él.

La solución es dejar de tratar un borrado como la ausencia de una fila y empezar a tratarlo como un evento. Los borrados son datos.

Así que a los borrados les damos su propia tabla. Cada borrado del sistema pasa por un ITombstoneWriter inyectado que registra una lápida: la clave y la hora en que murió. No existe ninguna ruta de código que borre una fila sin dejar una lápida, porque el borrado y la lápida son una sola operación. Un backup incremental es entonces dos partes capturadas en una única marca de agua: los upserts (filas con timestamp más reciente) y las lápidas (borrados desde la última marca de agua). La restauración reproduce ambos en orden temporal, de modo que un borrado se aplica igual que una escritura, y una clave que fue borrada y luego recreada se resuelve a lo que haya ocurrido en último lugar. El espacio vacío por fin tiene un registro asociado.

Ese es todo el truco, y es pequeño. La razón por la que importa no lo es.

El patrón trasciende Table Storage y DynamoDB. Cualquier sistema que modele un borrado como "la fila ya no está" no puede respaldar, replicar ni sincronizar borrados, porque no hay nada que transportar. Aparece en replays de eventos ingenuos que solo reproducen creaciones y actualizaciones. Aparece en cachés que expiran pero nunca invalidan. Aparece en réplicas de lectura que se desvían porque el borrado nunca se propagó. Y es más peligroso exactamente donde los borrados son tu forma de imponer la seguridad, que en un sistema de identidad es en todas partes: revocación, bajas, rotación, bloqueo. Si tu estrategia de durabilidad solo rastrea las cosas que existen, preservará fielmente las cosas que te esforzaste en hacer que dejaran de existir.

Así que audita tus propios backups con una sola pregunta: si borro un usuario ahora mismo, hago un backup y lo restauro, ¿ese usuario desaparece? Si la respuesta honesta es "no estoy seguro", tu backup es una máquina del tiempo apuntando en la dirección equivocada. No te protege de tus errores. Los resucita: la contraseña que rotaste, el empleado que diste de baja, el token que revocaste.

Los borrados son datos. Respáldalos como tales.

Si prefieres que tus backups respeten un borrado sin que tengas que demostrar que lo hacen, para eso existe una plataforma. Authagonal deja una lápida por cada borrado, de modo que una restauración nunca devuelve a la vida una credencial revocada.