Как расширить диск на работающем сервере

MAATRIX

Место на диске заканчивается в самый неподходящий момент — обычно ночью, по алерту от мониторинга, а не когда вы спокойно планировали апгрейд. Хорошая новость: диск почти всегда можно расширить прямо на работающем сервере, без переустановки системы и без остановки сервисов. Плохая новость: сама по себе покупка большего диска ничего не даёт — операционная система не увидит новое место, пока вы не расширите раздел и файловую систему поверх него. Разберём оба типичных случая: облачный VPS с виртуальным диском и физический сервер, где данные лежат на LVM.

Почему диск в панели больше, а в системе — нет

Это самая частая путаница у тех, кто впервые расширяет диск. Человек заходит в панель управления провайдера, увеличивает диск с 20 до 60 ГБ, видит подтверждение — и идёт проверять df -h на сервере. А там как было 20 ГБ, так и осталось.

Дело в том, что увеличение диска в панели провайдера — это операция на уровне гипервизора: он просто выделяет виртуальной машине больше блочного пространства. Внутри VM это пространство физически появляется как «хвост» на диске /dev/sda (или /dev/vda — в зависимости от драйвера), но раздел (/dev/sda1) и файловая система поверх него как были старого размера, так и остаются. Операционная система работает с разделом и ФС, а не с диском напрямую, поэтому ей нужно явно сказать: «вот теперь границы раздела и файловой системы расширились».

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

Дальше — конкретные шаги для двух разных сценариев. Они принципиально разные по инструментам, поэтому сначала определите, какой у вас случай.

Сценарий 1: VPS с виртуальным диском — шаг за шагом

Типичная ситуация: арендованный VPS, диск виртуальный, у провайдера есть кнопка «увеличить диск» в панели. После нажатия этой кнопки на стороне гипервизора всё готово за секунды-минуты, но внутри системы нужно ещё три шага.

Шаг 0. Убедитесь, что диск в панели действительно увеличен. Проверьте баланс операции — на некоторых панелях увеличение диска применяется не мгновенно, а встаёт в очередь и завершается за несколько минут. Если сразу лезть в систему, можно увидеть старый размер просто потому, что гипервизор ещё не закончил операцию.

Шаг 1. Посмотрите текущую разметку.

lsblk

Вывод покажет физический размер диска и размер раздела внутри него — если они отличаются, место действительно появилось, просто раздел его ещё не занимает:

NAME   MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda      8:0    0  60G  0 disk
├─sda1   8:1    0   1M  0 part
└─sda2   8:2    0  20G  0 part /

Здесь диск sda уже 60 ГБ, а корневой раздел sda2 — всё ещё 20 ГБ. Разница в 40 ГБ — это то самое неразмеченное пространство, которое нужно «прирастить» к разделу.

Дополнительно можно посмотреть таблицу разделов подробнее:

sudo fdisk -l /dev/sda

Это покажет точные границы (сектора) каждого раздела и подтвердит, что после последнего раздела есть свободное место.

Шаг 2. Расширьте раздел. Дальше — секции ниже про growpart и parted, где выбрать инструмент зависит от того, что уже установлено в системе.

Шаг 3. Расширьте файловую систему поверх раздела. Отдельная секция ниже — команда зависит от того, ext4 у вас или XFS.

Если у вас несколько разделов и целевой (обычно корневой) не последний по номеру в таблице — расширить его «на месте» без сдвига следующих разделов не получится штатными средствами growpart. В такой раскладке обычно проще либо переносить данные на новый больший диск целиком, либо изначально проектировать разметку так, чтобы расширяемый раздел (или LVM-том) шёл последним.

Расширение раздела: growpart и parted

growpart — самый простой и безопасный путь для типичного случая: один диск, раздел, который нужно расширить, идёт последним. Утилита входит в пакет cloud-guest-utils (Ubuntu/Debian) или cloud-utils-growpart (RHEL/CentOS/AlmaLinux); на большинстве образов от облачных провайдеров она уже установлена, так как это часть cloud-init.

sudo apt install cloud-guest-utils   # если growpart ещё не установлен
sudo growpart /dev/sda 2

Здесь /dev/sda — диск, 2 — номер раздела (для sda2 из примера выше). После выполнения lsblk должен показать, что раздел вырос до нового размера диска (за вычетом служебных зон, если они есть).

Частая ошибка на этом шаге — перепутать диск с разделом и запустить growpart /dev/sda2 2 вместо growpart /dev/sda 2. Команда ожидает именно имя диска и номер раздела отдельно, а не имя раздела целиком.

parted нужен, если growpart недоступен, если раздел не последний, или если вы хотите видеть и контролировать каждый шаг вручную:

sudo parted /dev/sda
(parted) print                     # посмотреть текущую таблицу разделов
(parted) resizepart 2 100%         # расширить раздел 2 до конца диска
(parted) quit

resizepart в GPT-таблицах работает надёжно; в MBR — тоже, но исторически MBR менее гибок к нестандартной разметке. parted умеет работать с работающей файловой системой (изменение таблицы разделов «на лету», без размонтирования), но сам по себе он не трогает файловую систему — это отдельный шаг ниже в любом случае.

Если у вас на сервере LVM поверх единственного раздела (комбинированная схема, которую иногда используют и на VPS) — сначала расширяете раздел одним из способов выше, затем pvresize на физический том, затем lvextend — логика та же, что описана в сценарии 2 ниже, только физический том один, без добавления нового диска.

Расширение файловой системы: ext4 и XFS

Раздел стал больше — но файловая система внутри него до сих пор ограничена старыми размерами и об этом «не знает». Команда для расширения зависит от типа ФС.

ext4:

sudo resize2fs /dev/sda2

Без указания размера resize2fs растягивает файловую систему до размера всего раздела — это то, что нужно в 99% случаев. Команда безопасно работает на смонтированной файловой системе (online resize), простой не нужен.

XFS:

sudo xfs_growfs /

Важное отличие: для XFS команда принимает не путь к устройству, а точку монтирования. xfs_growfs тоже работает online, но у XFS есть особенность, которая ловит новичков: файловую систему XFS можно только увеличивать «на лету» — уменьшить её без пересоздания с нуля нельзя вообще, ни онлайн, ни оффлайн. Это не проблема для сценария расширения, но стоит держать в голове на будущее — если понадобится уменьшить том, готового пути назад с XFS нет.

После любой из команд проверьте результат:

df -h

Если новое место не появилось — велика вероятность, что раздел на самом деле не расширился (проверьте lsblk ещё раз) либо команда была выполнена не над тем разделом/точкой монтирования.

Сценарий 2: физический сервер с LVM — добавляем диск без переноса данных

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

Шаг 1. Проверьте, что новый диск виден системе.

lsblk
sudo fdisk -l /dev/sdb

Если физический диск уже вставлен (или проброшен на уровне гипервизора для физического сервера с виртуализацией), но не виден — иногда достаточно пересканировать шину:

echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan

Шаг 2. Создайте физический том (PV) на новом диске.

sudo pvcreate /dev/sdb

Если диск уже размечен под что-то другое — сначала очистите разметку (wipefs -a /dev/sdb), предварительно убедившись, что там точно нет нужных данных.

Шаг 3. Добавьте физический том в существующую группу томов (VG).

sudo vgextend vg_data /dev/sdb

vg_data — имя вашей группы томов, посмотреть его можно командой vgs или vgdisplay. После этой команды vgs покажет увеличенный суммарный размер группы — новый диск теперь часть общего пула, из которого нарезаются логические тома.

Шаг 4. Расширьте логический том (LV).

sudo lvextend -l +100%FREE /dev/vg_data/lv_home

Флаг -l +100%FREE отдаёт логическому тому всё свободное место в группе. Если нужно оставить запас на будущее (например, под снапшоты), указывайте конкретный объём: -L +200G.

Шаг 5. Расширьте файловую систему поверх LV — теми же командами, что и в предыдущей секции, только путь — это путь к логическому тому:

sudo resize2fs /dev/vg_data/lv_home        # для ext4
sudo xfs_growfs /home                       # для XFS, путь монтирования

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

Если группы томов вообще не было изначально (система установлена без LVM, разделы обычные) — добавить диск «бесшовно» не получится: либо переносите данные на новую разметку с нуля, либо используете новый диск как отдельную точку монтирования под конкретную директорию (например, под /var/lib/docker или бэкапы), не трогая существующую систему разделов.

Что проверить перед расширением на любом сценарии

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

Практический чек-лист перед началом:

• Свежий бэкап. Не «бэкап недельной давности», а актуальный снапшот или дамп прямо перед операцией. Если на сервере ещё не настроено регулярное резервное копирование — это ровно тот момент, когда стоит настроить хотя бы разовый бэкап через borgbackup или аналогичный инструмент, прежде чем трогать разметку.
• Снапшот на уровне гипервизора, если провайдер это позволяет — для VPS это часто быстрее и надёжнее, чем файловый бэкап, и откатывается мгновенно.
• Проверка lsblk/fdisk -l дважды перед выполнением любой команды, меняющей разметку — особенно если работаете через SSH с несколькими открытыми сессиями на разные серверы.
• Не выполняйте операции расширения в момент пиковой нагрузки на сервис, даже если технически они online — лишняя дисковая активность на живой базе данных или лог-агрегаторе не идёт на пользу задержкам.
• Проверьте свободное место после каждого шага, а не только в конце — если growpart или lvextend отработали не так, как ожидалось, лучше остановиться на середине, чем продолжать по накатанному сценарию.

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

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