Администрирование · 12 мин
Как правильно администрировать 1С: пошаговое руководство
Практическое руководство по администрированию 1С: пользователи и права, резервное копирование, обновления, журнал регистрации, производительность и типичные ошибки администраторов.
Администрирование 1С — это не разовая настройка после установки, а регулярный цикл работ: управление пользователями и правами, резервное копирование, контроль обновлений, мониторинг производительности и обслуживание базы. Ошибка в любой из этих зон приводит либо к потере данных, либо к остановке учёта, поэтому задачи администрирования нужно выполнять по регламенту, а не «по памяти».
Объём работ зависит от режима работы базы. В файловом варианте администратор отвечает за каталог базы, расписание копий и обновления платформы. В клиент-серверном варианте добавляются кластер серверов 1С, СУБД (обычно MS SQL Server или PostgreSQL), регламентные задания СУБД и разграничение ответственности между администратором 1С и администратором баз данных.
Ниже разобраны ключевые направления администрирования: от создания учётных записей до регламентного обслуживания. Материал ориентирован на типовые конфигурации на платформе 1С:Предприятие 8.3, но большинство принципов применимы и к более ранним версиям.
Управление пользователями и правами доступа
Первое правило — у каждого сотрудника должна быть персональная учётная запись, а не общий вход «Администратор» или «Бухгалтер». Общие учётные записи делают бессмысленным журнал регистрации: по нему невозможно установить, кто изменил документ или удалил данные. При увольнении сотрудника учётную запись не удаляют, а отключают (снимают флаг аутентификации), чтобы сохранить историю действий в документах.
Права назначаются по принципу минимума: пользователь получает только те роли, которые нужны для его работы. В типовых конфигурациях на БСП (Библиотека стандартных подсистем) это реализовано через профили групп доступа: вместо ручного подбора ролей администратор включает пользователя в готовый профиль — «Бухгалтер», «Менеджер по продажам», «Кладовщик». Полные права должны быть у одного-двух человек, и эти учётные записи не используются для повседневной работы.
Для защиты от подбора пароля включите в настройках конфигуратора или через консоль кластера требования к сложности паролей и ограничение на срок действия. Если пользователей много и есть домен, настройте аутентификацию операционной системы — это упрощает вход и централизует блокировку доступа при увольнении.
Резервное копирование: что, как и как часто
Резервная копия — единственная защита от потери данных при сбое диска, ошибочном обновлении или действиях сотрудника. Для файловой базы копия — это архив файла 1Cv8.1CD, сделанный при отсутствии активных сеансов, либо выгрузка в файл .dt через конфигуратор. Копирование файла 1CD «на живую», пока пользователи работают, даёт повреждённую копию — такой файл может не открыться именно тогда, когда он понадобится.
В клиент-серверном варианте копию делает средствами СУБД: для MS SQL Server — полный бэкап плюс бэкапы журнала транзакций, для PostgreSQL — pg_dump или физические копии с WAL-архивом. Выгрузка .dt в клиент-серверном режиме используется как дополнительная мера и для переноса базы, но не заменяет бэкапы СУБД: большая база выгружается и загружается часами.
Минимальный рабочий регламент: ежедневная копия, хранение копий за последние несколько недель, хотя бы одна копия вне основного сервера (другой диск, сетевое хранилище, облако). Периодически — например, раз в месяц — проверяйте восстановление копии на тестовой машине. Копия, восстановление которой никогда не проверялось, считается отсутствующей.
- 1Создайте на тестовом компьютере пустую базу или каталог
- 2Восстановите туда свежую копию (загрузите .dt или восстановите бэкап СУБД)
- 3Откройте базу в режиме предприятия и проверьте актуальность данных по последним документам
- 4Зафиксируйте дату проверки в журнале регламентных работ
Обновление платформы и конфигурации
Обновления делятся на обновления платформы (технологическая часть, ставится отдельным дистрибутивом) и обновления конфигурации (прикладная часть с учётной логикой). Обновлять нужно и то, и другое: платформа получает исправления ошибок и уязвимостей, конфигурация — изменения законодательства, форм отчётности и печатных форм.
Безопасный порядок такой: сначала разворачивается копия рабочей базы, на ней выполняется обновление конфигурации, затем проверяются ключевые операции — проведение документов, формирование регламентированной отчётности, обмены с другими системами. Только после успешной проверки обновление переносится на рабочую базу, причём обязательно после свежей резервной копии и в нерабочее время.
При обновлении платформы учитывайте совместимость: новая версия платформы должна поддерживаться вашей конфигурацией, а в клиент-серверном варианте версии платформы на сервере и у клиентов должны совпадать. Если база доработана, перед обновлением конфигурации выполните сравнение и объединение с анализом изменённых объектов — бездумное обновление «загрузкой конфигурации из файла» затрёт все доработки.
Журнал регистрации и контроль событий
Журнал регистрации фиксирует действия пользователей и системные события: входы, изменение данных, ошибки, работу регламентных заданий. Это основной инструмент расследования инцидентов: кто удалил документ, когда появилась ошибка обмена, почему ночью не выполнилось регламентное задание.
Настройте уровень регистрации осознанно. Фиксация всех событий без фильтра быстро раздувает журнал и замедляет систему; разумный минимум — ошибки, предупреждения, доступ и изменение данных. Журнал хранится в каталоге базы (файловый вариант) или в каталоге сервера (клиент-серверный); для больших баз полезно настроить сокращение журнала по расписанию с архивацией старых фрагментов.
Раз в неделю просматривайте журнал на предмет повторяющихся ошибок: единичная ошибка обмена может быть случайностью, а одна и та же ошибка каждую ночь — признак сломанного регламентного задания, о котором пользователи просто не сообщают.
Как проверить здоровье базы по журналу
Нет ошибок или единичные сбои с последующим успешным выполнением
Одно и то же задание падает каждый запуск
Редкие ошибки ввода пароля отдельными пользователями
Массовые неудачные входы с одного адреса — возможен подбор пароля
Отсутствуют или единичны
Регулярные взаимоблокировки и таймауты в рабочее время
Производительность и блокировки
Типичные жалобы — «1С тормозит» и «зависает при проведении». В файловом режиме основные причины — большой размер базы, медленный диск или сеть при размещении базы на файловом ресурсе, антивирус, сканирующий файл базы. Исключите каталог базы из проверки антивируса на всех машинах, разместите базу на быстром диске, а при росте числа пользователей выше нескольких человек планируйте переход на клиент-серверный режим.
В клиент-серверном варианте производительность определяется связкой «сервер 1С + СУБД»: настройками памяти СУБД, планами запросов, индексами и регламентным обслуживанием СУБД (обновление статистики, перестроение индексов). Управляемые блокировки в конфигурации снижают конфликты, но при ошибках в коде или нехватке индексов всё равно возникают взаимоблокировки — их видно в журнале регистрации и в консоли кластера.
Для диагностики используйте консоль кластера (список сеансов, соединений, блокировок), технологический журнал с замерами длительных запросов и штатные средства СУБД. Не пытайтесь «лечить» медленную работу увеличением таймаутов — это маскирует проблему, а не решает её.
Как выбрать действие при «тормозах»
Регламентное обслуживание базы
Регулярное обслуживание предотвращает деградацию базы. Для файловых баз раз в месяц или при подозрениях на проблемы запускайте «Тестирование и исправление» из конфигуратора — обязательно на копии или после свежего бэкапа, поскольку отдельные режимы исправления могут удалять повреждённые данные. Утилита chdbfl из комплекта платформы проверяет физическую целостность файла 1CD.
Для клиент-серверных баз обслуживание СУБД критичнее: регламентное обновление статистики и обслуживание индексов в MS SQL Server, autovacuum и периодический VACUUM/ANALYZE в PostgreSQL. Без этого запросы со временем начинают выполняться по неоптимальным планам, и база «тормозит» без видимой причины.
Отдельная задача — контроль роста. Размер базы растёт за счёт документов, хранимых файлов, версий объектов и журнала регистрации. Настройте сроки хранения версий объектов, периодически очищайте ненужные помеченные объекты через штатное удаление, следите за свободным местом на дисках с базой и бэкапами — переполнение диска СУБД приводит к аварийной остановке.
Границы самостоятельной работы и когда привлекать специалистов
Самостоятельно администратор без глубокого опыта 1С может безопасно выполнять: заведение пользователей и назначение профилей, настройку расписания бэкапов, просмотр журнала регистрации, установку обновлений на тестовую копию, запуск тестирования и исправления на копии. Эти операции обратимы или выполняются в изолированной среде.
К специалисту по 1С или администратору СУБД стоит обращаться при: повреждении базы и ошибках реструктуризации, настройке и оптимизации кластера серверов, хронических взаимоблокировках, миграции между СУБД или на новое оборудование, восстановлении после сбоя, когда штатная копия не разворачивается. Попытки «починить» такие проблемы методом проб на рабочей базе обычно увеличивают объём потерь.
Что важно запомнить
Ядро администрирования 1С — персональные учётные записи с минимальными правами, ежедневные проверяемые резервные копии, обновления через тестовую базу, регулярный просмотр журнала регистрации и плановое обслуживание базы и СУБД. Любые рискованные операции выполняются только после свежей копии и в нерабочее время.
Частые вопросы
Как часто нужно делать резервные копии базы 1С?
Минимум — ежедневно, при интенсивном вводе данных в клиент-серверном режиме добавляют бэкапы журнала транзакций с интервалом в часы или десятки минут. Частота определяется допустимым объёмом потери данных: сколько часов работы компания готова ввести повторно.
Чем выгрузка .dt отличается от бэкапа СУБД?
Файл .dt — это логическая выгрузка средствами платформы, удобная для переноса базы между серверами и СУБД. Бэкап СУБД — физическая копия, которая создаётся и восстанавливается значительно быстрее на больших базах и поддерживает восстановление на момент времени. В клиент-серверном режиме основным средством должен быть бэкап СУБД.
Можно ли обновлять конфигурацию, пока пользователи работают?
Типовые конфигурации поддерживают обновление с динамической установкой для части изменений, но безопасная практика — завершить сеансы, сделать копию и обновлять в монопольном режиме. Динамическое обновление не подходит для изменений структуры данных и может привести к ошибкам у пользователей со старым кэшем.
Что делать, если база 1С не открывается после сбоя электричества?
Не запускайте повторные попытки открытия подряд. Скопируйте файл базы (или сделайте копию на уровне СУБД) как есть, затем на копии выполните проверку физической целостности утилитой chdbfl для файловой базы и тестирование и исправление в конфигураторе. Если копия не восстанавливается — переходите к последнему проверенному бэкапу.
Когда файловую базу пора переводить на клиент-серверный режим?
Признаки перехода: одновременно работают больше нескольких пользователей, база выросла до нескольких гигабайт, регулярно возникают конфликты блокировок и жалобы на скорость, требуется доступ через веб-сервер или тонкий клиент извне. Переход выполняется выгрузкой .dt и загрузкой в базу на СУБД с последующей настройкой кластера.
Нужно ли отключать антивирус на сервере с 1С?
Полностью отключать защиту не требуется. Правильное решение — добавить в исключения антивируса каталоги базы, журнала регистрации, технологического журнала и служебные каталоги сервера 1С и СУБД. Постоянное сканирование этих файлов заметно замедляет работу и может вызывать конфликты доступа.