Эксперты в подборе IT-оборудования
Копию боевой клиент-серверной базы 1С делают средствами СУБД - MS SQL или PostgreSQL, а не средствами самой 1С. Выгрузка в .dt через конфигуратор для этого не годится: она требует монопольного доступа, то есть выгнать всех пользователей, и на базе в несколько сотен гигабайт растянется на часы. Средства СУБД снимают копию с работающей базы, никого не отключая.
Ниже - все рабочие способы и границы применимости каждого.
| Способ | Для какой базы | Чем делается | Когда подходит |
|---|---|---|---|
| Копирование каталога базы | файловая | проводник, скрипт, планировщик | сеансов нет, база небольшая |
Выгрузка в .dt | файловая и серверная | конфигуратор 1С | перенос базы, архив перед обновлением конфигурации |
| Средства СУБД | серверная | MS SQL или PostgreSQL | основной способ для боевой базы |
| Встроенный механизм конфигурации | файловая | сама 1С, по расписанию | небольшая база у одного-двух пользователей |
| Резервное копирование виртуальной машины | любая | гипервизор | дополнение к бэкапу базы, но не замена |
База 1С - это учёт, зарплата, склад и вся история операций. Её потеря останавливает компанию целиком, а не отдельный участок.
Сценарии, из-за которых базу теряют, в практике повторяются одни и те же. Пользователь провёл или удалил не тот документ, и обнаружилось это через неделю. Шифровальщик прошёл по сети и добрался до сетевой папки с базой. Вышел из строя диск или массив. Обновление конфигурации легло криво, и откатываться некуда. Ни один из этих случаев не решается «аккуратной работой» - решается только тем, что копия есть и её можно развернуть.
Отдельно про шифровальщиков, потому что это самый частый случай последних лет: они целенаправленно ищут и портят доступные по сети резервные копии. Копия, лежащая на том же сервере или в подключённой сетевой папке, от них не спасает. Про это - в разделе про хранение.
В типовых конфигурациях на управляемых формах есть встроенный механизм резервного копирования. Настраивается он в разделе «Администрирование», в подразделе, который в разных конфигурациях называется по-разному - «Настройки работы с файлами», «Резервное копирование» или «Обслуживание». Там задаётся расписание: ежедневно в заданное время либо при завершении работы последнего пользователя.
Штука полезная, но границы у неё жёсткие. Механизм рассчитан на файловые базы и делает ту же выгрузку, что и конфигуратор. Для базы в клиент-серверном варианте он либо недоступен, либо упирается в то же требование монопольного доступа. Поэтому для серверной базы его как основной способ не рассматривают - он годится как дополнительная страховка на небольшой базе.
Если база живёт на сервере и с ней работают несколько человек одновременно, идти надо в СУБД. Об этом следующие разделы.
Файловая база - это каталог, в котором лежит файл данных 1Cv8.1CD и рядом служебные файлы, включая журнал регистрации. Способа два.
Копирование каталога. Самый простой вариант: закрыть все сеансы 1С и скопировать папку базы целиком. Именно папку: если взять один 1Cv8.1CD, потеряется журнал регистрации и часть служебных данных. Проверить, что сеансов не осталось, надёжнее всего по отсутствию процессов 1cv8.exe и 1cv8c.exe на машинах пользователей: копирование файла, с которым кто-то работает, даёт битую копию, и узнаете вы об этом только при восстановлении.
Автоматизируется это обычным скриптом и планировщиком заданий - например, копированием в подпапку с датой в имени.
Выгрузка в .dt. Через конфигуратор, порядок описан ниже в отдельном разделе. Для файловой базы это нормальный вариант: выгрузка получается компактной и переносимой, а монопольный доступ на маленькой базе не проблема.
У файлового варианта есть общий предел: он не рассчитан на десяток одновременных пользователей. Если база выросла и в ней постоянно работают, разговор про резервное копирование обычно быстро переходит в разговор про переезд на клиент-серверную схему - и тогда бэкап решается по-другому.
Здесь главное правило: копию делает СУБД, а не 1С. У этого способа два принципиальных плюса. Пользователей отключать не нужно - база копируется на ходу. И копия получается согласованной на конкретный момент времени, со всеми незавершёнными транзакциями в корректном состоянии.
Сначала - модель восстановления базы, потому что от неё зависит, какие копии вообще возможны.
| Модель восстановления | Какие копии доступны | Что с журналом транзакций | Кому подходит |
|---|---|---|---|
| Полная (Full) | полная, разностная, копия журнала | растёт, пока не сделать копию журнала | боевая база, где важна каждая проведённая операция |
| Простая (Simple) | полная и разностная | обрезается автоматически | базы, где допустимо потерять изменения с последнего бэкапа |
Три типа копий работают в связке:
Типовое расписание для боевой базы выглядит так: полная копия раз в сутки ночью, разностная - несколько раз в течение дня, копия журнала - каждые 15-60 минут. Настраивается это планом обслуживания в SQL Server Management Studio (Management → Maintenance Plans) либо заданием агента SQL Server.
Главные грабли полной модели восстановления. Если модель полная, а копии журнала не делаются, файл журнала растёт неограниченно и рано или поздно съедает диск. Обнаруживается это обычно в тот момент, когда база встаёт с ошибкой нехватки места. Правило простое: выбрали полную модель - обязаны делать копии журнала по расписанию. Не готовы - переводите базу в простую модель осознанно, понимая, что восстановление на произвольный момент времени станет невозможным.
У PostgreSQL два принципиально разных подхода.
Логическая выгрузка - pg_dump. Формирует файл с содержимым базы. Удобна тем, что переносится между версиями и разворачивается по одной базе, а не кластером целиком. Минус - на больших объёмах выгрузка и особенно обратная загрузка идут долго, а согласованность держится за счёт длинной транзакции, что на нагруженной базе даёт свои эффекты.
Физическая копия - pg_basebackup. Снимает копию файлов кластера целиком. Работает быстрее на больших базах и служит основой для восстановления на момент времени.
Архивирование WAL. Журнал предзаписи (Write-Ahead Log) можно непрерывно складывать в архив. Вместе с физической копией это даёт восстановление на любой момент времени - аналог связки «полная копия плюс журнал» в MS SQL. Настраивается параметрами archive_mode и archive_command в конфигурации сервера.
На практике всё это редко собирают руками: берут готовую обвязку вроде pgBackRest или Barman, которая сама следит за расписанием, сроками хранения, проверкой целостности и умеет восстанавливать на заданный момент.
Обе СУБД умеют проверять целостность готовой копии, не разворачивая её. В MS SQL это RESTORE VERIFYONLY, в PostgreSQL - pg_verifybackup для физических копий. Проверку стоит включить прямо в задание резервного копирования: она ловит битые файлы сразу, а не в день аварии. Полноценную проверку разворачиванием это не заменяет, но отсекает самый обидный класс проблем.
Резервная копия виртуальной машины целиком - вещь полезная, но она не заменяет копию базы. Снимок работающей ВМ с активной СУБД может оказаться несогласованным, а восстановление отдельной базы или отдельного документа из образа виртуалки превращается в отдельный проект. Правильная схема - копия средствами СУБД плюс, отдельно, резервное копирование виртуальной машины на случай отказа всего узла.
Порядок такой:
buh_2026-08-03.dt..dt.Ограничения, о которых стоит знать до того, как выбирать этот способ основным:
Поэтому .dt - это хороший формат для переноса базы между серверами и для архива перед обновлением конфигурации, но плохой в роли ежедневного бэкапа боевой серверной базы.
Правильно сделанная копия, лежащая рядом с базой, защищает только от одного сценария из четырёх - от логической ошибки пользователя. От отказа массива, от пожара и от шифровальщика она не спасает.
Рабочий ориентир - правило 3-2-1: три копии данных, на двух разных типах носителей, одна из них - вне площадки. Для небольшой компании это выглядит просто: боевая база на сервере, ежедневные копии на отдельном сервере или NAS, и ещё одна копия, которая уезжает за пределы офиса или лежит на носителе, не подключённом к сети постоянно.
Отдельно про защиту от шифровальщика: копия должна быть недоступна на запись из-под учётной записи, которая работает в сети. Помогает всё, что разрывает эту доступность, - отдельные учётные данные у сервера копий, доступ только на добавление, снапшоты на стороне хранилища, отчуждаемый носитель. Копия в сетевой папке, доступной всем на запись, шифруется вместе с базой.
Срок хранения задают исходя из того, как быстро в компании замечают проблему. Ошибку, найденную через месяц, вчерашняя копия не исправит. Обычная схема - ежедневные копии за последнюю неделю-две, еженедельные за пару месяцев, ежемесячные за год. Старые копии при этом надо чистить по расписанию, иначе диск кончится в самый неподходящий момент - как это устроено на примере Proxmox, показано в статье про удаление старых резервных копий. Как под это подобрать сервер и объём дисков, разобрано отдельно: как выбрать сервер для бэкапов. Про то, чем полный бэкап отличается от разностного и инкрементного, - в разборе видов резервного копирования.
Порядок действий одинаков почти для любого сбоя.
RESTORE DATABASE в MS SQL с последующим применением разностной копии и журналов, либо pg_restore и разворачивание физической копии в PostgreSQL. Для файловой базы или .dt - конфигуратор, «Администрирование» → «Загрузить информационную базу».Копия, которую ни разу не разворачивали, копией не считается. Проверяйте восстановление на тестовом стенде хотя бы раз в квартал - именно на этой проверке выясняется, что задание падало последние два месяца, что в копии нет нужной базы или что пароль от архива никто не помнит.
Можно ли сделать копию серверной базы 1С, не выгоняя пользователей?
Да, и это основной способ. Средства СУБД - MS SQL или PostgreSQL - снимают копию с работающей базы. Отключать людей требует только выгрузка в .dt через конфигуратор.
Что лучше: выгрузка .dt или бэкап средствами СУБД?
Для боевой клиент-серверной базы - средства СУБД, без вариантов. Выгрузка .dt остаётся для переноса базы между серверами и для архива перед обновлением конфигурации.
Как часто делать копии?
Ориентир простой: спросите, сколько часов работы компания готова потерять. Если ответ «нисколько» - нужны копии журнала транзакций каждые 15-30 минут. Если «полдня» - хватит полной копии ночью и разностной в обед.
Почему файл журнала транзакций разросся на десятки гигабайт?
Классический случай: база в полной модели восстановления, а копии журнала не делаются. Журнал не обрезается, пока его не скопировали. Лечится настройкой регулярной копии журнала, а не разовым сжатием файла.
Куда девать копии, чтобы их не зашифровали вместе с базой?
На отдельный сервер или хранилище, доступ к которому не идёт из-под пользовательских учётных записей, плюс одна копия вне площадки. Сетевая папка, доступная всем на запись, шифруется вместе с базой.
Нужен ли отдельный сервер под резервные копии?
Для одной небольшой базы хватит сетевого хранилища. Как только копий становится несколько и появляются требования по срокам хранения, отдельная машина под бэкапы окупается быстро - и дисками подешевле, и тем, что не делит нагрузку с боевым сервером.
По теме: резервная копия данных: полное руководство · сервер баз данных SQL · толстый и тонкий клиент в 1С для терминального сервера
Нужен сервер под резервные копии 1С?
Инженеры ITTELO подберут конфигурацию под ваш объём баз и глубину хранения, соберут и протестируют сервер под нагрузку перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
