Recuperación de datos en Snowflake: Time Travel y Fail-safe

Imagina que el cierre mensual lleva dos días abierto cuando aparece el problema: una transformación ha sobrescrito datos que parecían correctos. El proceso terminó sin errores, los informes se actualizaron y varias personas tomaron decisiones con ellos. Ahora necesitamos volver atrás. Alguien recuerda que Snowflake tiene Time Travel y la conversación se relaja demasiado pronto.

La función puede resolver una parte importante del incidente. Pero entre recuperar una tabla y devolver al negocio un dato fiable hay trabajo que ninguna casilla de configuración decide por nosotros: identificar el momento válido, reconstruir las dependencias y distinguir las operaciones legítimas de las que propagaron el error. La recuperación merece diseñarse alrededor de lo que necesitamos volver a hacer.

¿Fail-safe sustituye a Time Travel?

No. Time Travel permite acceder al historial dentro de la retención efectiva; Fail-safe es un recurso posterior de recuperación gestionada por Snowflake, con límites y bajo mejor esfuerzo. Ninguno demuestra por sí solo que los consumidores puedan volver a operar con datos fiables.

El pasado disponible tiene una fecha de caducidad

Según la documentación de Time Travel, la retención estándar es de un día; ampliarla por encima de ese plazo requiere Enterprise Edition o superior. Para objetos permanentes puede llegar a 90 días. Son límites y posibilidades de configuración, no la prueba de que nuestras tablas estén conservando ese historial. Conviene separar la capacidad contratada de la retención efectiva.

Las tablas transitorias tienen otra protección: su Time Travel se limita a cero o un día y carecen de Fail-safe. Esa elección puede ser razonable para resultados reconstruibles. Se vuelve delicada cuando llamamos «intermedio» a un dato cuyo origen ya desapareció o cuyo reprocesamiento exige recursos que no tenemos disponibles.

Pensemos en un escenario hipotético: detectamos un error 36 horas después de producirse y la tabla conserva 24 horas de historial. Hemos llegado 12 horas tarde para recuperar con Time Travel el estado anterior al error. Los números son ilustrativos, pero la relación importa: el plazo de detección consume la ventana de recuperación. Una revisión semanal y una retención de un día pueden convivir perfectamente en una configuración y muy mal en un incidente.

Qué significa recurrir a Fail-safe

Snowflake define Fail-safe como un periodo no configurable de siete días posterior a Time Travel, durante el que el proveedor puede intentar recuperar datos. Es un servicio de último recurso, bajo criterio de mejor esfuerzo, y la recuperación puede tardar desde varias horas hasta varios días. No ofrece al usuario una segunda ventana normal de consulta histórica.

La documentación también recoge exclusiones: las tablas con datos ingeridos mediante Snowpipe Streaming Classic no están cubiertas por esa recuperación. Por eso sería imprudente extender una promesa general de Fail-safe a cualquier tabla sin revisar su modalidad y su origen.

Desde el punto de vista del negocio, «quizá podamos recuperarlo dentro de unos días» puede ser valioso y, a la vez, insuficiente para emitir pedidos esta tarde. La discusión necesita dos compromisos diferentes: cuánta información reciente aceptaríamos perder y cuánto tiempo podemos permanecer sin operar. Habitualmente los llamamos RPO y RTO. Mantener historial ayuda, pero los tiempos reales también dependen de accesos, validaciones y sistemas consumidores.

El diseño tampoco termina en esas dos funciones. Snowflake documenta copias de seguridad con políticas propias de conservación, disponibles en todas sus ediciones, y bloqueo de retención para Business Critical o superior. Permiten plantear necesidades distintas del historial de Time Travel. Elegir entre mecanismos y combinarlos exige definir qué fallo queremos cubrir; disponer de más funciones no sustituye esa decisión.

GitLab y la distancia entre tener copias y poder usarlas

El postmortem de GitLab del incidente del 31 de enero de 2017 sigue siendo una lectura incómoda y útil. Tras un borrado accidental, el equipo recurrió a una instantánea creada unas seis horas antes. Estimó que la pérdida afectó aproximadamente a 5.000 proyectos, 5.000 comentarios y 700 cuentas nuevas. Los repositorios de código y las wikis no perdieron sus datos.

Las copias habituales de base de datos estaban fallando por una incompatibilidad entre versiones de la herramienta de copia y PostgreSQL. El relato muestra una organización con mecanismos de protección que, llegado el momento, no podía utilizar como esperaba. Es un caso histórico de PostgreSQL, no una prueba de rendimiento ni un fallo de Snowflake. Su valor aquí es operativo: la existencia de una política y el resultado de una restauración son evidencias distintas.

Podemos reconocer esa distancia sin caer en la moraleja fácil de culpar a quien ejecutó el borrado. Si la continuidad de una plataforma depende de que nadie cometa un error bajo presión, hemos dejado una parte del diseño sin terminar.

Cadena de recuperación aceptada

La cadena de recuperación aceptada separa cuatro evidencias que conviene exigir al hablar de continuidad. Es un modelo de decisión propuesto aquí, no un procedimiento de restauración ni una garantía contractual.

Historial disponible

Existe una versión recuperable anterior al error, dentro de sus límites reales.

Estado coherente

El conjunto recuperado corresponde a un momento lógico que podemos justificar.

Dependencias reconstruidas

Conocemos los consumidores afectados y qué resultados deben corregirse.

Uso aceptado

Una persona responsable valida qué puede reanudarse y con qué discrepancias.

Una restauración que solo demuestra el primer eslabón acredita disponibilidad del pasado. La continuidad necesita llegar hasta la aceptación del uso. Por eso interesa medir cuánto tarda toda la cadena y qué pérdida resulta tolerable, sin confundir el tiempo de ejecutar una operación con el de resolver el incidente.

Restauración ≠ recuperación del servicio. Recuperar una tabla no retira los resultados erróneos ya distribuidos. RPO ≠ RTO. Uno expresa la pérdida de datos tolerable en términos de tiempo; el otro, el plazo objetivo de recuperación.

La tabla vuelve; las consecuencias no retroceden solas

En una plataforma analítica, un valor equivocado puede haber alimentado una segmentación comercial, un fichero entregado a un tercero o una alerta. Recuperar el origen no retira automáticamente esos resultados. Tampoco garantiza que todas las tablas relacionadas correspondan al mismo momento lógico.

Por eso una prueba útil de recuperación termina cuando una persona responsable puede aceptar el resultado para su uso. Hace falta saber qué dependencias se reconstruyeron, qué discrepancias permanecen y desde qué punto se reanuda el procesamiento. Esta parte tiene mucho que ver con la documentación que ayuda a trabajar: si solo enumera herramientas, durante el incidente habrá que improvisar las decisiones.

Una tabla reconstruible solo lo es mientras sigan disponibles sus datos de origen, su lógica y la capacidad necesaria para ejecutarla. Esa condición también merece fecha. Un cambio de proveedor, una depuración del almacenamiento o una transformación que utiliza valores actuales pueden hacer que repetir el proceso ya no produzca el mismo pasado.

No todas las tablas necesitan la máxima retención. Un cálculo desechable y un registro irreemplazable merecen tratamientos diferentes. Lo defendible es que esa diferencia responda a una decisión conocida, con pruebas y responsables, y que el ahorro no se apoye en una reconstrucción imaginaria.

En la próxima conversación sobre continuidad, una evidencia concreta vale más que una lista de funciones: cuándo se recuperó por última vez un conjunto representativo de datos, cuánto tardó y quién confirmó que volvía a servir. Si aún no existe esa evidencia, ya sabemos qué parte de la tranquilidad está pendiente de comprobar.