El error de migración que casi me cuesta la base de datos completa

Migrar de proveedor de base de datos siempre suena más simple en el plan que en la ejecución real. El nuestro sonaba especialmente simple: mismo motor, misma versión, solo cambiaba quién alojaba los servidores. Ese supuesto casi nos cuesta caro.

Lo que dimos por sentado

Asumimos que las políticas de backup automático del proveedor nuevo funcionaban igual que las del anterior. Nunca lo confirmamos por escrito ni lo probamos antes de migrar en serio, porque "es el mismo motor de base de datos" sonaba suficiente.

Lo que pasó en producción

El script de migración corrió bien. Los datos se movieron. Todo se veía perfecto durante casi una semana, hasta que necesitamos restaurar una tabla que un compañero había modificado por error. Ahí descubrimos que el backup automático del proveedor nuevo corría con una frecuencia mucho menor a la que teníamos configurada antes, y el snapshot más reciente disponible tenía casi dos días de atraso.

// lo que asumimos que existía
backup_frequency: "cada 1 hora"

// lo que en realidad venía configurado por defecto
backup_frequency: "cada 24 horas"

Cómo lo resolvimos

Configuramos manualmente la frecuencia de backup apenas encontramos el problema, y agregamos una alerta que revisa todos los días que el snapshot más reciente no tenga más de dos horas de atraso. Perdimos parte de un día de datos de una sola tabla, algo recuperable pero que nos dejó con el susto suficiente como para no volver a asumir nada.

La lección real

"Mismo motor" no significa "misma configuración por defecto". Cada proveedor tiene sus propios valores iniciales, y la única forma segura de saberlo es leyendo su documentación específica o probándolo antes de depender de eso en producción.

Ahora, antes de dar por migrado cualquier servicio crítico, hacemos una prueba real de recuperación de backup el mismo día. Si no podemos restaurar algo en un ambiente de prueba, no confiamos en que vamos a poder restaurarlo cuando de verdad lo necesitemos.