Как сделать серверную копию 1С

Копию боевой клиент-серверной базы 1С делают средствами СУБД - MS SQL или PostgreSQL, а не средствами самой 1С. Выгрузка в .dt через конфигуратор для этого не годится: она требует монопольного доступа, то есть выгнать всех пользователей, и на базе в несколько сотен гигабайт растянется на часы. Средства СУБД снимают копию с работающей базы, никого не отключая.

Ниже - все рабочие способы и границы применимости каждого.

Резервное копирование 1С: зачем нужно и как обезопасить информацию компании

База 1С - это учёт, зарплата, склад и вся история операций. Её потеря останавливает компанию целиком, а не отдельный участок.

Сценарии, из-за которых базу теряют, в практике повторяются одни и те же. Пользователь провёл или удалил не тот документ, и обнаружилось это через неделю. Шифровальщик прошёл по сети и добрался до сетевой папки с базой. Вышел из строя диск или массив. Обновление конфигурации легло криво, и откатываться некуда. Ни один из этих случаев не решается «аккуратной работой» - решается только тем, что копия есть и её можно развернуть.

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

Защитите данные 1С с помощью автоматического бэкапа

В типовых конфигурациях на управляемых формах есть встроенный механизм резервного копирования. Настраивается он в разделе «Администрирование», в подразделе, который в разных конфигурациях называется по-разному - «Настройки работы с файлами», «Резервное копирование» или «Обслуживание». Там задаётся расписание: ежедневно в заданное время либо при завершении работы последнего пользователя.

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

Если база живёт на сервере и с ней работают несколько человек одновременно, идти надо в СУБД. Об этом следующие разделы.

Создание резервной копии в файловом режиме

Файловая база - это каталог, в котором лежит файл данных 1Cv8.1CD и рядом служебные файлы, включая журнал регистрации. Способа два.

Копирование каталога. Самый простой вариант: закрыть все сеансы 1С и скопировать папку базы целиком. Именно папку: если взять один 1Cv8.1CD, потеряется журнал регистрации и часть служебных данных. Проверить, что сеансов не осталось, надёжнее всего по отсутствию процессов 1cv8.exe и 1cv8c.exe на машинах пользователей: копирование файла, с которым кто-то работает, даёт битую копию, и узнаете вы об этом только при восстановлении.

Автоматизируется это обычным скриптом и планировщиком заданий - например, копированием в подпапку с датой в имени.

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

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

Резервная копия 1С в клиент-серверном режиме работы

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

MS SQL Server

Сначала - модель восстановления базы, потому что от неё зависит, какие копии вообще возможны.

Три типа копий работают в связке:

• Полная - вся база целиком. База для всех остальных копий.
• Разностная - только то, что изменилось с последней полной. Делается быстро, занимает меньше места.
• Копия журнала транзакций - все операции с момента предыдущей копии журнала. Доступна только при полной модели восстановления и нужна ровно для одного: восстановиться на момент времени, а не на «вчерашнюю ночь».

Типовое расписание для боевой базы выглядит так: полная копия раз в сутки ночью, разностная - несколько раз в течение дня, копия журнала - каждые 15-60 минут. Настраивается это планом обслуживания в SQL Server Management Studio (Management → Maintenance Plans) либо заданием агента SQL Server.

Главные грабли полной модели восстановления. Если модель полная, а копии журнала не делаются, файл журнала растёт неограниченно и рано или поздно съедает диск. Обнаруживается это обычно в тот момент, когда база встаёт с ошибкой нехватки места. Правило простое: выбрали полную модель - обязаны делать копии журнала по расписанию. Не готовы - переводите базу в простую модель осознанно, понимая, что восстановление на произвольный момент времени станет невозможным.

PostgreSQL

У PostgreSQL два принципиально разных подхода.

Логическая выгрузка - pg_dump. Формирует файл с содержимым базы. Удобна тем, что переносится между версиями и разворачивается по одной базе, а не кластером целиком. Минус - на больших объёмах выгрузка и особенно обратная загрузка идут долго, а согласованность держится за счёт длинной транзакции, что на нагруженной базе даёт свои эффекты.

Физическая копия - pg_basebackup. Снимает копию файлов кластера целиком. Работает быстрее на больших базах и служит основой для восстановления на момент времени.

Архивирование WAL. Журнал предзаписи (Write-Ahead Log) можно непрерывно складывать в архив. Вместе с физической копией это даёт восстановление на любой момент времени - аналог связки «полная копия плюс журнал» в MS SQL. Настраивается параметрами archive_mode и archive_command в конфигурации сервера.

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

Проверка самой копии

Обе СУБД умеют проверять целостность готовой копии, не разворачивая её. В MS SQL это RESTORE VERIFYONLY, в PostgreSQL - pg_verifybackup для физических копий. Проверку стоит включить прямо в задание резервного копирования: она ловит битые файлы сразу, а не в день аварии. Полноценную проверку разворачиванием это не заменяет, но отсекает самый обидный класс проблем.

Чем не стоит подменять бэкап базы

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

Резервное копирование информационной базы программы «1С» в режиме «Конфигуратор»

Порядок такой:

1. Запустить 1С в режиме «Конфигуратор» - выбрать нужную базу в списке и нажать «Конфигуратор» вместо «1С:Предприятие».
2. В меню выбрать «Администрирование» → «Выгрузить информационную базу».
3. Указать путь и имя файла. Практика, которая экономит время потом: включать в имя название базы и дату, например buh_2026-08-03.dt.
4. Нажать «Сохранить» и дождаться завершения. На выходе получится файл с расширением .dt.

Ограничения, о которых стоит знать до того, как выбирать этот способ основным:

• Выгрузка требует монопольного доступа: все пользователи должны выйти из базы, иначе конфигуратор откажется начинать.
• Время растёт с объёмом базы. На нескольких десятках гигабайт это уже десятки минут, на сотнях - часы.
• Если в базе есть логические ошибки, выгрузка может завершиться неудачей именно тогда, когда копия нужнее всего.

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

Куда класть копии и по какому расписанию

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

Рабочий ориентир - правило 3-2-1: три копии данных, на двух разных типах носителей, одна из них - вне площадки. Для небольшой компании это выглядит просто: боевая база на сервере, ежедневные копии на отдельном сервере или NAS, и ещё одна копия, которая уезжает за пределы офиса или лежит на носителе, не подключённом к сети постоянно.

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

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

Как восстановить информацию в 1С после сбоя или повреждения базы данных

Порядок действий одинаков почти для любого сбоя.

1. Понять причину. Отказ диска, ошибка пользователя, некорректное обновление конфигурации, повреждение файлов базы. От этого зависит, из какой копии восстанавливаться: после ошибки пользователя нужна копия на момент до неё, после отказа железа подойдёт последняя.
2. Не трогать боевую базу. Первое, что делают перед восстановлением, - снимают копию текущего состояния, даже повреждённого. Иначе, если восстановление пойдёт не так, возвращаться будет некуда.
3. Восстановить на отдельной площадке. Разворачивать копию сразу поверх боевой базы - плохая идея. Восстановите на тестовом сервере или в отдельную базу, убедитесь, что данные на месте, и только потом переключайте пользователей.
4. Выполнить восстановление. Для серверной базы - средствами СУБД: RESTORE DATABASE в MS SQL с последующим применением разностной копии и журналов, либо pg_restore и разворачивание физической копии в PostgreSQL. Для файловой базы или .dt - конфигуратор, «Администрирование» → «Загрузить информационную базу».
5. Проверить целостность. В конфигураторе есть режим «Тестирование и исправление информационной базы» - он выявляет и устраняет логические ошибки. После восстановления его стоит прогнать хотя бы в режиме проверки.
6. Свериться с людьми. Бухгалтер за пять минут скажет, на месте ли последние документы. Это надёжнее любых технических проверок.

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

Можно ли сделать копию серверной базы 1С, не выгоняя пользователей?
Да, и это основной способ. Средства СУБД - MS SQL или PostgreSQL - снимают копию с работающей базы. Отключать людей требует только выгрузка в .dt через конфигуратор.

Что лучше: выгрузка .dt или бэкап средствами СУБД?

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

Как часто делать копии?
Ориентир простой: спросите, сколько часов работы компания готова потерять. Если ответ «нисколько» - нужны копии журнала транзакций каждые 15-30 минут. Если «полдня» - хватит полной копии ночью и разностной в обед.

Почему файл журнала транзакций разросся на десятки гигабайт?
Классический случай: база в полной модели восстановления, а копии журнала не делаются. Журнал не обрезается, пока его не скопировали. Лечится настройкой регулярной копии журнала, а не разовым сжатием файла.

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

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

По теме: резервная копия данных: полное руководство · сервер баз данных SQL · толстый и тонкий клиент в 1С для терминального сервера