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.

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.

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.

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 do Microsoft Azure VNET, controle de acesso baseado em função do plano de dados RBAC 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

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

Vida útil

• O processo de padrão de restauração restaura todas as propriedades de um contêiner, incluindo sua configuração TTL por padrão, isso pode resultar na exclusão de dados se a restauração for feita sem a maneira de desabilitar o TTL. Para evitar a exclusão, passe o parâmetro para desabilitar o TTL no PowerShell (-DisableTtl $true) ou 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.

• Não há suporte para contas Multi region write.

• O Link do Synapse para contas de banco de dados usando o modo de backup contínuo está em disponibilidade geral. A situação oposta, o modo de backup contínuo para contas habilitadas para Link do Azure Synapse, está em visualização 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 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.

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

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