Администрирование · 11 мин
Что такое бэкап 1С и как его правильно настроить
Что такое бэкап 1С простыми словами: виды резервных копий, как сделать выгрузку DT и SQL-копию, где хранить файлы и как проверить восстановление базы.
Бэкап 1С — это резервная копия информационной базы, которая позволяет восстановить данные после сбоя оборудования, ошибочного удаления документов, повреждения файлов или неудачного обновления конфигурации. Без актуальной копии потеря базы означает потерю всей учётной истории: документов, справочников, остатков и проводок, накапливавшихся годами.
Особенность резервного копирования в 1С в том, что существует несколько принципиально разных способов создания копий, и они не взаимозаменяемы. Файловая база и клиент-серверная база под управлением MS SQL или PostgreSQL копируются по-разному, и выбор неправильного метода — одна из главных причин, почему «регулярный бэкап» в критический момент оказывается непригодным для восстановления.
Ниже разобраны виды резервных копий, способы их создания, правила хранения, типичные ошибки и порядок проверки того, что копия действительно восстанавливается.
Что именно входит в резервную копию 1С
Информационная база 1С хранит в себе всё сразу: данные (документы, справочники, регистры) и конфигурацию (программный код, формы, отчёты). Поэтому полноценный бэкап — это копия базы целиком, а не только «проводок» или «номенклатуры». Восстановив такую копию, вы получаете базу в том состоянии, в котором она была на момент копирования.
Важно понимать, чего в бэкап обычно не входит. Внешние печатные формы и обработки, подключённые как файлы на диске, вложения, хранящиеся в томах на файловой системе, а также настройки самого сервера 1С — всё это лежит вне информационной базы и копируется отдельно. Если организация хранит сканы документов в присоединённых файлах с размещением в томах, нужно резервировать и эти каталоги.
Виды бэкапов 1С и когда какой использовать
Существует три основных способа резервного копирования, и у каждого своя область применения.
| Способ | Как создаётся | Когда подходит | Ограничения |
|---|---|---|---|
| Выгрузка в .dt | Конфигуратор → Администрирование → Выгрузить информационную базу | Перенос базы, копия перед обновлением, архив на долгий срок | Требует монопольного доступа; на больших базах выполняется долго |
| Копирование файла 1Cv8.1CD | Копирование файла базы средствами ОС | Быстрый бэкап файловой базы | Нельзя копировать, пока с базой работают пользователи |
| Бэкап средствами СУБД | План обслуживания в MS SQL, pg_dump для PostgreSQL | Регулярное копирование клиент-серверных баз | Требует навыков администрирования СУБД; восстановление только на ту же СУБД |
Для файловой базы небольшой компании чаще всего достаточно регулярной выгрузки .dt плюс копирования файла базы. Для клиент-серверной базы основной инструмент — штатный бэкап средствами СУБД, а .dt используют как дополнительную страховку перед обновлениями.
Сравнение вариантов
Универсальный формат, независим от СУБД, но медленный на больших базах и требует монопольного доступа.
Быстро и просто, но только для файловых баз и только при отсутствии активных сеансов.
Выполняется «на горячую» без остановки работы, идеален для регулярного расписания, но привязан к конкретной СУБД.
Как сделать бэкап файловой базы через конфигуратор
Выгрузка в .dt — самый доступный способ, не требующий дополнительного ПО. Порядок действий:
- 1Попросите всех пользователей выйти из базы и проверьте отсутствие активных сеансов.
- 2Откройте базу в режиме Конфигуратор под учётной записью с административными правами.
- 3Выберите меню «Администрирование» → «Выгрузить информационную базу…».
- 4Укажите папку для сохранения и понятное имя файла, например с датой: buh_2026-05-15.dt.
- 5Дождитесь окончания выгрузки и проверьте, что файл появился и имеет ненулевой размер.
На больших базах выгрузка может занимать десятки минут и более, поэтому её планируют на нерабочее время. Прерывать процесс нельзя — файл при этом будет повреждён и не пригоден для восстановления.
Альтернатива для файловой базы — скопировать сам файл 1Cv8.1CD из каталога базы. Это быстрее, но копировать можно только при полностью закрытых сеансах: копирование файла, с которым кто-то работает, даёт битую копию без каких-либо предупреждений.
Бэкап клиент-серверной базы
Если база работает на MS SQL Server или PostgreSQL, копировать файлы данных вручную не нужно и опасно. Правильный путь — штатные средства СУБД: план обслуживания и задания бэкапа в MS SQL Server или утилита pg_dump / pg_basebackup для PostgreSQL. Такие копии создаются «на горячую», без выгона пользователей, и легко ставятся на расписание.
pg_dump -U postgres -F c -f /backup/erp_base_$(date +%F).dump erp_baseДля клиент-серверных баз выгрузка .dt тоже применяется, но вспомогательно: перед обновлением конфигурации, при переносе базы на другую СУБД или для передачи копии разработчику. Основным ежедневным бэкапом её делать не стоит — на больших базах это слишком долго и требует монопольного доступа.
Отдельно позаботьтесь о копировании журнала транзакций или настройке differential/incremental-копий, если допустимая потеря данных мала. Полный бэкап раз в сутки означает, что при вечернем сбое вы потеряете целый рабочий день ввода документов.
Как часто делать копии и где их хранить
Частота определяется простым вопросом: сколько данных вы готовы потерять и ввести заново. Если допустима потеря одного дня — достаточно ежедневной копии. Если вводятся сотни документов в час, нужны копии несколько раз в день или бэкап журнала транзакций.
Классическое правило хранения — «3-2-1»: минимум три копии данных, на двух разных носителях, одна — вне основного помещения (другой офис, облачное хранилище). Бэкап, лежащий на том же диске, что и база, не защищает ни от отказа диска, ни от шифровальщика, ни от пожара.
Храните несколько поколений копий, а не одну последнюю. Повреждение данных или ошибочное удаление часто обнаруживается спустя дни, и тогда нужна копия недельной или месячной давности. Практичный минимум — ежедневные копии за неделю, еженедельные за месяц, ежемесячные за год.
Проверка бэкапа: как убедиться, что копия рабочая
Бэкап, который ни разу не восстанавливали, — это предположение, а не гарантия. Проверку выполняют на отдельной тестовой базе, чтобы не затронуть рабочую.
Как проверить результат
Загрузка завершается без ошибок, база открывается в режиме Предприятие
Ошибки при загрузке, сообщения о повреждении файла
Открываются ключевые отчёты (ОСВ, остатки), документы на месте, номенклатура читается
Пустые регистры, ошибки при формировании отчётов, отсутствие документов
Размер соотносится с размером базы и не скачет от копии к копии
Резкое уменьшение размера без причины — признак неполной выгрузки
Тестовое восстановление разумно делать регулярно — хотя бы раз в месяц, а также каждый раз после изменения схемы резервного копирования. Заодно вы отработаете саму процедуру восстановления, и в реальной аварии она не будет для вас незнакомой операцией под давлением.
Типичные ошибки и ограничения
Ещё одно ограничение, о котором забывают: файл .dt не является средством архивного хранения «навсегда». Загрузить очень старый .dt в современную платформу обычно можно, но конфигурация потребует обновления, и процесс может быть нетривиальным. Для долгосрочного архива имеет смысл хранить также дистрибутив платформы соответствующей версии.
Наконец, бэкап не заменяет защиту от ошибок пользователей. Если бухгалтер удалил нужный документ, восстановление всей базы из ночной копии вернёт документ, но откатит и всю работу за день. Поэтому регламент удаления данных и пометка на удаление вместо физического удаления — обязательное дополнение к резервному копированию.
Как выбрать действие
Удобно включать дату и время в имя файла копии и запретить перезапись: так проще найти нужную версию и исключается случайное уничтожение предыдущей копии. Также полезно вести простой журнал — когда сделана копия, куда положена, когда проверялась.
Итог
Что важно запомнить
Бэкап 1С — это копия всей информационной базы, и делать его нужно регулярно подходящим способом: .dt для файловых баз и переноса, средства СУБД для клиент-серверных. Храните несколько поколений копий на разных носителях, хотя бы одну — вне основного помещения, и регулярно проверяйте восстановление на тестовой базе.
Частые вопросы
Чем отличается файл .dt от файла 1Cv8.1CD?
1Cv8.1CD — это сам файл файловой базы, с которым работает платформа. Файл .dt — это выгрузка базы в переносимый формат, созданная через конфигуратор. Копию 1Cv8.1CD можно просто подключить обратно, а .dt нужно загрузить в пустую базу через «Загрузить информационную базу». При этом .dt универсальнее: его можно загрузить и в клиент-серверную базу.
Можно ли делать бэкап, пока пользователи работают в базе?
Выгрузку .dt и копирование файла файловой базы — нет, оба способа требуют отсутствия активных сеансов. А вот бэкап средствами MS SQL или PostgreSQL выполняется «на горячую», не мешая работе. Поэтому для баз, где нельзя останавливать работу, используют именно инструменты СУБД.
Как автоматизировать создание бэкапов?
Выгрузку .dt можно запускать из командной строки конфигуратора с параметрами и поставить в планировщик задач Windows. Для копирования файловой базы достаточно скрипта копирования по расписанию. Для клиент-серверных баз используют планы обслуживания MS SQL или cron-задания с pg_dump. В любом случае автоматизация должна включать контроль: уведомление об ошибке или проверку наличия свежего файла.
Сколько места нужно для хранения бэкапов?
Ориентируйтесь на размер базы, умноженный на количество хранимых копий. Выгрузка .dt обычно заметно меньше самой базы благодаря сжатию, но точное соотношение зависит от данных. Заложите запас на рост базы и периодически проверяйте, что на диске под копии остаётся свободное место — переполнение диска частая причина «тихого» прекращения бэкапов.
Как восстановить базу из файла .dt?
Создайте новую пустую информационную базу, откройте её в конфигураторе и выберите «Администрирование» → «Загрузить информационную базу…», указав файл .dt. После загрузки база будет полностью идентична той, из которой делалась выгрузка. Восстановление всегда выполняйте в новую базу, а не поверх рабочей, если не уверены в результате.
Нужен ли бэкап, если база работает в облаке у франчайзи или в 1С:Фреш?
В облачных сервисах резервное копирование обычно выполняет провайдер, но стоит уточнить условия: глубину хранения копий и порядок восстановления по запросу. Дополнительно разумно периодически выгружать собственную копию .dt — это защита и от ошибок самих пользователей, и от ситуаций, когда нужно быстро получить данные независимо от провайдера.