LVM на корпоративном сервере 1С: расширение диска без даунтайма

Привет! Меня зовут Семёнов Евгений Сергеевич, и я руковожу компанией АйТи Фреш. За 15 лет, что я работаю с серверами для малого и среднего бизнеса здесь, в Москве, у меня появилось одно незыблемое правило. Каждый Linux-сервер у наших клиентов я всегда ставлю на LVM. И дело тут вовсе не в какой-то «моде» или том, что «так правильно по учебнику». Просто в реальной жизни место на диске заканчивается постоянно, и всегда это происходит не вовремя – обычно на сервере с 1С, где каждая минута простоя оборачивается для бизнеса реальными деньгами. Сейчас я простыми словами объясню, что это за технология и почему она спасает компании от головной боли по ночам.

Сценарий, который повторяется в каждом моём аудите

Представьте такую картину, это прям из жизни. Звонят мне и просят приехать на новый объект – обычная компания, человек 30-40, склад у них где-то в Подольске, а бухгалтерия сидит в офисе на Соколе. Там стоит старенький Linux-сервер с 1С на PostgreSQL, который им поставил какой-то приходящий админ года четыре назад. Ну, работал он себе тихо-мирно, никто его не трогал. И вот, в среду, ровно в 14:00, бац – 1С вдруг перестаёт сохранять документы. Бухгалтерия, конечно, в панике, а директор тут же хватается за телефон.

Захожу по SSH, выполняю df -h — а там 100% занято на разделе с PostgreSQL. База выросла, логи накопились, временные файлы заполнились. Что нужно сделать? В идеале — расширить диск. На практике, если сервер размечен «по старинке» без LVM, варианты такие:

• Удалить часть данных. Но это база 1С — удалять нечего, всё нужно.
• Добавить новый физический диск, перенести часть базы на него, изменить путь. Час работы при условии, что тип файлов это позволяет.
• Остановить 1С, размонтировать диск, переразметить вручную через parted, расширить файловую систему. 2-4 часа даунтайма, риск повредить данные.
• Полностью переустановить сервер с нуля с правильной разметкой. День работы, недельная подготовка.

А если сервер изначально был установлен с LVM, я выполняю две команды за 30 секунд: lvextend -L +100G /dev/vg0/lv_pgsql и resize2fs /dev/vg0/lv_pgsql. И место добавилось. Бухгалтерия даже не успевает заметить, что что-то происходило. Вот ради этой одной возможности я и ставлю LVM на каждый клиентский сервер.

Что такое LVM простыми словами

Давайте попробуем объяснить LVM без сложных терминов. LVM, или Logical Volume Manager (по-русски – диспетчер логических томов), это такая «прослойка» между вашими физическими дисками и файловой системой. Представьте, что она делает диски невероятно гибкими, прямо как пластилин! С ней вы перестаёте быть привязанными к раз и навсегда заданному размеру каждого раздела.

Вот вам аналогия, чтобы было совсем понятно. Представьте, что у вас в офисе есть три кладовки, все разного размера. Если LVM нет, то каждая кладовка живёт своей жизнью: что вы положили в первую, то во вторую уже никак не переложишь, разве что стену ломать. А вот с LVM вы эти три кладовки как будто объединяете в одно огромное хранилище. И туда уже ставите виртуальные «коробки» нужного вам размера. Если какая-то коробка переполнилась – буквально за пять секунд вы её увеличиваете. Купили ещё одну, четвёртую кладовку? Просто добавляете её в общий пул, и все ваши «коробки» тут же получают доступ к новому, большему пространству.

Технически в LVM три уровня:

• Физический том (PV) — это ваш реальный диск или раздел. Например, /dev/sdb.
• Группа томов (VG) — это «общий пул» из нескольких PV. Например, vg0, объединяющая все диски сервера.
• Логический том (LV) — это виртуальный «диск» внутри VG, на котором живёт ваша файловая система. Например, lv_pgsql для базы 1С.

Может показаться, что это что-то очень сложное, но на самом деле при первой установке системы LVM настраивается буквально за 15 минут. А потом можно годами о нём даже не вспоминать!

Какие реальные задачи бизнеса решает LVM

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

Сценарий 1: «Сервер 1С переполнился»

Самый частый вызов. База растёт, файлы 1С пухнут, логи PostgreSQL копятся. С LVM это лечится так:

# Покупаем новый SSD, вставляем в сервер
# Добавляем в общий пул
pvcreate /dev/sdc
vgextend vg0 /dev/sdc

# Расширяем нужный том на 200 ГБ
lvextend -L +200G /dev/vg0/lv_pgsql --resizefs

Готово. Бухгалтерия продолжает работать. Время операции — 2 минуты с учётом того, что встать и физически вставить диск в сервер. Без LVM — это была бы переустановка системы или сложная переразметка.

Сценарий 2: «Хотим бэкапить базу 1С без остановки»

Это прямо классическая проблема. Файловая база 1С — это ведь просто куча мелких-мелких файлов, которые постоянно, ежесекундно меняются. Если вы попробуете скопировать их «как есть», то получите неконсистентный бэкап, который потом просто не запустится. А если останавливать 1С на время копирования, то будете терять по целому часу рабочего времени на каждый бэкап.

Зато с LVM-снапшотом мы можем сделать такую «мгновенную фотографию» состояния тома и уже спокойно копировать её.

# Делаем снапшот тома с 1С (10 ГБ под изменения)
lvcreate -L 10G -s -n snap_1c /dev/vg0/lv_1c

# Монтируем снапшот в режиме чтения
mount -o ro /dev/vg0/snap_1c /mnt/snap

# Копируем на другой сервер или в облако
rsync -aAX /mnt/snap/ backup@nas:/backup/1c/

# Удаляем снапшот
umount /mnt/snap
lvremove -f /dev/vg0/snap_1c

Снапшот делается за 0.5 секунды. Пользователи 1С продолжают работать, не замечая. Бэкап получается консистентным — это важно. Технология работает не только для 1С, но и для PostgreSQL, файловых шар, любых данных.

Сценарий 3: «Один диск в сервере начал сыпаться, надо мигрировать»

Представьте: SMART выдаёт тревожное предупреждение – на одном из дисков начал расти счётчик переназначенных секторов. Это значит, что диск потихоньку умирает. Данные нужно срочно переносить на новый, причём так, чтобы клиенты вообще ничего не заметили.

С LVM это делается командой pvmove — данные копируются поблочно на новый диск, и все операции прозрачно переадресовываются. 1С работает без перебоев:

# Подключаем новый диск
pvcreate /dev/sdd
vgextend vg0 /dev/sdd

# Мигрируем все данные с проблемного диска на новый
pvmove /dev/sdb /dev/sdd

# Удаляем старый диск из группы и физически вынимаем
vgreduce vg0 /dev/sdb
pvremove /dev/sdb

Скорость миграции зависит от объёма данных и нагрузки — для 500 ГБ типично занимает 2-4 часа. Но это всё в фоне, без даунтайма. Раньше для такой операции я приезжал клиенту в субботу ночью и работал до утра. Теперь запускаю pvmove в среду днём и иду пить кофе.

Сценарий 4: «Хотим ускорить медленную базу с помощью SSD-кэша»

Вот ещё один показательный случай из моей практики. У одного из наших клиентов стоит сервер с огромным RAID-массивом из обычных HDD на 8 ТБ – места там просто завались, но работает всё, конечно, медленно. База 1С у них всего на 200 ГБ, она бы легко поместилась на SSD, но покупать SSD-RAID на все 8 ТБ клиент не хочет – это дорого. Что мы делаем? Просто добавляем в сервер один NVMe SSD и настраиваем LVM-кэш. В итоге самые «горячие» данные базы, к которым чаще всего обращаются, хранятся на быстром SSD, а архивные – на более медленных HDD. Итог? Скорость работы 1С вырастает в 3-5 раз!

# Добавляем NVMe SSD в группу
pvcreate /dev/nvme0n1
vgextend vg0 /dev/nvme0n1

# Создаём кэш-пул на SSD
lvcreate -L 200G -n cache_data vg0 /dev/nvme0n1
lvcreate -L 1G -n cache_meta vg0 /dev/nvme0n1
lvconvert --type cache-pool --poolmetadata vg0/cache_meta vg0/cache_data

# Подключаем кэш к тому с базой 1С
lvconvert --type cache --cachepool vg0/cache_data vg0/lv_pgsql

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

Реальный кейс: как мы спасли торговую сеть от потери дня работы

Представьте себе: Январь 2026 года, утро понедельника. Звонит клиент – это крупная торговая сеть из 6 магазинов автозапчастей. У них сервер 1С на Ubuntu 22.04 просто не запускается, а в логах PostgreSQL вижу знакомую надпись: «no space left on device». Я быстро подключаюсь удалённо, смотрю – так и есть, раздел с базой забит на все 100%! Оказывается, база распухла за выходные из-за массового импорта прайсов поставщиков.

Но тут, к счастью, есть и отличная новость: этот сервер мы устанавливали три года назад и сразу сделали правильную разметку LVM. Более того, в шкафу у клиента лежит запасной SSD на 1 ТБ – мы всегда стараемся оставлять такой «резерв». Я тут же инструктирую их сисадмина (он, хоть и на больничном, но смог доехать до сервера): «Вставляй SSD в свободный слот, а дальше я всё настрою удалённо».

Через 15 минут после его приезда в офис сервер увидел новый диск. Я выполнил три команды: pvcreate, vgextend, lvextend --resizefs. Через 30 секунд база PostgreSQL запустилась, 1С заработала, продавцы за кассами не успели даже понять, что что-то было не так.

А вот если бы мы поставили этот сервер «по старинке», без LVM, то вариантов у нас было бы всего два, и оба так себе. Либо переустанавливать всю систему с нуля – это целый день работы, да ещё и потеря логов транзакций. Либо же лезть в эту сложную переразметку с огромным риском просто «убить» всю базу. И то, и другое означало бы минимум 4-6 часов простоя для всех шести магазинов! Учитывая, что средний оборот этой сети составляет 850 000 руб. в день, потери могли бы исчисляться сотнями тысяч. А так всё решилось одним моим вечерним звонком и покупкой SSD за 8 000 рублей.

Когда LVM не нужен

И честно — есть случаи, когда LVM я не настраиваю:

• Маленькие виртуальные машины с одной задачей. Если у вас VPS на 20 ГБ под одно приложение, которое ничего не пишет на диск, LVM добавляет сложности без пользы.
• Очень специфические сценарии с производительностью. Базы данных уровня enterprise с дисковыми СХД иногда требуют прямого доступа к raw-устройствам без LVM-прослойки.
• Серверы только под одну функцию с фиксированным объёмом. Например, сервер мониторинга с известным объёмом данных на год.

Но для подавляющего большинства – а это 95% корпоративных серверов малого и среднего бизнеса – LVM, по моему опыту, это абсолютно верное решение. Особенно если данные растут непредсказуемо, как это часто бывает с базами 1С, файловыми хранилищами, почтой или веб-приложениями.

Сколько стоит правильно настроить

Установить новый сервер сразу на LVM – это просто часть нашей обычной работы, когда мы разворачиваем Linux-серверы. Мы за это отдельно денег не берём. То есть, если вы заказываете у нас новый сервер «под ключ» – например, с 1С на PostgreSQL, файловой шарой и корпоративной почтой – то LVM будет настроен там по умолчанию.

Но если у вас уже работает сервер без LVM и вы решили его перевести на эту технологию, то это уже будет отдельная задача. Здесь потребуется либо полная переустановка системы, либо очень аккуратная работа по временному переносу данных. Посмотреть тарифы можно здесь:

А вот для клиентов, которые у нас на абонентском обслуживании, такие работы обычно включаются в плановые задачи, и никаких доплат за это не берём. Мы один раз всё настроим как следует – и вы будете годами об этом просто не вспоминать.

FAQ — частые вопросы клиентов про LVM

Зачем малому офису LVM, если можно просто разметить диск стандартно?

Стандартная разметка прибита гвоздями: чтобы добавить место, нужно остановить сервер, размонтировать диск, переразметить. На сервере 1С это означает 2-4 часа простоя бухгалтерии. С LVM вы добавляете диск или расширяете раздел за 30 секунд без остановки сервиса. Один раз правильно настроили — годами не возвращаетесь.

Можно ли использовать LVM на Windows-сервере с 1С?

LVM — это технология Linux. На Windows аналог называется Storage Spaces (на Windows Server) или Dynamic Disks (старее). Принцип похожий: пул из нескольких дисков, виртуальные тома с гибким размером. Для серверов 1С на Windows мы рекомендуем Storage Spaces для серверных версий или ReFS-диски с тонким резервированием.

Сколько стоит миграция существующего сервера на LVM?

Если сервер уже работает без LVM, миграция требует переустановки системы или сложной операции с pvmove + переразметкой. Для одного сервера 1С — 18 000 руб., включая ночное окно работ, тестирование и rollback-план. Часто проще запланировать переход при следующей замене железа — там это бесплатно входит в установку.

А что если один из дисков в LVM умрёт — потеряю всё?

Сам по себе LVM не защищает от смерти диска — он просто объединяет диски в пул. Защиту даёт RAID под LVM (mdadm + LVM поверх) или встроенный LVM RAID (lvconvert --type raid1). Мы всегда ставим LVM поверх mdadm RAID 1 или RAID 10 для серверов с базами данных. Это даёт и гибкость LVM, и защиту от одного отказавшего диска.

Как делать бэкап 1С через LVM-снапшот?

Создаём снапшот тома с базой 1С (lvcreate -s), монтируем его в режиме чтения, копируем файлы базы куда нужно (на другой сервер, в облако, на NAS), удаляем снапшот. Для пользователей 1С процесс невидим — база работает все эти 10-15 минут без перерыва. Идеально для горячего бэкапа SQL-баз или файловых баз 1С.