Перезапуск сервера 1С 8.3 без потери данных: Windows, Linux, кластер и виртуалки
Содержание
Чтобы перезапустить сервер
1С:Предприятие 8.3, перезапускают службу агента сервера: в Windows это служба 1C:Enterprise 8.3 Server Agent (x86-64) в оснастке services.msc, в Linux — юнит srv1cv8-<версия>@default через systemctl restart (на старых установках — service srv1cv83 restart). Агент при остановке гасит менеджер кластера и все рабочие процессы, а при запуске поднимает их заново.
Способов несколько, и выбирают их по ситуации. Оснастка «Службы» — для разового перезапуска руками. Командная строка и PowerShell — когда сервер нужно перезапустить удалённо или по расписанию. Полная перезагрузка Windows или виртуальной машины — только если зависла сама ОС или после установки обновлений. В любом случае все пользователи будут отключены, а несохранённые документы потеряются — поэтому перезапуск делают вне рабочего времени или после предупреждения.
Когда серверу 1С нужен перезапуск
Перезапуск — не лечение от всего. Он помогает, когда проблема сидит в памяти процессов сервера, а не в базе или настройках.
Типичные поводы:
- 🐢 Рабочий процесс раздулся по памяти.
rphostзанимает гигабайты, всё тормозит, хотя нагрузка обычная. - 🔒 «Висят» сеансы. Пользователь давно закрыл программу, а в консоли кластера его сеанс жив и держит лицензию или блокировку.
- 🧩 Ошибки кэша сеансовых данных. Странные сбои при входе в базу, которые проходят после очистки каталогов
snccntx. - ⬆️ Обновлена платформа на сервере. Новая версия начинает работать только после перерегистрации и запуска службы новой версии.
- 🔑 Сменили лицензии. Активировали программную лицензию или подключили новый ключ защиты.
- ⚙️ Изменили параметры кластера или рабочего сервера. Часть настроек, например диапазон портов, применяется только после перезапуска.
Когда перезапуск не поможет: база повреждена, не хватает места на диске СУБД, ошибка в коде конфигурации, нет сети до сервера. Если ошибка повторяется сразу после перезапуска — ищите причину в логах, а не перезапускайте второй раз.
Подготовка к перезапуску сервера 1С
Пять минут подготовки избавят от звонков «у меня всё пропало». Главное — чтобы в момент остановки никто не проводил документы и не шло обновление базы.
- Узнайте, кто работает. Откройте
Администрирование серверов 1С Предприятия, раскройте кластер →Информационные базы→ нужная база →Сеансы. Из командной строки то же самое показываетrac session list --cluster=<id кластера>. - Предупредите пользователей. Письмом или в мессенджере, с точным временем и длительностью простоя.
- Заблокируйте вход. В свойствах информационной базы в консоли кластера включите
Блокировка начала сеансов включена, задайте время и сообщение. В типовых конфигурациях то же делается из программы:Администрирование → Обслуживание → Блокировка работы пользователей. - Остановите регламентные задания. В тех же свойствах базы — флажок
Блокировка регламентных заданий включена. Иначе обмен или загрузка выписок могут оборваться посередине. - Сделайте резервную копию, если перезапуск связан с обновлением платформы или правкой настроек кластера. Для простого перезапуска при «распухшей» памяти копия не обязательна: данные хранятся в СУБД, и остановка службы их не трогает.
Блокировка сеансов в консоли не выгоняет тех, кто уже вошёл, — она только не пускает новых. Работающих пользователей программа предупредит и завершит их сеансы через заданное время, если блокировку включали из самой конфигурации.
Как перезапустить сервер 1С на Windows
Сервер 1С под Windows работает как служба. Отдельно перезапускать менеджер кластера (rmngr) или рабочие процессы (rphost) не нужно — агент (ragent) управляет ими сам.
Через оснастку «Службы»
- Нажмите
Win + R, введитеservices.msc. - Найдите службу
1C:Enterprise 8.3 Server Agent (x86-64). Если на сервере стоит несколько версий платформы, в имени может быть указан номер версии — выбирайте ту, что запущена. - Правой кнопкой →
Перезапустить. Или по очередиОстановитьиЗапустить. - Подождите 20–60 секунд и проверьте, что служба в состоянии «Выполняется».
Из командной строки и PowerShell
Сначала узнайте точное имя службы — на разных серверах оно различается:
Get-Service | Where-Object { $_.DisplayName -like "*1C*" }
Затем перезапустите:
Restart-Service -Name "1C:Enterprise 8.3 Server Agent (x86-64)" -Force
В классической командной строке (запуск от имени администратора):
net stop "1C:Enterprise 8.3 Server Agent (x86-64)"
net start "1C:Enterprise 8.3 Server Agent (x86-64)"
Если служба зависла в состоянии «Остановка», проверьте, остались ли процессы:
tasklist | findstr /I "ragent rmngr rphost"
Принудительное завершение taskkill /IM rphost.exe /F обрывает транзакции прямо в момент записи. Делайте это только если служба не останавливается больше 5 минут и все пользователи уже отключены.
Перезапуск с очисткой кэша сеансовых данных
Это главный приём администраторов при «необъяснимых» ошибках входа в базу. Кэш лежит в каталоге кластера srvinfo, по умолчанию C:\Program Files\1cv8\srvinfo\reg_1541\.
- Остановите службу агента сервера.
- Убедитесь, что процессов
rphost,rmngr,ragentнет. - В каталоге
reg_1541переименуйте или удалите папкиsnccntx…(их может быть несколько, с длинным суффиксом). - Запустите службу.
Не трогайте файл 1CV8Clst.lst — это реестр кластера со списком баз и настроек. Без него кластер придётся собирать заново. Перед очисткой скопируйте весь каталог reg_1541 в сторону — пять секунд, а откатиться можно в любой момент.
Сервер администрирования RAS
Если для управления используется rac, на сервере работает ещё и служба RAS (ras.exe). Она не участвует в работе пользователей, но после перезапуска агента её тоже стоит перезапустить, иначе rac может отвечать ошибкой подключения.
Перезапуск сервера 1С на Linux
На Linux порядок зависит от того, как ставили платформу. С версии 8.3.21 установщик кладёт systemd-юнит в каталог версии, а в более ранних версиях использовался init-скрипт.
| Платформа | Как найти службу | Команда перезапуска |
|---|---|---|
| 8.3.21 и новее | systemctl list-units | grep 1cv8 | sudo systemctl restart srv1cv8-8.3.xx.xxxx@default |
| До 8.3.21 (deb/rpm) | ls /etc/init.d/ | grep srv1cv8 | sudo service srv1cv83 restart |
Платформа 8.3.21 и новее
Юнит устроен как шаблон: в имени есть номер версии и экземпляр после @. Сначала найдите точное имя:
systemctl list-units --all | grep -i 1cv8
Затем перезапуск и проверка:
sudo systemctl restart srv1cv8-8.3.24.1467@default
sudo systemctl status srv1cv8-8.3.24.1467@default
Номер версии в примере условный — подставьте свой из вывода первой команды.
Старые установки с init-скриптом
sudo service srv1cv83 stop
sudo service srv1cv83 start
sudo service srv1cv83 status
Проверка, что сервер поднялся
pgrep -a ragent
pgrep -a rphost
ss -tlnp | grep -E '1540|1541'
Агент слушает порт 1540, менеджер кластера — 1541. Если портов нет в выводе, служба не стартовала — смотрите journalctl -u <имя юнита> -n 50.
Кэш сеансовых данных на Linux лежит в домашнем каталоге пользователя usr1cv8, обычно /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/. Очистка та же: остановить службу, убрать snccntx*, запустить. Файл 1CV8Clst.lst не трогать.
После ручной очистки проверьте владельца каталога: если запускали команды от root, новые файлы могут оказаться чужими для usr1cv8, и служба не стартует. Исправляется chown -R usr1cv8:grp1cv8 на каталог .1cv8.
Перезапуск кластера из нескольких серверов 1С
В кластере из нескольких рабочих серверов порядок важнее скорости. Один из серверов — центральный: на нём живёт реестр кластера, через него клиенты узнают, куда подключаться.
Порядок для планового перезапуска всего кластера:
- Включите блокировку сеансов и регламентных заданий во всех базах кластера.
- Перезапустите рабочие (нецентральные) серверы по одному. Дождитесь, пока каждый вернётся в консоли в нормальное состояние.
- Последним перезапустите центральный сервер.
- Проверьте в консоли, что все рабочие серверы видны и на них поднялись рабочие процессы.
- Снимите блокировки.
Если нужен перезапуск одного узла днём, без остановки работы, посмотрите параметры отказоустойчивости в свойствах рабочего сервера и требования назначения функциональности. При правильно настроенном резервировании сеансы переедут на другие серверы, но пользователи на перезапускаемом узле всё равно получат разрыв соединения.
Не меняйте местами центральный и рабочие серверы «на ходу» и не удаляйте рабочий сервер из кластера ради перезапуска. Это меняет реестр кластера, и при ошибке базы пропадут из списка.
Мягкая альтернатива полному перезапуску
Если проблема только в памяти рабочих процессов, можно не останавливать службу. В свойствах кластера есть параметры Интервал перезапуска (в секундах) и Допустимый объем памяти. Кластер сам поднимает новый рабочий процесс, переводит на него новые соединения, а старый гасит, когда тот освобождается. Пользователи этого почти не замечают.
Перезапуск сервера 1С в VMware и Hyper-V
На виртуальной машине перезапуск службы ничем не отличается от физического сервера. Особенности появляются, когда перезагружают саму ВМ.
- 🔌 Выключение гостевой ОС, а не «питания». В VMware используйте
Restart Guest OS(нужны VMware Tools), в Hyper-V —Завершение работычерез службы интеграции. ЖёсткийResetравен выдёргиванию шнура: СУБД может потом долго восстанавливаться. - 🔑 Программная лицензия привязана к параметрам машины. Смена числа процессоров, MAC-адреса сетевой карты, перенос ВМ на другой хост с другим оборудованием может сделать лицензию недействительной. После таких изменений сервер 1С стартует, но пользователи не войдут без повторной активации.
- 🗝️ USB-ключи защиты. Аппаратный ключ, проброшенный в ВМ, после перезагрузки хоста иногда «отваливается». Проверьте, видит ли его гостевая система и запущена ли служба менеджера лицензий Sentinel (
hasplms). - 📸 Снимки (snapshot/checkpoint). Откат ВМ к снимку вместо перезапуска откатит и базу данных, если СУБД на той же машине. Снимок — не способ «перезагрузить начисто».
- 🕒 Время. После восстановления ВМ из паузы часы гостя могут уйти. Расхождение времени между сервером 1С и СУБД даёт ошибки в регламентных заданиях — проверьте синхронизацию.
Если СУБД и сервер 1С на разных ВМ, перезагружайте сначала сервер 1С, потом СУБД, а поднимайте в обратном порядке: сначала СУБД, затем 1С.
Автоматический перезапуск по расписанию
Регулярный ночной перезапуск — костыль, но рабочий: он сдерживает утечки памяти, пока не найдена их причина. Прежде чем его ставить, попробуйте Интервал перезапуска из раздела про кластер — это мягче.
Windows: планировщик заданий
Сохраните скрипт, например C:\Scripts\restart-1c.ps1:
$svc = "1C:Enterprise 8.3 Server Agent (x86-64)"
Stop-Service -Name $svc -Force
Start-Sleep -Seconds 30
Start-Service -Name $svc
Add-Content -Path "C:\Scripts\restart-1c.log" -Value "$(Get-Date -Format s) $((Get-Service $svc).Status)"
И создайте задание на 3:30 каждую ночь от имени SYSTEM:
schtasks /Create /TN "Restart 1C Server" /TR "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\restart-1c.ps1" /SC DAILY /ST 03:30 /RU SYSTEM
Linux: cron или таймер systemd
Самый простой вариант — строка в sudo crontab -e:
30 3 * * * /usr/bin/systemctl restart srv1cv8-8.3.24.1467@default
Время перезапуска сверяйте с регламентными заданиями и резервным копированием. Перезапуск в момент ночного бэкапа СУБД или обмена с сайтом оборвёт их. И помните про версию в имени юнита: после обновления платформы строку в cron нужно поправить, иначе она будет перезапускать старую службу.
Если сервер 1С не поднимается после перезапуска
Чаще всего после перезапуска всплывает то, что уже было сломано, просто служба работала по инерции.
Полезные места для логов:
- Windows —
Просмотр событий → Журналы Windows → Приложение, источник с «1C» в названии. - Linux —
journalctl -u <имя юнита>и системный журнал. - Технологический журнал 1С, если он включён файлом
logcfg.xml: там видно, на каком шаге падает запуск.