Partilhar via

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

  • Aplica-se a: ✅ NoSQL, ✅ MongoDB, ✅ Apache Gremlin, ✅ Table

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 localmente redundantes. 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 em várias regiões.

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 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, 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 ou em uma conta existente. 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 necessário ao restaurar 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 da restauração depende da quantidade de dados que precisam ser restaurados. A configuração de consistência da conta de banco de dados recém-restaurada é 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 a 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, rede virtual, controle de acesso baseado em função de plano de dados 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 em um ponto específico no tempo 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 previamente. 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.

Diagrama que mostra eventos do ciclo de vida com timestamps para uma conta restaurável.

  • Cenário 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 do T3, local, nome da conta de destino, grupo de recursos e nome da conta de destino são suficientes para restaurar a partir do portal do Azure, PowerShell ou CLI.

    Eventos de ciclo de vida com carimbos de data/hora para um banco de dados e contêiner restauráveis.

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

  • Cenário 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.

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

  • 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 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 Gerenciar permissões para restaurar uma conta do Azure Cosmos DB.

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

As gravações executadas na região do hub são imediatamente confirmadas e o backup é feito de forma assíncrona em 100 segundos. Em contas de gravação múltipla, quaisquer mutações realizadas na região satélite são enviadas para a região central para confirmação. A região do hub verifica se alguma resolução de conflito é necessária, atribui um carimbo de data/hora de resolução de conflitos depois de resolver os conflitos e envia de volta 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 resumo, o processo de restauração apenas restaura os documentos confirmados pela região do hub no ponto de restauração.

O que acontece com a restauração de uma conta de escrita 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 política de resolução de conflitos personalizada são redefinidas para "o último a escrever prevalece", com base no carimbo de data/hora.

Nota

A restauração a partir da região satélite é mais lenta em comparação com a restauração na região do hub para contas em múltiplas regiões, para resolver as gravações provisórias locais ao serem confirmadas ou tomar medidas para revertê-las.

Para saber mais sobre como entender os carimbos de data/hora em uma conta habilitada para gravação múltipla, consulte Noções básicas sobre carimbos de data/hora.

Cenário de exemplo: Dada uma conta de múltiplas gravações com duas regiões: Leste dos EUA e Oeste dos EUA, das quais Leste dos EUA é a região principal, considere a seguinte sequência de eventos:

  • T1: O cliente escreve um documento Doc1 para o Leste dos EUA (Como o Leste dos EUA é a região central, a gravação é imediatamente confirmada)

  • T2: Cliente escreve um documento Doc2 para West US

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

  • T4: East US recebeu Doc2, confirma o documento e envia Doc2 de volta para West US

  • T5: Oeste dos EUA recebeu Doc2 confirmado

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

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

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 de 7 dias

  • O período de retenção para um nível é de 30 dias, em comparação com 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 sete dias não é cobrado.
  • A restauração é sempre cobrada em qualquer camada

Tempo de viver

  • 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 desativar o TTL. Para evitar a exclusão, passe um 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.

  • Atualmente, os clientes que desativaram o Synapse Link (obsoleto) dos contentores não conseguem migrar para backup contínuo. E o armazenamento analítico não está incluído nos backups.

  • 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 a conta alterar qualquer rede virtual, configuração de 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 junto com a criação da coleção, o que deve e só pode ser feito usando os comandos da extensão create collection extension commands.

  • 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

  • Last updated on