A melhor maneira de impedir que o sistema raiz se encha quando uma montagem falha?

Temos um servidor web interno (virtualizado, hospedando o ReviewBoard, mas não muito relevante) e temos um modo de falha relativamente consistente com montagens NFS com falha, causando / a encher. Distro é o Ubuntu (não pergunte) se uma solução depende de uma distribuição diferente, será mais lenta de implementar.

Os backups estão sendo executados em / mnt / backup /, que é suposto montar um NFS em outro sistema. Infelizmente, quando a montagem falha ou cai, os backups são executados no sistema de arquivos raiz, o que, como você pode imaginar, não leva muito tempo antes / está cheio, e os serviços começam a falhar.

Várias soluções possíveis foram discutidas.

1. Monitore / mnt / backups e verifique se não é root. Talvez um trabalho cron.

2. Use / mnt / protected / backups e monte / proteja primeiro em um sistema de arquivos pequeno, talvez uma montagem em loop em um arquivo local, para que seja muito menos provável que falhe.

3. Chmod a-rwx / mnt / backups (o ponto de montagem do sistema de arquivos raiz). Não sei se a montagem sobre o diretor protegido funcionará, acho que funciona.

4. Na árvore montada, crie um diretório chamado "Backups" e vincule o link "ln - s / mnt / backup / Backups / Backups". O uso de / Backups para backups falhará, a menos que o / mnt / backup esteja montado, pois a árvore local não contém o subdiretório.

5. Executando uma verificação de que o diretório esteja montado corretamente no script de backup.

Estou interessado em qualquer feedback sobre essas abordagens, prós e contras ou quaisquer técnicas adicionais que as pessoas usem como uma maneira padrão de proteger o sistema de arquivos raiz deste tipo de maldade.

Número 5 - Faça um teste no seu script de backup para garantir que o diretório esteja montado antes de continuar. O script falhará se a montagem não estiver disponível ou presente. Ou você pode apenas garantir que tudo esteja montado antes da execução do backup.

Experimente o mountpointcomando, que verifica se um diretório especificado é um ponto de montagem:

mountpoint -q /mnt/backups || mount /mnt/backups

A solução mais resistente a erros é tornar o ponto de montagem gravável. Essa seria sua solução nº 3. No entanto, há uma etapa adicional que você deve executar. chattr +i /mnt/backups. Isso ocorre porque, mesmo sem permissões, o root ainda poderá gravar no diretório. Com chattr +i(define sinalizador imutável), nem mesmo o root pode gravar nele. Depois que a montagem é montada, as permissões não importam, pois serão do diretório remoto, não do diretório local.

O que ewwhite disse. Além disso, um monitoramento extra da integridade do sistema básico não seria uma má idéia.

Algo como o Monit pode verificar para ver quanto espaço resta . Se você quiser se concentrar no monitoramento do sistema, pode olhar para o Nagios, mas o Monit é leve e fará o básico.

Como você está usando o Ubuntu, o Monit já está no repositório, então você pode fazer o "sudo apt-get install monit" e começar a olhar os arquivos de configuração para dizer a ele para enviar alertas para o lugar certo, monitorar os serviços certos, etc. Aqui está um tutorial rápido .

Aqui está um liner que você pode executar como um trabalho cron, ele assume que a montagem em questão está no fstab:

if mountpoint -q /mnt ; then : ; else mount /mnt ; fi

Para uma solução de longo prazo: Não tenho certeza de como fazer isso no Ubuntu (eu sou centralizado em RH) ou se vale a pena (se você tiver apenas uma máquina), mas uma metodologia que funcionou para nós por MUITOS anos é criar lógica lógica separada. volumes, sistemas de arquivos e até grupos de volumes em máquinas servidores. Portanto, como uma prática padrão, criamos volumes lógicos LVM para /, / tmp. / usr, / usr / local, / opt, / home, / var, espaço para swap e uma partição separada para / boot. Essa abordagem dificulta ainda mais o preenchimento e desativação do sistema de arquivos. Na verdade, essa abordagem tornará quase impossível preencher o sistema de arquivos /. Você ainda precisa assistir / tmp, / var, é claro. Se precisarmos abrigar dados, criaremos um grupo de volumes totalmente diferente para eles. Essa abordagem também tem outros benefícios, expanda os sistemas de arquivos à vontade, mova-os, crie novos, etc.