Установка нового VPS обычно начинается с выбора, который многие администраторы делают на автомате. Какая файловая система будет лежать в основе всего дальнейшего? В большинстве случаев берётся то, что предлагает шаблон провайдера, и это решение остаётся неизменным на годы. На самом деле выбор между ext4, XFS и Btrfs определяет очень многое - от скорости работы баз данных и веб-серверов до возможностей резервного копирования и восстановления после сбоев. В 2026 году картина уже не та, что была пять лет назад. Каждая из трёх систем созрела до своего конкретного применения, и понимание различий между ними экономит часы переустановки и потерянных данных.
Какие файловые системы по умолчанию используют современные дистрибутивы и почему они выбрали именно их
Прежде чем разбираться в деталях, полезно посмотреть, что выбирают сами разработчики дистрибутивов. RHEL и его производные (CentOS Stream, Rocky Linux, AlmaLinux) с версии 7 ставят XFS по умолчанию для всех корневых разделов. Debian и Ubuntu остаются на ext4, что сохраняется десятилетиями и стало почти традицией. Fedora Workstation с 2020 года использует Btrfs. openSUSE Tumbleweed и Leap делают то же самое уже дольше. Arch Linux в официальном облачном образе тоже идёт с Btrfs и сжатием zstd по умолчанию.
Эти выборы не случайны. Red Hat ориентирована на корпоративный сегмент с большими дисковыми массивами, серверами баз данных и высокой пропускной способностью - там XFS показывает себя лучше всех. Debian и Ubuntu держат ext4 как наиболее проверенный временем вариант, на котором меньше всего сюрпризов на любом железе. Fedora и openSUSE вкладываются в современные технологии управления данными, для чего Btrfs со снапшотами и контрольными суммами подходит идеально. На VPS, где обычно нет аппаратных RAID-контроллеров, а диски управляются гипервизором провайдера, важны именно те аспекты, которые отличают эти системы между собой.
Что предлагает ext4 и почему она остаётся стандартом для большинства задач VPS
Ext4 появилась в 2008 году как развитие ext3 и быстро стала отраслевым стандартом. Это журналируемая файловая система с проверенной временем стабильностью, поддерживаемая всеми дистрибутивами без исключения. На VPS её главное достоинство - предсказуемость. Ext4 ведёт себя одинаково на любых нагрузках, не имеет неожиданных провалов производительности и редко требует ручной настройки.
Создание раздела ext4 максимально простое:
sudo mkfs.ext4 /dev/vdb1
# Монтирование с типичными опциями для VPS
sudo mount -o defaults,noatime /dev/vdb1 /mnt/data
# Запись в /etc/fstab
echo "/dev/vdb1 /mnt/data ext4 defaults,noatime 0 2" | sudo tee -a /etc/fstab
Опция noatime отключает обновление времени последнего доступа к файлам, что заметно ускоряет работу при большом количестве операций чтения и снижает нагрузку на диск.
Ext4 умеет расти и уменьшаться, что для VPS критично. Если провайдер предоставляет возможность добавления дискового пространства на лету, расширение делается так:
# Расширение ext4 онлайн без размонтирования
sudo resize2fs /dev/vdb1
# Уменьшение требует размонтирования и проверки
sudo umount /mnt/data
sudo e2fsck -f /dev/vdb1
sudo resize2fs /dev/vdb1 100G
sudo mount /dev/vdb1 /mnt/data
Главные недостатки ext4 проявляются на крайних режимах работы. Максимальный размер одного файла ограничен 16 TiB, что для большинства задач избыточно, но в больших медиа-архивах может стать проблемой. Иноды (inodes) распределяются один раз при создании файловой системы, и их число фиксированное. Если на сервере планируется хранить миллионы маленьких файлов, есть риск исчерпать иноды раньше дискового пространства, и тогда придётся переформатировать весь раздел.
Проверить состояние инодов на работающем разделе можно так:
df -i /mnt/data
Вывод покажет общее количество инодов, использованное и свободное. Если IUse% приближается к 80-90%, пора задуматься о переходе на XFS или о форматировании ext4 с увеличенным числом инодов:
# Создание ext4 с увеличенным числом инодов (один на 8 КБ вместо 16 КБ)
sudo mkfs.ext4 -i 8192 /dev/vdb1
Реальный сценарий, ставший почти классическим. Сервер логирования rsyslog заполнил ext4-раздел на 2 ТБ при использовании всего 48% дискового пространства. Причина - исчерпание инодов из-за миллионов мелких лог-файлов. Решение оказалось трудозатратным - переформатирование с другими параметрами с временным переносом данных. С тех пор многие администраторы переводят серверы логов на XFS именно из-за этой особенности.
Чем XFS превосходит ext4 на тяжёлых нагрузках и где её ограничения становятся проблемой
XFS родилась в 1993 году в недрах Silicon Graphics для операционной системы IRIX и в 2001 году была портирована в Linux. Это 64-битная журналируемая файловая система, изначально спроектированная под высокопроизводительные серверы с большими дисками. Её главные архитектурные особенности - распределение пространства на независимые группы (allocation groups), каждая из которых обрабатывается параллельно, и B+-деревья для управления метаданными. Это даёт XFS преимущество на многоядерных системах и при работе с большими файлами.
Создание XFS-раздела:
sudo mkfs.xfs /dev/vdb1
# С явным указанием количества групп распределения для лучшей параллелизации
sudo mkfs.xfs -d agcount=8 /dev/vdb1
# Монтирование с типичными опциями
sudo mount -o defaults,noatime,nodiratime /dev/vdb1 /mnt/data
Расширение XFS работает только в большую сторону:
# Расширение онлайн
sudo xfs_growfs /mnt/data
Уменьшить XFS-раздел нельзя в принципе. Это структурное ограничение архитектуры, и обещания добавить такую функцию звучат уже больше десяти лет, но конкретных дат до сих пор нет. На VPS, где размер диска иногда меняется в обе стороны при смене тарифа, это серьёзно. План возможных уменьшений нужно учитывать при первоначальном выборе.
В тестах Phoronix на ядре 6.11 в августе 2024 года XFS вместе с ext4 заняла верхние строчки в большинстве сценариев, при этом XFS оказалась быстрее на больших файлах и параллельной нагрузке. Особенно показательным стало исследование George Mason University, где четыре файловые системы тестировались на создании и чтении одного миллиарда файлов размером от 1 до 10 КБ. XFS была единственной системой, которая прошла тест без какой-либо предварительной настройки. ZFS заняла около 92 часов на цикл записи и чтения. Btrfs не смогла завершить тест чтения. Ext4 потребовала полного переформатирования с увеличенными таблицами инодов перед запуском. Только XFS работала из коробки.
В ядре Linux 7.0, вышедшем в марте 2026 года, XFS получила механизм автономного самовосстановления метаданных. Если файловая система обнаруживает повреждённые метаданные, она исправляет их автоматически без размонтирования. Это убирает один из главных аргументов в пользу Btrfs - проверку целостности данных на лету. XFS в 2026 году становится не только самой быстрой, но и одной из самых надёжных файловых систем для производственных серверов.
Сценарий применения XFS - сервер баз данных, файловое хранилище, виртуализационный хост, медиа-сервер с большими файлами. Везде, где идёт интенсивный последовательный или параллельный ввод-вывод, XFS показывает лучший результат. Для веб-серверов общего назначения с тысячами мелких файлов разница с ext4 минимальна, и тут можно выбирать любой из двух вариантов.
Что особенного в Btrfs и зачем нужны её снапшоты на VPS
Btrfs (произносится "Better FS" или "Butter FS") - принципиально другая файловая система. Это copy-on-write (CoW) система с встроенными снапшотами, контрольными суммами для каждого блока данных, прозрачным сжатием, поддержкой подтомов (subvolumes) и встроенной программной RAID-конфигурацией. По возможностям она ближе к ZFS, чем к ext4 или XFS, но интегрирована в основное ядро Linux и не имеет лицензионных проблем.
Создание Btrfs-раздела и его монтирование с компрессией:
sudo mkfs.btrfs /dev/vdb1
# Монтирование со сжатием zstd
sudo mount -o compress=zstd,noatime /dev/vdb1 /mnt/data
# В fstab
echo "/dev/vdb1 /mnt/data btrfs compress=zstd,noatime 0 0" | sudo tee -a /etc/fstab
Сжатие zstd даёт значительную экономию места на текстовых данных - логи, исходный код, конфигурационные файлы сжимаются обычно в 2-4 раза без заметных потерь скорости. Для VPS с ограниченным дисковым пространством это полезная экономия.
Подтомы (subvolumes) в Btrfs - это что-то вроде самостоятельных файловых систем внутри одной физической. Каждый подтом можно монтировать отдельно, делать с ним снапшоты и переносить независимо от других:
# Создание подтома
sudo btrfs subvolume create /mnt/data/web
# Список подтомов
sudo btrfs subvolume list /mnt/data
# Удаление подтома
sudo btrfs subvolume delete /mnt/data/web
Снапшоты - убийственная функция Btrfs. Создание мгновенной копии состояния подтома требует наносекунд и почти не занимает места до момента, когда оригинал начнёт изменяться. Снапшоты живут как обычные подтомы и могут монтироваться, копироваться, удаляться независимо.
# Создание снапшота подтома web
sudo btrfs subvolume snapshot /mnt/data/web /mnt/data/snapshots/web-2026-04-27
# Только для чтения (рекомендуется для бэкапов)
sudo btrfs subvolume snapshot -r /mnt/data/web /mnt/data/snapshots/web-readonly
# Откат к снапшоту - удаление текущего и переименование снапшота
sudo btrfs subvolume delete /mnt/data/web
sudo btrfs subvolume snapshot /mnt/data/snapshots/web-2026-04-27 /mnt/data/web
Для VPS типичный сценарий - снимок состояния перед обновлением системы или развёртыванием новой версии приложения. Если что-то пошло не так, откат к снапшоту занимает секунды и возвращает всё на свои места. На ext4 или XFS аналогичную процедуру пришлось бы делать через rsync с резервным копированием, что значительно дольше и чревато ошибками.
Контрольные суммы для каждого блока - другая важная особенность. Btrfs хранит CRC32C-сумму для каждого блока данных и каждого блока метаданных. При чтении сумма проверяется автоматически, и если данные повреждены, файловая система сообщает об этом. На системах с зеркальной конфигурацией Btrfs может автоматически восстановить повреждённые данные с дублирующего диска.
# Запуск проверки целостности (scrub)
sudo btrfs scrub start /mnt/data
# Просмотр статуса
sudo btrfs scrub status /mnt/data
Однако есть и серьёзные минусы. Производительность Btrfs на тяжёлых нагрузках уступает ext4 и XFS, особенно на базах данных. В тестах Phoronix на Linux 6.11 Btrfs занимала последнее или предпоследнее место во всех четырёх рабочих нагрузках. Особенно заметна разница на конкурентной записи в SQLite - XFS и ext4 описаны как "явно самые быстрые", тогда как Btrfs "значительно медленнее всех". Причина - тот самый copy-on-write механизм, который даёт целостность данных, одновременно создаёт накладные расходы на запись.
Отдельная проблема - RAID5 и RAID6 в Btrfs. На январь 2026 года эти конфигурации всё ещё не считаются продакшен-ready и имеют известные проблемы при отказе диска во время записи (так называемая write hole). Для VPS это обычно не критично, потому что RAID управляется гипервизором, но если кто-то планирует Btrfs RAID на отдельных блочных устройствах, нужно ограничиться только RAID0 или RAID1. В RHEL 9.7 Btrfs остаётся на статусе технологического превью и не имеет полной коммерческой поддержки.
Какие сценарии VPS требуют какой именно файловой системы и где какая лучше всего себя показывает
Веб-сервер с базой данных и небольшим количеством статики - типичная задача для VPS. Здесь побеждает ext4 для общего назначения или XFS, если ожидается рост базы и интенсивные запросы. Btrfs тоже работоспособен, но даст процентов 10-20 потери производительности на запись в БД, что обычно неоправданно для маленького проекта.
# Типичная разметка для веб-сервера на VPS - ext4
sudo mkfs.ext4 -L webdata /dev/vdb1
sudo mount -o defaults,noatime /dev/vdb1 /var/www
Сервер баз данных среднего и крупного масштаба - сценарий для XFS. Параллельная обработка allocation groups, отличная работа с большими файлами таблиц, хорошее поведение под высокой нагрузкой. Особенно эффективно для PostgreSQL, MySQL, MariaDB на нагрузках от десятков транзакций в секунду и выше.
sudo mkfs.xfs -L dbdata /dev/vdb1
sudo mount -o defaults,noatime,nodiratime,logbsize=256k /dev/vdb1 /var/lib/mysql
Опция logbsize=256k увеличивает размер буфера журнала, что для интенсивных записей даёт небольшой прирост производительности.
Сервер логов или хранилище миллионов мелких файлов - тоже территория XFS. Динамическое распределение инодов решает проблему их исчерпания, которая мучает ext4 в подобных сценариях.
Сервер для разработки, где нужны частые откаты к рабочему состоянию - идеальное место для Btrfs. Снимок перед каждым обновлением, лёгкий откат при проблемах, подтома для разделения окружений тестирования и продакшена. Сжатие zstd экономит место на исходниках и логах. Производительность здесь не критична, а удобство управления важнее.
Файловое хранилище и бэкапы - снова Btrfs. Контрольные суммы защищают от тихого повреждения данных, снапшоты дают мгновенные точки восстановления, сжатие экономит место. Если бэкапы делаются в виде снапшотов с инкрементной отправкой через btrfs send/receive, получается удивительно эффективная схема:
# Создание снапшота для отправки
sudo btrfs subvolume snapshot -r /mnt/data /mnt/data/.snapshots/2026-04-27
# Отправка на удалённый сервер через ssh
sudo btrfs send /mnt/data/.snapshots/2026-04-27 | ssh backup@remote "btrfs receive /backup/server1"
# Инкрементная отправка следующего снапшота
sudo btrfs send -p /mnt/data/.snapshots/2026-04-27 /mnt/data/.snapshots/2026-04-28 | \
ssh backup@remote "btrfs receive /backup/server1"
Как принять окончательное решение и что проверить перед форматированием
Простое решающее дерево для выбора файловой системы на новом VPS выглядит так. Если планируется работа с базой данных под серьёзной нагрузкой или с большими файлами - XFS. Если хочется снапшотов, проверки целостности или лёгкого управления подтомами - Btrfs. Во всех остальных случаях - ext4, и не нужно усложнять. Это не идеологический выбор, а просто маппинг рабочей нагрузки на сильные стороны каждой системы.
Перед форматированием всегда стоит проверить несколько вещей. Поддерживает ли ядро дистрибутива нужные функции современной версии файловой системы? Как настроен fstrim для NVMe-дисков (особенно важно на VPS с виртуальным NVMe)? Какие опции монтирования рекомендует производитель базы данных или приложения для конкретной файловой системы?
Полезный скрипт для проверки состояния всех файловых систем на сервере:
#!/bin/bash
# fs-status.sh
echo "=== Mounted filesystems ==="
mount | grep -E 'ext4|xfs|btrfs' | column -t
echo ""
echo "=== Filesystem usage ==="
df -hT | grep -E 'ext4|xfs|btrfs'
echo ""
echo "=== Inode usage ==="
df -i | grep -E 'ext4|xfs|btrfs'
echo ""
echo "=== Btrfs status (if any) ==="
for mp in $(mount | grep btrfs | awk '{print $3}'); do
echo "Subvolume list for $mp:"
sudo btrfs subvolume list "$mp" 2>/dev/null | head -10
done
Окончательная мысль для тех, кто разрабатывает VPS-инфраструктуру в 2026 году. Время, когда файловые системы выбирались по принципу "какая досталась с шаблоном дистрибутива", уже прошло. Каждая из трёх систем - ext4, XFS и Btrfs - заняла свою прочную нишу. Понимание различий между ними не такое сложное, как кажется на первый взгляд, а выгода от правильного выбора накапливается на протяжении всей жизни сервера. Один час, потраченный на изучение собственных рабочих нагрузок и подбор подходящей файловой системы, экономит десятки часов на отладке проблем производительности и восстановлении данных в будущем.
Канал сайта в Telegram
Канал сайта на YouTube