Accounting base 1С: что это и как работает информационная база

Запрос «accounting base 1С» чаще всего означает одно из двух: либо пользователь ищет, что такое учётная (бухгалтерская) база данных в 1С, либо встретил англоязычный термин в документации, логах или при развёртывании 1С на сервере. В обоих случаях речь идёт об информационной базе 1С — центральном хранилище, где живут все документы, справочники, проводки и настройки конфигурации, например «1С:Бухгалтерия предприятия».

Понимание устройства этой базы важно не только программистам. Бухгалтеру это помогает объяснить IT-отделу, где лежат его данные и почему нельзя просто «скопировать папку» во время работы пользователей. Администратору — правильно выбрать режим работы, организовать резервное копирование и диагностировать проблемы с производительностью.

Ниже разберём, что именно называют accounting base в экосистеме 1С, чем файловая база отличается от клиент-серверной, какие СУБД поддерживаются, как безопасно обслуживать базу и какие ошибки приводят к потере данных.

Что такое информационная база 1С простыми словами

Информационная база — это совокупность всех данных, с которыми работает прикладное решение 1С:Предприятие. В неё входят не только сами записи (документы, элементы справочников, регистры бухгалтерии), но и конфигурация — описание структуры объектов, алгоритмов, форм и отчётов.

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

Важно отличать базу от платформы. Платформа 1С:Предприятие — это «движок» (клиентское приложение, сервер 1С), а информационная база — контент, с которым движок работает. Одна и та же платформа может обслуживать несколько независимых баз: например, бухгалтерию, зарплату и торговлю.

Файловый и клиент-серверный режимы: в чём разница

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

В файловом режиме вся база — один файл 1Cv8.1CD в каталоге на диске или сетевом ресурсе. Пользователи подключаются к нему напрямую. Это просто и дёшево, но имеет жёсткие ограничения: при росте числа одновременных пользователей и объёма данных возникают блокировки и замедления, а риск повреждения файла при сбоях сети или питания выше.

В клиент-серверном режиме данные хранятся в полноценной СУБД, а между пользователями и СУБД стоит сервер 1С:Предприятия. Такой вариант выдерживает десятки и сотни одновременных подключений, даёт более тонкое управление блокировками и правами, но требует лицензий на сервер 1С и СУБД, а также квалифицированного администрирования.

Какие СУБД используются для базы 1С

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

Наиболее распространены Microsoft SQL Server и PostgreSQL (включая специально адаптированные сборки для 1С). Также поддерживаются Oracle Database и IBM Db2. Каждая СУБД имеет свои особенности настройки: параметры памяти, модели восстановления, настройки изоляции транзакций — и от корректной настройки напрямую зависит скорость проведения документов и построения отчётов.

Важный нюанс: база 1С внутри СУБД имеет собственную структуру таблиц, генерируемую платформой. Изменять эти таблицы напрямую средствами SQL запрещено — это почти гарантированно приводит к рассогласованию данных и неработоспособности базы. Все операции должны выполняться через платформу или её штатные механизмы.

Как узнать, где находится база, и какой у неё режим

Самый простой способ — открыть окно запуска 1С (список информационных баз), выбрать нужную базу и нажать «Изменить». Мастер покажет тип расположения: «На данном компьютере или в локальной сети» (файловый режим с указанием каталога) или «На сервере 1С:Предприятия» (клиент-серверный режим с именем сервера и именем базы).

Изнутри сеанса режим можно определить через пункт меню «Сервис» / «О программе» либо программно: функция ИнформационнаяБазаФайловая() возвращает признак файлового режима, а строка соединения показывает тип СУБД и сервер.

СтрокаСоединения = СтрокаСоединенияИнформационнойБазы();
Если ИнформационнаяБазаФайловая(СтрокаСоединения) Тогда
	Сообщить("Файловый режим");
Иначе
	Сообщить("Клиент-серверный режим");
КонецЕсли;

Для клиент-серверной базы дополнительные сведения (версия СУБД, размер базы, активные сеансы) доступны в консоли кластера серверов 1С:Предприятия и средствами самой СУБД. Эти данные нужны при диагностике медленной работы и планировании обслуживания.

Резервное копирование и обслуживание учётной базы

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

Для файловой базы существует два подхода. Первый — выгрузка в файл .dt через конфигуратор (рекомендуемый способ: он сохраняет данные в независимом от режима формате). Второй — копирование каталога базы, но только при гарантированном отсутствии активных сеансов: копирование открытого файла даёт неконсистентную копию.

Для клиент-серверной базы основной инструмент — штатные средства СУБД (резервные копии MS SQL, pg_dump или pg_basebackup для PostgreSQL). Они позволяют делать «горячие» копии без остановки работы. Дополнительно рекомендуется периодическая выгрузка в .dt как страховка от логических повреждений.

1. 1
   Определите режим базы: файловый или клиент-серверный (окно запуска 1С, кнопка «Изменить»).
2. 2
   Для файловой базы настройте регулярную выгрузку в .dt по расписанию; для клиент-серверной — расписание бэкапов средствами СУБД.
3. 3
   Храните копии минимум на двух разных носителях, один — вне основного офиса или сервера.
4. 4
   Периодически выполняйте тестовое восстановление копии в отдельную базу и проверяйте, что она открывается и данные читаются.
5. 5
   Перед обновлением конфигурации обязательно делайте свежую копию и убеждайтесь, что она восстанавливается.

Типичные проблемы и ошибки при работе с базой

Первая группа проблем — повреждение файловой базы после аварийного завершения: отключения питания, обрыва сети, принудительного закрытия процесса. Признаки — ошибки «Файл базы данных повреждён», невозможность войти, пропавшие документы. Штатный инструмент диагностики — утилита chdbfl.exe из каталога платформы: она проверяет физическую целостность файла. Перед её запуском обязательно сделайте копию файла базы.

Вторая группа — деградация производительности. В файловом режиме это обычно следствие роста объёма и числа пользователей, размещения базы на медленном сетевом диске или работы антивируса, который сканирует файл базы при каждом обращении. В клиент-серверном — недостаток памяти у СУБД, неактуальная статистика, фрагментация индексов, длительные транзакции и блокировки.

Третья группа — ошибки обслуживания: отсутствие тестирования восстановления, хранение единственной копии на том же сервере, обновление конфигурации без бэкапа, прямое вмешательство в таблицы СУБД. Каждая из этих ошибок регулярно приводит к потере данных на практике.

Как выбрать режим и организовать работу

Выбор режима стоит делать по фактической нагрузке, а не по привычке. Если с базой одновременно работает небольшое число пользователей, объём данных умеренный и нет требований к работе 24/7 — файловый режим оправдан и дешевле. Если пользователей много, документооборот интенсивный, нужны регламентные задания и интеграции — переходите на клиент-серверный вариант.

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

Независимо от режима полезно вести учёт того, где лежит база, кто отвечает за копии и когда последний раз проверялось восстановление. Большинство потерь данных происходит не из-за сложных технических причин, а из-за того, что «бэкап вроде был, но никто не проверял».

Частые вопросы