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.

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

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. Obter o carimbo de data/hora mais recente garante que o recurso tenha feito backups até o carimbo de data/hora determinado e possa ser restaurado 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 depende dos cenários e do impacto. Na maioria dos casos, é preferível restaurar contêineres e bancos de dados excluídos em uma conta existente para evitar o custo da transferência de dados, que é necessário no caso de serem restaurados para uma nova conta. Para cenários em que você modificou os dados acidentalmente, restaurar para 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.

Nota

Com o modo de backup contínuo, os backups são feitos em todas as regiões onde sua conta do Azure Cosmos DB está disponível. Os backups feitos para cada conta de região são localmente redundantes por padrão e Zona redundante se sua conta tiver o recurso de zona de disponibilidade habilitado para essa região. A ação de restauração sempre restaura os dados em uma nova conta.

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, VNET, RBAC de plano de dados ou configurações de ponto final privado.
• Todas as Regiões da conta de origem.
• Procedimentos armazenados, gatilhos, UDFs.
• Atribuições de controle de acesso baseadas em função. Estes terão de ser reatribuídos.

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

A seguir estão alguns dos principais cenários abordados pelo recurso de restauração point-in-time. 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

As contas do Azure Cosmos DB que têm backup contínuo de 30 dias habilitado incorrerão em 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 é uma função da quantidade de dados restaurados e é calculada da seguinte forma:

  $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

Gorjeta

Para obter mais informações sobre como medir o uso atual de dados da sua conta do Azure Cosmos DB, consulte Explore Azure Monitor Azure Cosmos DB insights. O nível contínuo de 7 dias não incorre em encargos pelo backup dos dados.

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

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 Table com suporte para backup contínuo. A API para Cassandra não é suportada agora.

• Não há suporte para contas de gravação em várias regiões.

• Atualmente, o Azure Synapse Link pode ser habilitado em contas de banco de dados de backup contínuo. Mas a situação oposta ainda não é suportada, não é possível ativar o backup contínuo em contas de banco de dados habilitadas para Synapse Link. 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. Você precisa adicionar explicitamente outra região para ter resiliência para a conta e o 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 é feito usando os comandos create collection extension.

• A funcionalidade de restauração point-in-time sempre é restaurada para uma nova conta do Azure Cosmos DB. Atualmente, o restauro para uma conta existente não é suportado. Se estiver interessado em fornecer 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 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 .

• O processo de restauro restaura todas as propriedades de um contentor, incluindo a configuração TTL. Como resultado, é possível que os dados restaurados sejam excluídos imediatamente se você configurou dessa forma. Para evitar esta situação, o carimbo de data/hora do restauro deve ser adicionado antes das propriedades TTL serem adicionadas ao contentor.

• Índices exclusivos na API para MongoDB não podem ser adicionados ou atualizados 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