Com a necessidade de backup de 10 TB, isso fica um pouco complicado.

As réplicas não substituem os backups adequados

Embora os membros do conjunto de réplicas atrasadas possam fornecer uma maneira relativamente fácil de ajudá-lo com operações acidentais, não há substitutos para backups adequados, assim como o RAID não é um substituto para backups baseados no sistema de arquivos.

Recomendações

Isso depende muito da aparência da sua configuração.

Instantâneos de SAN

Com 10 TB, suponho que você tenha algum tipo de SAN conectado. A maneira mais fácil de fazer backup do MongoDB nesses ambientes é garantir que o registro no diário esteja ativado no sistema de arquivos e no MongoDB e simplesmente tirar um instantâneo do volume SAN de um dos secundários, provavelmente um oculto para garantir que suas operações não ocorram. não seja interrompido. Isso geralmente leva apenas alguns segundos, mas _certifique-se_ de que sua janela de oplog de replicação seja suficiente. Caso contrário, talvez seja necessário ressincronizar o secundário.

Não use mongodump

Tenho que discordar de RolandoMySQLDBA sobre o uso de mongodump. Em primeiro lugar, impõe bloqueios no servidor. Embora sejam removidos relativamente rápido, o grande número de bloqueios pode aumentar e interferir em suas operações, a menos que sejam executados em um nó oculto ou quando não houver preferência de leitura atingindo os secundários. Além disso, não é exatamente rápido. Eu esperaria que ele fosse executado por horas, pelo menos, provavelmente levando mais tempo do que sua janela de backup. Observação lateral: sempre execute o mongodump com a --oplogopção. Lembre-se também de que o mongodump não faz backup de índices, mas das operações para criar índices. Esses índices devem ser recriados durante uma restauração, o que pode aumentar enormemente o tempo necessário para isso. Pela minha experiência, se você precisar restaurar um banco de dados, deseja fazê-lo o mais rápido possível. Outro ponto por que o mongodump não é adequado para fazer backup de 10 TB.

Notas sobre snapshots LVM

Você pode fazer um instantâneo do LVM em uma instância mongod em execução, desde que tenha o registro no diário ativado no mongod (e, pela minha experiência, não custa nada habilitá-lo no nível FS também). No entanto, os instantâneos LVM vêm com algumas implicações. Primeiro, você obviamente precisa ter espaço em disco suficiente para fazer as alterações durante as operações de backup. Deixe-me esclarecer isso.

Vamos supor que você tenha uma taxa de alteração horária de 500 GB. E que você deseja que seu backup seja bloqueado antes de ser carregado em algum armazenamento. Mesmo ao usar bzip2 paralelo , a compactação de 10 TB levaria algumas horas para terminar, simplesmente porque o fato de que provavelmente a taxa de transferência de armazenamento em massa se tornaria seu fator limitante. Vamos supor que levaria 2 horas para compactar os dados para 2 TB. Portanto, agora precisaríamos de cerca de 2 TB + 2 * 500 GB de espaço livre em disco, 1 TB necessário para o instantâneo LVM. Isso criaria a necessidade de superprovisionar seu sistema de arquivos por pelo menos30%. Caso você queira ter uma margem de segurança adequada, isso pode aumentar facilmente para 60-70% (20% para um fator de utilização de 0,8 para o sistema de arquivos original, o mesmo para o tamanho do instantâneo mais o espaço necessário para o próprio backup compactado ). Na maioria dos ambientes de produção, isso seria inaceitável, já que o superprovisionamento seria estático (você não gostaria que um script de backup se confundisse com seu LVM dinamicamente, gostaria?).

cópia de segurança MMS

Embora o backup MMS tenha alguns recursos impressionantes (backup contínuo, recuperação pontual fácil), ele vem com uma séria desvantagem: seu preço para grandes implantações pode facilmente chegar aos milhares. Com uma taxa de alteração por hora presumida de 500 GB nesses 10 TB, seria uma soma média de seis dígitos para backups na nuvem . Por mês.

Minha sugestão é que ele faça uma assinatura corporativa para seus servidores por ser elegível para ter uma instância MMS local, incluindo backup.

Resumo

Aqui estão as opções que eu escolheria em ordem decrescente de preferência.

1. Instantâneos SAN: fáceis de implementar, relativamente baratos
2. Assinatura Enterprise: melhores recursos. Instale, configure, esqueça, está lá quando você precisar
3. Instantâneos LVM: fáceis de implementar, mas os custos do provisionamento excessivo necessário podem aumentar com o tempo.

Existem duas opções

BACKUP FÍSICO

Se você não se importa com o tempo de inatividade, a coisa mais simples a fazer é

service mongod stop

Faça um instantâneo LVM ou uma força bruta cpda pasta de dados Mongo para outro disco

service mongod start

Obviamente, você não deseja tempo de inatividade se os 10 TB de dados estiverem em uma máquina autônoma.

CONJUNTO DE RÉPLICA ATRASADO

Se você tiver um conjunto de réplicas com três nós, use um dos nós para backups

{
        "_id" : "myreplica",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "10.20.30.40:27017",
                        "priority" : 2
                },
                {
                        "_id" : 2,
                        "host" : "10.20.30.41:27017"
                },
                {
                        "_id" : 3,
                        "host" : "10.20.30.42:27017",
                        "priority" : 0,
                        "slaveDelay" : 3600
                }
        ]
}

Use o nó com "_id' : 3todos os seus backups físicos. Portanto, sem tempo de inatividade. Para obter um instantâneo da meia-noite, você pode iniciar o backup à 1h, pois o nó oculto está 1 hora atrasado.

Claro que o inconveniente é ter mais dois servidores com 10TB cada e a sanidade do administrador de sistema em risco.

MONGODUMP

Você pode usar o mongodump na máquina autônoma, mas deve esperar a degradação do desempenho, pois o mongodump é um programa cliente que usa uma conexão como qualquer outra conexão.

Se você deseja backup pontual, deve usar

mongodump --oplog 

O backup BSON lógico será menor (especialmente gzipado ou bzipado) do que o backup físico.

O uso mongodump --oplogseria melhor feito no nó oculto. Dessa forma, não há impacto no desempenho do Master.

AVISO LEGAL

Sou relativamente novo no MongoDB (MongoDBA acidental/incidental). Espero que minha resposta ajude.