Backup contínuo com restauração pontual no Azure Cosmos DB

APLICA-SE AO: NoSQL MongoDB Gremlin Table

O recurso de restauração pontual do Azure Cosmos DB ajuda em vários cenários, incluindo:

• Recuperar-se de uma operação de gravação ou exclusão acidental em um contêiner.
• Restaurar uma conta, um banco de dados ou um contêiner excluído.
• Restaurar em qualquer região (onde os backups existiam) no momento da restauração pontual.

O Azure Cosmos DB executa backup de dados em segundo plano sem consumir nenhuma taxa de transferência provisionada (RUs) extra ou afetar o desempenho e a disponibilidade de seu banco de dados. Os backups contínuos são feitos em todas as regiões em que a conta existe. Por exemplo, uma conta pode ter uma região de gravação no Oeste dos EUA e regiões de leitura no Leste dos EUA e Leste dos EUA 2. Essas regiões de réplica então podem fazer backup em uma conta remota do Armazenamento do Azure em cada região respectiva. Por padrão, cada região armazena o backup em contas de armazenamento com redundância local. Se a região tiver Zonas de disponibilidade habilitadas, o backup será armazenado em contas de armazenamento com redundância de zona.

Diagrama ilustrando como é feito o backup de um contêiner com uma região de gravação no Leste e no Leste dos EUA 2. O contêiner faz backup em uma conta de Armazenamento de Blobs do Azure remota em cada região de gravação e leitura respectiva.

A janela de tempo disponível para restauração (também conhecida como período de retenção) é o valor inferior das duas opções a seguir: 30 dias e 7 dias.

A opção selecionada depende da camada escolhida de backup contínuo. O ponto no tempo de restauração pode ser qualquer carimbo de data/hora dentro do período de retenção não anterior ao que o ponto em que o recurso foi criado. No modo de coerência forte, os backups feitos na região de gravação são mais atualizados quando comparados às regiões de leitura. Regiões de leitura podem ficar para trás devido a problemas de rede ou outros problemas transitórios. Ao fazer a restauração, você pode obter o carimbo de data/hora restaurável mais recente para um determinado recurso em uma região específica. Fazer referência ao carimbo de data/hora restaurável mais recente ajuda a confirmar se os backups de recurso estão no carimbo de data/hora fornecido e podem ser restaurados nessa região.

No momento, você pode restaurar o conteúdo de uma conta do Azure Cosmos DB (API para NoSQL ou MongoDB, API para tabela, API para Gremlin) de um ponto de tempo específico para uma outra conta. Você pode executar essa operação de restauração por meio do portal do Azure, da CLI do Azure (CLI do Azure), do Azure PowerShell ou de modelos do Azure Resource Manager.

Redundância do armazenamento de backup

Por padrão, o Azure Cosmos DB armazena dados de backup de modo contínuo em blobs de armazenamento com redundância local. Para as regiões que têm redundância de zona configurada, o backup é armazenado em blobs de armazenamento com redundância de zona. No backup contínuo, você não pode atualizar a redundância de armazenamento de backup.

Diferentes maneiras de restaurar

O modo de backup contínuo dá suporte a duas maneiras de restaurar contêineres e bancos de dados excluídos. Eles podem ser restaurados em uma nova conta, conforme documentado aqui, ou podem ser restaurados em uma conta existente, conforme descrito aqui. A escolha entre esses dois modos depende dos cenários. Na maioria dos casos, é preferível restaurar contêineres e bancos de dados excluídos em uma conta existente. Isso evita o custo da transferência de dados necessária no caso de eles serem restaurados para uma nova conta. Para o cenário em que a modificação acidental de dados foi feita, a restauração em uma nova conta pode ser a opção preferencial.

Restaurações de conta de gravação de várias regiões (versão prévia)

Todas as gravações executadas na região do hub são imediatamente confirmadas e o backup delas é feito de maneira assíncrona dentro de 100 segundos. As mutações executadas na região satélite (região sem resolução de conflitos) são enviadas para a região do hub para confirmação. A região do hub verifica se alguma resolução de conflitos é necessária e atribui um carimbo de data/hora de conflito resolvido após resolver os conflitos e envia de volta para a região satélite. A região satélite só faz backup das entidades após a confirmação ser recebida da região do hub.
Para resumir, o processo de restauração restaura apenas as entidades que são confirmadas com o carimbo de data/hora de resolução de conflitos da região do hub.

Observação

Mais informações sobre contas de várias regiões de gravação podem ser encontradas aqui, a região do hub é a primeira região do portal.

O que não é restaurado para restaurações de conta de gravação de várias regiões (versão prévia)?

As mutações que ainda não foram confirmadas pelo carimbo de data/hora de restauração não são restauradas. As coleções com a política de resolução de conflitos personalizada são redefinidas para os últimos êxitos do gravador com base no carimbo de data/hora.

Exemplo: considerando uma conta de região de várias gravações com duas regiões Leste dos EUA e Oeste dos EUA, das quais Leste dos EUA é a região do hub, considere a seguinte sequência de eventos:

Nesse cenário, se o carimbo de data/hora de restauração for T3, somente a entidade1 será restaurada. A Entidade2 não foi confirmada pela região do hub até T3. Somente se o carimbo de data/hora > T4, a entidade2 será restaurada. T1: O cliente grava um documento Doc1 no Leste dos EUA. (Como o Leste dos EUA é a região do hub, a gravação é confirmada imediatamente)
T2: O cliente grava um documento Doc2 no Oeste dos EUA. T3: Oeste dos EUA envia Doc2 para Leste dos EUA para confirmação. T4: Leste dos EUA recebe Doc2, confirma o documento e envia Doc2 de volta para o Oeste dos EUA. T5: Oeste dos EUA recebe Doc2 confirmado.

Nesse cenário, se o carimbo de data/hora de restauração fornecido for T3, somente o Doc1 será restaurado. O Doc2 não foi confirmado pelo hub até T3. Somente se o carimbo de data/hora > de restauração for T4, o doc2 será restaurado.

Observação

A restauração na região do hub tem suporte na versão prévia pública.

O que é restaurado para uma nova conta?

Em um estado estável, todas as mutações executadas na conta de origem (inclusive bancos de dados, contêineres e itens) são submetidas a backup de forma assíncrona em 100 segundos. Se a mídia de backup do Armazenamento do Azure estiver inoperante ou indisponível, as mutações persistirão localmente até que a mídia esteja disponível. Então as mutações são liberadas para evitar qualquer perda na fidelidade de operações que podem ser restauradas.

Você pode optar por restaurar qualquer combinação de contêineres de taxa de transferência provisionados, banco de dados de taxa de transferência compartilhada ou a conta inteira. A ação de restauração restaura todos os dados e as propriedades de índices deles em uma nova conta. O processo de restauração garante que todos os dados restaurados em uma conta, um banco de dados ou um contêiner sejam consistentes até o tempo de restauração especificado. A duração da restauração dependerá da quantidade de dados que precisam ser restaurados. A configuração de consistência da conta de banco de dados recém-restaurada será igual às configurações de consistência da conta de banco de dados de origem.

Observação

Com o modo de backup contínuo, os backups são feitos em todas as regiões em que a conta de Azure Cosmos DB esteja disponível. Os backups feitos para cada conta de região são localmente redundantes por padrão e com redundância de zona se sua conta tiver o recurso de zona de disponibilidade habilitado para a região. A ação de restauração sempre restaura os dados em uma nova conta.

O que não foi restaurado?

As seguintes configurações não são restauradas após a recuperação pontual:

• – Um subconjunto de contêineres em banco de dados de taxa de transferência não pode ser restaurado. Todo o banco de dados pode ser restaurado como um todo.
• Firewall, VNET de Rede Virtual, RBAC de controle de acesso baseado em função do plano de dados ou configurações de ponto de extremidade privado.
• Todas as Regiões da conta de origem.
• Procedimentos armazenados, gatilhos e UDFs.
• Atribuições do controle de acesso baseado em função.

Não é possível adicionar essas configurações à conta restaurada após a conclusão da restauração.

Período de tempo restaurável para contas ao vivo

Para restaurar as contas ao vivo do Azure Cosmos DB que não são excluídas, uma prática recomendada é sempre identificar o carimbo de data/hora restaurável mais recente do contêiner. Depois, você poderá usar esse carimbo de data/hora para restaurar a conta para a versão mais recente.

Cenários de restauração

O recurso de restauração pontual dá suporte aos cenários a seguir. Cenários [1] até [3] demonstram como disparar uma restauração se o carimbo de data/hora de restauração for conhecido com antecedência. No entanto, pode haver cenários em que o tempo exato de exclusão acidental ou corrupção não é conhecido. Cenários [4] e [5] demonstram como descobrir o carimbo de data/hora de restauração usando as novas APIs de feed de eventos no banco de dados ou nos contêineres restauráveis.

1. Restaurar conta excluída – Todas as contas excluídas que podem ser restauradas estão visíveis no painel de Restauração. Por exemplo, se a Conta A for excluída no carimbo de data/hora T3. Nesse caso, o carimbo de data/hora pouco antes do T3, local, nome da conta de destino, grupo de recursos e nome da conta de destino é suficiente para restaurar de portal do Azure, PowerShellou CLI.

   

2. Restaurar dados de uma conta em uma região específica – por exemplo, se a Conta A existir em duas regiões leste dos EUA e oeste dos EUA no carimbo de data/hora T3. Se você precisar de uma cópia da conta A no oeste dos EUA, poderá fazer uma restauração pontual do portal do Azure, do PowerShellou do CLI com oeste dos EUA como o local de destino.

3. Recuperar-se de uma operação de gravação ou exclusão acidental em um contêiner com um carimbo de data/hora de restauração conhecido – Por exemplo, se souber que o conteúdo do Contêiner 1 no Banco de dados 1 foi modificado acidentalmente no carimbo de data/hora de T3. É possível fazer uma restauração pontual do portal do Azure, do PowerShellou do CLI em outra conta no carimbo de data/hora T3 para recuperar o estado desejado do contêiner.

4. Restaurar uma conta para um ponto anterior no tempo antes da exclusão acidental do banco de dados – No portal do Azure, é possível usar o painel feed de eventos para determinar quando um banco de dados foi excluído e encontrar a hora da restauração. Da mesma forma, com CLI do Azure e o PowerShell, é possível descobrir o evento de exclusão do banco de dados enumerando o feed de eventos do banco de dados e, em seguida, disparar o comando Restaurar com os parâmetros necessários.

5. Restaurar uma conta para um ponto anterior no tempo antes da exclusão acidental ou modificação das propriedades do contêiner. – No portal do Azure, é possível usar o painel do feed de eventos para determinar quando um contêiner foi criado, modificado ou excluído para localizar a hora da restauração. Da mesma forma, com CLI do Azure e o PowerShell, é possível descobrir todos os eventos do contêiner enumerando o feed de eventos do contêiner e, em seguida, disparar o comando Restaurar com os parâmetros necessários.

Permissões

O Azure Cosmos DB permite isolar e restringir as permissões de restauração para a conta de backup contínuo a uma função específica ou a uma entidade de segurança. Para saber mais, consulte o artigo Permissões.

Preços

A conta do Azure Cosmos DB com backup contínuo de 30 dias tem um custo mensal extra para armazenar o backup. As camadas de 30 dias e de sete dias geram encargos contínuos para restaurar seus dados. O custo de restauração é adicionado toda vez que a operação de restauração é iniciada. Se configurar uma conta com backup contínuo, mas não restaurar os dados, somente o custo de armazenamento do backup será incluído em sua fatura.

O exemplo a seguir se baseia no preço de uma conta do Azure Cosmos DB implantada no Oeste dos EUA. O preço e o cálculo podem variar dependendo da região que está sendo usada, consulte a página de preço do Azure Cosmos DB para obter as informações mais recentes sobre preço.

• Todas as contas habilitadas com a política de backup contínuo de 30 dias incorrem em um preço mensal para o armazenamento de backup, calculado da seguinte maneira:

  US$ 0,20/GB * Tamanho dos dados em GB na conta * Número de regiões

• Cada invocação da API de restauração incorre em uma única cobrança. A cobrança é uma função da quantidade de dados restaurada:

  US$ 0,15/GB * Tamanho dos dados em GB.

Por exemplo, se tiver 1 TB de dados em duas regiões:

• O custo de armazenamento de backup é calculado como (1000 * 0,20 * 2) = US$ 400 por mês

• O custo de restauração é calculado como (1000 * 0,15) = US$ 150 por restauração

Dica

Para obter mais informações de como medir o uso de dados atual da conta do Azure Cosmos DB, confira Explorar insights do Azure Cosmos DB do Azure Monitor. A camada contínua de sete dias não gera em encargos para backup dos dados.

Camada contínua de 30 dias versus camada contínua de sete dias

• O período de retenção para uma camada é de 30 dias versus sete dias para outra camada.
• A camada de retenção de 30 dias é cobrada pelo armazenamento de backup. A camada de retenção de 7 dias não é cobrada.
• A restauração é sempre cobrada em qualquer camada

Chaves gerenciadas pelo cliente

Consulte Como as chaves gerenciadas pelo cliente afetam os backups contínuos? para saber:

• Como configurar a conta do Microsoft Azure Cosmos DB ao usar chaves gerenciadas pelo cliente com backups contínuos.
• Como as chaves gerenciadas pelo cliente afetam as restaurações?

Limitações atuais

No momento, a funcionalidade de restauração pontual tem as seguintes limitações:

• As APIs do Azure Cosmos DB para SQL, MongoDB, Gremlin e Table são compatíveis com um backup contínuo. Não há suporte para a API do Cassandra no momento.

• Atualmente, o Link do Azure Synapse pode ser habilitado em contas de banco de dados de backup contínuo. Mas a situação oposta ainda não tem suporte – não é possível ativar o backup contínuo em contas de banco de dados habilitadas para Link do Synapse. E o repositório analítico não está incluído nos backups. Para obter mais informações sobre backup e repositório analítico, confira Backup do repositório analítico.

• A conta restaurada é criada na mesma região em que está a conta de origem. Não é possível restaurar uma conta em uma região sem a conta de origem.

• A janela de restauração é de apenas 30 dias para a camada contínua de 30 dias e sete dias para a camada contínua de 7 dias. Essas camadas podem ser alternadas, mas as quantidades reais (7 ou 30) não podem ser alteradas. Além disso, se você mudar da camada de 30 dias para a camada de 7 dias, haverá o potencial de perda de dados em dias além do sétimo.

• Os backups não são configurados automaticamente para recuperação de desastre geográfico. Outra região deve ser explicitamente adicionada para resiliência da conta e do backup.

• Enquanto uma restauração está em andamento, não modifique nem exclua as políticas de IAM (Gerenciamento de Identidades e Acesso). Essas políticas concedem as permissões para que a conta altere qualquer configuração de VNET, firewall.

• As contas do Azure Cosmos DB for MongoDB com backup contínuo não dão suporte à criação de um índice exclusivo em uma coleção existente. Para essa conta, índices exclusivos precisam ser criados junto com a coleção. Isso pode ser feito por meio dos comandos de extensão de criação da coleção.

• A funcionalidade de restauração pontual sempre faz a restauração para uma nova conta do Azure Cosmos DB. Atualmente, não é possível restaurar para uma conta existente. Se estiver interessado em deixar comentários sobre a restauração in-loco, entre em contato com a equipe do Azure Cosmos DB por meio do seu representante de conta.

• Após a restauração, é possível que, para determinadas coleções, o índice consistente possa estar recompilando. É possível verificar o status da operação de recompilação pela propriedade IndexTransformationProgress.

• O processo de restauração restaura todas as propriedades de um contêiner, incluindo sua configuração de TTL por padrão, você pode passar o parâmetro para desabilitar a TTL ao fazer a restauração. Por isso, é possível que os dados restaurados sejam excluídos imediatamente se você configurou essa maneira. Para evitar essa situação, o carimbo de data/hora de restauração precisa ser anterior à adição de propriedades de TTL no contêiner.

• Não é possível adicionar nem atualizar índices exclusivos na API para MongoDB quando você cria uma conta no modo de backup contínuo. Eles também não podem ser modificados quando você migra uma conta do modo periódico para o modo contínuo.

• A restauração de modo contínuo pode não restaurar a configuração de taxa de transferência válida do ponto de restauração em diante.

Próximas etapas

• Habilite o backup contínuo usando o portal do Azure, o PowerShell, a CLI ou o Azure Resource Manager.
• Obter o carimbo de data/hora restaurável mais recente para contas SQL e MongoDB.
• Restaure a conta de backup contínuo usando o portal do Azure, o PowerShell, a CLI ou o Azure Resource Manager.
• Migre para uma conta de backup periódico para backup contínuo.
• Gerencie as permissões necessárias para restaurar dados com o modo de backup contínuo.
• Modelo de recurso do modo de backup contínuo