Copia de seguridad continua con la característica de restauración a un momento dado de Azure Cosmos DB

  • Artículo

SE APLICA A: NoSQL MongoDB Gremlin Table

La característica de restauración a un momento dado de Azure Cosmos DB ayuda en varios escenarios, como por ejemplo:

  • Recuperación de una operación de escritura o eliminación accidental dentro de un contenedor.
  • Restauración de una cuenta, una base de datos o un contenedor eliminados.
  • Restauración en cualquier región (donde existan copias de seguridad) en el momento dado de la restauración.

Azure Cosmos DB realiza la copia de seguridad de datos en segundo plano sin consumir ningún rendimiento aprovisionado (RU) adicional ni afectar al rendimiento y la disponibilidad de la base de datos. Las copias de seguridad continuas se crean en todas las regiones en las que existe la cuenta. Por ejemplo, una cuenta puede tener una región de escritura en Oeste de EE. UU. y regiones de lectura en Este de EE. UU. y Este de EE. UU. 2. A continuación, se puede realizar una copia de seguridad de estas regiones de réplica en una cuenta remota de Azure Storage en cada región correspondiente. De manera predeterminada, cada región almacena la copia de seguridad en cuentas de almacenamiento con redundancia local. Si la región tiene habilitadas las zonas de disponibilidad, la copia de seguridad se almacena en cuentas de almacenamiento con redundancia de zona.

Diagram illustrating how a container is backed up across multiple regions.

La ventana de tiempo disponible para la restauración (también conocido como período de retención) es el más bajo de las dos opciones siguientes: 30 días y 7 días.

La opción seleccionada depende del nivel elegido de copia de seguridad continua. El momento dado para la restauración puede ser cualquier marca de tiempo dentro del período de retención no más allá del punto en el que se creó el recurso. En el modo de coherencia fuerte, las copias de seguridad realizadas en la región de escritura están más actualizadas en comparación con las realizadas en las regiones de lectura. Las regiones de lectura pueden retrasarse debido a problemas de red u otros de carácter transitorio. Al realizar la restauración, puede obtener la marca de tiempo restaurable más reciente de un recurso determinado en una región específica. Obtener la marca de tiempo más reciente garantiza que el recurso ha realizado copias de seguridad hasta la marca de tiempo especificada, y puede restaurar en esa región.

Actualmente, puede restaurar el contenido de una cuenta de Azure Cosmos DB (API de NoSQL o MongoDB, API para Table o API para Gremlin) en un momento dado a otra cuenta. Puede realizar esta operación de restauración a través de Azure Portal, la CLI de Azure (la CLI de Azure), Azure PowerShell o plantillas de Azure Resource Manager.

Redundancia del almacenamiento de copia de seguridad

De forma predeterminada, Azure Cosmos DB almacena datos de copia de seguridad en modo continuo en blobs de almacenamiento con redundancia local. En el caso de las regiones que tienen configurada la redundancia de zona, la copia de seguridad se almacena en blobs de almacenamiento con redundancia de zona. En el modo de copia de seguridad continua, no se puede actualizar la redundancia de almacenamiento de copia de seguridad.

Diferentes formas de restauración

El modo de copia de seguridad continua admite dos maneras de restaurar contenedores y bases de datos eliminados. Se pueden restaurar en una nueva cuenta como se documenta aquí o restaurarse en una cuenta existente como se describe aquí. La elección depende de los escenarios y el impacto. En la mayoría de los casos, se prefiere restaurar contenedores y bases de datos eliminados en una cuenta existente para evitar el costo de la transferencia de datos necesaria en el caso de que se restauren en una nueva cuenta. En los escenarios en los que haya modificado los datos accidentalmente, lo correcto es restaurarlos en una cuenta nueva.

¿Qué se restaura en una cuenta nueva?

En un estado estable, se realiza una copia de seguridad de todas las mutaciones realizadas en la cuenta de origen (lo que incluye las bases de datos, los contenedores y los elementos) de forma asincrónica en 100 segundos. Si los elementos multimedia de la copia de seguridad de Azure Storage están inactivos o no están disponibles, las mutaciones se conservan localmente hasta que el los elementos multimedia estén disponibles. A continuación, las mutaciones se vacían para evitar la pérdida de la fidelidad de las operaciones que se pueden restaurar.

Puede optar por restaurar cualquier combinación de contenedores de rendimiento aprovisionados, una base de datos de rendimiento compartida o toda la cuenta. La acción de restauración restaura todos los datos y sus propiedades de índice en una cuenta nueva. El proceso de restauración garantiza que todos los datos restaurados en una cuenta, una base de datos o un contenedor tienen la garantía de que el tiempo de restauración especificado es coherente. La duración de la restauración dependerá de la cantidad de datos que sea necesario restaurar. La configuración de coherencia de la cuenta de base de datos recién restaurada será la misma que la configuración de coherencia de la cuenta de base de datos de origen.

Nota:

Con el modo de copia de seguridad continua, las copias de seguridad se crean en todas las regiones en las que está disponible su cuenta de Azure Cosmos DB. De manera predeterminada, las copias de seguridad creadas para cada cuenta de región son localmente redundantes y tienen redundancia de zona si la cuenta tiene habilitada la característica de zona de disponibilidad para esa región. La acción de restauración siempre restaura los datos en una cuenta nueva.

¿Qué es lo que no se restaura?

Las configuraciones siguientes no se restauran después de la recuperación a un momento dado:

  • No se puede restaurar un subconjunto de contenedores en una base de datos de rendimiento compartido. Toda la base de datos se puede restaurar en su conjunto.
  • Firewall, red virtual, RBAC del plano de datos o configuración de puntos de conexión privados.
  • Todas las regiones de la cuenta de origen.
  • Procedimientos almacenados, desencadenadores y UDF.
  • Asignaciones de control de acceso basado en roles. Estas deberán volver a asignarse.

Puede agregar estas configuraciones a la cuenta restaurada una vez completada la restauración.

Marca de tiempo de restauración para cuentas activas

Para restaurar cuentas activas de Azure Cosmos DB que no se eliminan, es recomendable identificar siempre la marca de tiempo de restauración más reciente para el contenedor. A continuación, puede usar esta marca de tiempo para restaurar la cuenta a su versión más reciente.

Escenarios de restauración

A continuación, se muestran algunos de los escenarios clave que se abordan con la característica de restauración a un momento dado. Los escenarios [1] a [3] muestran cómo desencadenar una restauración si la marca de tiempo de restauración se conoce de antemano. Sin embargo, puede haber escenarios en los que no conozca la hora exacta de un daño o una eliminación accidental. Los escenarios [4] y [5] muestran cómo detectar la marca de tiempo de restauración con las nuevas API de fuente de eventos en la base de datos o los contenedores que se pueden restaurar.

Life-cycle events with timestamps for a restorable account.

  1. Restaurar una cuenta eliminada: puede ver todas las cuentas eliminadas que se pueden restaurar en el panel Restaurar. Por ejemplo, si la cuenta A se elimina en la marca de tiempo T3. En este caso, basta la marca de tiempo justo antes de T3, la ubicación, el nombre de la cuenta de destino y el grupo de recursos para restaurar desde Azure Portal, PowerShell o la CLI.

    Life-cycle events with timestamps for a restorable database and container.

  2. Restaurar los datos de una cuenta en una región determinada: por ejemplo, si la cuenta A existe en dos regiones, Este de EE. UU. y Oeste de EE. UU. en la marca de tiempo T3. Si necesita crear una copia de la cuenta A en Oeste de EE. UU. , puede hacer una restauración a un momento dado desde Azure Portal, PowerShell o la CLI con Oeste de EE. UU. como la ubicación de destino.

  3. Recuperar de una operación de escritura o eliminación accidental dentro de un contenedor con una marca de tiempo de restauración conocida: por ejemplo, si sabe que el contenido del contenedor 1 dentro de la base de datos 1 se modificó accidentalmente en la marca de tiempo T3. Puede realizar una restauración a un momento dado desde Azure Portal, PowerShell o la CLI en otra cuenta en la marca de tiempo T3 para recuperar el estado deseado del contenedor.

  4. Restaurar una cuenta a un momento dado antes de la eliminación accidental de la base de datos: en el Azure Portal, puede usar el panel fuente de eventos para determinar cuándo se eliminó una base de datos y buscar la hora de restauración. De un modo similar, con la CLI de Azure y PowerShell, puede descubrir el evento de eliminación de la base de datos si enumera la fuente de eventos de la base de datos y, luego, desencadena el comando de restauración con los parámetros necesarios.

  5. Restaurar una cuenta a un momento dado antes de la eliminación o la modificación accidental de las propiedades del contenedor: en Azure Portal, puede usar el panel de la fuente de eventos para determinar cuándo se creó, modificó o eliminó un contenedor a fin de encontrar la hora de restauración. De un modo similar, con la CLI de Azure y PowerShell, puede descubrir todos los eventos del contenedor si enumera la fuente de eventos del contenedor y, luego, desencadena el comando de restauración con los parámetros necesarios.

Permisos

Azure Cosmos DB permite aislar y restringir los permisos de restauración de una cuenta de copia de seguridad continua a un rol o una entidad de seguridad concretos. Para más información, consulte el artículo Permisos.

Precios

Las cuentas de Azure Cosmos DB que tienen habilitada la copia de seguridad continua de 30 días incurrirán en un gasto mensual adicional por concepto de almacenamiento de la copia de seguridad. Tanto el nivel de 30 días como el de 7 días de copia de seguridad continua incurren en gastos para restaurar los datos. El costo de restauración se suma cada vez que se inicia la operación de restauración. Si configura una cuenta con copia de seguridad continua pero no restaura los datos, en la factura solo se incluye el costo de almacenamiento de copia de seguridad.

El ejemplo siguiente se basa en el precio de una cuenta de Azure Cosmos DB implementada en Oeste de EE. UU. Los precios y el cálculo pueden variar en función de la región que use; consulte la página de precios de Azure Cosmos DB para más información.

  • Todas las cuentas habilitadas con la directiva de copia de seguridad continua con 30 días incurren en un gasto mensual para el almacenamiento de copia de seguridad que se calcula como se indica a continuación:

    USD 0,20/GB * Tamaño de los datos en GB en la cuenta * Cantidad de regiones

  • Cada invocación de API de restauración incurre en un cargo único. El gasto es una función de la cantidad de datos restaurados y se calcula como se indica a continuación:

    USD 0,15/GB * Tamaño de los datos en GB.

Por ejemplo, si tiene 1 TB de datos en dos regiones:

  • El costo del almacenamiento de copia de seguridad se calcula como (1000 * 0,20 * 2) = USD 400 al mes

  • El costo de restauración se calcula como (1000 * 0,15) = USD 150 por restauración

Sugerencia

Para más información sobre cómo medir el uso de datos actual de la cuenta de Azure Cosmos DB, consulte Exploración de Información de Azure Cosmos DB de Azure Monitor. El nivel de 7 días continuo no conlleva cargos por la copia de seguridad de los datos.

Nivel continuo de 30 días frente al nivel continuo de 7 días

  • El período de retención de un nivel es de 30 días frente a 7 días para otro nivel.
  • El nivel de retención de 30 días se cobra por el almacenamiento de copia de seguridad; no se cobra el nivel de retención de 7 días.
  • La restauración se cobra en cualquier nivel

Claves administradas por el cliente

Consulte ¿Cómo afectan las claves administradas por el cliente a las copias de seguridad continuas? para obtener información:

  • Configuración de la cuenta de Azure Cosmos DB al usar claves administradas por el cliente junto con copias de seguridad continuas.
  • ¿Cómo afectan las claves administradas por el cliente a las restauraciones?

Limitaciones actuales

Actualmente, la funcionalidad de restauración a un momento dado tiene las siguientes limitaciones:

  • Solo se admiten las API de Azure Cosmos DB para SQL, MongoDB, Gremlin y Table para la copia de seguridad continua. Actualmente, no se admite la API de Cassandra.

  • No se admiten cuentas de escritura de varias regiones.

  • Actualmente, Azure Synapse Link se puede habilitar en cuentas de base de datos de copia de seguridad continua. Pero la situación opuesta todavía no se admite; no es posible activar la copia de seguridad continua en las cuentas de base de datos habilitadas para Synapse Link. Y el almacén analítico no se incluye en las copias de seguridad. Para más información sobre la copia de seguridad y el almacén analítico, consulte Copia de seguridad del almacén analítico.

  • La cuenta restaurada se crea en la misma región en la que existe la cuenta de origen. No se puede restaurar una cuenta en una región en la que la cuenta de origen no existe.

  • La ventana de restauración solo es de 30 días para el nivel continuo de 30 días y siete días para el nivel continuo de 7 días. Estos niveles se pueden cambiar, pero las cantidades reales (7 o 30) no se pueden cambiar. Además, si cambia de nivel de 30 días a nivel de 7 días, existe la posibilidad de pérdida de datos en días posteriores al séptimo.

  • Las copias de seguridad no son resistentes a los desastres geográficos, de manera automática. Tendrá que agregar explícitamente otra región a fin de tener resistencia para la cuenta y la copia de seguridad.

  • Mientras una restauración está en curso, no modifique ni elimine las directivas de administración de identidades y acceso (IAM). Estas directivas conceden los permisos para que la cuenta cambie cualquier configuración de firewall de red virtual.

  • Las cuentas de Azure Cosmos DB for MongoDB con copia de seguridad continua no admiten la creación de un índice único para una colección existente. Para esta cuenta, se deben crear índices únicos junto con su colección. Para ello, use los comandos de extensión de creación de colección.

  • La funcionalidad de restauración a un momento dado siempre se restaura en una nueva cuenta de Azure Cosmos DB. Actualmente no se admite la restauración de una cuenta existente. Si está interesado en proporcionar comentarios sobre la restauración en contexto, póngase en contacto con el equipo de Azure Cosmos DB mediante su representante de cuenta.

  • Después de la restauración es posible que, en determinadas colecciones, se pueda recompilar el índice coherente. Puede comprobar el estado de la operación de recompilación mediante la propiedad IndexTransformationProgress.

  • El proceso de restauración restaura todas las propiedades de un contenedor, incluida la configuración de TTL. Como resultado, es posible que los datos restaurados se eliminen inmediatamente si se configuraron de este modo. Para evitar esta situación, la marca de tiempo de restauración debe ser antes de que se agreguen las propiedades de TTL en el contenedor.

  • Los índices únicos de la API para MongoDB no se pueden agregar ni actualizar al crear una cuenta en modo de copia de seguridad continua. Tampoco se pueden modificar al migrar una cuenta de modo periódico a continuo.

  • Es posible que la restauración en modo continuo no restaure la configuración de rendimiento válida a partir del punto de restauración dado.

Pasos siguientes