Temos um servidor da Web interno (virtualizado, hospedando o ReviewBoard, mas não super relevante) e temos um modo de falha relativamente consistente com montagens de NFS com falha que causam o preenchimento. Distro é Ubuntu (não pergunte) se uma solução depende de uma distribuição diferente, será mais lento para implementar.
Backups estão sendo realizados para / mnt / backup /, que é suposto a uma montagem NFS para 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 demora muito tempo antes / está cheio e os serviços começam a falhar.
Várias soluções possíveis foram discutidas.
Monitore / mnt / backups e verifique se não é root. Talvez um trabalho cron.
Use / mnt / protected / backups e monte / proteja primeiro em um sistema de arquivos pequeno, talvez uma montagem de loop em um arquivo local, por isso é muito menos provável que falhe.
Chmod a-rwx / mnt / backups (o ponto de montagem do sistema de arquivos raiz). Não tenho certeza se a montagem sobre o diretor protegido funcionará, acho que sim.
Na árvore montada, crie um diretório chamado "Backups" e, em seguida, clique no link "ln -s / mnt / backup / Backups / Backups". O uso de / Backups para backups falhará, a menos que o / mnt / backup esteja montado, uma vez que a árvore local não contém o subdiretório.
Executando uma verificação de que o diretório está 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 forma padrão de proteger o sistema de arquivos raiz desse tipo de maldade.
Número 5 - Coloque um teste em seu script de backup para garantir que o diretório seja montado antes de continuar. O script deve falhar se a montagem não estiver disponível ou presente. Ou você pode apenas certificar-se de que as coisas estão montadas antes de executar o backup.
Experimente o comando mountpoint , que verifica se um diretório especificado é um ponto de montagem:
mountpoint -q /mnt/backups || mount /mnt/backups
A solução mais à prova de erros é tornar o ponto de montagem não regravável. Esta seria sua solução # 3. No entanto, há um passo adicional que você deve realizar. %código%. Isso ocorre porque, mesmo sem permissões, o root ainda seria capaz de gravar no diretório. Com chattr +i /mnt/backups (define sinalizador imutável) nem mesmo o root pode gravar nele. Uma vez que o mount é montado, as permissões não importam, pois as permissões serão do diretório remoto, não do local.
O que ewwhite disse. Além disso, algum monitoramento extra para a saúde do sistema básico não seria uma má ideia.
Algo como o Monit pode verificar quanto espaço resta . Se você quiser ter uma visão completa do monitoramento do sistema, pode ver o Nagios, mas o Monit é leve e fará o básico.
Como você está usando o Ubuntu, o Monit já está no repo, então você pode fazer "sudo apt-get install monit", então começar a procurar pelos arquivos de configuração para enviar alertas para o lugar certo, monitorar o direito serviços, etc. Aqui está um rápido tutorial .
Aqui está um liner que você pode executar como cron job, ele assume que o mount em questão está no fstab:
if mountpoint -q /mnt ; then : ; else mount /mnt ; fi
Para uma solução de longo prazo: Não sei como fazer isso no Ubuntu (sou centrada na 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 volumes lógicos separados, sistemas de arquivos, mesmo grupos de volumes em máquinas servidoras. Então, como uma questão de prática padrão, criamos volumes lógicos LVM para /, / tmp. / usr, / usr / local, / opt, / home, / var, espaço de troca e uma partição separada para / boot. Essa abordagem torna ainda mais difícil para os sistemas de arquivos preencher e desativar o sistema. Na verdade, essa abordagem tornará quase impossível preencher o sistema / file. Você ainda precisa assistir / tmp, / var, é claro. Se precisarmos armazenar dados, criamos um grupo de volumes totalmente diferente para ele. Essa abordagem também tem outros benefícios, expandir os sistemas de arquivos à vontade, movê-los, criar novos, etc. E, como uma observação histórica, levamos esse método para o Linux a partir do SO AIX nos anos 90!