Какой сервер выбрать для 1С: как избежать критических ошибок

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

Ниже разберём, что действительно влияет на работу 1С: процессор, память, накопители, ОС, резервирование и безопасность.

• До 10 пользователей — 4 ядра, 32 ГБ RAM, SSD.
• 10–30 пользователей — 8 ядер, 64 ГБ RAM, NVMe.
• 30+ пользователей / ERP — раздельные роли: сервер приложений + сервер БД.

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

Торговая компания из 15 сотрудников запускает 1С на дешёвом VPS с 2 ядрами и 8 ГБ RAM. Первые месяцы система работает терпимо. Затем база растёт с 20 до 80 ГБ, число одновременных подключений увеличивается с 5 до 12, и начинаются зависания по 10–15 раз в день.

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

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

Три частые ошибки при выборе

1. Использовать обычный ПК вместо сервера

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

2. Покупать конфигурацию «на сейчас»

Сегодня в системе 10 пользователей и небольшая база. Через год сотрудников уже 25, объём данных вырос в несколько раз. Сервер перестаёт справляться.

3. Экономить на дисковой подсистеме

Если рабочая база 1С до сих пор стоит на HDD — тормоза вы создаёте себе сами.

Кейс: после переноса базы с SATA SSD на NVMe открытие тяжёлого отчёта сократилось с 42 до 11 секунд.

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

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

Перед расчётом ответьте на 5 вопросов

• Сколько пользователей работают одновременно в часы пик?
• Какие конфигурации используются: БП, ЗУП, УТ, ERP?
• Какой размер базы сейчас и как быстро она растёт?
• Есть ли системный администратор внутри компании?
• Нужна ли отказоустойчивость или достаточно резервных копий?

Что считать в первую очередь

Смотрите не на общее число сотрудников, а на количество одновременных сессий. Именно этот показатель влияет на CPU и RAM.

Оцените рост базы. Если сейчас она занимает 50 ГБ и ежегодно прибавляет по 15–20 ГБ, через три года понадобится минимум 120 ГБ только под данные.

Заложите запас. Это дешевле, чем экстренный перенос системы позже.

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

«Бухгалтерия предприятия» для компании из 5 человек и «Управление торговлей» с 10 000 позиций номенклатуры создают совершенно разную нагрузку. БП в основном работает с проводками и отчётами. Нагрузка на диск обычно умеренная. УТ при активной торговле постоянно пишет данные: приходы, расходы, перемещения, переоценки. Если документов много, слабый диск начинает душить систему первым.

«Зарплата и управление персоналом» чаще нагружает сервер в конце месяца — во время расчёта зарплаты. В остальное время может быть спокойно. Если ЗУП работает на том же сервере, что и УТ, пики иногда совпадают. Именно в такие дни бизнес получает самые болезненные тормоза.

С 1С:ERP всё серьёзнее. Там больше фоновых заданий, тяжёлые отчёты, выше требования к СУБД и дисковой подсистеме.

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

Если система уже тормозит — хватит гадать, откройте мониторинг. Диспетчер задач Windows, Performance Monitor или штатные средства виртуализации быстро покажут, где проблема: процессор, память или хранилище. На практике серверы часто меняют после жалоб пользователей, хотя проблема копилась месяцами в логах и мониторинге. Снимайте показатели в часы пик. Замеры в обед, когда половина сотрудников ушла, почти бесполезны.

Что смотреть по CPU

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

Что смотреть по RAM

Когда памяти мало, система начинает активно использовать файл подкачки. После этого отклик заметно проседает. Смотрите на рост page faults, задержки при открытии документов и ухудшение работы при росте числа сессий. Если памяти впритык, 1С может работать терпимо утром и раздражать всех к середине дня.

Что смотреть по дискам

Очередь к диску и высокая задержка чтения/записи — классическая причина тормозов. Частый случай: CPU загружен на 20%, зато диск стоит в очереди. Пользователи уверены, что нужен новый процессор. Для SSD и NVMe короткие всплески допустимы. Постоянная очередь — уже проблема.

Главное правило диагностики

Не меняйте всё сразу. Сначала устраните одно узкое место, затем снова измерьте показатели. Иначе легко потратить бюджет и не получить результата.

Обычно всё упирается в четыре вещи:

• процессор;
• оперативную память;
• накопители;
• сеть.

Слабое место в любом из этих узлов тормозит систему целиком, даже если остальное железо дорогое.

Процессор: как выбирать без ошибок

1С умеет использовать несколько потоков, но не каждая операция масштабируется одинаково хорошо. Проведение документов и часть отчётов часто чувствительны к скорости одного ядра. Фоновые задания, параллельные пользователи и обмены уже любят большее число ядер.

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

Для большинства задач малого и среднего бизнеса важнее хороший баланс:

• достаточная частота одного ядра;
• запас по физическим ядрам;
• нормальная подсистема памяти.

Нередко сервер с 8 быстрыми ядрами работает лучше, чем машина с 16 медленными.

Также заранее проверьте возможность расширения RAM и дисков. Через год именно это становится критичным чаще, чем модель процессора.

RAM: сколько памяти нужно

Чаще всего 1С тормозит из-за нехватки RAM. Когда памяти мало, сервер начинает выгружать данные на диск. Даже быстрый NVMe в таком режиме заметно медленнее оперативной памяти. Результат знаком многим: зависания в пиковые часы, долгие открытия форм, жалобы пользователей.

Грубый ориентир для расчёта:

RAM = (число пользователей × 1,5 ГБ) + (20% размера базы) + 8 ГБ под ОС и СУБД

Это не норматив, а стартовая точка. Реальное потребление зависит от конфигурации, фоновых задач и выбранной СУБД.

Если расчёт даёт 43 ГБ — берут 64 ГБ. Если выходит 113 ГБ — смотрят в сторону 128 ГБ.

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

Диски: где 1С теряет время быстрее всего

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

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

Что выбрать

Частый сценарий: покупают дорогой CPU, а базу оставляют на старом SATA SSD. Потом удивляются задержкам в ERP.

RAID: нужен ли он

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

Что используют чаще всего

• RAID 1 — два диска с зеркалом. Подходит для небольших систем.
• RAID 10 — хороший выбор для нагруженной 1С. Даёт и скорость, и резервирование.
• RAID 5 — компромиссный вариант, но запись слабее, восстановление дольше.

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

Сетевые интерфейсы: пропускная способность и стабильность соединения

Сеть ломает производительность реже дисков и RAM, но при росте нагрузки её быстро замечают. Если пользователей много, есть филиалы, RDP-доступ или постоянные обмены между узлами — сеть становится критичной. Базовый минимум сегодня — стабильный 1 GbE. При 30+ активных пользователях, тяжёлых обменах или нескольких серверах уже стоит смотреть на 10 GbE. Во многих проектах сначала меняют сервер, а потом выясняется, что bottleneck был в старом коммутаторе на 1 GbE.

Что проверить

• старые коммутаторы;
• битые кабели;
• перегруженные VPN-каналы;
• нестабильный Wi-Fi там, где нужен кабель.

Иногда проблема «медленной 1С» вообще находится не на сервере.

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

Но по мере роста компании один сервер начинает мешать сам себе.

На одной машине одновременно живут:

• СУБД;
• сервер приложений;
• RDP-сессии;
• обмены;
• фоновые задания;
• резервное копирование.

Рано или поздно эти процессы начинают бороться за одни и те же ресурсы.

Когда стоит разделять роли

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

Выбор ОС обычно упирается не в религию, а в людей, которые будут это сопровождать.

Когда берут Windows Server

• в компании уже есть Windows-инфраструктура;
• администратор уверен в этой среде;
• нужна тесная интеграция с Active Directory и Microsoft-сервисами;
• используется MS SQL Server.

Минус очевидный: лицензии стоят денег.

Когда смотрят в сторону Linux

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

Linux может работать отлично. Но если внутри нет компетенции, экономия быстро заканчивается. Плохо сопровождаемый Linux хуже хорошего Windows Server. И наоборот.

Как выбирать честно

Если команда сильна в Windows — берите Windows. Если есть опытный Linux-специалист и нужна экономия на лицензиях — Linux с PostgreSQL часто выглядит разумно. Если специалистов нет вовсе — иногда проще арендовать управляемое облако, чем спорить про ОС.

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

Что обычно требуется для клиент-серверной работы

• лицензия на используемую конфигурацию;
• клиентские лицензии;
• лицензия на сервер 1С;
• при необходимости лицензия СУБД.

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

Считать нужно не сотрудников в штате, а тех, кто реально работает в системе одновременно. Если в компании 30 человек, а одновременно заходят 18–20, ориентироваться стоит на этот сценарий, а не на общее число сотрудников. Не забудьте про фоновые задания, обмены, интеграции и регламентные процессы. Они тоже потребляют ресурсы.

Где чаще переплачивают

• берут большой запас «на всякий случай»;
• не анализируют пики нагрузки;
• покупают лишние серверные лицензии;
• не пересматривают схему после роста компании.

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

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

Что реально защищает RAID

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

• удаления базы по ошибке;
• вируса-шифровальщика;
• повреждения файловой системы;
• ошибки администратора;
• пожара, кражи или отказа всего сервера.

Что делает резервная копия

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

Минимальная схема для малого и среднего бизнеса

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

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

Правило 3-2-1

• 3 копии данных;
• 2 разных носителя;
• 1 копия вне основной площадки.

Это может быть сервер + NAS + облачное хранилище. Не обязательно дорого, обязательно разумно.

Когда нужна репликация

Если час простоя стоит дорого, одного backup уже мало. Тогда используют репликацию: изменения с основной базы уходят на резервный узел почти в реальном времени. При аварии компания переключается быстрее и теряет меньше данных. Это особенно актуально для торговли, логистики, производства и компаний с плотным документооборотом.

Когда нужен кластер

Если критична непрерывная работа, используют несколько узлов приложения 1С. При падении одного узла пользователи продолжают работать на остальных. Скорость может снизиться, но бизнес не останавливается полностью.

Disaster Recovery Plan: что делать в день аварии

Во время сбоя хуже всего импровизация. DRP — это заранее подготовленный сценарий:

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

Если инструкции нет, её начинают писать прямо во время аварии. Это самый дорогой момент для творчества.

Что проверить уже сегодня

• Когда делался последний backup?
• Где он хранится?
• Пробовали ли его восстановить?
• Сколько займёт запуск после сбоя?
• Кто отвечает за процесс?

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

Главный вывод

Компании редко жалеют, что сделали резервирование заранее. Зато часто жалеют, что откладывали его слишком долго.

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

Доступ

Уберите пустые пароли, отключите ненужные учётки, настройте сложные пароли и MFA там, где есть удалённый вход. Если сервер доступен из интернета и на нём открыт RDP без MFA — это не вопрос “случится или нет”, а вопрос времени.

Учётные записи

Частая история: сотрудник уволился полгода назад, а его учётная запись всё ещё активна. Раз в месяц проверяйте:

• кто имеет доступ;
• какие права выданы;
• нет ли старых учёток;
• нужны ли административные права.

Сеть

Открывайте только нужные порты. Доступ к серверу ограничивайте VPN, белыми IP или внутренней сетью. Если база и сервер приложений разделены, держите обмен между ними в отдельном сегменте сети.

Обновления

Большинство массовых взломов используют давно известные уязвимости. Обновляйте:

• Windows / Linux;
• платформу 1С;
• PostgreSQL / MS SQL;
• антивирус и агенты защиты.

Но обновления платформы 1С сначала проверяйте на тестовом контуре.

Журналы и контроль

Логи часто вспоминают только после инцидента. Тогда уже поздно. Фиксируйте:

• неудачные входы;
• ночные подключения;
• массовое удаление данных;
• подозрительную активность пользователей.

Минимум, который нужен почти всем

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

Большинству компаний не нужен дорогой SOC. Им нужен порядок в базовых вещах.

Что важнее всего

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

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

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

Когда оправдан собственный сервер

Физический сервер даёт полный контроль:

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

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

Что обычно недооценивают

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

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

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

Когда логичнее облако

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

• не нужны крупные стартовые вложения;
• ресурсы можно увеличить быстро;
• удалённым сотрудникам проще подключаться;
• часть инфраструктурных задач берёт провайдер.

Для компаний с несколькими офисами или удалённой командой это нередко самый спокойный путь.

Но риски тоже есть

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

Если саппорт отвечает сутками, красивый тариф быстро теряет смысл.

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

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

Худшее решение — покупать сервер «потому что так солиднее» или идти в облако только из-за модного слова. Сначала считайте нагрузку, людей и риски. Потом выбирайте площадку.

Когда 1С замедляется, многие сразу смотрят в сторону нового сервера. На практике причина часто дешевле и прозаичнее. Иногда хватает настройки СУБД, перераспределения ролей или замены накопителя. Иногда без апгрейда действительно не обойтись. Задача — понять, где узкое место, а не покупать всё подряд.

С чего начать диагностику

Фраза «1С тормозит» сама по себе ничего не объясняет. Один пользователь может ждать отчёт, второй — зависать при проведении документа, третий — терять соединение по RDP. Это три разные проблемы.

Сначала фиксируйте:

• когда именно возникают жалобы;
• что делает пользователь в этот момент;
• сколько людей работает одновременно;
• что показывает загрузка CPU, RAM и дисков;
• есть ли ошибки в журналах 1С и ОС.

Типовые симптомы и реальные причины

Что часто упускают

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

Другой частый случай — антивирус проверяет каталоги базы в реальном времени. Формально защита есть, фактически система сама себе мешает.

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

• CPU стабильно упирается в потолок в пиковые часы;
• RAM не хватает даже после оптимизации;
• дисковая система не держит нагрузку;
• число пользователей выросло в разы;
• появились новые тяжёлые конфигурации: ERP, УТ, BI-отчёты.

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

Когда сначала настраивать

• плохое расписание регламентных заданий;
• ошибки в настройках PostgreSQL или MS SQL;
• лишние службы на сервере;
• неудачное распределение ролей;
• устаревшая версия платформы 1С.

Иначе можно купить дорогое железо и сохранить ту же проблему уже за большие деньги.

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

• Снять метрики в момент жалоб.
• Посмотреть журналы и блокировки.
• Устранить самое явное узкое место.
• Повторно измерить результат.
• Только потом решать вопрос с апгрейдом.

Такой подход обычно экономит и деньги, и нервы.

Тест Гилева давно используют в среде 1С для быстрой оценки производительности. Его любят за простую цифру на выходе: получил баллы — можно сравнивать варианты. Но ошибка многих компаний — покупать сервер только по красивому числу баллов. Один тест не заменяет анализ реальной нагрузки.

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

• однопользовательский — показывает скорость одного сеанса;
• многопользовательский — показывает поведение системы под нагрузкой.

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

• разницу между двумя конфигурациями;
• эффект после апгрейда;
• влияние замены дисков;
• просадку производительности со временем;
• реакцию системы при росте числа пользователей.

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

• качество вашей сети;
• ошибки пользователей;
• неудачные доработки конфигурации;
• специфику конкретных отчётов;
• реальные блокировки в рабочей базе.

Сервер может показать хорошие баллы и всё равно раздражать сотрудников в ежедневной работе.

Сами по себе баллы мало что значат. Польза появляется только в сравнении:

• до и после апгрейда;
• HDD против NVMe;
• 32 ГБ RAM против 64 ГБ;
• старый сервер против нового.

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

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

Хороший сервер для 1С — не обязательно самый дорогой. Это тот, который выдерживает вашу нагрузку сегодня, даёт запас на рост завтра и не превращается в источник ежедневных проблем.

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

Можно ли запустить 1С на обычном компьютере без выделенного сервера?

Можно, но обычно это временная схема для 1–3 пользователей.

Как часто нужно делать резервные копии базы 1С?

Минимум ежедневно. Для активной базы — чаще.

Что лучше для 1С: MS SQL Server или PostgreSQL?

Обе СУБД подходят. Важнее квалификация администратора.

Сколько оперативной памяти достаточно для сервера 1С на 20 пользователей?

Часто начинают с 64 ГБ. Для тяжёлых сценариев — 64–128 ГБ.

Нужен ли антивирус на сервере 1С?

Да, но каталоги базы и журналы обычно исключают из realtime-проверки.

Какой главный совет при выборе сервера для 1С?

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