Резервное копирование базы 1С: от файловой до серверной

Самый надёжный бэкап файловой базы 1С — закрыть все сеансы и скопировать папку с файлом 1Cv8.1CD в другое место. Для серверной базы так нельзя: данные лежат в СУБД, и копию снимают средствами MS SQL или PostgreSQL. Третий способ, универсальный для обоих вариантов, — выгрузка информационной базы в файл .dt из конфигуратора.

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

Где лежат данные и что именно копировать

У 1С 8.3 два варианта хранения, и бэкап у них разный.

Файловая база. Все данные — в одном файле 1Cv8.1CD внутри каталога базы. Рядом лежат служебные файлы кэша и журнал регистрации. Путь к каталогу виден в окне запуска 1С: выделите базу в списке и посмотрите строку внизу — там полный путь вроде C:\Bases\Buh.

Клиент-серверная база . Конфигурация и данные хранятся в СУБД (MS SQL Server или PostgreSQL), а сервер 1С — это промежуточное звено. Файла 1Cv8.1CD здесь нет. Копировать «папку базы» бессмысленно: таблицы лежат внутри базы данных СУБД.

Отсюда простое правило:

• файловая база — копируем файлы или выгружаем .dt;
• серверная база — бэкап средствами СУБД или выгружаем .dt;
• .dt работает в обоих случаях, но подходит не для любого размера (об этом ниже).

Выгрузка информационной базы в файл .dt

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

Порядок:

1. Запустите базу в режиме Конфигуратор (в окне запуска выберите базу, затем «Конфигуратор»).
2. Меню Администрирование → Выгрузить информационную базу.
3. Укажите имя и папку для файла, нажмите «Сохранить».

Восстановление из .dt — там же: Администрирование → Загрузить информационную базу, выбрать файл .

Что важно знать про .dt:

• Для выгрузки и загрузки нужен монопольный доступ — все пользователи должны выйти. Если кто-то работает, конфигуратор выдаст список активных сеансов.
• Это «логическая» выгрузка: платформа читает данные объектами и пишет в файл. Для базы в несколько десятков гигабайт выгрузка идёт долго — часами, и может упасть по памяти.
• Поэтому .dt хорош для файловых баз и небольших серверных, а также для переноса базы между компьютерами и между файловым и серверным вариантом.

Для крупной серверной базы .dt как основной бэкап не годится — там нужны средства СУБД.

Копирование файловой базы на уровне файлов

Самый быстрый способ для файловой базы — просто скопировать файлы, пока в базе никто не работает .

1. Попросите всех выйти из базы (проверьте, что окон 1С не осталось).
2. Откройте каталог базы — путь берётся из окна запуска.
3. Скопируйте файл 1Cv8.1CD в другое место: на другой диск, в сетевую папку, в облако.

Достаточно одного файла 1Cv8.1CD — в нём и данные, и конфигурация. Служебные папки кэша (1Cv8FTxt, 1Cv8Log и подобные) копировать не нужно, журнал регистрации — по желанию.

Восстановление простое: закрываете базу, кладёте сохранённый 1Cv8.1CD обратно в каталог вместо текущего (текущий сначала переименуйте, не удаляйте). Или добавляете каталог с копией как новую базу в список.

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

Бэкап серверной базы средствами СУБД

Для клиент-серверного варианта копию снимают на уровне базы данных СУБД. Это основной и самый надёжный способ для крупных баз: он быстрый и не требует выгонять пользователей.

MS SQL Server. Копия делается командой BACKUP DATABASE или регламентным заданием (Maintenance Plan) в SQL Server Management Studio. Пример разовой копии:

BACKUP DATABASE [buh_base]
TO DISK = N'D:\SqlBackup\buh_base_full.bak'
WITH INIT, COMPRESSION;

Здесь buh_base — имя базы данных в SQL Server (не путь к базе 1С, а имя базы на сервере СУБД). Опция COMPRESSION сжимает файл копии, INIT перезаписывает прежний файл.

PostgreSQL. Для баз 1С чаще всего используют логическую выгрузку pg_dump:

pg_dump -U postgres -F c -f /var/backup/buh_base.dump buh_base

Флаг -F c создаёт сжатый формат, удобный для восстановления через pg_restore. Для очень больших баз вместо pg_dump применяют физический бэкап pg_basebackup с архивированием журналов WAL — это тема отдельной настройки на стороне PostgreSQL.

Восстановление — тоже средствами СУБД: RESTORE DATABASE в MS SQL, pg_restore в PostgreSQL. После восстановления базу данных подключают к кластеру 1С через консоль администрирования серверов.

Автоматизация регулярного бэкапа

Копия раз в неделю «когда вспомнил» — не стратегия. Бэкап должен делаться по расписанию сам.

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

"C:\Program Files\1cv8\8.3.24.1234\bin\1cv8.exe" DESIGNER /F "C:\Bases\Buh" /N "Админ" /P "пароль" /DumpIB "D:\Backup\buh_%date%.dt"

Разберём параметры:

• DESIGNER — запуск в режиме конфигуратора;
• /F — путь к каталогу файловой базы (для серверной используется /S сервер\база);
• /N и /P — имя пользователя и пароль;
• /DumpIB — выгрузить базу в указанный файл.

Этот .bat ставят в «Планировщик заданий» Windows на ночь. Номер версии платформы в пути (8.3.24.1234) подставьте свой — он виден в окне «О программе».

Серверная база — средства СУБД. Здесь расписание задаёт сама СУБД:

• MS SQL — регламентное задание (Maintenance Plan) или job в SQL Server Agent с нужным расписанием;
• PostgreSQL — запуск pg_dump через планировщик ОС (cron в Linux, «Планировщик заданий» в Windows).

Независимо от способа держитесь правила 3-2-1: три копии, на двух разных носителях, одна — вне офиса (сетевое хранилище или облако). Локальная копия на том же диске, где и база, не спасёт при отказе диска.

Сколько копий хранить и когда их делать

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

Поэтому хранят несколько поколений копий. Рабочая схема для небольшой фирмы:

• ежедневная копия — за последние 7 дней;
• еженедельная — за последний месяц (например, копия каждого воскресенья);
• ежемесячная — за последний год.

Старые копии при этом удаляются автоматически, чтобы не забить диск. В пакетном .bat для этого подставляют в имя файла дату (buh_%date%.dt) и отдельной командой чистят файлы старше N дней.

Два параметра, от которых пляшет вся схема:

• За какой период не жалко потерять данные. Если допустимо потерять день работы — бэкап раз в сутки. Если даже час простоя дорог — чаще, вплоть до копий в течение дня.
• Как быстро нужно восстановиться. От этого зависит, где держать копии: локальная копия разворачивается за минуты, выгрузка из облака — дольше.

Отдельно держите копию перед каждым обновлением конфигурации и перед любым массовым изменением данных (групповая перепроводка, обработки, свёртка базы). Это не заменяет регламентный бэкап, а страхует конкретную рискованную операцию.

Восстановление из копии и проверка целостности

Бэкап, который ни разу не разворачивали, — это надежда, а не копия. Проверять восстановление нужно заранее, а не в день аварии.

Восстановление по типам копий:

Проверка целостности файловой базы. Если база повреждена или вы сомневаетесь в копии, проверьте её утилитой chdbfl.exe — она лежит в каталоге bin платформы. Утилита проверяет физическую целостность файла 1Cv8.1CD и может исправить часть ошибок (поставьте галку «Исправлять обнаруженные ошибки»). Перед проверкой с исправлением сделайте копию файла.

Логическая проверка. Для проверки структуры и логики данных есть штатный механизм: Конфигуратор → Администрирование → Тестирование и исправление. Он проверяет логическую целостность, ссылки, пересчитывает итоги. Запускают в монопольном режиме и обязательно на копии, а не на боевой базе первым заходом.

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