Как увеличить диск VPS и расширить ext4, XFS или LVM в Linux 

После увеличения диска в панели провайдера новое место не всегда сразу становится доступно внутри Linux. Сначала нужно понять, на каком уровне остался старый размер: диск, раздел, LVM или файловая система.

Базовая проверка:

    
        
    lsblk
lsblk -f
df -hT

Если диск вырос, а раздел — нет, обычно помогает: sudo growpart /dev/sda 1

Для ext4 после этого расширяем файловую систему: sudo resize2fs /dev/sda1

Для XFS указываем точку монтирования: sudo xfs_growfs /

Если используется LVM, цепочка длиннее:

    
        
    sudo growpart /dev/sda 3
sudo pvresize /dev/sda3
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

После этого расширяем файловую систему внутри логического тома через resize2fs или xfs_growfs.

Перед изменением разделов и LVM стоит сделать актуальную резервную копию и сохранить исходную схему через lsblk, fdisk -l, pvs, vgs и lvs.

Финальная проверка:

    
        
    lsblk
df -hT

Для LVM дополнительно:

    
        
    sudo pvs
sudo vgs
sudo lvs

Если lsblk показывает новый объем, а df -hT — старый, значит блочный уровень уже расширен, а файловая система еще нет. Именно по этому принципу проще всего искать проблему после resize.

Что происходит после увеличения диска у провайдера

Добро пожаловать!

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

Но на практике часто происходит иначе.

Допустим, диск был: 40 GB

Вы увеличили его до: 80 GB

В панели провайдера всё выглядит правильно, а внутри системы всего одна команда: df -h

по-прежнему показывает старый размер файловой системы.

И вот здесь начинается путаница.

Пользователь думает: «Я же уже увеличил диск. Почему Linux не видит новое место?»

Потому что увеличение виртуального диска у провайдера — это только первый слой.

После него Linux еще должен:

• Увидеть новый размер самого диска;
• При необходимости расширить раздел;
• Если используется LVM — увеличить Physical Volume и Logical Volume;
• Затем расширить саму файловую систему;
• И только после этого новое место станет реально доступно приложениям.

То есть кнопка «Resize disk» в панели облака не всегда означает: «Готово, у вас уже больше свободного места в /».

Чаще она означает: «Физический или виртуальный блочный диск стал больше. Теперь нужно корректно расширить всё, что лежит поверх него».

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

Именно этот процесс мы и разберем полностью.

Причем отдельно для трех распространенных сценариев:

• Обычный раздел с ext4;
• Обычный раздел с XFS;
• Диск, на котором используется LVM.

Погнали дальше

Почему Linux не всегда сразу использует новый объем

Начнем с самого важного различия.

Команда lsblk и команда df -h показывают не одно и то же.

Первая показывает блочные устройства и разделы.

А вторая, то есть df, показывает размер уже смонтированных файловых систем.

Например, после увеличения диска можно получить такую ситуацию:

Сам диск уже вырос до 80 ГБ.

Но раздел sda1 остался 40 ГБ.

А значит, файловая система внутри него физически не может использовать оставшиеся 40 ГБ.

Даже если расширить partition, это еще не всегда конец.

Например:

но: df -h всё еще показывает 40 ГБ.

Это означает, что раздел уже вырос, а файловая система внутри него — еще нет.

То есть есть несколько независимых уровней, и каждый может иметь свой размер.

Именно поэтому resize лучше выполнять поэтапно.

Чем отличаются диск, раздел, LVM и файловая система

Чтобы дальше не путаться в командах, разберем основные уровни.

Диск

Это само блочное устройство.

Например: /dev/sda или /dev/vda

После увеличения диска в панели провайдера именно этот уровень обычно становится больше первым.

Например: /dev/sda → 80 GB

Раздел

Внутри диска могут находиться разделы.

Например:

    
        
    /dev/sda1
/dev/sda2
/dev/sda3

Раздел — это выделенная часть диска.

Даже если весь /dev/sda вырос, конкретный /dev/sda1 сам по себе не обязан автоматически занять новое свободное место.

Именно для этого позже понадобится growpart или другой инструмент изменения таблицы разделов.

LVM

LVM добавляет еще один слой абстракции между partition и filesystem.

Вместо прямой схемы: partition → filesystem

Получается: partition → Physical Volume → Volume Group → Logical Volume → filesystem

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

После увеличения диска нужно проверить уже несколько уровней:

• partition;
• PV;
• VG;
• LV;
• filesystem.

Далее идём к крайнему, но не менее важному.

Файловая система

И наконец, на разделе или Logical Volume находится файловая система.

Чаще всего это: ext4 или XFS

И именно файловая система определяет, сколько места видят обычные приложения и команда: df -h

Поэтому для пользователя самое важное различие такое:

И если один слой вырос, это еще не гарантирует, что следующий автоматически сделал то же самое.

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

Перед тем как вообще выполнять какие-либо resize-команды, нужно понять текущую схему.

Начнем с: lsblk

Например, обычный раздел может выглядеть так:

NAME   MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

Здесь всё довольно просто:

• Диск /dev/sda — 80 ГБ;
• Раздел /dev/sda1 — 40 ГБ;
• Корень / находится прямо на этом разделе.

Это обычный сценарий без LVM.

Теперь посмотрим тип файловой системы: lsblk -f

Например:

Значит у нас: обычный partition + ext4

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

А вот LVM выглядит иначе.

Например:

Здесь уже видно: TYPE=lvm

И это сразу говорит, что между partition и filesystem есть дополнительный слой.

Подтвердить можно командами:

    
        
    sudo pvs
sudo vgs
sudo lvs

Если они показывают Physical Volume, Volume Group и Logical Volume — перед нами LVM.

Еще одна полезная команда: df -hT

Она покажет размер и тип смонтированной файловой системы.

Например:

Здесь сразу видно:

• Корень находится на LVM Logical Volume;
• Filesystem — ext4.

И именно поэтому дальше мы не будем давать одну огромную цепочку команд на все случаи.

Погнали дальше.

Перед расширением: делаем backup и проверяем текущую схему

С архитектурой разобрались. Теперь начинается тот этап, где лучше потратить лишние пять минут на проверку, чем потом несколько часов на восстановление.

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

Но есть важная оговорка: ошибка на уровне partition table или LVM может затронуть саму структуру хранения данных.

Поэтому перед первым growpart, pvresize или resize2fs нужно сохранить исходное состояние и иметь способ откатиться.

Почему resize обычно безопасен, но backup все равно нужен

Само по себе увеличение обычно менее рискованно, чем уменьшение.

Мы не пытаемся сжать файловую систему и не переносим данные в меньший объем. Наоборот — добавляем свободное пространство к уже существующей структуре.

Но риск все равно остается.

Например, можно:

• Выбрать не тот диск;
• Расширить не тот partition;
• Ошибиться с номером раздела;
• Перепутать LVM Logical Volume;
• Неправильно изменить partition table;
• Столкнуться с проблемой на стороне облачного диска;
• Выполнить команду на production-сервере, где уже есть аппаратные или файловые ошибки.

Поэтому перед resize лучше иметь актуальный бэкап данных.

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

Но снапшот не всегда заменяет нормальный бэкап.

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

Например, условная схема подготовки может быть такой:

Файлы приложения

→ backup

База данных

→ отдельный dump / native backup

Облачный диск

→ snapshot

Не обязательно использовать все три способа всегда. Однако хотя бы один рабочий вариант восстановления должен быть.

Проверяем диски, разделы и точки монтирования

Теперь зафиксируем текущее состояние.

Начнем с: lsblk

Команда показывает блочные устройства, partitions, LVM и точки монтирования.

Например:

Здесь сразу видно важную деталь:

• Диск /dev/sda — уже 80 ГБ;
• Корневой partition /dev/sda2 — только 39 ГБ.

То есть новый объем диска система увидела, но раздел еще не расширен.

Добавим информацию о файловых системах: lsblk -f

И отдельно посмотрим смонтированные файловые системы: df -hT

Например:

Здесь уже видно, что / использует ext4.

Дополнительно полезно посмотреть partition table: sudo fdisk -l

fdisk -l показывает размеры дисков, partitions и их границы.

Перед изменением полезно сохранить вывод в файл: sudo fdisk -l > ~/disk-layout-before.txt

А также:

    
        
    lsblk -f > ~/lsblk-before.txt
df -hT > ~/df-before.txt

Это не backup данных, а своеобразная и удобная контрольная точка.

Если после resize что-то покажется странным, можно сравнить исходную и новую схему.

Определяем тип файловой системы

Теперь нужно точно понять, какую filesystem будем расширять.

Самый простой вариант: df -hT или lsblk -f

Например: /dev/sda2  ext4 значит дальше понадобится resize2fs.

Если: /dev/sda2  xfs, то расширение будет выполняться через xfs_growfs.

Можно проверить конкретный mount point: findmnt /

Например:

findmnt особенно удобен, когда на сервере несколько дисков и partitions.

Он позволяет быстро ответить на вопрос: какое устройство реально используется для /?

Для другого каталога: findmnt /var или findmnt /data

И это важно, потому что расширять нужно именно то устройство, на котором находится нужная точка монтирования.

Проверяем LVM, если он используется

Если в lsblk видно TYPE=lvm, обычной проверки partitions уже недостаточно.

Посмотрим три уровня LVM.

• Physical Volumes: sudo pvs
• Volume Groups: sudo vgs
• Logical Volumes: sudo lvs

Например:

Здесь Physical Volume /dev/sda3 входит в Volume Group ubuntu-vg.

А:

показывает Logical Volume.

Полезно также выполнить lsblk и сопоставить все уровни между собой.

Например:

Если это корневой диск, findmnt / покажет: /dev/mapper/ubuntu--vg-ubuntu--lv

То есть расширять обычный /dev/sda3 напрямую как файловую систему здесь нельзя.

Сначала нужно будет:

• Расширить partition;
• Затем Physical Volume;
• Затем Logical Volume;
• И только потом filesystem.

Перед работой с LVM тоже можно сохранить исходное состояние:

    
        
    sudo pvs > ~/pvs-before.txt
sudo vgs > ~/vgs-before.txt
sudo lvs > ~/lvs-before.txt

На этом этапе у нас уже должна быть полноценная картина:

• Какой диск увеличен;
• Какой partition используется;
• Какая файловая система стоит сверху;
• Есть ли LVM;
• Какой именно Logical Volume смонтирован в нужную точку.

И только теперь имеет смысл переходить к resize.

Проверяем, увидел ли Linux новый размер диска

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

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

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

Сверяем размер диска до и после увеличения

Начнем с самой наглядной команды: lsblk

Допустим, до расширения картина была такой:

NAME   SIZE TYPE MOUNTPOINTS

После увеличения диска у провайдера до 80 ГБ мы ожидаем увидеть:

Именно такой вывод означает, что сам диск уже вырос, а раздел пока остался прежним.

Это нормальная ситуация.

Можно дополнительно проверить размер через: sudo fdisk -l /dev/sda

В начале вывода будет что-то вроде: Disk /dev/sda: 80 GiB

Еще один удобный вариант: lsblk -b

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

На этом этапе важно не перепутать: /dev/sda и /dev/sda1

Первое — весь диск.

Второе — отдельный раздел внутри него.

Если /dev/sda уже показывает новый объем, значит следующий шаг — работа со структурой внутри диска.

Если же сам /dev/sda все еще старого размера, сначала нужно заставить систему перечитать размер устройства.

Если новый объем не появился сразу

В облачных средах изменение размера виртуального диска часто подхватывается системой автоматически.

Но не всегда мгновенно.

Например, провайдер уже показывает 80 GB, а внутри VPS lsblk все еще возвращает sda 40G

Сначала стоит просто повторить проверку через несколько секунд или минут.

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

Для SCSI-дисков один из распространенных вариантов: echo 1 | sudo tee /sys/class/block/sda/device/rescan

После этого снова: lsblk

Важно заменить sda на имя именно вашего диска.

Если устройство называется vda или nvme0n1, путь и способ повторного сканирования могут отличаться.

Поэтому перед использованием sysfs-команды обязательно сначала определите тип устройства через: lsblk

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

Можно также попросить ядро перечитать таблицу разделов: sudo partprobe

Но здесь важно понимать разницу.

partprobe нужен прежде всего для того, чтобы ядро перечитало таблицу разделов.

Он не заменяет обнаружение нового размера самого виртуального диска.

То есть: диск все еще 40 ГБ и диск 80 ГБ, но раздел остался 40 ГБ — это две разные ситуации.

В первой проблема находится на уровне устройства.

Во второй диск уже виден правильно, и можно переходить к расширению раздела.

Когда нужен rescan, а когда достаточно перезагрузки

В большинстве облачных сред есть два нормальных сценария.

Первый — система сама видит новый размер без перезагрузки.

Тогда достаточно: lsblk чтобы увидеть новый объем и продолжить работу.

Второй — размер не обновляется.

Тогда можно выполнить повторное сканирование устройства, если понятно, какой тип диска используется и провайдер допускает такую операцию.

Например: echo 1 | sudo tee /sys/class/block/sda/device/rescan

Если же устройство ведет себя нестандартно, документация провайдера рекомендует перезагрузку или вы не хотите вручную работать с sysfs, обычный: sudo reboot часто оказывается самым простым вариантом.

После повторного подключения снова проверяем:

    
        
    lsblk
sudo fdisk -l

И только если сам диск уже показывает новый размер, идем дальше.

Здесь полезно придерживаться простого порядка проверки:

1. Смотрим размер диска через lsblk.
2. Если он старый — выполняем повторное сканирование или перезагрузку.
3. Проверяем еще раз.
4. Только после появления нового размера работаем с разделом, LVM и файловой системой.

Так мы не пытаемся расширить верхние уровни до того, как нижний вообще получил дополнительное пространство.

Следующим шагом как раз увеличим обычный раздел через growpart и убедимся, что он занял свободное место на диске.

Расширяем обычный раздел

Как говорили в конце прошлой главы, сам диск уже показывает новый объем. Теперь нужно проверить, занял ли существующий раздел появившееся свободное место.

Если нет, сначала расширяем именно раздел, а уже потом переходим к ext4 или XFS.

Когда сначала нужно увеличить раздел

Типичный случай выглядит так:

Здесь диск /dev/sda уже вырос до 80 ГБ, но раздел /dev/sda1 все еще занимает только 40 ГБ.

Оставшиеся 40 ГБ пока существуют как свободное пространство на уровне диска и недоступны файловой системе.

В такой ситуации нельзя сразу выполнять: sudo resize2fs /dev/sda1 и ждать, что файловая система magically растянется на весь диск.

resize2fs расширяет файловую систему внутри уже существующего раздела. Если сам /dev/sda1 остался старого размера, расти ей просто некуда.

Поэтому порядок такой:

1. Диск уже увеличен;
2. Расширяем раздел;
3. затем расширяем файловую систему.

Если же lsblk уже показывает:

раздел увеличивать повторно не нужно.

Тогда можно сразу переходить к ext4, XFS или следующему уровню LVM.

Расширяем раздел через growpart

Для удобного расширения разделов в Ubuntu часто используют утилиту growpart.

Она входит в пакет: cloud-guest-utils

Установим его, если пакет еще не установлен:

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

Теперь еще раз посмотрим схему: lsblk

Допустим, у нас:

Тогда команда будет: sudo growpart /dev/sda 1

Здесь важно обратить внимание на синтаксис.

Мы указываем /dev/sda как сам диск, а затем отдельно 1 как номер раздела.

То есть правильно: sudo growpart /dev/sda 1

а не: sudo growpart /dev/sda1 1

Потому что growpart должен сначала получить устройство целиком и уже внутри него найти нужный раздел.

Если корневой раздел, например, /dev/sda3, команда будет: sudo growpart /dev/sda 3

Для диска /dev/vda: sudo growpart /dev/vda 1

Поэтому перед запуском всегда сначала смотрим lsblk, а не копируем номер раздела из чужого примера.

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

В выводе обычно появляется информация о старом и новом размере раздела.

Проверяем новый размер раздела

Сразу после growpart проверяем результат: lsblk

Теперь ожидаем примерно:

Можно дополнительно посмотреть таблицу разделов: sudo fdisk -l /dev/sda

И убедиться, что /dev/sda1 действительно занял новый диапазон.

Если ядро не сразу обновило информацию о таблице разделов, можно выполнить: sudo partprobe

и повторить: lsblk

Но здесь есть важный момент.

Даже если раздел уже показывает 80 ГБ, команда: df -hT может по-прежнему показывать старый размер файловой системы.

Например:

Это не ошибка.

Раздел уже увеличен, а файловая система пока еще нет.

И именно здесь мы окончательно разделяем два уровня:

• lsblk показывает размер раздела;
• df -hT показывает размер файловой системы.

Теперь свободное место уже вошло в раздел.

Следующий шаг зависит от типа файловой системы: для ext4 используем resize2fs, а для XFS — xfs_growfs.

Расширяем файловую систему ext4

Проверяем, что используется ext4

Перед запуском resize2fs не стоит полагаться на память или чужой пример.

Проверим тип файловой системы: lsblk -f Или df -hT

Например:

Здесь видно, что корневая файловая система использует ext4.

Можно дополнительно проверить конкретную точку монтирования: findmnt /

Если в поле FSTYPE указано ext4, можно переходить дальше.

Увеличиваем файловую систему через resize2fs

Для ext4 используется команда: sudo resize2fs /dev/sda1

Здесь мы передаем именно устройство, внутри которого находится файловая система.

Если раздел называется иначе, например: /dev/vda1, то команда будет: sudo resize2fs /dev/vda1

Если ext4 находится внутри LVM, путь уже будет другим, например: /dev/mapper/ubuntu--vg-ubuntu--lv

Но LVM отдельно разберем в следующем большом разделе.

Для обычного раздела resize2fs определяет доступный объем и увеличивает файловую систему до максимально возможного размера внутри устройства.

Во многих случаях ext4 можно расширять прямо в смонтированном состоянии.

То есть для корневого / не обязательно заранее отмонтировать файловую систему или останавливать сервер.

После запуска можно увидеть сообщение примерно такого вида: The filesystem on /dev/sda1 is now ... blocks long.

Это означает, что файловая система заняла дополнительное пространство раздела.

Проверяем результат

Теперь снова выполняем: df -hT

Если раньше было: /dev/sda1  ext4   39G, то после расширения ожидаем уже значение, близкое к новому размеру раздела: /dev/sda1  ext4   78G

Почему не ровно 80 ГБ?

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

Дополнительно можно сравнить:

    
        
    lsblk
df -hT

Теперь размеры раздела и файловой системы должны быть согласованы.

Расширяем файловую систему XFS

С XFS логика похожая: сначала расширяем диск и раздел, а затем файловую систему.

Но команда и способ обращения к файловой системе отличаются.

Чем расширение XFS отличается от ext4

Для ext4 мы использовали: resize2fs /dev/sda1

То есть передавали блочное устройство.

Для XFS обычно используется: xfs_growfs и указывается уже точка монтирования.

Например, если XFS смонтирована как корень: /, то команда будет: sudo xfs_growfs /

Если файловая система смонтирована в: /data, то: sudo xfs_growfs /data

Это важное различие.

Не стоит автоматически подставлять /dev/sda1 только потому, что так было в примере с ext4.

Увеличиваем XFS через xfs_growfs

Сначала убеждаемся, что действительно используется XFS: df -hT

Например:

Или: findmnt /

Если видим: FSTYPE xfs — можно расширять.

Для корневой файловой системы: sudo xfs_growfs /

Команда определит размер лежащего под ней устройства и увеличит XFS до доступного максимума.

XFS также умеет расширяться в смонтированном состоянии.

Поэтому для обычного онлайн-расширения корня сервер останавливать не требуется.

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

Проверяем результат

Снова смотрим: df -hT

Например:

Можно дополнительно проверить: xfs_info /

Команда покажет параметры XFS, включая размер файловой системы.

Для другой точки монтирования, например /data: xfs_info /data

Итак, для обычных разделов ключевое различие сводится к инструменту:

На обычном VPS этого часто уже достаточно.

Расширяем диск с LVM

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

С LVM появляется дополнительный уровень.

Именно поэтому здесь особенно важно не прыгать сразу к resize2fs или xfs_growfs, а пройти цепочку по порядку.

Как устроена цепочка LVM

LVM — это Logical Volume Manager, то есть слой управления логическими томами поверх обычных блочных устройств.

Для новичка это удобнее всего воспринимать как несколько уровней:

Раздел

• → Physical Volume
• → Volume Group
• → Logical Volume
• → файловая система

Например:

• /dev/sda3
• → PV
• → ubuntu-vg
• → ubuntu-lv
• → ext4

или XFS на последнем уровне.

Каждый слой имеет собственный размер.

Поэтому после увеличения диска у провайдера может получиться такая ситуация:

• Диск уже стал 100 ГБ;
• Раздел под LVM всё ещё 50 ГБ;
• Physical Volume всё ещё 50 ГБ;
• Logical Volume всё ещё 50 ГБ;
• Файловая система тоже 50 ГБ.

То есть дополнительное пространство пока существует только на самом нижнем уровне.

Проверить текущую схему можно так: lsblk

А LVM отдельно:

    
        
    sudo pvs
sudo vgs
sudo lvs

Например:

Если диск уже вырос, а PSize остаётся прежним, значит до LVM свободное место ещё не дошло.

Расширяем partition под LVM

Сначала увеличиваем сам раздел, внутри которого находится Physical Volume.

Допустим, lsblk показывает:

Тогда расширяем третий раздел: sudo growpart /dev/sda 3

Напомню синтаксис: /dev/sda 3, где /dev/sda — весь диск, а 3 — номер раздела.

После этого проверяем: lsblk

Теперь ожидаем примерно:

Важно: Logical Volume при этом всё ещё может оставаться старого размера.

Мы пока увеличили только контейнер, внутри которого находится LVM.

Увеличиваем Physical Volume через pvresize

Теперь нужно сообщить LVM, что Physical Volume стал больше.

Для этого выполним: sudo pvresize /dev/sda3

Команда перечитает размер устройства и расширит PV до доступного объёма.

Проверяем: sudo pvs

Теперь может появиться свободное место:

Вот это уже важный этап.

PFree показывает, сколько пространства теперь доступно внутри Volume Group для логических томов.

Можно дополнительно посмотреть: sudo vgs

Например:

То есть физический том и группа томов уже видят новый объём, но Logical Volume пока его не использует.

Расширяем Logical Volume

Теперь увеличим нужный логический том.

Сначала ещё раз посмотрим его имя: sudo lvs

Например:

Или: lsblk, где путь может выглядеть так: /dev/mapper/ubuntu--vg-ubuntu--lv

Если хотим отдать логическому тому всё свободное место Volume Group: sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Можно использовать и путь через /dev/mapper, если он корректно определён.

Например:

    
        
    sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

После этого проверяем: sudo lvs

Теперь размер LV должен увеличиться.

Важно понимать, что +100%FREE означает: забрать всё свободное место Volume Group.

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

Тогда размер можно увеличить, например, на 20 ГБ: sudo lvextend -L +20G /dev/ubuntu-vg/ubuntu-lv

То есть:

• -L +20G — добавить конкретный объём;
• -l +100%FREE — использовать всё свободное пространство.

Идём дальше.

Расширяем файловую систему внутри LVM

На этом Logical Volume уже вырос.

Но файловая система внутри него всё ещё может оставаться старого размера.

Если используется ext4: sudo resize2fs /dev/ubuntu-vg/ubuntu-lv или sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

После этого: df -hT должен показать новый размер.

Если внутри LVM используется XFS, команда будет другой.

Сначала определяем точку монтирования: findmnt /

Например, если нужный Logical Volume смонтирован в /, расширяем: sudo xfs_growfs /

Для /data: sudo xfs_growfs /data

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

Есть и сокращённый вариант: sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Параметр -r просит LVM автоматически расширить файловую систему вместе с Logical Volume.

Это удобно, но в учебной схеме лучше сначала понимать, что реально происходит по слоям.

Иначе легко запомнить одну «волшебную» команду и потом не понимать, где искать проблему, если автоматическое расширение не сработало.

Для LVM ключевой порядок такой:

• раздел
• → pvresize
• → lvextend
• → расширение файловой системы

Если пропустить один из уровней, следующий просто не увидит новое пространство.

Проверяем результат после resize

Основная часть работы завершена: диск увеличен, раздел при необходимости расширен, LVM обновлен, а файловая система заняла новое пространство.

Но считать задачу законченной только потому, что команды отработали без ошибок, рано.

После изменения размера нужно убедиться, что новый объем виден на всех нужных уровнях и действительно доступен приложениям.

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

Сравниваем lsblk и df -hT

Начнем с двух самых полезных инструментов: lsblk и df -hT

Они отвечают на разные вопросы.

lsblk показывает, как система видит диски, разделы и логические тома.

Например:

NAME   SIZE TYPE MOUNTPOINTS

Здесь видно, что:

• Сам диск — 80 ГБ;
• Раздел тоже — 80 ГБ;
• Раздел смонтирован в /.

Но этого еще недостаточно.

Теперь df -hT может показать:

Вот это уже означает, что файловая система действительно расширена и новое место стало доступно пользователям и приложениям.

Именно поэтому lsblk и df нужно смотреть вместе.

Если:

• lsblk → 80G
• df    → 40G

Значит блочный уровень уже вырос, а файловая система — еще нет.

Если оба инструмента показывают новый размер, цепочка расширения завершилась успешно.

Проверяем LVM, если он используется

На сервере с LVM одной проверки df тоже мало.

Нужно убедиться, что новый объем прошел через все уровни LVM.

Сначала посмотрим Physical Volume: sudo pvs

Например:

Если PSize уже соответствует новому размеру, pvresize сработал.

Теперь Volume Group: sudo vgs

Если после lvextend -l +100%FREE свободное место было полностью отдано логическому тому, VFree будет близок к нулю.

Например:

Далее Logical Volume: sudo lvs

Например:

То есть все уровни согласованы.

Но если вы специально оставили часть свободного пространства в Volume Group, ненулевой VFree — это нормально.

Например: VFree = 20G, может означать, что вы специально увеличили LV только на 30 ГБ, а остаток оставили для другого логического тома.

Поэтому здесь важно не искать одно «правильное» число, а проверять, соответствует ли результат вашему плану.

Убеждаемся, что новое место реально доступно

Последняя проверка — уже самая практическая.

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

Для корня: df -h /

Для /data: df -h /data

Например, до расширения было:

а после:

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

Использованные данные остались на месте, а Avail заметно вырос.

Можно также проверить запись на файловую систему.

Например:

touch /tmp/resize-test

ls -l /tmp/resize-test

rm /tmp/resize-test

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

Для отдельного диска, смонтированного в /data, можно сделать аналогично:

    
        
    touch /data/resize-test
rm /data/resize-test

Если речь идет о production-сервере, после расширения стоит дополнительно убедиться, что основные сервисы продолжают работать.

Например: sudo systemctl --failed

Команда покажет службы, которые находятся в состоянии ошибки.

А для конкретного сервиса: sudo systemctl status nginx --no-pager или sudo systemctl status postgresql --no-pager

По итогу можно свести финальную диагностику к небольшой таблице:

На этом расширение можно считать успешно завершенным.

Диск, раздел, LVM и файловая система согласованы между собой, а дополнительное пространство действительно доступно системе.

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

Если размер не увеличился: разбираем типовые проблемы

Диск вырос, а partition остался прежним

Это одна из самых типичных ситуаций.

Например: lsblk показывает:

NAME   SIZE TYPE MOUNTPOINTS

Сам диск уже 80 ГБ, а раздел остался 40 ГБ.

Это означает, что свободное место уже существует, но оно пока не входит в /dev/sda1.

В таком случае сначала нужно увеличить раздел: sudo growpart /dev/sda 1

После этого: lsblk должен показать новый размер.

Если раздел всё равно не изменился, имеет смысл посмотреть таблицу разделов: sudo fdisk -l /dev/sda

Здесь уже можно понять, есть ли вообще свободное место непосредственно после нужного раздела.

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

Например, если структура выглядит так:

то просто растянуть sda1 до конца диска не получится: между ним и свободным пространством находится sda2.

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

Partition вырос, а df показывает старый размер

Следующая ситуация: lsblk показывает:

а: df -hT всё еще показывает: /dev/sda1  ext4  40G

Здесь проблема уже не в разделе.

Раздел вырос, а файловая система внутри него пока осталась прежнего размера.

Если это ext4: sudo resize2fs /dev/sda1

Если это XFS, сначала смотрим точку монтирования: findmnt /

А затем, например: sudo xfs_growfs /

После этого снова: df -hT

Именно df, а не только lsblk, должен показать новый доступный объем.

Это хороший пример того, почему resize нельзя оценивать по одной команде.

lsblk может уже выглядеть идеально, хотя приложения всё еще видят старую файловую систему.

LVM не видит свободное место

С LVM проблема может появиться на нескольких уровнях.

Допустим, раздел под LVM уже вырос: sda3  100G, но sudo pvs всё еще показывает Physical Volume размером 50 ГБ.

Значит, нужно выполнить: sudo pvresize /dev/sda3

После этого проверяем:

    
        
    sudo pvs
sudo vgs

Теперь новый объем должен появиться как свободное место внутри Volume Group.

Например: PFree  50G или VFree  50G

Если свободное место в VG уже есть, но df всё еще показывает старый размер, значит следующий уровень — Logical Volume — пока не расширен.

Проверяем: sudo lvs

И увеличиваем нужный LV: sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

После этого не забываем про файловую систему.

Для ext4: sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

Для XFS: sudo xfs_growfs /

То есть если LVM «не видит» новое место, полезно идти по уровням:

• Вырос ли раздел;
• Вырос ли PV;
• Появилось ли свободное место в VG;
• Увеличился ли LV;
• Увеличилась ли файловая система.

Топаем дальше.

growpart сообщает, что расширять нечего

Иногда после команды sudo growpart /dev/sda 1, можно получить сообщение о том, что раздел уже невозможно увеличить.

Это не всегда ошибка.

Возможны несколько причин.

Первая — раздел уже занимает всё доступное пространство.

Проверяем: lsblk и sudo fdisk -l /dev/sda

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

Вторая причина — новый размер самого диска еще не увиден Linux.

Например: sda  40G

Хотя в панели провайдера уже указано 80 ГБ.

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

Третья причина — свободное пространство находится не сразу после нужного раздела.

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

И еще один вариант — раздел уже расширен, а пользователь просто снова запускает growpart, хотя проблема теперь находится на уровне файловой системы.

ext4 или XFS не расширяются

Если раздел уже вырос, но сама файловая система не увеличивается, сначала еще раз проверяем ее тип: lsblk -f или df -hT

Это кажется очевидным, но довольно легко случайно запустить: resize2fs для XFS или попытаться использовать xfs_growfs там, где находится ext4.

Для ext4 также стоит убедиться, что передается правильное устройство: findmnt /

Например:

    
        
    SOURCE=/dev/sda1
FSTYPE=ext4

Тогда: sudo resize2fs /dev/sda1

Если используется LVM, устройством может быть уже: /dev/mapper/ubuntu--vg-ubuntu--lv, а не /dev/sda3.

Для XFS нужно проверять именно точку монтирования.

Например: findmnt / и затем sudo xfs_growfs /

Если команда сообщает, что файловая система уже имеет максимальный размер, проблема, скорее всего, находится ниже: раздел или Logical Volume еще не расширен.

Еще один полезный шаг — посмотреть системные сообщения: sudo dmesg | tail -n 50 или sudo journalctl -k -n 50 --no-pager

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

В итоге диагностика обычно сводится к одному принципу: «сначала найдите первый уровень, который всё еще показывает старый размер». 

По итогу:

• Если старый сам диск — проблема до разделов.
• Если старый раздел — работаем с growpart.
• Если старый PV или LV — идем в LVM.
• Если всё блочное уже выросло, а df нет — проблема на уровне файловой системы.

Это своеобразный поэтапный чек-лист. 

Остался ещё один момент который осталось пояснить в сегодняшней теме.

Как безопасно выполнять resize в production

Само расширение диска обычно не требует остановки сервера и во многих случаях проходит безболезненно. Но production-среда отличается от тестового VPS хотя бы тем, что цена ошибки здесь выше.

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

Основной риск не в resize2fs или xfs_growfs как таковых, а в том, что мы меняем структуру хранения данных. Если ошибиться устройством, разделом или логическим томом, последствия могут быть заметно серьезнее обычной ошибки в конфигурации Nginx.

Поэтому в production главное — не скорость, а предсказуемость: заранее знать исходную схему, иметь резервную копию и понимать, как вернуть сервис в рабочее состояние, если что-то пойдет не по плану.

Почему уменьшение диска — отдельная и более рискованная задача

В этой статье мы рассматривали именно увеличение диска и файловой системы.

Это принципиально важно.

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

При уменьшении всё наоборот.

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

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

Особенно важно помнить про XFS: XFS не поддерживает уменьшение файловой системы штатными средствами.

То есть сценарий:

XFS 100 ГБ

→ уменьшить до 50 ГБ

не решается простой обратной командой к xfs_growfs.

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

С ext4 уменьшение возможно, но оно сложнее расширения и обычно требует отмонтирования файловой системы.

Когда стоит планировать maintenance window

Многие операции расширения можно выполнять онлайн.

Например:

• growpart часто работает без остановки сервера;
• pvresize можно выполнять на активном LVM;
• lvextend тоже обычно не требует остановки;
• ext4 можно расширять в смонтированном состоянии;
• XFS также расширяется онлайн.

Поэтому на небольшом VPS вполне реально увеличить диск вообще без заметного простоя.

Но в production всё равно бывают случаи, когда лучше выделить окно обслуживания.

Например:

• Диск почти полностью заполнен;
• Сервер находится под высокой нагрузкой;
• База данных активно пишет большой объем данных;
• Используется сложная LVM-схема;
• Разделы расположены нестандартно;
• Нужно перемещать или переразмечать partitions;
• Нет уверенности, как именно облачный провайдер применяет новый размер;
• Предстоит перезагрузка системы.

В таких условиях даже операция, которая технически поддерживает online resize, становится менее предсказуемой.

Maintenance window дает возможность:

• Снизить нагрузку;
• Остановить особо чувствительные сервисы;
• Спокойно проверить backup;
• Выполнить resize;
• Проверить файловую систему;
• Протестировать приложения;
• При необходимости откатиться.

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

Почему backup лучше делать до изменения partition

Резервную копию можно сделать и после resize.

Но тогда она уже не защищает от ошибки, которая могла произойти во время изменения разделов.

Именно поэтому backup должен существовать до первой команды, которая меняет структуру диска.

Особенно перед:

1. growpart
2. изменением partition table,
3. pvresize
4. или операциями с Logical Volume.

Хорошая подготовка может включать:

• snapshot виртуального диска;
• резервную копию файлов;
• dump базы данных;
• сохранение текущей схемы через lsblk, fdisk -l, pvs, vgs, lvs.

Причем snapshot и backup лучше не считать полностью взаимозаменяемыми.

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

В итоге перед production-resize стоит хотя бы знать:

• где находится резервная копия;
• насколько она свежая;
• какие данные в нее входят;
• как быстро можно вернуть сервис.

В итоге подготовка выглядит довольно просто:

1. Определяем точный диск и раздел.
2. Проверяем файловую систему и LVM.
3. Создаем резервную копию.
4. Сохраняем исходную схему.
5. При необходимости планируем окно обслуживания.
6. Только после этого выполняем расширение.

Так resize превращается из потенциально нервной операции в обычную управляемую процедуру.

Заключение

Увеличение диска VPS не всегда заканчивается на кнопке Resize в панели облачного провайдера.

После изменения виртуального диска нужно последовательно проверить, какой уровень еще остался старого размера: сам диск, раздел, LVM или файловая система.

Для обычного раздела путь обычно короткий: Linux должен увидеть новый размер диска, затем раздел расширяется через growpart, а файловая система — через resize2fs для ext4 или xfs_growfs для XFS.

С LVM появляется еще несколько шагов: сначала увеличивается раздел, затем Physical Volume, после этого Logical Volume и только потом файловая система.

Главное здесь — не запоминать одну универсальную команду, а понимать структуру хранения на конкретном VPS. Именно это позволяет быстро диагностировать ситуацию, когда lsblk уже показывает новый объем, а df -hT — еще нет.

И, конечно, перед любыми изменениями дисковой разметки стоит иметь актуальную резервную копию. Само расширение обычно безопасно, но ошибка на уровне partition или LVM может стоить гораздо дороже нескольких минут, потраченных на backup и проверку исходной схемы.

FAQ

Нужно ли перезагружать VPS после увеличения диска?

Не всегда.

Во многих облачных средах Linux видит новый размер диска сразу, а growpart, pvresize, resize2fs и xfs_growfs можно выполнять без перезагрузки.

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

Почему lsblk уже показывает новый размер, а df -h — старый?

Потому что эти команды показывают разные уровни.

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

Для ext4 после расширения раздела обычно требуется: sudo resize2fs /dev/sda1

Для XFS: sudo xfs_growfs /

После этого новый объем должен появиться и в df -hT.

Можно ли сразу использовать lvextend -r и не выполнять resize2fs отдельно?

Да.

Например: sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Параметр -r просит LVM автоматически расширить и файловую систему вместе с логическим томом. Это поддерживается самим lvextend.

Но при ручной диагностике полезнее понимать отдельные этапы: pvresize → lvextend → расширение файловой системы. Так проще понять, на каком именно уровне возникла проблема.

Что означает +100%FREE в lvextend?

Это команда использовать всё оставшееся свободное место в Volume Group для выбранного Logical Volume. Официальная документация lvextend прямо приводит такой сценарий.

Если в одной VG находится несколько логических томов, лучше не использовать +100%FREE автоматически, а заранее решить, сколько пространства отдать конкретному LV.

Можно ли расширить XFS по имени устройства, а не по точке монтирования?

Современный xfs_growfs допускает работу с точкой монтирования или блочным устройством смонтированной XFS, но на практике точка монтирования обычно понятнее и менее двусмысленна. При этом файловая система должна быть смонтирована во время расширения.

Например: sudo xfs_growfs /

Что делать, если growpart пишет, что раздел нельзя увеличить?

Сначала проверьте:

    
        
    lsblk
sudo fdisk -l /dev/sda

Возможные причины:

• Сам диск еще не увидел новый размер;
• Раздел уже занимает всё доступное пространство;
• Свободное место находится не сразу после него;
• Расширение меньше минимального порога growpart.

Сам growpart работает по схеме DISK PARTITION-NUMBER и расширяет раздел настолько, насколько позволяет свободное место после него.

Можно ли уменьшить XFS обратно после увеличения?

С уменьшением всё сложнее, чем с расширением, и его лучше рассматривать как отдельную задачу.

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

Нужно ли делать backup, если growpart и расширение файловой системы выполняются онлайн?

Да.

Поддержка online resize означает, что операция может выполняться без остановки файловой системы, но не отменяет риск ошибки администратора, сбоя диска или неправильного выбора устройства.

Резервная копия нужна не потому, что growpart или resize2fs обязательно опасны, а потому, что работа идет непосредственно со структурой хранения данных.

Список источников

1. Ubuntu Manpages — growpart
2. Linux Manual Pages — xfs_growfs(8)
3. Linux Manual Pages — pvresize(8)
4. Linux Manual Pages — lvextend(8)