Quais são as razões das melhores práticas para ter várias partições para servidores? [duplicado]

Question

Quando instalo uma distro gráfica para fins pessoais, normalmente separo /boot e /home .

Quando eu instalo um servidor, fico apenas em /boot e / e, dependendo do projeto, posso considerar outros sob demanda, como mencionei aqui com /var/log e /var/lib/docker .

Com base na premissa de que estou falando de um servidor Linux, parece que há uma tendência de separar de forma imprudente todo diretório raiz em partições, não entendo o motivo.

@Doug O'Neal declararam aqui que há vários documentos de práticas recomendadas (por exemplo, CIS Benchmark) que mandate separando / var, / home, / usr, etc, em diferentes sistemas de arquivos.

Durante minha pesquisa, li este artigo que dá boas razões para separar partições, mas não parece ser exagerado para cada diretório.

Este outro artigo e aqui também menciona o diretório por particionamento, mas não dá qualquer razão, apenas faça isso por segurança, confiando cegamente neles!

O fato de você poder configurar diferentes flags na montagem como nodev, nosuid ou mesmo noexec não parece tão crucial para mim como se o usuário não fosse sudoer. Simplesmente negar o acesso de gravação seria suficiente, e se for sudoer, não evite danos.

O fato de você poder fazer backup deles separadamente não compensa o fardo. e o fato de você poder limpá-los separado, você poderia simplesmente remover o diretório.

O fato de você poder ter badblocks em alguns deles não me faz sentir aliviado, como os badblocks são dados por setor, os arquivos seriam danificados com ou sem partições.

O único fato que eu acho que poderia ser um pouco bom seria se as partições estivessem em discos separados e um deles não fosse carregado ou o setor da tabela de partição estivesse danificado, mas, dependendo do caso, você não conseguiria para inicializar o sistema de qualquer maneira, com ou sem várias partições espalhadas.

Pensando nessa última possibilidade, a fim de recuperar o disco não faria qualquer diferença em ter uma ou várias partições, você pode executar o testdisk ou ddrescue a imagem em qualquer caso irá resultar o mesmo.

Eu estou querendo saber quais são as razões das "melhores práticas" para ter várias separações de partição sem levar em conta quais se adequam ao projeto?

    

Answer 1

Acho que realmente depende de seus recursos para trabalhar, de suas configurações preexistentes e de como você pretende trabalhar no futuro. Se você ainda estiver executando em bare metal e armazenamento local, faz sentido particionar, pois você pode precisar expandir na camada física. Você pode não ter um slot sobressalente para colocar em um controlador RAID ou RAM suficiente para rodar o RAID no software, para fazer o melhor que puder com seus recursos. Por exemplo, se / home estiver sendo preenchido, você poderá adicionar outro disco ao sistema e, em seguida, rsync, depois, usar um único usuário, ressincronizar e redefinir os pontos de montagem. Um "tudo em um" é um impacto possível e insignificante, mas acho mais fácil migrar dessa maneira.

Bancos de dados sempre preferem separá-los por motivos de desempenho - coloque seus logs em um lugar, seus dados em outro e, se possível, seus índices em um terceiro local - com seus próprios discos e controladores! Simplesmente mantém a via aberta para transações de dados.

É principalmente sobre gerenciamento de espaço. Eu tenho um conjunto de servidores de produção que geram 100 GB de arquivos de log antes do início da rotação do log, já que, literalmente, muitas informações são necessárias para capturar alguns dados de transação estendidos. (Uma única "transação" pode acionar 10.000 subtarefas exclusivas, todas elas precisam ter status transacional completo mantido.) Se o desenvolvimento expandir esse requisito, posso optar por fazer um serviço pause / halt, remontar o novo caminho e começar - em vez de ter que deslocar 100 GB de logs ao redor ...

Não posso arriscar o sistema operacional dar um mergulho a partir de um problema de espaço em disco, nem o banco de dados aguardar que uma gravação faça um commit, para que possamos expandir o espaço para um disco (e controlador) separado no futuro . Se eu tiver uma caixa com um enorme armazenamento de dados e eu quiser usar o SSD para o SO e a camada de aplicativo, o híbrido é uma opção viável para mim. Novamente, é mais fácil migrar partições de dados do que unidades de disco inteiras. (e sim, eu uso old school "dd" para isso.)