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

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

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

Способ резервного копирования зависит от режима работы 1С: файловый вариант и клиент-серверный (на MS SQL Server, PostgreSQL и других СУБД) требуют разных подходов. Ниже разобраны оба сценария, правила расписания, хранения и проверки, а также типичные ошибки, из-за которых копии оказываются бесполезными именно в момент аварии.

Что именно нужно копировать в 1С

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

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

Бэкап файловой базы: выгрузка в dt

Штатный способ резервного копирования файловой базы — выгрузка в файл .dt через конфигуратор. Откройте базу в режиме «Конфигуратор», перейдите в меню «Администрирование» → «Выгрузить информационную базу», укажите путь и имя файла. Рекомендуется включать дату в имя файла, например Trade_2026-01-15.dt, чтобы копии не затирали друг друга.

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

Простое копирование файла 1Cv8.1CD средствами Windows допустимо только при гарантированном отсутствии активных сеансов. Если скопировать файл, пока с ним работают пользователи или фоновые процессы, копия может оказаться в несогласованном состоянии и не открыться. Выгрузка в dt надёжнее, так как платформа сама обеспечивает целостность данных при выгрузке.

1. 1
   Завершите работу всех пользователей и убедитесь, что сеансов нет
2. 2
   Откройте базу в режиме «Конфигуратор»
3. 3
   Выберите «Администрирование» → «Выгрузить информационную базу»
4. 4
   Укажите папку для хранения и имя файла с датой
5. 5
   Дождитесь завершения и проверьте, что файл создан и имеет заметный размер
6. 6
   Скопируйте файл на второй носитель или в сетевое хранилище

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

Для баз на MS SQL Server, PostgreSQL или другой поддерживаемой СУБД основным способом резервного копирования является штатный бэкап средствами самой СУБД. В MS SQL Server это задача Back Up Database (полная модель восстановления позволяет дополнительно копировать журнал транзакций и восстанавливать базу на произвольный момент времени). В PostgreSQL используется утилита pg_dump или физическое копирование с WAL-архивированием.

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

BACKUP DATABASE [TradeBase] TO DISK = N'D:\Backups\TradeBase_full.bak' WITH COMPRESSION, CHECKSUM;

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

Расписание и глубина хранения копий

Частота копий определяется допустимой потерей данных: спросите себя, за какой период вы готовы вводить документы заново. Для активно работающей базы разумный минимум — ежедневный бэкап. Для баз с небольшим числом операций допустимы копии 2–3 раза в неделю, но реже — уже риск.

Храните копии с разной глубиной: ежедневные — за последние 1–2 недели, еженедельные — за 1–2 месяца, ежемесячные — дольше. Это важно, потому что повреждение данных (например, ошибочное удаление документов) часто обнаруживают спустя дни, и самая свежая копия уже содержит ту же проблему. Глубокий архив позволяет откатиться к состоянию до ошибки.

Автоматизируйте процесс: для файловых баз — скрипт с запуском конфигуратора в пакетном режиме (параметры /DumpIB) через планировщик заданий Windows, для серверных — план обслуживания в СУБД. Ручной бэкап «когда вспомнили» рано или поздно превращается в отсутствие бэкапа.

Где хранить копии: правило независимости

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

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

Проверка восстановления и типичные ошибки

Единственный способ убедиться, что бэкап рабочий, — восстановить его. Раз в месяц разворачивайте свежую копию в тестовую базу: для dt — через «Загрузить информационную базу», для бэкапа СУБД — восстановлением в базу с другим именем. Откройте базу, проверьте, что отчёты строятся, а данные за последние дни на месте.

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

Частые вопросы о бэкапе 1С