A cópia DD funciona no terminal, mas não no cron

Question

Em um sistema RHEL5.4, eu configurei um script para fazer backup de uma unidade com a cópia dd todas as noites pelo cron. Eu cuspo a saída dd em um arquivo de log e email. Ele está em / etc / crontab e / var / spool / cron / root quando descobri que ele nem seria executado no cron.

O script deve copiar / dev / sda para /mnt/backup/sda.img (/ mnt / backup é um externo de 250gb montado).

Quando eu o executo como root no terminal ele funciona bem, eu posso ver os dados sendo gravados no disco e o sda.img está ficando maior.

No entanto, quando executado como cron, recebo a saída do dd dizendo que copiou 147gb, mas não consegue encontrar onde ele cuspiu 147gb para - ele não colocou em sda.img. Não está no sistema de arquivos em qualquer lugar, pois restam apenas 50GB.

Para onde foi? E como posso ter certeza de que a mesma coisa acontece no cron que acontece no terminal.

Eu paro o crond e o inicio antes e depois do backup, mas tenho a impressão de que o cron expulsa o trabalho, eu o fecho, ele faz o backup, recomeça e está no seu caminho alegre.

Obrigado.

EDIT: Desculpe, a linha dd é
    dd if = / dev / sda de = / mnt / backup / sda.img bs = 400K

E a linha do cron é a     01 0 * * * 2-6 /root/applog_backup.sh

Eu posso acessar os arquivos quando ele funciona com o
    mount -o loop, offset = 32256 sda.img / mnt / restore

Eu encerrei o cron para impedir que trabalhos por hora modifiquem o disco durante o backup. Também desliguei outros serviços e o banco de dados de produção para minimizar a gravação em disco nos locais importantes.

    

Answer 1

Você tem seu script "backup" sendo executado pelo cron ... e você encerra o cron no script para evitar que tarefas do cron sejam executadas durante o "backup". Você realmente não consegue ver onde está o problema aqui? Seu script é desligado, mas o crond está rodando o seu script, então, desligar o crond irá fechar os descritores conectados ao seu script, que irá então morrer, seja com um cano quebrado ou por um sinal de interrupção do próprio crond.

Como o script morreu, o crond não será mais reiniciado. Isso é o que chamamos de "atirar-se no pé".

Mesmo depois de reiniciar o crond, ele não terá registrado que o trabalho foi concluído, já que foi encerrado durante sua execução e / ou teve que sinalizar sua finalização. Seja o próprio crond ou o anacron (depende de qual cron scheduler você está usando), ele terá que executar o job novamente, potencialmente entrando em um loop infinito.

Seu problema é um excelente exemplo de tudo o que há de errado em inventar sua própria solução de "backup" se você não tiver experiência real com gerenciamento de confiabilidade e recuperação de desastres. Pior, falta de conhecimento de como o sistema funciona.

Primeiro, e mais importante, você não faz um despejo de disco bruto em um sistema de arquivos ao vivo . Os sistemas de arquivos foram inventados para que você não toque diretamente no conteúdo do disco bruto. Você quer salvar os arquivos armazenados no sistema de arquivos, é o que importa para você. Então você tem que acessá-los através do sistema de arquivos , não os bytes brutos armazenados no disco. Se a partição estiver montada, não há garantia absoluta de que seus dados estão realmente armazenados no disco e que o disco permanecerá em um estado consistente durante a cópia.

Mesmo se você pudesse capturar instantaneamente o estado do disco de maneira recuperável (como uma falha de energia repentina, que poderia ser recuperada rapidamente com um sistema de arquivos com diário, como o ext3), isso nunca é verdade com um hot disk dump. Um despejo de disco leva muito tempo para ser concluído, existem estados intermediários virtualmente infinitos entre o início e o final do despejo, e o dump conterá uma mistura desses estados, o que é potencialmente irrecuperável mesmo com um sistema de arquivos com journal.

E ainda não mencionei tudo o que há de errado nos backups de despejo de disco bruto:

• Não há diferença entre o espaço usado e o livre. Não importa se você tem um único arquivo de 100 kB ou 250 GB em dezenas de milhares de arquivos, tudo será copiado. É extremamente ineficiente. Você só usa essa abordagem se precisar de um clone idêntico do disco e com o disco desmontado .
• Você não pode fazer backups diferenciais ou incrementais. Todos os seus backups devem ser backups completos. Todos os tipos de ineficiência:
  1. Como isso demanda muito espaço, você normalmente manterá apenas uma única cópia de todos os dados. Se os seus arquivos forem danificados ou excluídos antes do backup e você não notar, os dados danificados ou excluídos serão copiados sobre o backup anterior, tornando-o inútil.
  2. Como você faz isso com os dados anteriores, se o sistema falhar no meio do dump (o que leva mais tempo desde que você está copiando todo o disco), tanto o sistema original quanto o backup são perdidos em um único tiro.
  3. Se 100 kB de dados forem alterados desde o backup anterior, você ainda despejará todo o disco. No seu caso, isso é pelo menos um milhão de vezes menos eficiente.
• Você não pode restaurar esse despejo em um disco com uma geometria diferente. Se o seu disco de substituição for menor, não haverá discussão; Se o disco de substituição for maior, você poderá restaurar o espaço extra ou fazer algumas alterações manuais (e perigosas para os não iniciados) na tabela de partições e superblocos de partição. Você quer confiar em seus arquivos, seu trabalho, para tal hack?
• Mesmo se você montar a imagem raw usando um dispositivo de loop e copiar os arquivos manualmente ... você acaba copiando seus arquivos manualmente !! Então o que você ganhou fazendo um despejo de disco bruto? Apenas copie seus malditos arquivos!

Muitas pessoas já passaram por isso e têm muita experiência para compartilhar em relação à recuperação de desastres. Não tente inventar sua própria solução de backup, você vai acabar atrapalhando as coisas. Use cópias de segurança adequadas, como o despejo , tar ou rsync . Se você precisar de algo mais robusto, use Amanda ou Bacula , ou uma das outras centenas de soluções prontas para uso.

Provavelmente não é a resposta que você estava esperando, mas precisava ser dita.

    

Answer 2

Por favor, por favor, não use dd para fazer backups de seu volume físico, por todos os motivos apresentados nos comentários da sua pergunta.

No mínimo, se você quiser fazer backups de disco para disco, use algo como rsync (apesar de que isso não seja isento de problemas), e volte aqui se não conseguir fazer isso funcionar cron .

    

Answer 3

Eu suspeito que sua linha cron não esteja correta. Por favor, edite seu arquivo crontab com as entradas abaixo:

1 0 * * 2-6 /root/applog_backup.sh

Deixe-me saber se isso resolve o problema.

    

Answer 4

Gostaria de sugerir que você aproveite o tempo e procure um produto chamado Bacula. É open source (grátis!) E faz um ótimo trabalho. É complexo de configurar, mas uma vez que você vá, você vai esquecer de se preocupar com backups novamente.