Backup e restauração com snapshots do sistema de arquivos
Nesta página
Este documento descreve um procedimento para criar backups de servidores independentes 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 fragmentados, consulte Fazer backup de um cluster fragmentado 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.
Visão geral dos snapshots
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.
Considerações
Mecanismo de armazenamento WiredTiger
O MongoDB 3.2 adicionou suporte para backup em nível de volume de instâncias do MongoDB 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.
Antes do MongoDB 3.2, a criação de backups em nível de volume de instâncias do MongoDB usando o WiredTiger exigia que os arquivos de dados e de diário residissem no mesmo volume.
Mecanismo de armazenamento criptografado (somente MongoDB Enterprise)
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
mongodestá 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
mongodnã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ânciamongodrola as chaves de banco de dados configuradas comAES256-GCMcifra e sai.
Dica
Em geral, se estiver usando backups baseados em sistema de arquivos para o MongoDB Enterprise, use o recurso de backup "quente", se possível.
Banco de dados válido no momento do snapshot
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.
Imagem inteira do disco
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.
Precaução contra falhas no site
Certifique-se de copiar dados de snapshots para outros sistemas. Isso garante que os dados estejam protegidos contra falhas no site.
Sem backups incrementais
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.
Snapshots com registro no diário
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.
Snapshots com Amazon EBS em uma configuração RAID 10
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 um snapshot.
Backup e restauração usando LVM no Linux
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 fragmentados, consulte Fazer backup de um cluster fragmentado com snapshots do sistema de arquivos.
Crie um snapshot
Alterado na versão 3.2: a partir do MongoDB 3.2, para fins de backup em nível de volume das instâncias do MongoDB usando o WiredTiger, não é mais necessário que os arquivos de dados e o diário estejam 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.
Arquive um snapshot
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-snap01nã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
dde comprime o resultado em um arquivo gzipado no diretório de trabalho atual.Aviso
Este comando irá gerar um grande arquivo
gzno seu diretório de trabalho atual. Certifique-se de que o sistema de arquivos onde você executará este comando tenha espaço livre suficiente.
Restaurar um snapshot
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
1Gpara o volume desejado.Descompacta e desarquiva o
mdb-snap01.gzna imagem de discomdb-new.Monta a imagem de disco
mdb-newno 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ê utilizar db.fsyncLock(), precisará remover o arquivo mongod.lock.
Restaurar diretamente de um snapshot
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
Novo na versão 3,6:
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 obter mais informações sobre collections UUIDs, consulte Collections.
Armazenamento de backup remoto
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
Faça o backup de instâncias utilizando um volume dedicado para arquivos de diário ou sem registro no diário
Alterado na versão 3.2: a partir do MongoDB 3.2, para fins de backup em nível de volume das instâncias do MongoDB usando o WiredTiger, não é mais necessário que os arquivos de dados e o diário estejam 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).
Limpe as gravações no disco e trave o banco de dados para evitar novas gravações.
Para liberar gravações no disco e "bloquear" o banco de dados, emita o método db.fsyncLock() em mongosh:
db.fsyncLock();
Execute a operação de backup descrita em Crie um snapshot.
Após a conclusão do snapshot, desbloqueie o banco de dados.
Para desbloquear o banco de dados após a conclusão do snapshot, use o seguinte comando em mongosh:
db.fsyncUnlock();