Compartir a través de

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.

Diagrama que ilustra cómo se realiza la copia de seguridad de un contenedor en varias regiones.

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. Hacer referencia a la marca de tiempo restaurable más reciente ayuda a confirmar que las copias de seguridad de recursos están hasta la marca de tiempo especificada y pueden restaurarse 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 entre estos dos modos depende de los escenarios. En la mayoría de los casos, se prefiere restaurar contenedores y bases de datos eliminados en una cuenta existente. Así se evita el costo de la transferencia de datos necesaria en caso de que se restauren en una nueva cuenta. En el escenario en el que se realizó la modificación accidental de datos, la restauración en una nueva cuenta podría ser la opción preferida.

¿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 VNET, control de acceso basado en rol de plano de datos RBAC o configuración del punto de conexión privado.
  • Todas las regiones de la cuenta de origen.
  • Procedimientos almacenados, desencadenadores y UDF.
  • Asignaciones de control de acceso basado en roles.

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

La característica de restauración a un momento dado admite los siguientes escenarios. 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.

Eventos del ciclo de vida con marcas de tiempo para una cuenta que se puede restaurar.

  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.

    Eventos del ciclo de vida con marcas de tiempo para una base de datos y contenedor que se pueden restaurar.

  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

La cuenta de Azure Cosmos DB con copia de seguridad continua de 30 días tiene un cargo mensual adicional para almacenar 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 cargo es una función de la cantidad de datos restaurados:

    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

Período de vida

  • El proceso de restauración predeterminado restaura todas las propiedades de un contenedor, incluida su configuración de TTL a un valor predeterminado, lo que puede provocar la eliminación de datos si la restauración se realiza sin forma de deshabilitar el TTL. Para evitar la eliminación, pase el parámetro para deshabilitar TTL en PowerShell (-DisableTtl $true) o cli (--disable-ttl True) al realizar la restauración.

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.

  • Multi region write no se admiten cuentas.

  • Synapse Link para las cuentas de base de datos que usan el modo de copia de seguridad continua es GA. La situación opuesta, el modo de copia de seguridad continua para las cuentas habilitadas para Synapse Link, está en versión preliminar pública. Actualmente, los clientes que deshabilitan Synapse Link desde contenedores no pueden migrar a la copia de seguridad continua. 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. Se debe agregar explícitamente otra región para la resistencia de 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.

  • 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.

  • Los índices únicos de la API para MongoDB no se pueden agregar, actualizar ni quitar 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