Как расширить диск и файловую систему на Debian/Ubuntu после увеличения VDS

После увеличения диска в панели управления VDS многие ожидают, что система сразу увидит новый объём. На практике гипервизор действительно добавляет виртуальному диску гигабайты, но таблица разделов и файловая система внутри Debian или Ubuntu остаются прежними. Поэтому df -h продолжает показывать старый размер, а свободное место не появляется.

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

В этой инструкции разберём типовые сценарии для Debian и Ubuntu: когда корневой раздел расположен прямо на диске, когда используется ext4, когда корень находится на xfs, а также что делать, если автоматический cloud-init growpart не сработал. Отдельно покажу, как понять, нужен ли вам growpart, parted или в крайнем случае fdisk.

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

Ещё один частый источник путаницы: размер диска, размер раздела и размер файловой системы — это три разные сущности. Можно увеличить сам виртуальный диск до 80 ГБ, но раздел на нём всё ещё будет 40 ГБ, а файловая система внутри раздела — тоже 40 ГБ. Пока не выполнены все этапы, место не появится.

С чего начать: проверяем, что диск действительно стал больше

Первое действие — не запускать команды наугад, а посмотреть текущую картину. Нас интересует, видит ли Linux увеличенный размер блочного устройства и где расположен корневой раздел.

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

Типичный вывод может выглядеть так:

NAME   SIZE FSTYPE TYPE MOUNTPOINT
vda     80G        disk
vda1     1M        part
vda2    40G ext4   part /

Здесь видно главное: сам диск vda уже 80 ГБ, а корневой раздел vda2 всё ещё 40 ГБ. Значит, нужно расширять именно раздел, а затем файловую систему на нём.

Дополнительно полезно проверить, что ядро видит новое состояние устройства:

sudo fdisk -l

Если размер диска в lsblk и fdisk -l не изменился, проблема ещё не на уровне разделов. Тогда либо увеличение диска в панели не применилось, либо гостевая система не перечитала параметры устройства. В виртуальной среде это часто решается повторной проверкой через несколько секунд или обычной перезагрузкой ВМ.

Сначала убедитесь, что вырос именно диск, и только потом меняйте раздел. Если диск по-прежнему старого размера, расширять раздел бессмысленно.

Как понять, какой у вас сценарий расширения

На Debian и Ubuntu чаще встречаются такие варианты:

• обычный раздел на диске, например /dev/vda2 или /dev/sda3, файловая система ext4;
• обычный раздел на диске с файловой системой xfs;
• расширение через growpart с последующим увеличением файловой системы;
• сценарий, где автоматическое расширение должен был выполнить cloud-init, но этого не произошло.

Для большинства облачных образов самый удобный и безопасный путь — использовать growpart. Эта утилита расширяет существующий раздел до конца свободного пространства на диске. Если её нет, можно воспользоваться parted. fdisk лучше оставлять как запасной вариант, когда другие способы недоступны.

Проверить наличие growpart можно так:

which growpart

Если команда ничего не вернула, установите пакет:

sudo apt update
sudo apt install -y cloud-guest-utils

Если вы часто работаете с типовыми облачными шаблонами, может пригодиться и отдельный разбор про подготовку образов с cloud-init: это помогает понять, почему авторасширение иногда не запускается.

Самый удобный путь: growpart для root-раздела

Предположим, у нас диск /dev/vda, а корневой раздел — /dev/vda2. Тогда команда будет такой:

sudo growpart /dev/vda 2

Если диск называется /dev/sda, а раздел корня — /dev/sda1, используйте:

sudo growpart /dev/sda 1

После успешного выполнения growpart раздел станет больше, но файловая система внутри него всё ещё может оставаться прежнего размера. Это ожидаемо. Следующий шаг зависит от того, используется ли ext4 или xfs.

Узнать тип файловой системы можно через lsblk -f или так:

findmnt -no FSTYPE /

Если вывод показывает ext4, используйте resize2fs:

sudo resize2fs /dev/vda2

Если корневой раздел находится на /dev/sda1, команда будет такой:

sudo resize2fs /dev/sda1

Для xfs расширение выполняется по точке монтирования:

sudo xfs_growfs /

После этого проверьте результат:

df -h /
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT

Если нужна более короткая версия именно для такого сценария, посмотрите также материал про расширение диска через growpart на VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если growpart недоступен: расширение через parted

Иногда growpart недоступен, а ставить дополнительные пакеты не хочется. В таком случае можно работать через parted. Этот способ тоже подходит для онлайн-расширения, но требует внимательности: нужно точно знать номер раздела, который вы меняете.

Сначала смотрим разметку:

sudo parted /dev/vda print

Допустим, нужный раздел — номер 2. Тогда выполняем:

sudo parted /dev/vda resizepart 2 100%

После изменения таблицы разделов расширяйте файловую систему:

sudo resize2fs /dev/vda2

Или для xfs:

sudo xfs_growfs /

Если система сообщает, что ядро не перечитало таблицу разделов, сначала проверьте, применились ли изменения фактически. Иногда помогает команда:

sudo partprobe /dev/vda

Но на рабочем корневом разделе это не всегда срабатывает мгновенно. Если таблица уже изменена, а ядро продолжает использовать старую геометрию, может понадобиться перезагрузка.

Когда приходится использовать fdisk

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

Это рабочий, но рискованный сценарий. Ошибка в стартовом секторе делает раздел нечитаемым. Поэтому использовать fdisk стоит только тогда, когда вы точно зафиксировали начальный сектор и понимаете, как устроена текущая разметка.

Если есть выбор между growpart, parted и fdisk, в обычной задаче порядок такой: сначала growpart, затем parted, и только потом fdisk как резерв.

Отдельный случай: cloud-init growpart не сработал

Во многих облачных образах Debian и Ubuntu корневой раздел должен расширяться автоматически при первом запуске. Часто за это отвечает модуль cloud-init growpart. Но на практике автоматизация может не отработать: модуль отключён, образ собран нестандартно, нужные пакеты отсутствуют или процедура уже выполнялась раньше.

Проверить состояние cloud-init можно так:

cloud-init status --long

Полезно посмотреть и логи:

sudo grep -i growpart /var/log/cloud-init.log
sudo grep -i resize /var/log/cloud-init.log

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

Пошаговый безопасный алгоритм для ext4

Если нужен короткий рабочий алгоритм без лишней теории, то для стандартного root на ext4 он выглядит так:

1. Убедиться, что диск уже увеличен на стороне VDS.
2. Проверить имя диска и раздела через lsblk.
3. Расширить раздел через growpart или parted.
4. Увеличить файловую систему командой resize2fs.
5. Проверить итог через df -h.

Пример команд:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
sudo growpart /dev/vda 2
sudo resize2fs /dev/vda2
df -h /

Если вместо growpart используется parted:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
sudo parted /dev/vda resizepart 2 100%
sudo resize2fs /dev/vda2
df -h /

Пошаговый безопасный алгоритм для XFS

С xfs логика та же, но завершающая команда другая. Самая частая ошибка — пытаться указать устройство вместо точки монтирования. Для xfs_growfs нужен именно смонтированный путь.

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
sudo growpart /dev/vda 2
sudo xfs_growfs /
df -h /

Если у вас не корень, а отдельный том, например /data, команда будет такой:

sudo xfs_growfs /data

Если сомневаетесь, что именно у вас используется на сервере, полезно заранее разобраться в отличиях файловых систем. Для этого есть отдельный материал про настройку и различия ext4 и XFS на VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Типичные ошибки и как их избежать

На практике проблемы почти всегда сводятся к нескольким сценариям.

• Увеличили диск в панели, но в гостевой ОС он не вырос. Значит, до разделов ещё рано: сначала нужно убедиться, что виртуальный диск реально стал больше.
• Расширили раздел, но забыли увеличить файловую систему. В lsblk размер уже новый, а в df -h старый.
• Перепутали тип файловой системы и запустили не ту команду: resize2fs для xfs или xfs_growfs без проверки точки монтирования.
• Перепутали диск и раздел, особенно на серверах с несколькими устройствами: vda, vdb, sda, nvme0n1.
• Попробовали использовать fdisk без фиксации начального сектора раздела.

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

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
sudo fdisk -l

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

Как проверить результат и убедиться, что место реально доступно

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

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
df -h /

Если оба вывода показывают новый размер, задача решена. Если раздел уже увеличился, а файловая система нет, значит, не выполнен или не завершился этап с resize2fs либо xfs_growfs. Если же даже диск не вырос, возвращайтесь к панели VDS и проверяйте изменение на уровне виртуальной инфраструктуры.

Дополнительно полезно посмотреть сообщения ядра после изменения таблицы разделов:

dmesg | tail -n 50

Там часто видно, перечитал ли Linux таблицу разделов и обнаружил ли новый размер устройства.

Практический вывод

Расширение диска на Debian или Ubuntu после увеличения VDS — задача несложная, если не смешивать в голове три уровня: диск, раздел и файловую систему. В типовом случае всё сводится к простой связке: lsblk для диагностики, growpart или parted для увеличения раздела, затем resize2fs для ext4 или xfs_growfs для xfs.

Если автоматический cloud-init growpart не сработал, это не повод усложнять задачу. На работающем сервере обычно быстрее и надёжнее выполнить расширение вручную, проверить результат и только потом разбираться, почему не отработала автоматизация.

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