Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / /

Faça backup e restaure um sistema autogerenciado com snapshots do sistema de arquivos

Nesta página

  • Visão geral dos snapshots
  • Considerações
  • Backup e restauração usando LVM no Linux
  • Faça o backup de instâncias utilizando um volume dedicado para arquivos de diário ou sem registro no diário

Este documento descreve um procedimento para criar backups de servidores autônomo do MongoDB e conjuntos de réplicas usando ferramentas no nível do sistema, como LVM ou dispositivo de armazenamento, bem como as estratégias de restauração correspondentes. Para obter informações sobre clusters sharded, consulte Fazer backup de um cluster fragmentado autogerenciado com snapshots do sistema de arquivos.

Esses snapshots do sistema de arquivos, ou métodos de backup "em nível de bloco", usam ferramentas de nível do sistema para criar cópias do dispositivo que contém os arquivos de dados do MongoDB. Esses métodos são concluídos rapidamente e funcionam de forma confiável, mas exigem configuração adicional do sistema fora do MongoDB.

Dica

Veja também:

Os snapshots funcionam criando ponteiros entre os dados em tempo real e um volume especial de snapshots. Esses ponteiros são teoricamente equivalentes a "links rígidos". Como os dados de trabalho divergem do snapshot, o processo de snapshot usa uma estratégia de cópia em gravação. Como resultado, o snapshot armazena somente dados modificados.

Após fazer o snapshot, você monta a imagem do snapshot no sistema de arquivos e copia os dados do snapshot. O backup resultante contém uma cópia completa de todos os dados.

O MongoDB oferece suporte ao backup em nível de volume usando o mecanismo de armazenamento WiredTiger quando os arquivos de dados e os arquivos de diário da instância do MongoDB residem em volumes separados. No entanto, para criar um backup coerente, o banco de dados tem de ser bloqueado, e todos as gravações no banco de dados têm que ser suspensas durante o processo de backup.

Para mecanismos de armazenamento criptografados que utilizam o modo de criptografia AES256-GCM, o AES256-GCM exige que cada processo utilize um valor de bloco de contador único com a chave.

Para mecanismo de armazenamento criptografado configurado com cifra AES256-GCM:

  • Restauração a partir de um hot backup
    A partir da versão 4.2, se você restaurar a partir de arquivos obtidos via backup "quente" (ou seja, o mongod está em execução), o MongoDB pode detectar chaves "sujas" na inicialização e rolar automaticamente a chave do banco de dados para evitar a reutilização IV (Initialization Vector).
  • Restaurando a partir do Cold Backup

    No entanto, se você restaurar a partir de arquivos obtidos via backup "frio" (ou seja, o mongod não está em execução), o MongoDB não poderá detectar chaves "sujas" na inicialização, e a reutilização do IV anulará as garantias de confidencialidade e integridade.

    A partir do 4,2, para evitar a reutilização das chaves após restaurar de um snapshot de sistema de arquivos frio, o MongoDB adiciona uma nova opção de linha de comando --eseDatabaseKeyRollover. Quando iniciada com a opção --eseDatabaseKeyRollover, a instância mongod rola as chaves de banco de dados configuradas com AES256-GCM cifra e sai.

O banco de dados deve ser válido quando o snapshot ocorrer. Isso significa que todas as gravações aceitas pelo banco de dados precisam ser totalmente gravadas no disco: nos arquivos de diário ou de dados.

Se o backup ocorrer antes que alguns arquivos sejam gravados no disco, o backup não incluirá essas alterações.

Para o mecanismo de armazenamento WiredTiger, os arquivos de dados refletem um estado consistente a partir do último checkpoint. Os checkpoints ocorrem a cada 2 GB de dados gravados ou a cada minuto.

Os snapshots criam uma imagem de uma imagem completa do disco. A menos que você precise fazer backup de todo o sistema, considere isolar os arquivos de dados, de diário (se aplicável) e a configuração do MongoDB em um disco lógico que não contenha outros dados.

Como alternativa, armazene todos os arquivos de dados do MongoDB em um dispositivo dedicado para poder fazer backups sem duplicar dados estranhos.

Certifique-se de copiar dados de snapshots para outros sistemas. Isso garante que os dados estejam protegidos contra falhas no site.

Este tutorial não inclui procedimentos para backups incrementais. Embora diferentes métodos de snapshot forneçam recursos diferentes, o método LVM descrito abaixo não fornece nenhuma capacidade para capturar backups incrementais.

Se sua instância mongod tiver o registro no diário ativado, você poderá usar qualquer tipo de sistema de arquivos ou ferramenta de snapshot em nível de volume/bloco para criar backups.

Se você gerencia sua própria infraestrutura em um sistema baseado em Linux, configure seu sistema com LVM para fornecer seus pacotes de disco e fornecer recursos de snapshots. Você também pode usar configurações baseadas em LVM dentro de um ambiente em nuvem/virtualizado.

Observação

A execução do LVM oferece flexibilidade adicional e permite a possibilidade de usar snapshots para fazer backup do MongoDB.

Se a sua implementação depender do Elastic Block Storage (EBS) da Amazon com RAID configurado em sua instância, será impossível obter um estado consistente em todos os discos usando a ferramenta de instantâneo da plataforma. Como alternativa, você pode fazer um dos seguintes procedimentos:

  • Liberte todas as gravações em disco e crie um bloqueio de escrita para garantir um estado consistente durante o processo de backup.

    Se você escolher essa opção, consulte Fazer backup de instâncias com arquivos de diário em volume separado ou sem registro no diário.

  • Configure o LVM para executar e manter seus arquivos de dados MongoDB em cima do RAID dentro do seu sistema.

    Se você escolher essa opção, realize a operação de backup do LVM descrita em Criar uma captura de tela.

Esta seção fornece uma visão geral de um processo básico de backup usando o LVM em um sistema Linux. Embora as ferramentas, comandos e caminhos podem ser (ligeiramente) diferentes dependendo do seu sistema, as etapas a seguir fornecem uma visão geral de alto nível do processo de backup.

Observação

Siga o procedimento a seguir como diretriz para orientar a configuração de seu sistema e infraestrutura de backup. Os sistemas de backup de produção devem considerar vários requisitos específicos de cada aplicativo e fatores exclusivos para ambientes específicos.

Para obter informações sobre clusters sharded, consulte Fazer backup de um cluster fragmentado autogerenciado com snapshots do sistema de arquivos.

Alterado na versão 3.2: a partir do MongoDB 3.2, para fins de backup em nível de volume de instâncias do MongoDB usando WiredTiger, os arquivos de dados e o diário não precisam mais residir em um único volume.

Para criar um snapshot com LVM, emita um comando como raiz no seguinte formato:

lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb

Este comando cria um snapshot LVM (com a opção --snapshot) denominado mdb-snap01 do volume mongodb no grupo de volume vg0.

Este exemplo cria um snapshot denominado mdb-snap01 localizado em /dev/vg0/mdb-snap01. A localização e os caminhos para os grupos e dispositivos de volume dos sistemas podem variar ligeiramente dependendo da configuração de LVM do seu sistema operacional.

O snapshot tem um limite de 100 megabytes, devido ao parâmetro --size 100M. Esse tamanho não reflete a quantidade total de dados no disco, mas sim a quantidade de diferenças entre o estado atual de /dev/vg0/mongodb e a criação do snapshot (ou seja /dev/vg0/mdb-snap01.)

Aviso

Certifique-se de criar snapshots com espaço suficiente levando em conta o crescimento dos dados, especialmente pelo período de tempo necessário para copiar dados do sistema ou para uma imagem temporária.

Se o snapshot ficar sem espaço, a imagem do snapshot se tornará inutilizável. Descarte esse volume lógico e crie outro.

O snapshot existirá quando o comando retornar. Você pode restaurar diretamente do snapshot a qualquer momento ou criando um novo volume lógico e restaurando desse snapshot para a imagem alternativa.

Embora os snapshots sejam ótimos para criar backups de alta qualidade rapidamente, eles não são ideais como um formato para armazenar dados de backup. Os snapshots normalmente dependem da mesma infraestrutura de armazenamento que as imagens de disco originais. Portanto, é crucial que você arquive esses snapshots e os armazene em outro lugar.

Depois de criar um snapshot, monte o snapshot e copie os dados em um armazenamento separado. Seu sistema pode tentar compactar as imagens de backup à medida que você as move offline. Como alternativa, faça uma cópia em nível de bloco da imagem do snapshot, como no procedimento a seguir:

umount /dev/vg0/mdb-snap01
dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz

A sequência acima realiza as seguintes ações:

  • Garante que o dispositivo /dev/vg0/mdb-snap01 não esteja montado. Nunca faça uma cópia em nível de bloco de um snapshot do sistema de arquivos ou do sistema de arquivos montado.

  • Executa uma cópia em nível de bloco de toda a imagem de snapshot utilizando o comando dd e comprime o resultado em um arquivo gzipado no diretório de trabalho atual.

    Aviso

    Este comando irá gerar um grande arquivo gz no seu diretório de trabalho atual. Certifique-se de que o sistema de arquivos onde você executará este comando tenha espaço livre suficiente.

Para restaurar um snapshot criado com LVM, emita a seguinte sequência de comandos:

lvcreate --size 1G --name mdb-new vg0
gzip -d -c mdb-snap01.gz | dd of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb

A sequência acima realiza as seguintes ações:

  • Cria um novo volume lógico chamado mdb-new, no grupo de volume /dev/vg0. O caminho para o novo dispositivo será /dev/vg0/mdb-new.

    Aviso

    O volume máximo será de 1 gigabyte. A restauração só terá sucesso se o sistema de arquivos original for igual ou inferior a 1 gigabyte.

    Altere 1G para o volume desejado.

  • Descompacta e desarquiva o mdb-snap01.gz na imagem de disco mdb-new.

  • Monta a imagem de disco mdb-new no diretório /srv/mongodb. Modifica o ponto de montagem para coincidir com a localização do arquivo de dados do MongoDB ou a outro local, conforme necessário.

Observação

O snapshot restaurado terá um arquivo mongod.lock obsoleto. Se você não remover esse arquivo do snapshot, o MongoDB poderá presumir que o arquivo de bloqueio obsoleto indica um desligamento incorreto. Se você estiver executando com storage.journal.enabled habilitado e não usar db.fsyncLock(), não será necessário remover o arquivo mongod.lock . Se você usar db.fsyncLock() , precisará remover o bloqueio.

Para restaurar um backup sem gravar em um arquivo gz compactado, emita a seguinte sequência de comandos:

umount /dev/vg0/mdb-snap01
lvcreate --size 1G --name mdb-new vg0
dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb

Observação

Todas as coleções MongoDB têm UUIDs por padrão. Quando o MongoDB restaura as coleções, as coleções restauradas retêm seus UUIDs originais. Ao restaurar uma coleção onde nenhum UUID estava presente, o MongoDB gera um UUID para a coleção restaurada.

Para mais informações sobre UUIDs de coleção, consulte Coleções.

Você pode implementar backups fora do sistema usando o processo combinado e o SSH.

Essa sequência é idêntica aos procedimentos explicados acima, exceto pelo fato de que ela arquiva e compacta o backup em um sistema remoto usando SSH.

Considere o seguinte procedimento:

umount /dev/vg0/mdb-snap01
dd if=/dev/vg0/mdb-snap01 | ssh username@example.com gzip > /opt/backup/mdb-snap01.gz
lvcreate --size 1G --name mdb-new vg0
ssh username@example.com gzip -d -c /opt/backup/mdb-snap01.gz | dd of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb

Alterado na versão 3.2: a partir do MongoDB 3.2, para fins de backup em nível de volume de instâncias do MongoDB usando WiredTiger, os arquivos de dados e o diário não precisam mais residir em um único volume. No entanto, o banco de dados deve ser bloqueado e todas as gravações no banco de dados devem ser suspensas durante o processo de backup para garantir a consistência do backup.

Se sua instância mongod estiver em execução sem registro no diário ou tiver os arquivos de diário em um volume separado, você deverá liberar todas as gravações no disco e bloquear o banco de dados para evitar gravações durante o processo de backup. Se você tiver uma configuração de conjunto de réplicas, para o backup use um secundário que não esteja recebendo leituras (ou seja, um membro oculto).

1

Para limpar gravações no disco e "bloquear" o banco de dados, emita o método db.fsyncLock() em mongosh:

db.fsyncLock();
2
3

Para desbloquear o banco de dados de dados depois de criar o snapshot, use o seguinte comando em mongosh:

db.fsyncUnlock();

Voltar

Métodos de backup