Compartir vía

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

SE APLICA A: NoSQL MongoDB Gremlin Tabla de

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.
  • Restaurar 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 forma predeterminada, cada región almacena la copia de seguridad en cuentas de almacenamiento con redundancia local. Si la región tiene habilitadas 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.

El período de tiempo disponible para la restauración (también conocido como período de retención) es el valor inferior 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, Azure PowerShell o las 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 cuenta nueva o en una cuenta existente. 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. Esto evita el costo de la transferencia de datos necesaria al restaurar a una cuenta nueva. En escenarios en los 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 depende de la cantidad de datos que se deben restaurar. La configuración de coherencia de la cuenta de base de datos recién restaurada es 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. Las copias de seguridad realizadas para cada cuenta de región tienen redundancia local por defecto, y redundancia entre zonas si la característica de zona de disponibilidad está habilitada en su cuenta 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, control de acceso basado en roles para el plano de datos, 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 del 1 al 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 mediante las nuevas API de fuente de eventos en la base de datos o contenedores restaurables.

Diagrama que muestra eventos de ciclo de vida con marcas de tiempo para una cuenta restaurable.

  • Escenario 1: Restaurar cuenta eliminada: todas las cuentas eliminadas que puede restaurar están visibles 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 de ciclo de vida con marcas de tiempo para una base de datos y un contenedor restaurables.

  • Escenario 2: Restauración de 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 una copia de la cuenta A en Oeste de EE. UU., puede realizar una restauración a un momento dado desde Azure Portal, PowerShell o la CLI con Oeste de EE. UU. como ubicación de destino.

  • Escenario 3: recuperarse 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 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.

  • Escenario 4: Restauración de una cuenta a un momento dado anterior antes de la eliminación accidental de la base de datos: en Azure Portal, puede usar el panel de fuente de eventos para determinar cuándo se eliminó una base de datos y encontrar el tiempo 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.

  • Escenario 5: Restauración de una cuenta a un momento dado anterior antes de la eliminación accidental o modificación de las propiedades del contenedor: en Azure Portal, puede usar el panel de fuente de eventos para determinar cuándo se creó, modificó o eliminó un contenedor para encontrar el tiempo 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 Administración de permisos para restaurar una cuenta de Azure Cosmos DB.

Comprender la restauración de cuentas de escritura en varias regiones

Las escrituras realizadas en la región central se confirman inmediatamente y se realiza una copia de seguridad asincrónica en un plazo de 100 segundos. En las cuentas de escritura múltiple, las mutaciones realizadas en la región de satélite se envían a la región del centro de conectividad para su confirmación. La región central comprueba si se necesita alguna resolución de conflictos , asigna una marca de tiempo de resolución de conflictos después de resolver los conflictos y envía el documento a la región satélite. La región satélite solo realiza una copia de seguridad de los documentos después de recibir la confirmación del centro. En resumidas cuentas, el proceso de restauración solo restaura los documentos confirmados por la región del centro de conectividad en el punto temporal de la restauración.

¿Qué ocurre con la restauración de la cuenta de escritura en varias regiones?

  • Las mutaciones que aún no han sido confirmadas por la marca de tiempo de restauración no se restauran.
  • Las colecciones con la directiva de resolución de conflictos personalizada se restablecen a las ganancias del último escritor en función de la marca de tiempo.

Nota:

La restauración desde una región satélite es más lenta en comparación con la restauración en la región del centro de conectividad de la cuenta de varias regiones para resolver las escrituras provisionales como confirmadas o tomar una acción para revertirlas.

Para obtener más información sobre la comprensión de las marcas de tiempo en una cuenta con capacidad de escritura múltiple, consulte Comprensión de las marcas de tiempo.

Escenario de ejemplo: dada una cuenta de región de varias escrituras con dos regiones Este de EE. UU. y Oeste de EE. UU., fuera de la cual Este de EE. UU. es la región central, tenga en cuenta la siguiente secuencia de eventos:

  • T1: El cliente escribe un documento Doc1 en Este de EE. UU. (Dado que Este de EE. UU. es la región central, la escritura se confirma inmediatamente).

  • T2: El cliente escribe un documento Doc2 en Oeste de EE. UU.

  • T3: Oeste de EE. UU. envía Doc2 al Este de EE. UU. para su confirmación

  • T4: Este de EE. UU. recibió Doc2, confirma el documento y envía de nuevo Doc2 a Oeste de EE. UU.

  • T5: Oeste de EE. UU. recibió la confirmación de Doc2

En este escenario, si la marca de tiempo de restauración proporcionada es T3 para la región del hub como origen, solo se restaura Doc1. Doc2 no ha sido confirmado por el centro de conectividad por T3. Solo si la marca de tiempo de restauración es mayor que T4, se restaura doc2, ya que la restauración en T4 del satélite solo contiene doc1, dado que doc2 aún no está confirmado.

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:

    $0,15/GB * Tamaño de 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 = 400 USD al mes

  • El costo de restauración se calcula como 1000 * 0,15 = 150 USD 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 continuo de 7 días no incurre en cargos por la copia de seguridad de los datos.

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

  • El período de retención de un nivel es de 30 días en comparación con 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 siete 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 de forma predeterminada. Esto puede provocar la eliminación de datos si la restauración se realiza sin deshabilitar el TTL. Para evitar la eliminación, pase un 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.

  • Azure Synapse Link para las cuentas de base de datos mediante el modo de copia de seguridad continua está disponible con carácter general. 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 obtener más información, 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 y red virtual.

  • Las cuentas de Azure Cosmos DB para 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 la creación de la colección, que solo se puede hacer mediante los comandos de extensión de creación de colecciones.

  • Después de la restauración, es posible que, para determinadas colecciones, el índice coherente pueda volver a generarse. 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.

Pasos siguientes

  • Last updated on