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