Диск занят на 12%: сколько вы платите за пустое место

MAATRIX

Зайдите на сервер и наберите df -h — велика вероятность, что цифра в столбце Use% вас удивит. Диск занят на 12%, на 18%, изредка на 30%, а платите вы каждый месяц за весь заказанный том целиком, будто он забит под завязку. Это не ошибка биллинга — это последствие решения, принятого один раз при заказе сервера: «возьмём диск с запасом, чтобы потом не возиться». Ниже — как это решение превращается в постоянную переплату и что с этим делать практически, без крайностей в обе стороны.

Откуда берётся диск, занятый на 12%

Сценарий почти всегда одинаковый. При заказе сервера кто-то прикидывает не текущий объём данных, а некий образ будущего: «у нас будет расти база», «прибавится пользователей», «не хочется потом переезжать». В расчёт закладывается не факт, а прогноз на год-два-три вперёд, причём прогноз обычно оптимистичный по росту и пессимистичный по трудозатратам на последующее расширение — «лучше сразу взять с запасом, чтобы не трогать это больше никогда».

В моменте это выглядит разумно: диск стоит в тарифе не так уж дорого, а головной боли с миграцией на больший том хочется избежать. Проблема в том, что прогноз почти никогда не сбывается быстро. Рост оказывается медленнее ожидаемого, часть функциональности откладывается, архитектура меняется — а диск, купленный под гипотетическое будущее, стоит занятым на 12% месяцами, а то и годами. Приложение, база данных, логи и бэкапы вместе занимают долю от заказанного объёма, и эта доля не меняется от того, что вы продолжаете платить за оставшиеся 88%.

Важная оговорка: 12% в заголовке — иллюстративный пример, а не универсальный норматив. У кого-то это 20%, у кого-то 8%. Механизм переплаты один и тот же независимо от точной цифры: платите вы за заказанный объём, а не за использованный.

Экономика пустого места: за что именно вы платите каждый месяц

Диск в тарифе VPS или выделенного сервера — это не расход по факту использования, а фиксированная ёмкость, забронированная за вами. В отличие от трафика, где обычно считают мегабайты и терабайты факта, диск считают по заказанному объёму: провайдер резервирует место на массиве под ваш том целиком, вне зависимости от того, заполнен он на 5% или на 95%. Это логично с точки зрения инфраструктуры — провайдер не может продать это же место ещё раз, пока ваш том существует, — но с точки зрения вашего бюджета это означает, что каждый месяц вы платите ренту за пространство, которое физически не используется.

Это отличается от переплаты за CPU и RAM, о которой обычно говорят в разрезе «средняя загрузка 4%» — там переплата это простаивающая вычислительная мощность, которая всё равно была бы недоступна другим клиентам сервера. С диском переплата более прямая: вы буквально арендуете квадратные метры склада под коробки, которых пока нет, и будете арендовать их до тех пор, пока кто-то не решит уменьшить аренду или не заполнит склад.

Отдельно стоит связка «диск с запасом» плюс «бэкапы и снапшоты» — если на большом основном томе ещё и накапливаются старые снапшоты, переплата удваивается: платите и за пустое место на основном диске, и за копии, которые давно никому не нужны. Это отдельная тема, но она часто идёт в одном счёте с переразмеренным диском.

Почему запас для диска — не то же самое, что запас для CPU и RAM

Ключевое отличие диска от вычислительных ресурсов — в том, как дорого обходится ошибка в меньшую сторону и как просто её исправить постфактум.

Увеличение CPU или RAM «на лету» зависит от гипервизора, тарифного плана провайдера и гостевой ОС. Часть платформ поддерживает hot-add памяти и ядер без остановки виртуальной машины, часть — нет: чтобы ядро увидело новые ресурсы, требуется перезагрузка гостевой системы, а иногда и полная остановка/старт (не просто reboot, а именно stop/start у гипервизора) для переприменения конфигурации. Поэтому исторически многие берут CPU и RAM с запасом заранее — плановое окно на увеличение по факту нужды обходится дороже в организационном смысле, чем несколько лишних гигабайт памяти в тарифе.

С диском ситуация обычно мягче. У подавляющего большинства провайдеров VPS увеличение виртуального диска — это операция на уровне хранилища, которая не требует остановки машины: том расширяется «снаружи», а дальше файловая система донастраивается изнутри гостевой ОС уже онлайн, без выключения сервиса. Именно поэтому для диска стратегия «заказываем под реальную текущую потребность плюс разумный близкий запас, а не под гипотетическое далёкое будущее» работает гораздо лучше, чем для CPU и RAM: цена ошибки в меньшую сторону — это спокойная операция на 10-15 минут, а не простой сервиса ради переезда.

Это не значит, что расширение диска всегда абсолютно бесплатно с точки зрения рисков — ниже разберём, что может пойти не так и когда лучше перестраховаться. Но по умолчанию для типового VPS с виртуальным диском на LVM или GPT-разметке рост объёма — рутинная операция, а не проект.

Как считать реальную потребность, а не гипотетическое будущее

Практический подход строится не на прогнозе «что если через два года», а на трёх понятных числах.

Текущий факт. Посмотрите, сколько данных реально лежит на сервере сейчас:

df -h
du -sh /var/lib/*
du -sh /var/log/*
ncdu /

df -h покажет общую занятость по разделам, du -sh — какие директории тяжелее всего (обычно это база данных, логи и загруженные пользователями файлы), ncdu — интерактивно и быстро найти, что именно съедает место, если счёт идёт не на единицы, а на десятки директорий.

Скорость роста за обозримый период. Не «через три года», а на горизонте, который вы реально можете предсказать — квартал, полгода. Если логи ротируются и чистятся по политике, а бэкапы уезжают во внешнее хранилище, рост тома обычно измеряется процентами в месяц, а не кратным увеличением. Если роста по факту пока не было (проект только запущен), закладывать кратный запас под воображаемый рост менее оправданно, чем закладывать разумный буфер и следить за трендом по факту.

Буфер на непредвиденное. Полностью убирать запас тоже не стоит — заполнение диска под 100% приводит к остановке записи в СУБД, падению бэкапов и труднообъяснимым сбоям в самый неподходящий момент. Разумный буфер поверх текущего факта и ближнего роста — это не «запас на будущее», а операционная подушка, чтобы не ловить алерт о нехватке места ночью. Подробно о том, сколько места стоит закладывать сверху и что незаметно съедает свободное пространство, разобрано в статье сколько дискового пространства закладывать с запасом — она смотрит на ту же задачу с обратной стороны: как не уйти в другую крайность и не остаться совсем без запаса.

Формула в итоге простая: заказываемый диск = текущий факт + прогнозируемый рост на ближайшие месяцы + операционный буфер. Всё, что сверх этого — переплата за гипотезу, которую вы всегда успеете докупить, когда она подтвердится фактом.

Как расширить диск, когда место реально понадобится

Если разметка сделана через LVM (что стоит делать по умолчанию именно ради будущего расширения), последовательность действий выглядит так:

1. Увеличиваете размер виртуального диска в панели управления или через API провайдера — операция на стороне хранилища, обычно без остановки сервера.
2. Внутри гостевой ОС заставляете ядро увидеть новый размер блочного устройства:

echo 1 > /sys/class/block/vda/device/rescan
lsblk

1. Расширяете раздел под новый размер диска (для GPT-разметки удобно через growpart из пакета cloud-guest-utils):

growpart /dev/vda 1

1. Расширяете физический том и логический том LVM:

pvresize /dev/vda1
lvextend -l +100%FREE /dev/mapper/vg0-root

1. Расширяете файловую систему онлайн — для ext4:

resize2fs /dev/mapper/vg0-root

для XFS (единственная файловая система, которую нельзя уменьшить, только увеличить, и это стоит держать в голове при выборе):

xfs_growfs /

Вся цепочка обычно укладывается в несколько минут и не требует простоя сервиса, если раздел смонтирован и активно используется — ext4 и XFS поддерживают онлайн-расширение. А вот уменьшение тома — операция принципиально другого уровня риска: для ext4 она возможна, но требует размонтирования и по факту офлайн-окна, а для XFS невозможна вообще без пересоздания файловой системы и переноса данных. Отсюда практический вывод: расширять диск по мере роста — нормально и дёшево, а вот заказывать диск заведомо большим «про запас», рассчитывая потом ужаться, — плохая идея в обе стороны: и переплата сейчас, и невозможность безболезненно сократить объём позже.

Перед любым расширением тома на боевом сервере не лишним будет снапшот текущего состояния — если что-то пойдёт не так на этапе lvextend/resize2fs, откат обойдётся дешевле, чем восстановление из бэкапа. Про то, как устроены и во что обходятся снапшоты, если их не чистить годами, — в отдельной статье про LVM-снапшоты, расширение и риски.

Когда экономить на диске не стоит

У подхода «бери по факту, расширяй по мере роста» есть законные исключения, и их стоит проговорить честно.

Дисковый ввод-вывод, а не только объём. Для нагруженных баз данных и других I/O-интенсивных сервисов важен не только занятый процент, но и производительность — на части тарифов IOPS и пропускная способность растут вместе с объёмом диска, и урезание тома «под факт» может упереться не в место, а в скорость отклика раньше, чем закончится свободное пространство. Прежде чем минимизировать диск для такой нагрузки, стоит понимать, как вообще считаются заявленные цифры IOPS и почему они часто недостижимы на практике — это разобрано в статье что такое IOPS на самом деле и почему цифра недостижима.

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

Провайдер без поддержки онлайн-расширения. Вся логика «закажи по факту, расширь позже» держится на одном допущении — что расширение действительно доступно без простоя. Прежде чем строить план вокруг этого допущения, стоит явно проверить у конкретного провайдера, как у него устроено увеличение диска: через панель самостоятельно, через тикет с ожиданием, или вообще недоступно для выбранного тарифа. Если расширение по факту требует простоя или заявки в поддержку на день-два, часть выгоды от подхода «без запаса» исчезает — и разумный ближний буфер стоит закладывать чуть щедрее.

Частые вопросы