partclone - отличная тулза для клонирования любых файловых систем (быстро и просто и может скипать плохие сектора).
#troubleshooting #disk
#troubleshooting #disk
что-та сожрало все место на жестком диске!!!
Вы такие заходите на сервер, выполняете df -h и видите следующую картину:
Воу-воу, полегче думаете вы. Расчехляем пылесос и начинаем зачистку логов. Для начала следует выснить кто же поднасрал:
Видим несколько файлов - 13G и 1G. Так. приехали. Уже что-то не так. окейси, вдруг там кто-то в корень логов насрал множеством файлов. ls -lash - ба. да файлов с папками всего ничего. ХММММ думаете вы. Ну, ок, посчитаем:
20G
Но ведь df показывает 49!!! WTF!? Что это может значить, когда файлы по факту занимают куда меньше чем показывает общая занятость диска. Первая мысль - проверить размер диска и фс. вдруг кто-то что-то подкрутил. А вторая - куда более правильная - место занимают файлы, которых нет. Нет ничего что занимает, значит это и занимает, ага. Это значит, что мы столкнулись с ситуацией, когда файл с диска удалили, но процесс еще держит его открытым. проверим эту теорию:
А, вот оно. Проблема в том, что при ротации лога, filebeat не отпускает старый файл. В данной ситуации достаточно перезапустить службу filebeat и волшебным образом место на жестком диске вернется обратно.
З.Ы. Вычитал тут полезный ключик для ncdu\du - ключ -x - который не будет обсчитывать вглубь примонтированные тома. так, например, если у вас смонтировано на /var, /var/log, итп какие-то тома (удаленные или локальные), запустив ncdu -x / вы получите информацию только по корню без смонтированных.
#disk #troubleshooting
Вы такие заходите на сервер, выполняете df -h и видите следующую картину:
/dev/sdb 49G 49G 0G 100% /var/log
Воу-воу, полегче думаете вы. Расчехляем пылесос и начинаем зачистку логов. Для начала следует выснить кто же поднасрал:
cd /var/log && du -hs ./* | grep G
Видим несколько файлов - 13G и 1G. Так. приехали. Уже что-то не так. окейси, вдруг там кто-то в корень логов насрал множеством файлов. ls -lash - ба. да файлов с папками всего ничего. ХММММ думаете вы. Ну, ок, посчитаем:
du -hs ./
20G
Но ведь df показывает 49!!! WTF!? Что это может значить, когда файлы по факту занимают куда меньше чем показывает общая занятость диска. Первая мысль - проверить размер диска и фс. вдруг кто-то что-то подкрутил. А вторая - куда более правильная - место занимают файлы, которых нет. Нет ничего что занимает, значит это и занимает, ага. Это значит, что мы столкнулись с ситуацией, когда файл с диска удалили, но процесс еще держит его открытым. проверим эту теорию:
# lsof | grep "/var/log" | grep deleted
filebeat 2211 root 13r REG 8,16 32037162645 27 /var/log/haproxy.log.1 (deleted)
filebeat 2211 2212 root 13r REG 8,16 32037162645 27 /var/log/haproxy.log.1 (deleted)
filebeat 2211 2213 root 13r REG 8,16 32037162645 27 /var/log/haproxy.log.1 (deleted)
....
А, вот оно. Проблема в том, что при ротации лога, filebeat не отпускает старый файл. В данной ситуации достаточно перезапустить службу filebeat и волшебным образом место на жестком диске вернется обратно.
З.Ы. Вычитал тут полезный ключик для ncdu\du - ключ -x - который не будет обсчитывать вглубь примонтированные тома. так, например, если у вас смонтировано на /var, /var/log, итп какие-то тома (удаленные или локальные), запустив ncdu -x / вы получите информацию только по корню без смонтированных.
#disk #troubleshooting