На VDS файловая система — это не «вкус» и не религиозный выбор. Это набор компромиссов между предсказуемостью, удобством эксплуатации, возможностями бэкапа/отката и тем, как именно ваш storage ведёт себя под реальной нагрузкой (БД, логи, контейнеры, CI-кеши, медиаконтент). Ниже разберём три самые частые опции для Linux: ext4, XFS и btrfs — с упором на практику: восстановление после аварий, snapshots, send/receive и типичные грабли.
Контекст VDS: что важно перед выбором файловой системы
На «железе» вы обычно знаете, какой RAID/HBA, какой кэш, есть ли батарейка, что с NVMe, как настроены очереди и барьеры записи. На VDS часть деталей скрыта: вам дают виртуальный блоковый диск, который внутри может оказаться файлом на массиве, LVM-томом, Ceph/RBD, zvol и т.д. Это напрямую влияет на latency и поведение при fsync/flush, а значит — на работу журналирования и хвостовые задержки.
Почти всегда вы живёте в цепочке слоёв: гостевая ФС → виртуальный блоковый девайс → хранилище провайдера. У многих платформ есть snapshots «снаружи» (на уровне платформы). В таком случае snapshots внутри гостя — не единственный вариант, но часто самый удобный способ быстрых откатов именно «внутри VM», без участия панели провайдера.
Третий пункт — восстановление. То, что на bare metal выглядит как «загрузиться в rescue и прогнать fsck», на VDS может быть и проще, и сложнее (лимиты IOPS, тонкое выделение места, нестандартный backend). Поэтому до выбора ФС полезно честно ответить: как вы делаете бэкапы, как быстро откатываетесь и что делаете, если том не монтируется.
ext4 на VDS: дефолт, который редко подводит
ext4 — самый предсказуемый вариант для большинства веб-проектов. Он простой в сопровождении, отлично диагностируется, нормально переживает внезапные перезагрузки и «в среднем по больнице» даёт стабильное поведение.
Производительность ext4
По ощущениям и по реальным инцидентам ext4 часто выигрывает не рекордными бенчмарками, а предсказуемой latency на смешанных нагрузках: много мелких файлов (зависимости, статика, шаблоны), логи, временные файлы плюс крупные последовательные записи. Для типового стека (Nginx/Apache + PHP-FPM + MySQL/PostgreSQL) это почти всегда безопасный старт.
fsck для ext4: реальность на проде
У ext4 есть зрелый и понятный fsck (e2fsck) — эксплуатационно это большое преимущество. Цена — время: на больших томах офлайн-проверка может занять часы. На VDS это означает простой, если ФС не монтируется и нужна проверка из rescue.
Практически: многие раздвигают плановый запуск проверки (по количеству монтирований/времени), но это не отменяет необходимость иметь процедуру восстановления и бэкапы. Журналирование помогает, но не является «магией на все случаи».
Snapshots в ext4: только внешними механизмами
Нативных snapshots в ext4 нет. Если нужны снимки, обычно используют LVM snapshots (если LVM внутри VM) или snapshots на уровне платформы. Для бэкапов на уровне файлов (rsync/restic/borg) важно обеспечить консистентность данных, особенно БД: «копия каталога данных» без режима бэкапа легко превращается в «бэкап, который не восстановится».
Если вы хотите выжать максимум из ext4/XFS по задержкам и стабильности, посмотрите отдельный разбор настроек и типовых ошибок: тюнинг ext4/XFS на VDS без мифов.
Здесь уместно заранее договориться о «плане Б»: где лежат бэкапы, как быстро вы поднимаете чистую VM, и как выглядит процедура восстановления, если том внезапно не монтируется. На практике это экономит больше времени, чем тонкая погоня за процентовкой в синтетике.
XFS на VDS: масштаб и параллельность, но свои правила ремонта
XFS исторически силён на больших объёмах, параллельных операциях и высоких последовательных потоках. На VDS его часто выбирают под медиахранилища, большие логи, бэкапы и вообще под сценарии «много данных, много потоков».
Когда XFS раскрывается по производительности
XFS нередко выигрывает на:
- крупных файлах и последовательном I/O;
- высокой параллельности (много потоков чтения/записи);
- больших каталогах и объёмах данных.
Но важно помнить: если ваш виртуальный диск упирается в лимиты IOPS или высокий базовый latency на платформе, «магии от ФС» не будет — она лишь по-разному распределит издержки.
fsck в мире XFS: по-другому, не «как у ext4»
Главный сюрприз: классического «всё чинящего fsck» для XFS нет в привычном смысле. Для проверки/восстановления используют xfs_repair и связанные утилиты. Практические следствия простые:
- при проблемах часто нужен офлайн-ремонт (размонтировать том, иногда — уйти в rescue);
- на больших томах ремонт может быть как быстрым, так и очень долгим — зависит от характера повреждения и объёма;
- в отдельных сценариях восстановление метаданных может сопровождаться потерями (как и в других ФС), поэтому бэкапы обязательны.
Если выбираете XFS, держите в голове: «починю fsck’ом за 5 минут» — не всегда про него, и это нормально, если процессы DR отлажены.
Snapshots в XFS
Как и ext4, XFS не даёт встроенных snapshots. Обычно снимки обеспечиваются LVM или платформой VDS. Если вам нужен откат «после каждого деплоя» без внешних слоёв — это чаще аргумент в сторону btrfs.
Btrfs на VDS: snapshots и send/receive как инструмент эксплуатации
btrfs — это про управление данными: subvolume, snapshots, встроенная инкрементальная репликация (send/receive), сжатие, checksums данных и метаданных. На VDS это может быть очень практично — при условии, что вы готовы к дисциплине: мониторинг места, регулярные проверки и тест восстановления.
Snapshots в btrfs: быстрые откаты и «заморозка» состояния
Снимки в btrfs делаются на уровне subvolume и обычно создаются мгновенно (copy-on-write). Это удобно для:
- отката после неудачного обновления (пакеты, конфиги, код);
- консистентного состояния набора файлов под бэкап;
- регулярных точек восстановления (hourly/daily) внутри VM.
Но snapshots — не бэкап. Если умер диск или повредился backend хранилища, снимки на том же диске не спасут. Их сила раскрывается, когда вы реплицируете снимки на другой узел или другое хранилище.
send/receive: инкрементальные бэкапы «на уровне ФС»
btrfs send/btrfs receive позволяет отправлять snapshots (полные и инкрементальные) на другой сервер или диск. По сути, вы переносите изменения между двумя состояниями ФС без дорогого «пересчёта всего дерева», как это бывает у файловых бэкапов на больших наборах мелких файлов.
Базовый рабочий шаблон выглядит так:
btrfs subvolume snapshot -r /data /data/.snapshots/hourly-2025-12-25-1200
btrfs send /data/.snapshots/hourly-2025-12-25-1200 | btrfs receive /backup/btrfs
btrfs send -p /data/.snapshots/hourly-2025-12-25-1100 /data/.snapshots/hourly-2025-12-25-1200 | btrfs receive /backup/btrfsКлючевой момент — ретеншн: если не удалять старые snapshots, COW будет удерживать старые версии блоков и «съедать» место. План очистки — обязательная часть дизайна.
Производительность btrfs: где осторожно
По performance btrfs сильно зависит от паттерна нагрузки и настроек. Он может быть отличным для «файлового мира» (деплои, откаты, много чтений), но на некоторых сценариях записи проигрывать ext4/XFS по latency из‑за copy-on-write и дополнительной работы с метаданными.
Отдельная тема — базы данных. Частый прагматичный подход: держать код/конфиги/артефакты на btrfs ради snapshots, а данные БД — на отдельном томе с ext4 или XFS. Если вы всё же хотите БД на btrfs, тестируйте именно свой профиль нагрузки (fsync, размер WAL/redo, параллельность) и закладывайте запас по месту.
Проверка и восстановление btrfs: нет «кнопки починить»
У btrfs есть btrfs check, но это не аналог «надёжного fsck, который всегда безопасно чинит» как в мире ext*. Базовая эксплуатационная практика — это регулярный scrub (проверка контрольных сумм), мониторинг ошибок и заранее отрепетированное восстановление из реплики.
Если вы выбираете btrfs ради snapshots и send/receive, закладывайте в регламент мониторинг свободного места, периодический scrub и тест восстановления. Это важнее, чем спор «какая ФС быстрее».
Чтобы админки и внутренние веб-интерфейсы (панели, мониторинг, репозитории) не превращались в точку риска, используйте корректно настроенные SSL-сертификаты.
Отдельно проверьте, как у вас устроен доступ к резервной площадке: ключи, ограничение по IP, раздельные учётки и журналирование. Это часто важнее выбора ФС, когда начинается реальный инцидент.
Сравнение по сценариям: что ставить на VDS
Вместо «таблички ради таблички» — практичные развилки.
Сайт/приложение + классический LEMP/LAMP без экзотики
Берите ext4, если вам важны простота и предсказуемость. Это лучший дефолт, особенно когда команда небольшая, а процедуры DR ещё не идеально отточены.
Большие файлы, логи, бэкапы, медиаконтент, высокая параллельность
Смотрите в сторону XFS. Он хорошо масштабируется и часто показывает отличный результат на больших объёмах и потоковой записи/чтении. Просто заранее убедитесь, что у вас понятная стратегия восстановления и проверяемые бэкапы.
Нужны snapshots как рабочая фича и инкрементальная репликация
Тут btrfs очень силён: snapshots и send/receive реально меняют процесс деплоя и бэкапа. Но это выбор «в обмен на дисциплину»: нужно следить за свободным местом, разрастанием снимков и регулярно проверять целостность.
Практика: вопросы перед миграцией и мини-чеклист наблюдаемости
Вопросы перед тем, как «переехать»
Где ваши бэкапы и как вы их проверяете? Если бэкап не тестировался восстановлением — это гипотеза.
Нужно ли быстро откатываться? Если да — snapshots (btrfs или platform/LVM) часто важнее «+5% в бенчмарке».
Что критичнее: throughput или latency? Для веба и БД часто важнее хвосты (p95/p99), а не среднее.
Сколько мелких файлов? Node/PHP экосистемы любят плодить их тысячами — метаданные важны.
Есть ли ограничения на IOPS? На лимитированном диске разница между ФС может сгладиться или проявиться в неожиданном месте.
Мини-чеклист, чтобы не гадать о performance
Смотрите не только MB/s, но и latency (p95/p99) по диску и по приложению.
Контролируйте очередь I/O и время обслуживания запросов (симптомы «диск не вывозит»).
Проверяйте реальную динамику свободного места (особенно на btrfs со snapshots).
Отслеживайте сообщения ядра: remount read-only, I/O errors, corruption, reset устройства.
И ещё: не путайте «скорость файловой системы» и «скорость приложения». Если MySQL упирается в режимы fsync (например, настройки наподобие innodb_flush_log_at_trx_commit), смена ФС без профилирования может ничего не дать.
Если у вас на VDS часто меняется размер диска (или планируется рост проекта), держите под рукой инструкцию по безопасному расширению: как увеличить диск на VDS и расширить раздел и файловую систему.
Вывод: коротко и по делу
ext4 — лучший «безопасный выбор» на VDS, если вы хотите стабильность, понятный fsck и минимум сюрпризов.
XFS — сильный вариант для больших объёмов и параллельной работы с данными, но с другой моделью восстановления (не ждите «обычный fsck»).
btrfs — инструмент для тех, кому важны snapshots и send/receive как часть процесса бэкапа и деплоя. Он даёт мощные фичи, но требует дисциплины: место, ретеншн, scrub, тест восстановления.
Если сомневаетесь — начните с ext4, а «фичи уровня snapshots» доберите платформенными снимками и нормальной системой бэкапов. И наоборот: если откат и инкрементальная репликация — ключевая боль, btrfs часто окупается быстрее, чем бесконечный тюнинг.
