Resumen

  • La Backup Compliance Policy fija un mínimo de copias para todo el proyecto. Impide borrar instantáneas protegidas y reducir su conservación una vez creadas, cualquiera que sea el rol del usuario.
  • Al terminar un clúster protegido, sus instantáneas existentes siguen el calendario de copias. La conservación adicional posterior tiene otro régimen: los usuarios con el rol apropiado pueden borrarlas durante esa prórroga.

La ventaja de que el jefe no pueda hacerlo todo

Ser propietario de un proyecto suele traer una expectativa razonable: tener la última palabra. MongoDB Atlas vende una protección que recorta esa expectativa en el momento de borrar el pasado. El título sigue en la pantalla. La papelera deja de obedecerlo.

La Backup Compliance Policy prohíbe eliminar instantáneas protegidas, con independencia del rol. También impide reducir su retención después de tomarlas, desactivar Cloud Backup o rebajar las reglas de un clúster por debajo del mínimo del proyecto.

La utilidad está en esa resistencia. Una empresa puede querer que un administrador apresurado no elimine toda la historia de recuperación al limpiar un entorno. Puede querer poner la misma barrera a quien consiga controlar su cuenta. Conservar siempre una salida unilateral para el administrador debilitaría la promesa que está comprando.

MongoDB explica además que esta protección limita las vías para bajar el gasto de almacenamiento mediante borrado o reducción de plazos. La incomodidad económica y la resistencia técnica nacen de la misma decisión. El presupuesto debe entrar en la conversación antes de que esa decisión empiece a producir historia.

Dónde nace una obligación larga

La documentación sitúa el requisito en los clústeres dedicados M10 o superiores; aquí se examinan esos entornos de Atlas Core. El mínimo se aplica a todo el proyecto. Los clústeres existentes se ajustan y los nuevos lo heredan. Una política individual más exigente puede conservar un nivel superior.

Eso convierte la ubicación de un servicio en una decisión de conservación. Si una prueba breve se instala en un proyecto de retención larga, sus copias pueden durar mucho más que la prueba. El equipo puede dar por terminada la experiencia mientras el calendario del pasado sigue corriendo.

Cambiar la frecuencia futura tampoco borra el compromiso acumulado. Una reducción en el calendario del clúster afecta a las próximas copias, respetando el mínimo, y el registro de operaciones existente mantiene su ventana original. Las modificaciones de la política de protección rigen las instantáneas futuras. Los plazos ya protegidos exigen su propia gestión.

Por eso, una conversación de ahorro tiene dos partes: qué nuevas obligaciones se aceptan desde ahora y qué queda por conservar de lo anterior. Una orden de gasto emitida hoy llega tarde para cambiar por sí sola todos los vencimientos de ayer.

Un clúster jubilado deja herederos

El procedimiento de terminación distingue la conservación protegida de la copia ordinaria. Con la política activa, Atlas mantiene las instantáneas existentes conforme a las reglas después de terminar el clúster. Sin ella, pero con Cloud Backup activado, la interfaz permite escoger mantenerlas. Con Cloud Backup desactivado, esa opción no está disponible.

En Atlas Core, el registro de operaciones para restaurar a un punto del tiempo puede quedar estático hasta que deje de ser utilizable para esa recuperación. Lo que persiste es la historia que ya se había escrito. El clúster terminado deja de generar nuevas operaciones de negocio.

La herencia también ocupa casillas administrativas. Bajo la política, un proyecto con instantáneas pendientes no se puede eliminar; si no se pueden retirar todos los proyectos, tampoco se puede eliminar la organización. MongoDB indica además que el nombre del clúster terminado identifica sus copias e impide crear otro con ese mismo nombre.

El cierre necesita, por tanto, un destinatario para el inventario restante. Las horas de actividad del clúster tienen su cargo; el almacenamiento que sigue existiendo tiene el suyo. La factura de la historia exige un responsable aunque el responsable del producto se haya cambiado de equipo.

La excepción vacía incluye los archivos del fondo

La desactivación de una política en un proyecto no vacío pasa por la persona designada de seguridad o del área jurídica. Esa persona abre una solicitud de soporte y supera una verificación extensa. MongoDB Support aprueba la solicitud; después, los propietarios del proyecto pueden desactivar la política. Gestionar el proyecto y estar autorizado para iniciar esa petición son funciones distintas.

La excepción se aplica a proyectos realmente vacíos: sin clústeres activos, sin clústeres pausados y sin instantáneas conservadas de clústeres terminados. En ese caso, un propietario del proyecto o de la organización puede desactivar la política. La lista vacía de bases en marcha aún deja pendiente comprobar los cajones de atrás.

La configuración identifica al representante por nombre y dirección de correo del portal de soporte. Una dirección incorrecta requiere corregirse con Support. Si el compromiso sobrevive al empleo de esa persona, alguien debe heredar su capacidad de gestionar el trámite. Los documentos utilizados no publican un plazo real de respuesta que permita valorar la espera de un cliente concreto.

Guardar más y proteger más tienen calendarios distintos

La conservación adicional de instantáneas prolonga su presencia después del período protegido. Durante esa extensión, un usuario con el rol apropiado puede borrarlas. Cuando acaba, Atlas las elimina automáticamente.

Una copia vieja puede seguir ahí y haber perdido ya aquella barrera especial frente al borrado. Al comprador que busca resistencia frente a una cuenta autorizada le interesa la fecha de fin de protección. Al que quiere consultar un pasado más lejano también le interesa el final de la conservación adicional. Un gráfico que solo enseñe la edad máxima mezcla ambos objetivos.

Hay otra razón para mirar cada fecha. Cuando dos reglas producen la misma instantánea, se aplica la conservación más larga. MongoDB lo ilustra con copias diarias guardadas dos días y una copia del sábado guardada tres semanas: la instantánea compartida sigue la regla semanal. Es un ejemplo de precedencia, no un plazo impuesto a todos los proyectos.

Contar copias no basta para presupuestar

La guía de costes de los clústeres dedicados explica que Cloud Backups suele ser incremental y que el comportamiento concreto depende del proveedor de almacenamiento. Las cantidades reportadas y la región determinan el coste. La tarifa por GB al mes aparece en partidas diarias de GB-día; esa presentación distribuye el cargo a lo largo del tiempo. Las copias continuas tienen tarifas propias y combinan instantáneas con el registro interno de operaciones.

Determinados cambios de configuración, conmutaciones o tareas de mantenimiento de la nube subyacente pueden exigir varias instantáneas completas. A la inversa, los datos que otra instantánea siga referenciando permanecen aunque se borre una copia. Ni multiplicar el número de copias por la base actual ni esperar una rebaja proporcional ofrece una estimación fiable. Hacen falta volumen facturable, regiones, vencimientos y tarifas aplicables.

La empresa puede comprar esta restricción con buenos motivos. Lo que merece una firma adicional es su continuidad: quién financiará el pasado y responderá por él cuando el servicio que lo produjo ya no tenga reuniones, equipo ni hoja de ruta.