Заполнение корневой файловой системы, нет больших файлов

Так что я совсем новый сисадмин, только что закончил школу и проходил стажировку. Единственная проблема в том, что я единственный сисадмин на месте и никто не показал мне работу. В любом случае, это очень маленькая компания, один сервер CentOs с такой конфигурацией:

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda3             184G  140G   35G  81% /

tmpfs                 2.3G     0  2.3G   0% /lib/init/rw

udev                  2.3G  212K  2.3G   1% /dev

tmpfs                 2.3G     0  2.3G   0% /dev/shm

/dev/sda1             4.6G  156M  4.2G   4% /boot

/dev/sda4              33G  176M   31G   1% /tmp

/dev/sdb1             1.8T  1.8T     0 100% /media/backupInterne

/dev/sdd1             917G  470G  401G  54% /media/Data

Я приехал сюда всего несколько дней назад и сразу заметил полный диск, и я работаю над решением этой проблемы. Моя другая проблема здесь sda3 сейчас на 81%. 4 дня назад это было на 79%.

Я бегал ду-ха | Команда sort -rh в каталоге / root ничего не выделяет. Сделал это за несколько дней, так как раздел sda3 быстро заполняется, никаких существенных различий, которые могли бы объяснить его рост.

большое спасибо

linux filesystems mount

— littleadmin
источник

Мое предположение было бы роста журнала , потому что sdb1полон, но мы увидим , насколько большой /varэто .. что вы получаете от du -sh /*?

— Шейн Мэдден

Если вы хотите увидеть, какие файлы имеют изменения, вы можете использовать findс -mtime n [smhdw]. Я подозреваю, что Шейн прав. Частично это могут быть файлы журналов с жалобами на полный том sdb1. Команда может выглядеть так: find / -type f -mtime 1d -print если ваш find поддерживает, --exclude-dir=вы можете исключить / dev и / proc.

— Hennes

/ var равен 1.7G, и его размер за последние несколько дней практически не изменился, это была моя первая идея проверить это. Я всегда запускаю команду du с параметром --exclude = 'media', так как в этом каталоге нет ничего, кроме смонтированных каталогов

— littleadmin

Поскольку вы написали, что вы новый администратор, я бы указал на одну из наиболее распространенных причин растущего использования диска. Лог-файлы. Если вы откроете файл (например, журнал с веб-сервера), а затем удалите этот файл, тогда файл все равно будет использовать дисковое пространство, пока программа не закроет свой дескриптор этого файла. Последнее иногда решается отправкой регистрации ( kill -1 PID-> перечитать конфигурационный файл и перезапустить для многих демонов) или тупым топором перезагрузки.

— Hennes

В случае, если это рост журналов, он может

— завершиться

Ответы:

Вот что я использую, пытаясь выяснить подобные проблемы.

du -s `ls -a | egrep -v '\.\.'` | sort -nr | head

Он покажет вам использование каждого каталога / файла в текущем каталоге. Оттуда вы спускаетесь в подкаталоги, пока не найдете что-то очевидное.

Наличие всего в одном большом разделе может затруднить диагностику подобных проблем. Другой подход, который стоит попробовать - это использовать

lsof

чтобы увидеть, какие файлы открываются различными процессами, и посмотреть, сможете ли вы найти некоторые подсказки. Это очень ударить или пропустить, хотя.

— Фред Волшебное чудо пса
источник

+1 за упоминание lsof. Этот инструмент пригодится новому администратору (даже если он коснулся этой проблемы).

— Hennes

использование по каталогу / файлам дает мне 5 результатов, ни один из них не превышает 600 КБ.

— littleadmin

Это звучит очень похоже на аналогичную проблему, которая у меня есть все время с удаленными файлами (но ссылка все еще там).

Если мы говорим о системе Linux, запустите:

lsof + L1

Это будет список удаляемых файлов, но они все еще открыты и используются чем-то. Ключ в том, чтобы получить все, что имеет файловый дескриптор, открытый для его освобождения.

— Эйрик Тофт
источник

К сожалению, не дал никаких файлов, которые могли бы объяснить потерю места, которое происходит каждый день. спасибо

— littleadmin

Возможно ли, что что-то записывается в каталог, который затем монтируется с файловой системой? В этот раз у меня были гигабайты необъяснимых волос. Хотя это никогда не должно быть возможным, я смог доказать, что это может произойти.

— Эйрик Тофт

Я тоже думаю о чем-то подобном, но как это могло произойти? И как мне проверить это, не размонтируя все?

— littleadmin

Я наконец понял, что происходит. Одна из точек монтирования была подключена неправильно, поэтому делала резервное копирование непосредственно на sda3.

Спасибо всем за помощь

— littleadmin
источник