Администрирование · 11 мин
Бэкап 1С: какой формат выбрать и как правильно его сделать
Разбираем форматы резервных копий 1С: выгрузка в DT, дамп SQL-базы, архив каталога. Чем отличаются, когда какой использовать и как проверить восстановление.
Вопрос о формате резервной копии 1С возникает у каждого администратора и бухгалтера рано или поздно — обычно в момент, когда базу уже нужно срочно восстановить. На практике используются три основных подхода: выгрузка информационной базы в файл с расширением .dt через конфигуратор, резервное копирование средствами СУБД (для клиент-серверных баз) и простое копирование каталога файловой базы. У каждого способа есть свои ограничения, и выбор зависит от режима работы базы, её размера и требований к скорости восстановления.
Главное правило, которое стоит усвоить сразу: формат бэкапа определяется не личными предпочтениями, а архитектурой вашей системы. Файловая база (один файл 1Cv8.1CD в папке) и клиент-серверная база на MS SQL, PostgreSQL или Oracle копируются принципиально по-разному. Ошибка в выборе метода приводит к тому, что копия либо не создаётся, либо оказывается непригодной для восстановления.
Отдельная проблема — регулярная выгрузка данных через обработки вида «выгрузить в XML» или «сохранить в Excel». Это не резервное копирование, а перенос части данных. Такой файл не содержит конфигурацию, настройки и полную структуру базы, поэтому восстановить из него рабочую систему невозможно.
Какие форматы резервных копий существуют в 1С
Под «форматом бэкапа 1С» обычно понимают один из четырёх вариантов. Первый — файл .dt, который создаётся через пункт «Администрирование → Выгрузить информационную базу» в конфигураторе. Это фирменный формат платформы 1С: он содержит и данные, и конфигурацию, и не зависит от того, какая СУБД используется. Второй вариант — прямое копирование файла 1Cv8.1CD для файловых баз, по сути побайтовая копия базы.
Третий вариант — резервная копия средствами СУБД: файл .bak для MS SQL Server, дамп, созданный через pg_dump, для PostgreSQL. Четвёртый — ZIP- или RAR-архив, в который упаковывают любой из перечисленных файлов для экономии места. Архивация — это не отдельный формат, а способ хранения: распаковать архив можно всегда, а вот превратить его содержимое в рабочую базу зависит от того, что лежит внутри.
Сравнение форматов
Универсален, переносится между СУБД и платформами. Требует монопольного доступа, медленный на больших базах.
Быстро и просто, но только для файлового режима. Копировать можно только при закрытых сеансах, иначе файл будет в несогласованном состоянии.
Стандарт для клиент-серверных баз. Быстрый, поддерживает расписание и инкрементальные копии, но привязан к конкретной СУБД.
Экономит место и упрощает хранение. Сам по себе не является бэкапом — важно, что за файл лежит внутри.
Выгрузка в DT: когда это правильный выбор
Формат DT — штатный механизм платформы, и это единственный способ, который одинаково работает и для файловых, и для клиент-серверных баз. Чтобы создать выгрузку, откройте конфигуратор, выберите «Администрирование → Выгрузить информационную базу» и укажите путь к файлу. Платформа сформирует единый файл, содержащий конфигурацию, все данные и служебную информацию.
У DT есть существенное ограничение: выгрузка требует монопольного доступа к базе. Все пользователи должны выйти, фоновые задания — завершиться. На большой базе (десятки гигабайт) процесс может занять часы, и всё это время работа с системой невозможна. Поэтому для крупных клиент-серверных баз DT используют не как ежедневный бэкап, а как инструмент миграции: переноса базы на другую СУБД, другую версию платформы или создания копии для тестирования.
Ещё одно достоинство DT — переносимость. Загрузить такой файл можно в базу на любой поддерживаемой СУБД и даже в файловый режим. Если вы планируете переезд с файловой базы на PostgreSQL или обратно, выгрузка/загрузка через DT — стандартный путь.
Копирование файловой базы: простота и её пределы
Файловая база 1С физически — это каталог, ключевой элемент которого — файл 1Cv8.1CD. Скопировав этот файл (а лучше весь каталог), вы получаете полноценную резервную копию. Многие организации настраивают простой скрипт, который ночью копирует файл в сетевую папку или облачное хранилище и упаковывает его в архив.
Критическое условие: во время копирования с базой никто не должен работать. Если пользователь в момент копирования проводит документ, файл окажется в несогласованном состоянии — часть данных запишется до копирования, часть после. Такая копия может открыться, но содержать логические повреждения, которые проявятся позже. Поэтому копирование делают либо ночью при гарантированном отсутствии сеансов, либо с принудительным завершением соединений.
Бэкап клиент-серверной базы средствами СУБД
Если база работает на MS SQL Server, PostgreSQL или другой СУБД, правильный формат резервной копии — штатный бэкап этой СУБД. Для MS SQL это задача «Back Up Database» в SQL Server Management Studio, создающая файл .bak; для PostgreSQL — утилита pg_dump или pg_basebackup. Такие копии создаются быстро, не требуют выгона пользователей (СУБД обеспечивает согласованность на уровне транзакций) и легко ставятся на расписание.
Дополнительное преимущество — поддержка разностных и инкрементальных копий, а также копий журнала транзакций. Это позволяет восстановить базу не только на момент ночного бэкапа, но и на любую минуту в течение дня, что критично для учётных систем. Настройка требует базовых навыков администрирования СУБД, но однажды настроенный план обслуживания работает без вмешательства.
BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_full.bak' WITH COMPRESSION, CHECKSUM;Важно понимать: бэкап СУБД привязан к конкретной СУБД и её версии. Восстановить BAK-файл MS SQL в PostgreSQL нельзя. Если нужен перенос между разными СУБД — используйте выгрузку в DT. Также помните, что кластер 1С хранит часть служебных настроек (список баз, параметры) отдельно от самой базы данных, поэтому при полном восстановлении инфраструктуры их нужно сохранять тоже.
Как проверить, что бэкап рабочий
Бэкап, который ни разу не проверяли восстановлением, нельзя считать бэкапом. Файл может быть битым, обрезанным при копировании или созданным в момент активных транзакций. Минимальная проверка — периодическое восстановление копии в тестовую базу: загрузка DT через «Загрузить информационную базу», подключение скопированного каталога как новой файловой базы или restore BAK-файла на тестовом сервере.
После восстановления откройте базу в режиме предприятия, сверьте ключевые показатели (например, обороты за последний месяц) с рабочей базой и выполните тестирование и исправление в конфигураторе для файловой копии. Только такой цикл «создал — восстановил — проверил» даёт уверенность, что в критической ситуации копия действительно спасёт.
Как проверить качество копии
Размер сопоставим с предыдущими копиями, файл открывается архиватором или платформой
Размер резко меньше обычного или равен нулю — копия оборвалась
База загружается, открывается в режиме предприятия, данные на месте
Ошибка при загрузке или пустые таблицы — копия непригодна
Копия сделана в период без активных сеансов
В логах видны активные пользователи в момент копирования файловой базы
Частые ошибки при организации резервного копирования
Самая распространённая ошибка — хранение бэкапов на том же диске, где лежит рабочая база. При отказе диска, шифровальщике или случайном удалении папки теряется и база, и все её копии. Копии должны уходить минимум на другое физическое устройство, а лучше — в отдельное хранилище или облако. Вторая типичная ошибка — отсутствие ротации: диск с бэкапами переполняется, скрипт падает, и об этом узнают только когда копия понадобилась.
Какой формат выбрать: краткий маршрут решения
Итоговая логика выбора проста. Файловая база небольшого размера — регулярное копирование каталога по расписанию плюс периодическая выгрузка в DT для надёжности. Клиент-серверная база — полный бэкап средствами СУБД ежедневно плюс копии журнала транзакций в течение дня. Перенос между платформами, СУБД или создание тестовой копии — всегда DT. В любом случае копии хранятся отдельно от рабочей базы и регулярно проверяются восстановлением.
Как выбрать формат
Что важно запомнить
Формат бэкапа 1С зависит от режима работы: файловая база копируется как файл или выгружается в DT, клиент-серверная — средствами СУБД. DT универсален, но требует монопольного доступа. Любая копия должна храниться отдельно от базы и периодически проверяться восстановлением.
Частые вопросы
Чем DT отличается от обычной выгрузки данных в XML?
DT — это полный снимок информационной базы: конфигурация, все данные, пользователи и настройки в одном файле, из которого базу можно полностью восстановить. Выгрузка в XML через обработки переноса — это только часть данных по определённым правилам. Из XML-файла рабочую систему восстановить нельзя, он предназначен для переноса данных между базами.
Можно ли загрузить DT от файловой базы в клиент-серверную?
Да, это одно из главных преимуществ формата. Создайте пустую базу на сервере 1С, откройте её в конфигураторе и выполните «Загрузить информационную базу». Единственное условие — версии платформы на источнике и приёмнике должны быть совместимы, обычно рекомендуется одинаковый релиз.
Нужно ли останавливать работу пользователей для бэкапа?
Для выгрузки в DT и копирования файла 1Cv8.1CD — да, обязательно, иначе копия будет несогласованной. Для бэкапа средствами СУБД — нет: MS SQL и PostgreSQL создают согласованную копию на лету без блокировки работы пользователей.
Сколько копий и как долго хранить?
Универсального норматива нет, но разумный минимум — ежедневные копии за последнюю неделю, еженедельные за месяц и ежемесячные за более длительный срок. Глубина хранения зависит от того, как быстро в вашей организации обнаруживают ошибки в данных: если ошибку могут заметить через месяц, копия за этот месяц должна существовать.
Что делать, если DT-файл не загружается с ошибкой?
Сначала проверьте, что файл скопирован полностью и его размер совпадает с исходным. Убедитесь, что версия платформы не ниже той, на которой делалась выгрузка. Если ошибка повторяется, попробуйте загрузку на другом компьютере и проверьте диск на ошибки. Если копия единственная и не читается — восстановить из неё базу, скорее всего, не удастся, что ещё раз подчёркивает необходимость нескольких независимых копий.