Usando o slapcat para fazer backup do LDAP

Question

Estou executando um diretório OpenLDAP em um servidor Debian, usando o backend hdb. Eu tenho me perguntado sobre backups, e fiz algumas leituras na net. O Slapcat parece ser o caminho a percorrer, mas continuo vendo esses posts falando que é perigoso usá-lo enquanto o slapd está rodando.

De que maneira isso é perigoso? Estou planejando executar esses backups durante a noite, e nenhuma gravação será feita no banco de dados durante a noite - provavelmente, as leituras ocorrerão.

Se houver outra solução de backup mais adequada para isso, eu ficaria feliz em saber disso.

    

Answer 1

O OpenLDAP suporta vários backends, sendo os mais populares atualmente o bdb / hdb. A partir da página de manual do slapcat :

   For some backend types, your slapd(8) should not be running (at  least,
   not  in  read-write mode) when you do this to ensure consistency of the
   database. It is always safe  to  run  slapcat  with  the  slapd-bdb(5),
   slapd-hdb(5), and slapd-null(5) backends.

Portanto, desde que você esteja usando o bdb ou o hdb como backend, não há problema em executá-lo enquanto o slapd está em execução. Eu uso isso em muitos servidores e recomendo. É realmente a melhor maneira de fazer backup.

Alternativas incluiriam a emissão de um comando de pesquisa ldap para o servidor para retornar a árvore inteira. Isso será significativamente mais lento que o slapcat, porque toda a comunicação deve passar pelas camadas da rede e as regras de controle de acesso devem ser verificadas. Além disso, você precisa ter certeza de que o usuário que está pesquisando tem os direitos de acesso corretos.

    

Answer 2

Temos usado o slapcat para nossos backups, assim como as outras respostas mencionadas. Eles eram muito confiáveis por mais de 4 anos, mas desde a atualização do Debian lenny para o squeeze nós experimentamos backups ocasionalmente truncados. Esses backups quebrados ocorrem em cerca de 1 de 30 casos. Estamos rodando o slapcat enquanto o slapd está rodando. A parte ruim é que o slapcat não dá nenhuma indicação de um problema, ou seja, o código de saída é zero. Por razões históricas, estamos usando o backend bdb. Pode ser melhor com o backend hdb.

Nós olhamos em volta para considerar melhores estratégias de backup, mas além de configurar um escravo que pode ser interrompido para o backup, não há muito mais no que diz respeito aos procedimentos padrão ou às melhores práticas. Isso nos levou a repensar nossa política de backup e a escrever alguns scripts para automatizar a nova política.

Primeiro, temos um script chamado safe-ldif que executa o slapcat várias vezes até obter o mesmo número de entradas LDAP duas vezes seguidas. Este é um trade off entre velocidade e confiabilidade. Em segundo lugar, decidimos colocar todas as entradas LDIF individualmente em um repositório Git. Isso nos dá uma compactação muito melhor do que apenas compactar os arquivos LDIF individuais do slapcat. Além disso, é muito conveniente ter um histórico das estrofes individuais do LDIF.

Se alguém mais estiver interessado, dê uma olhada no link

    

Answer 3

O motivo pelo qual o slapcat é perigoso é porque ele pesquisa diretamente no banco de dados. Dependendo do formato do banco de dados, isso pode causar corrupção de arquivos ou deadlocks.

Veja o que eu faço:

1. Configurar replicação entre duas instalações openldap
2. Periodicamente, encerre o slapd no escravo, copie os arquivos do banco de dados e reinicie-o

É isso. Eu corro ambas as cópias do openldap na mesma máquina (portas diferentes, a replicação está ligada apenas a 127.0.0.1 , então não vaza na ethernet atual).

    

Answer 4

Se você estiver disposto a recriar seu diretório LDAP usando o backend bdb, esse pode ser o caminho a seguir. No meu site, estamos executando um backup do slapcat em um diretório ativo com ~ 10k entradas a cada 4 horas nos últimos seis anos, e não tivemos nenhum problema com ele.