Maneira recomendada de combinar uma partição menor em um diretório grande

Question

Eu tenho uma partição específica no meu servidor (/ var) que está sendo preenchida em poucos dias. Estou executando um servidor de email ocupado e todos os emails do usuário estão aqui.

No entanto, agora preciso aumentar o armazenamento para acomodar mais e-mails.

Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           796M  556K  796M   1% /run
/dev/sda6       254G   32G  209G  14% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
none            5.0M  4.0K  5.0M   1% /run/lock
none            3.9G   80K  3.9G   1% /run/shm
none            100M     0  100M   0% /run/user
/dev/sda1       188M   66M  114M  37% /boot
/dev/sda7       1.6T  1.2T  364G  76% /var

Portanto, lemos muitas informações on-line e há várias recomendações.

O primeiro que eu encontrei está usando a partição LVM. Assim, posso adicionar um segundo disco rígido ao meu servidor e, em seguida, usar o LVM para combinar dois discos rígidos em uma partição lógica. Enquanto ainda estou lendo como exatamente fazer isso, eu li que, se uma unidade falhar, os dados serão perdidos sem uma maneira fácil de recuperar. Isso meio que me mandou procurar uma segunda alternativa.

O segundo está usando um sistema de arquivos de união que me permite mesclar vários diretórios em um. Até agora me deparei com essas implementações; unionfs, aufs, mhddfs e overlayfs. Neste caso, eu poderia rodar um segundo HDD ou pegar emprestado algum espaço de uma partição menos preenchida, como no meu caso root.

Eu experimentei overlayfs no meu localhost porque ele foi adicionado ao kernel principal do Linux.

Com muitas opções, não sei exatamente com qual solução devo ir em um servidor de e-mail crítico de produção. Eu apreciaria alguns ponteiros. Obrigado.

    

Answer 1

Primeiro, um sistema de arquivos de sobreposição / união não é a resposta correta aqui. Esses são para os casos em que você tem um sistema de arquivos somente leitura que contém a maioria dos seus dados e precisa ter alguma customização limitada além do que é gravável (por exemplo, o LiveCD usa sistemas de arquivos de sobreposição para permitir a impressão de um sistema de arquivos gravável embora a mídia seja somente leitura).

O LVM é quase certamente o que você quer, e não precisa ser confiável (ele pode fazer configurações de RAID com replicação). Alternativamente, você poderia simplesmente colocar um novo disco rígido (maior), e colocar /var nisso, apesar de eu sugerir colocar apenas /var/mail ou qualquer diretório de armazenamento de e-mail principal, e manter o resto onde ele está .

Em uma situação ideal, você deve tentar obter vários discos rígidos do mesmo tamanho e executar um conjunto RAID10 ou RAID5 / 6 naqueles com /var/mail na parte superior e, em seguida, trabalhar para que os usuários limpem e-mail antigo no servidor (essa situação é parte do motivo pelo qual a maioria dos provedores de e-mail coloca um limite no armazenamento de e-mail no servidor).

    

Answer 2

Sua melhor opção é adicionar pelo menos duas unidades grandes (por exemplo, 4 TB ou mais) e usar alguma forma de RAID-1 ou RAID-10 - se você não tiver nenhuma redundância de armazenamento em sua missão crítica serviço, você está fazendo errado.

Se você adicionar apenas duas unidades, use o RAID-1. para quatro ou mais, use o RAID-10. Eu aconselharia contra o uso de RAID-5 ou RAID-6 para e-mail porque o armazenamento de mensagens precisa de muita largura de banda de I / O, e o RAID-5 é muito mais lento que o RAID-1 / RAID-10 (e o RAID-6 é ainda mais lento) .

Existem várias formas de implementar o RAID-1 / RAID-10, incluindo mdadm e lvm . Com qualquer um desses, você pode criar uma matriz RAID, formatá-la com seu sistema de arquivos preferido e montá-la no lugar de /var/mail . Você também pode adicionar mais unidades conforme necessário no futuro, contanto que seu sistema de arquivos suporte o crescimento (por exemplo, xfs tem xfs_growfs , ext2 / 3/4 tem resize2fs ).

Outra opção é usar btrfs . Isso tem suporte embutido para recursos semelhantes a RAID e aumenta automaticamente o sistema de arquivos quando você adiciona mais unidades de armazenamento a ele. Ele também suporta detecção e correção de erros, snapshots, sub-volumes, compressão de arquivos transparente e muito mais.

O ZFS tem recursos semelhantes ao btrfs (e é o que eu pessoalmente uso) mas tem a desvantagem de não ser (e provavelmente nunca será devido a incompatibilidade de licenças entre CDDL e GPL) uma parte do kernel da linha principal. Está disponível apenas como patch ou módulo DKMS. Isso não é grande coisa hoje em dia, mas é mais trabalho.

Minha recomendação seria usar btrfs ou zfs. IMO não há realmente nenhum bom motivo para usar mdadm ou lvm antigo, a menos que você já esteja usando e tenha experiência e investimento significativos na tecnologia.

Existem várias perguntas e respostas neste site que detalham como configurar o mdadm, lvm, btrfs e / ou zfs e outros.

De qualquer forma, não importa como você implementa o seu sistema de arquivos RAID ou RAID, você terá que transferir seus e-mails antigos para o novo sistema de arquivos com o mínimo de tempo de inatividade. Em todos os casos, o procedimento será muito parecido com isto:

1. instale as novas unidades. Se você não tem baias hot swap, isso exigirá algum tempo de inatividade.

2. configure o novo raid e / ou sistema de arquivos

3. monte como /var/mail.new

4. rsync /var/mail/ para /var/mail.new/

5. Você pode repetir a etapa 4 quantas vezes quiser até ter tempo de concluir esse procedimento (provavelmente o melhor feito fora do horário comercial). Além de algum tempo de inatividade possível na etapa 1, não deve haver nenhum tempo de inatividade visível ao usuário até este ponto .... no máximo, eles podem ter notado que o sistema está um pouco mais lento que o normal enquanto os trabalhos rsync estão em execução. / p>

6. pare seu MTA (sendmail, exim, postfix ou qualquer outro) e seus daemons pop / imap e qualquer outra coisa que grave em /var/mail/ . Se você tiver usuários que fazem login em um shell para ler e-mails (por exemplo, com o mutt), peça para eles fazerem logout e não permitirem que façam login novamente até que você tenha terminado.

   Em suma, você precisa parar qualquer coisa e tudo que grava em qualquer arquivo em /var/mail . Você os reinicia mais tarde no passo 13.

7. execute uma% finalrsync de /var/mail/ a /var/mail.new/ para sincronizar as alterações desde a última execução.

8. mv /var/mail /var/mail.old
9. mkdir /var/mail
10. desmonte /var/mail.new e monte-o novamente como /var/mail (talvez com mount --move /var/mail.new /var/mail como mencionado por Austin Hemmelgarn)

11. examine a propriedade e as permissões de /var/mail.old e certifique-se de que /var/mail tenha exatamente o mesmo.

    Isso é feito facilmente com:

    chmod --reference=/var/mail.old /var/mail

    (nota --reference requer a versão GNU do chmod , que é padrão no linux)

12. edite /etc/fstab para que o novo sistema de arquivos seja sempre montado como /var/mail após uma reinicialização

13. agora você pode reiniciar seus serviços MTA, pop e imap e permitir que os usuários façam o login novamente. monitore-o bem de perto para verificar se ele está funcionando corretamente.

14. como quiser, quando tiver certeza de que a nova configuração está funcionando bem e você não precisará mais do diretório de e-mail antigo, é possível excluir /var/mail.old e todo o seu conteúdo.

BTW, você terminará com mais de 1TB em /var depois de fazer isso. Isso pode ser excessivo para as suas necessidades.