Backup contínuo com restauração point-in-time no Azure Cosmos DB

APLICA-SE A: NoSQL MongoDB Gremlin Tabela

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

• Recuperação de uma operação acidental de gravação ou exclusão dentro de um contêiner.
• Restaurando uma conta, banco de dados ou contêiner excluído.
• Restauração em qualquer região (onde existiam backups) no momento da restauração.

O Azure Cosmos DB executa o backup de dados em segundo plano sem consumir nenhuma taxa de transferência provisionada (RUs) extra ou afetar o desempenho e a disponibilidade do seu banco de dados. Backups contínuos são feitos em todas as regiões onde a conta existe. Por exemplo, uma conta pode ter uma região de escrita no Oeste dos EUA e ler regiões no Leste dos EUA e Leste dos EUA 2. Em seguida, é possível fazer backup dessas regiões de réplica em uma conta remota do Armazenamento do Azure em cada região respetiva. 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 ou 7 dias.

A opção selecionada depende da camada escolhida de backup contínuo. O ponto no tempo para restauração pode ser qualquer carimbo de data/hora dentro do período de retenção, não mais atrás do ponto em que o recurso foi criado. No modo de consistência forte, os backups feitos na região de gravação são mais atualizados quando comparados às regiões de leitura. As 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. A referência ao carimbo de data/hora restaurável mais recente ajuda a confirmar se os backups de recursos estão até o carimbo de data/hora determinado e podem ser restaurados nessa região.

Atualmente, você pode restaurar o conteúdo de uma conta do Azure Cosmos DB (API para NoSQL ou MongoDB, API para Tabela, API para Gremlin) em um momento específico para 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 dos modelos do Azure Resource Manager.

Redundância de armazenamento de cópias de segurança

Por padrão, o Azure Cosmos DB armazena dados de backup em modo contínuo em blobs de armazenamento localmente redundantes. 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 modo de backup contínuo, não é possível atualizar a redundância de armazenamento de backup.

Diferentes maneiras de restaurar

O modo de backup contínuo suporta 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 estes 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 de transferência de dados que é necessário no caso de serem restaurados para uma nova conta. Para cenários em que a modificação acidental de dados foi feita, a restauração em uma nova conta pode ser a opção preferida.

O que é restaurado em uma nova conta?

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

Pode optar por restaurar qualquer combinação de contentores de débito aprovisionados, bases de dados de débito partilhadas ou a conta inteira. A ação de restauro restaura todos os dados, bem como as propriedades de índice, para uma nova conta. O processo de restauro garante que todos os dados restaurados numa conta, numa base de dados ou num contentor têm a garantia de serem consistentes até ao tempo de restauro especificado. A duração do restauro dependerá da quantidade de dados que precisam de ser restaurados. A configuração de consistência da conta de banco de dados recém-restaurada será a mesma que as configurações de consistência da conta de banco de dados de origem.

O que não é restaurado?

As seguintes configurações não são restauradas após a recuperação point-in-time:

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

Você pode adicionar essas configurações à conta restaurada após a conclusão da restauração.

Carimbo de data/hora restaurável para contas reais

Para restaurar contas ativas 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 para o contêiner. Em seguida, você pode usar esse carimbo de data/hora para restaurar a conta para sua versão mais recente.

Cenários de restauro

O recurso de restauração point-in-time suporta os seguintes cenários. Os cenários [1] a [3] demonstram como acionar uma restauração se o carimbo de data/hora da restauração for conhecido de antemão. No entanto, pode haver cenários em que você não sabe a hora exata da exclusão acidental ou corrupção. Os 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 contêineres restauráveis.

1. Restaurar 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 imediatamente antes de T3, local, nome da conta de destino, grupo de recursos e nome da conta de destino é suficiente para restaurar a partir do portal do Azure, PowerShell ou 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 precisar de uma cópia da conta A no oeste dos EUA, você pode fazer uma restauração point-in-time a partir do portal do Azure, PowerShell ou CLI com West US como o local de destino.

3. Recuperar de uma operação acidental de gravação ou exclusão dentro de 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. Você pode fazer uma restauração point-in-time do portal do Azure, PowerShell ou 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 no tempo anterior 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 localizar o tempo de restauração. Da mesma forma, com a CLI do Azure e o PowerShell, você pode descobrir o evento de exclusão de banco de dados enumerando o feed de eventos do banco de dados e, em seguida, acionar o comando restore com os parâmetros necessários.

5. Restaure uma conta para um ponto no tempo anterior 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 encontrar o tempo de restauração. Da mesma forma, com a CLI do Azure e o PowerShell, você pode descobrir todos os eventos de contêiner enumerando o feed de eventos de contêiner e, em seguida, acionar o comando restore com os parâmetros necessários.

Permissões

O Azure Cosmos DB permite isolar e restringir as permissões de restauração para uma conta de backup contínuo para uma função específica ou 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 uma cobrança mensal extra para armazenar o backup. O nível de 30 dias e 7 dias de retorno contínuo incorre em encargos para restaurar seus dados. O custo de restauração é adicionado sempre que a operação de restauração é iniciada. Se você configurar uma conta com backup contínuo, mas não restaurar os dados, apenas o custo de armazenamento de backup será incluído na sua fatura.

O exemplo a seguir é baseado 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 você está usando, consulte a página de preços do Azure Cosmos DB para obter as informações de preços mais recentes.

• Todas as contas habilitadas com política de backup contínuo com 30 dias incorrem em uma cobrança mensal pelo armazenamento de backup calculada da seguinte forma:

  $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 é função da quantidade de dados restaurados:

  $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

Nível contínuo de 30 dias vs nível contínuo de 7 dias

• O período de retenção para um nível é de 30 dias contra 7 dias para outro nível.
• O nível de retenção de 30 dias é cobrado pelo armazenamento de backup. O nível de retenção de 7 dias não é cobrado.
• A restauração é sempre cobrada em qualquer camada

Time to live

• O processo de restauração padrã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 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 geridas pelo cliente

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

• Como configurar sua conta do 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

Atualmente, a funcionalidade de restauração point-in-time tem as seguintes limitações:

• APIs do Azure Cosmos DB para SQL, MongoDB, Gremlin e Tabela com suporte para backup contínuo. A API para Cassandra não é suportada agora.

• Multi region write as contas não são suportadas.

• Synapse Link para contas de banco de dados usando o modo de backup contínuo é GA. A situação oposta, modo de backup contínuo para contas habilitadas para Synapse Link, está em visualização pública. Atualmente, os clientes que desabilitaram o Synapse Link de contêineres não podem migrar para o backup contínuo. E o armazenamento analítico não está incluído nos backups. Para obter mais informações sobre backup e armazenamento analítico, consulte Backup de repositório analítico.

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

• A janela de restauração é de apenas 30 dias para o nível contínuo de 30 dias e sete dias para o nível contínuo de 7 dias. Esses níveis podem ser alternados, mas as quantidades reais (7 ou 30) não podem ser alteradas. Além disso, se você mudar do nível de 30 dias para o nível de 7 dias, há o potencial de perda de dados em dias além do sétimo.

• Os backups não são automaticamente resistentes a desastres geográficos. Outra região deve ser explicitamente adicionada para resiliência da conta e do backup.

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

• As contas do Azure Cosmos DB para MongoDB com backup contínuo não oferecem suporte à criação de um índice exclusivo para uma coleção existente. Para essa conta, índices únicos devem ser criados juntamente com sua coleção; Isso pode ser feito usando os comandos create collection extension.

• Após a restauração, é possível que, para certas coleções, o índice consistente esteja sendo reconstruído. Você pode verificar o status da operação de reconstrução por meio da propriedade IndexTransformationProgress .

• Índices exclusivos na API para MongoDB não podem ser adicionados, atualizados ou descartados quando você cria uma conta de 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 em modo contínuo pode não restaurar a configuração de taxa de transferência válida a partir do ponto de restauração.

Próximos passos

• Habilite o backup contínuo usando o portal do Azure, PowerShell, CLI ou Azure Resource Manager.
• Obtenha 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, PowerShell, CLI ou Azure Resource Manager.
• Migre para uma conta do backup periódico para o backup contínuo.
• Gerencie as permissões necessárias para restaurar dados com o modo de backup contínuo.
• Modelo de recursos do modo de backup contínuo