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

APLICA-SE A: NoSQL MongoDB Gremlin Tabela

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.
• Restaurando uma conta excluída, um banco de dados ou um contêiner.
• 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.

A janela de tempo disponível para restauração (também conhecida como período de retenção) é o valor mais baixo 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, do Azure PowerShell ou dos 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 ou em uma conta existente. 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 ao restaurar para uma nova conta. Para cenários em que a modificação acidental de dados foi feita, restaurar em uma nova conta pode ser a opção preferencial.

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 depende da quantidade de dados que precisa ser restaurada. A configuração de consistência da conta de banco de dados recém-restaurada é igual às configurações de consistência da conta de banco de dados de origem.

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, rede virtual, 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.

Carimbo de data/hora restaurável para contas online

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. Os cenários 1 a 3 demonstram como iniciar uma restauração se a marca temporal de restauração for conhecida antecipadamente. No entanto, pode haver cenários em que o tempo exato de exclusão acidental ou corrupção não é conhecido. Os cenários 4 e 5 demonstram como descobrir o timestamp de restauração usando as novas APIs de feed de eventos no banco de dados ou nos contêineres restauráveis.

• Cenário 1 – Restaurar a conta excluída: todas as contas excluídas que você pode restaurar ficam visíveis no painel Restaurar . 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 são suficientes para restaurar de portal do Azure, PowerShell ou CLI.

  

• Cenário 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á realizar uma restauração pontual no portal do Azure, no PowerShell ou na CLI, definindo o Oeste dos EUA como local de destino.

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

• Cenário 4 – Restaurar uma conta para um ponto anterior no tempo antes da exclusão acidental do banco de dados: no portal do Azure, você pode usar o painel de 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.

• Cenário 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, você pode usar o painel de feed de eventos para determinar quando um contêiner foi criado, modificado ou excluído para localizar o tempo de 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, confira Gerenciar permissões para restaurar uma conta do Azure Cosmos DB.

Entender a restauração da conta de gravação em várias regiões

As escritas realizadas na região do hub são confirmadas imediatamente e armazenadas de forma assíncrona dentro de 100 segundos. Em contas com várias gravações, todas as mutações realizadas na região satélite são enviadas para a região do hub para obter confirmação. A região do hub verifica se alguma resolução de conflitos é necessária, atribui um carimbo de data/hora de resolução de conflitos após resolver os conflitos e envia o documento para a região satélite. A região satélite só faz backup dos documentos após a confirmação ser recebida do hub. Em suma, o processo de restauração restaura apenas os documentos confirmados pela região do hub pelo ponto de tempo de restauração.

O que acontece durante a restauração de uma conta com gravação em várias regiões?

• As mutações que ainda não foram confirmadas pela marca temporal 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.

Para saber mais sobre como entender carimbos de data/hora em uma conta habilitada para várias gravações, consulte Conceitos básicos sobre carimbos de data/hora.

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

• 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: Cliente grava um documento Doc2 no Oeste dos EUA

• T3: Oeste dos EUA envia Doc2 ao Leste dos EUA para confirmação

• T4: Leste dos EUA recebeu Doc2, confirma o documento e envia Doc2 de volta para o Oeste dos EUA

• T5: Oeste dos EUA recebeu Doc2 confirmado

Nesse cenário, se o carimbo de data/hora de restauração fornecido for T3 para a região do hub como origem, somente o Doc1 é restaurado. O Doc2 não foi confirmado pelo hub até T3. Somente se o carimbo de data/hora de restauração for maior que T4, o doc2 será restaurado como restauração em T4 no satélite contém apenas o doc1, já que o doc2 ainda não foi confirmado.

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 de API de restauração incorre em uma cobrança única. A cobrança é uma função da quantidade de dados restaurada:

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

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

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

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

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

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

Vida útil

• O processo de restauração padrão restaura todas as propriedades de um contêiner, incluindo sua configuração de TTL por padrão. Isso pode resultar na exclusão de dados se a restauração for feita sem desabilitar o TTL. Para evitar a exclusão, passe um parâmetro para desabilitar a TTL no PowerShell (-DisableTtl $true) ou na CLI (--disable-ttl True) ao fazer a restauração.

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.

• O Link do Azure Synapse para contas de banco de dados usando o modo de backup contínuo está geralmente disponível. A situação oposta, que é o modo de backup contínuo para contas habilitadas com o Synapse Link, está em versão prévia pública. Atualmente, os clientes que desabilitam o Link do Synapse de contêineres não podem migrar para o backup contínuo. E o repositório analítico não está incluído nos backups. Para saber mais, confira o 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 rede virtual, configuração de 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 devem ser criados junto com sua coleção. Isso pode ser feito usando os comandos de extensão de criação de coleções.

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

• Não é possível adicionar, atualizar nem remover í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 do modo contínuo pode não restaurar a configuração da taxa de transferência que era válida no momento do ponto de restauração.

Próximas etapas

• Habilitar o backup contínuo usando o portal do Azure, o PowerShell, a CLI ou o Azure Resource Manager
• Restaurar a conta de backup contínuo usando o portal do Azure, o PowerShell, a CLI ou o Azure Resource Manager
• Obter o data/hora restaurador mais recente para contas de backup contínuas
• Migrar uma conta do backup periódico para o backup contínuo
• Gerenciar as permissões para restaurar uma conta do Azure Cosmos DB
• Modelo de recurso para a restauração pontual do Azure Cosmos DB
• Noções básicas sobre gravações em várias regiões no Azure Cosmos DB
• Noções básicas sobre carimbos de data/hora no Cosmos DB
• Distribuição global de dados com Azure Cosmos DB – os bastidores