Linux Partição primária Debian (/) do servidor Full, como fazer espaço para isso

Question

Como posso liberar espaço no sistema de arquivos raiz com segurança?

df diz:

Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              9.7G  9.2G     0 100% /
tmpfs                 3.9G     0  3.9G   0% /lib/init/rw
udev                   10M  244K  9.8M   3% /dev
tmpfs                 3.9G  620K  3.9G   1% /dev/shm
/dev/md3              1.8T  327G  1.4T  19% /home

=============================================== =======================

du me dá:

root@sbs691:/# ls | xargs du -hs
5.8M    bin
13M     boot
244K    dev
8.0K    dotdeb.gpg
8.1M    etc
281G    home
17M     lib
3.7M    lib32
0       lib64
16K     lost+found
8.0K    media
4.0K    mnt
157M    opt
du: cannot access 'proc/31735/task/31735/fd/4': No such file or directory
du: cannot access 'proc/31735/task/31735/fdinfo/4': No such file or directory
du: cannot access 'proc/31735/fd/4': No such file or directory
du: cannot access 'proc/31735/fdinfo/4': No such file or directory
0       proc
41M     root
4.0K    run
14M     sbin
4.0K    selinux
4.0K    srv
0       sys
129M    tmp
2.2G    usr
431M    var

=============================================== ======

Atualizar após o primeiro comentário, du de /var :

root@sbs691:/var# ls | xargs du -hs
4.8M    backups
149M    cache
4.0K    games
265M    lib
4.0K    local
12K     lock
14M     log
4.0K    mail
4.0K    opt
200K    run
24K     spool
4.0K    tmp
16K     www

O problema agora está resolvido temporariamente reiniciando o nginx

service nginx restart

Depois de reiniciar

root@sbs691:/# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              9.7G  6.0G  3.3G  65% /
tmpfs                 3.9G     0  3.9G   0% /lib/init/rw
udev                   10M  244K  9.8M   3% /dev
tmpfs                 3.9G  620K  3.9G   1% /dev/shm
/dev/md3              1.8T  339G  1.4T  20% /home

    

Answer 1

Você provavelmente tem um arquivo que foi excluído, mas que está sendo mantido aberto (via fd) pelo daemon que está gravando nele. Dê uma olhada na saída de

lsof +L1

, que listará esses arquivos. Quando você conhece o arquivo, você só precisa descobrir qual daemon e, em seguida, dizer-lhe para reiniciar ou reabrir o arquivo de log.

A partir dos comentários: Descobriu-se que o OP tinha arquivos deletados em / var e não tinha reiniciado os daemons (especificamente nginx) que estavam gravando nos arquivos.

    

Answer 2

O caminho mais rápido (e um tanto hackiano) é inicializar o servidor em uma mídia de resgate e mover /var e talvez até mesmo /usr para o sistema de arquivos /home e fazer uma ligação simbólica de volta.

A abordagem correta (TM) é redimensionar as partições de uma maneira sensata, mas desde que você use um software RAID, isso não é exatamente fácil ou rápido.

    

Answer 3

• Como é um sistema Debian, você provavelmente acumulou muitos pacotes baixados em /var/cache/apt , o que pode encher o seu /var . A menos que você tenha um bom motivo para mantê-los, emita apt-get clean como root para removê-los.

• Você pode usar as ferramentas RAID parted ou ferramentas semelhantes para alterar o tamanho das suas partições. Lembre-se de ter um backup atual pronto antes disso!

• Como um recurso rápido, que eu realmente não posso recomendar, você também pode mover sua pasta /usr para a partição /home e o link simbólico da raiz. Lembre-se de ter um backup atual pronto antes disso! Minha ordem de trabalho seria:

  1. Se possível, desligue e reinicie a partir de um sistema de recuperação.
  2. Copie a pasta com todas as permissões, links, etc .: # cp -a /usr /home/root-usr ( Os caminhos serão diferentes quando você trabalha em um sistema de resgate! Certifique-se de que não haja nenhum usuário chamado root-usr ! ; -))
  3. Compare a pasta antiga com a nova para garantir que a cópia funcionou: # diff -r /usr /home/root-usr
  4. Remova o diretório antigo e crie um link simbólico: # rm -rf /usr; ln -s /home/root-usr /usr ( Certifique-se de que o link simbólico esteja correto ao fazer isso a partir de um sistema de recuperação! Você pode ter chroot para fazer isso. )
  5. Reinicie no seu sistema.

Tenha sempre cuidado. Você deveria saber o que faz.

    

Answer 4

A sua pasta var tem cerca de 431M de dados, começaria limpando seus registros.

    

Answer 5

Seus números não se somam. Você pode ter dados em seu root que você não "vê".

Eu só posso contar ~ 3G na saída du de sua raiz. Eu suspeito que você tenha:

• em algum momento copiou os dados em /home para um sistema de arquivos diferente e alterou o ponto de montagem, mas não conseguiu excluir a cópia original - isso, é claro, ainda ocupa espaço. Você não pode ver agora que mudou o ponto de montagem.

  Para encontrar esse tipo de fantasma dos dados da ópera , comparamos os totais de du em / (sem cruzar limites fs) e df .

• Ou criamos alguns arquivos grandes em / e, nesse caso, você precisa movê-los / excluí-los. Eles não pertencem a eles.

Answer 6

O / home foi posteriormente adicionado / montado no sistema?

se você tem dados antigos em md1 e em seu diretório / home, e montou a nova partição (md3) no diretório / home com opção não vazia o / home pode ocultar os dados originais que colocaram e reservaram seu tamanho em md1, mas você não pode ver por causa dessa outra patição,

Se você pode interromper as operações do servidor, desative o sistema no modo de recuperação

init 1

umount /home system, e procure os arquivos que ficaram na partição raiz original (md1)

ls -la /home