Администрирование · 12 мин
Как сделать резервную копию 1С перед обновлением
Как сделать резервную копию 1С перед обновлением: выгрузка через конфигуратор, копирование файловой базы, SQL-бэкап, проверка восстановления и типичные ошибки.
Обновление конфигурации 1С — операция, которая изменяет структуру базы данных: добавляет реквизиты, пересчитывает итоги, конвертирует данные. Если процесс прервётся из-за отключения электричества, нехватки места на диске или ошибки в самом обновлении, база может остаться в повреждённом состоянии, из которого её уже нельзя открыть. Единственная защита от этого — актуальная резервная копия, сделанная непосредственно перед запуском обновления.
Способ резервного копирования зависит от того, как развёрнута ваша база: файловый вариант (папка с файлом 1Cv8.1CD на диске или сетевом ресурсе) или клиент-серверный (база на MS SQL Server, PostgreSQL или другой СУБД). Для файловой базы достаточно выгрузки через конфигуратор или копирования файла, для серверной нужны средства СУБД. Ниже разобраны все рабочие сценарии с проверкой результата.
Почему перед обновлением обязательна резервная копия
Обновление конфигурации — это не просто замена «программы», а реструктуризация базы данных. Платформа физически перестраивает таблицы, и если в этот момент произойдёт сбой, база окажется в промежуточном состоянии: часть таблиц уже нового формата, часть — старого. Откатить такое состояние штатными средствами невозможно.
Типичные причины неудачного обновления: нехватка свободного места на диске (реструктуризация больших таблиц требует временного пространства, сопоставимого с размером базы), разрыв сети при работе с сетевым ресурсом, пропуск промежуточных релизов, отключение электричества. Во всех этих случаях резервная копия — единственный способ вернуться к рабочему состоянию.
Важно понимать: копия, сделанная неделю назад, не равна копии перед обновлением. За неделю в базе появляются новые документы, проводки, справочники. Если придётся восстанавливаться из старой копии, эти данные придётся вносить заново вручную. Поэтому бэкап делают непосредственно перед запуском обновления, а не «когда-то раньше».
Подготовка: что сделать до создания копии
Перед выгрузкой убедитесь, что с базой никто не работает. Активные сеансы пользователей могут привести к тому, что копия окажется логически непротиворечивой, но неполной: документ, проводимый в момент копирования, может попасть в копию частично. Список активных сеансов виден в консоли кластера (для серверной базы) или через пункт «Администрирование → Активные пользователи» в режиме 1С:Предприятие.
Проверьте свободное место на диске. Файл выгрузки .dt обычно занимает заметно меньше размера базы за счёт сжатия, но для реструктуризации при обновлении понадобится дополнительное пространство. Ориентир — свободного места должно быть не меньше полутора-двух размеров базы.
Завершите фоновые и регламентные задания, которые могут изменять данные во время копирования: обмены с другими системами, загрузку курсов валют, полнотекстовое индексирование. Для этого в серверном варианте удобно временно заблокировать регламентные задания в свойствах базы в консоли кластера.
- 1Попросите пользователей выйти из базы и проверьте отсутствие активных сеансов
- 2Заблокируйте регламентные задания и обмены данными
- 3Проверьте свободное место на диске с базой и на диске для копии
- 4Создайте отдельную папку для копии с понятным именем, включающим дату и версию конфигурации
Способ 1: выгрузка базы через конфигуратор в файл .dt
Универсальный способ, который работает и для файловых, и для серверных баз. Откройте базу в режиме конфигуратора под пользователем с правами администратора. В меню выберите «Администрирование → Выгрузить информационную базу», укажите путь и имя файла с расширением .dt и дождитесь завершения выгрузки.
Файл .dt содержит и данные, и конфигурацию базы, поэтому из него можно полностью восстановить базу на любом компьютере через «Администрирование → Загрузить информационную базу». Это делает .dt самодостаточной копией, независимой от исходного расположения базы.
Ограничения способа: выгрузка больших баз занимает заметное время, а при загрузке .dt теряются некоторые специфические настройки — например, хранилище конфигурации и настройки журнала регистрации подключаются заново. Кроме того, выгрузка в .dt не подходит для баз с очень большим объёмом, где практичнее бэкап средствами СУБД.
Способ 2: копирование файла файловой базы
Если база файловая, самый быстрый вариант — скопировать файл 1Cv8.1CD из каталога базы. Узнать путь к каталогу можно в списке информационных баз при запуске 1С: он отображается в нижней части окна выбора баз. Также путь виден в конфигураторе через «Администрирование → Параметры информационной базы».
Обязательное условие: в момент копирования с базой никто не должен работать, иначе файл скопируется в несогласованном состоянии и может не открыться. При копировании по сети дополнительно убедитесь, что соединение стабильно — обрыв на середине многогигабайтного файла даст битую копию.
Копировать стоит весь каталог базы, а не только файл 1Cv8.1CD: рядом могут лежать служебные файлы и подкаталоги, например с полнотекстовым индексом. Для надёжности скопируйте каталог целиком и дополнительно заархивируйте его — архив занимает меньше места и проще переносится на внешний носитель.
Способ 3: резервное копирование серверной базы средствами СУБД
Для баз на MS SQL Server, PostgreSQL или другой СУБД штатный и самый быстрый способ — бэкап средствами самой СУБД. В MS SQL Server это делается через SQL Server Management Studio: правый клик по базе → «Задачи» → «Создать резервную копию», тип копии — «Полная». В PostgreSQL используется утилита pg_dump или pg_dumpall.
Бэкап СУБД выполняется быстрее выгрузки в .dt и не требует завершения всех сеансов (хотя для гарантированной согласованности перед обновлением пользователей всё равно лучше вывести). Восстановление выполняется средствами той же СУБД, после чего база снова доступна через сервер 1С.
Несмотря на наличие SQL-бэкапа, перед обновлением рекомендуется сделать и выгрузку в .dt: она пригодится, если нужно будет развернуть копию базы на другом сервере или в другой СУБД для разбора ситуации. Два независимых типа копий — стандартная практика перед рискованными операциями.
Сравнение способов копирования
Подходит для любых баз, создаёт переносимую копию. Ограничение — медленно на больших базах, требует монопольного доступа.
Самый быстрый вариант для файловых баз. Ограничение — только файловый режим и обязательное отсутствие пользователей.
Оптимален для серверных баз любого размера. Ограничение — требует доступа к СУБД и навыков администрирования.
Как проверить, что резервная копия рабочая
Копия, которая не проверена, — это не копия, а надежда. Минимальная проверка для .dt: создайте пустую информационную базу, зайдите в конфигуратор и выполните «Администрирование → Загрузить информационную базу», указав файл копии. Если загрузка завершилась без ошибок и база открывается в режиме предприятия, копия рабочая.
Для копии файловой базы добавьте скопированный каталог в список баз и откройте его. Проверьте, что открываются ключевые отчёты (например, оборотно-сальдовая ведомость) и данные выглядят актуальными: свежие документы на месте, итоги сходятся с рабочей базой.
Тестовое восстановление делайте на отдельной копии базы, а не поверх рабочей. Загрузка .dt полностью замещает содержимое базы, в которую загружается, — ошибка с выбором целевой базы уничтожит рабочие данные.
Как проверить результат
Файл .dt или архив существует, размер сопоставим с ожидаемым, дата изменения — сегодняшняя
Файл отсутствует, имеет нулевой размер или старую дату
Загрузка .dt или подключение каталога проходит без ошибок, база открывается
Ошибки при загрузке, сообщения о нарушении целостности
Последние документы и итоги совпадают с рабочей базой
Отсутствуют свежие документы, итоги расходятся
Типичные ошибки и ограничения
Самая частая ошибка — делать копию в ту же папку или на тот же диск, где лежит рабочая база. При сбое диска теряется и база, и копия. Храните резервную копию на другом физическом носителе: втором диске, сетевом хранилище или внешнем диске.
Вторая ошибка — путать выгрузку .dt с копированием каталога базы, в котором работают пользователи. Копирование «на живую» даёт файл, который может не открыться. Третья типичная проблема — начать обновление, не проверив копию, и обнаружить её неработоспособность уже после сбоя.
Отдельно стоит сказать об обновлении через интернет из режима 1С:Предприятие. В типовых конфигурациях перед установкой обновления программа предлагает создать резервную копию — не пропускайте этот шаг. Но даже встроенная копия не отменяет ручную выгрузку в .dt на отдельный носитель для критичных баз.
Что делать, если обновление пошло не так
Если обновление прервалось с ошибкой, не пытайтесь запускать его повторно поверх повреждённой базы и не выполняйте «Тестирование и исправление» до создания копии текущего состояния — эти действия могут усугубить повреждение. Сначала сохраните то, что осталось, затем восстановите базу из резервной копии.
Порядок отката: удалите повреждённую базу (или переименуйте её каталог), создайте пустую базу и загрузите в неё файл .dt, либо верните на место скопированный каталог файловой базы, либо восстановите базу из бэкапа СУБД. После восстановления проверьте, что база открывается и данные на месте, и только потом разбирайтесь с причиной неудачного обновления: нехваткой места, пропущенными релизами или ошибками в данных.
Если база большая, а обновление сложное (переход через несколько релизов, нестандартные доработки), безопаснее сначала выполнить обновление на копии базы. Это позволит отработать процедуру, замерить время реструктуризации и убедиться, что обновление проходит чисто, прежде чем повторять его на рабочей базе.
Что важно запомнить
Перед обновлением выведите пользователей, сделайте выгрузку в .dt (для серверной базы — ещё и бэкап СУБД), сохраните копию на другом носителе и проверьте её восстановление. Только после этого запускайте обновление.
Частые вопросы
Можно ли обновлять 1С без резервной копии, если база маленькая?
Технически — да, но размер базы не влияет на риск повреждения при сбое реструктуризации. Даже маленькая база содержит документы и справочники, восстановление которых вручную займёт неоправданно много времени. Выгрузка маленькой базы в .dt занимает минуты, поэтому экономить на ней нет смысла.
Чем отличается выгрузка в .dt от архивации через «Сохранить копию» в типовых конфигурациях?
Встроенная функция резервного копирования в типовых конфигурациях по сути выполняет ту же выгрузку в файл .dt, но делает это из режима предприятия и может сохранять копии по расписанию. Разница в удобстве, а не в результате: в обоих случаях получается файл .dt, пригодный для восстановления через конфигуратор.
Нужно ли делать копию, если обновление устанавливает фирма-франчайзи или обслуживающий специалист?
Да. Ответственность за данные несёт владелец базы, а подрядчики тоже ошибаются. Убедитесь, что копия сделана и лежит в доступном вам месте, прежде чем давать добро на обновление. Профессиональный специалист сам начнёт с резервного копирования — его отказ от этого шага должен насторожить.
Сколько хранить резервную копию после успешного обновления?
Минимум — до тех пор, пока не убедитесь, что обновлённая база работает корректно: закрыт хотя бы один отчётный период, проведены регламентные операции, пользователи не сообщают о проблемах. На практике копию перед обновлением держат несколько месяцев, особенно если обновление затрагивало учётные механизмы.
Можно ли сделать резервную копию, пока пользователи работают в базе?
Бэкап средствами СУБД технически возможен без остановки работы, но перед обновлением это не имеет смысла: обновление всё равно потребует монопольного доступа. Выгрузка в .dt при активных сеансах либо невозможна, либо даст несогласованную копию. Правильный порядок — сначала вывести пользователей, потом делать копию.
Что делать, если файл .dt не загружается с ошибкой?
Сначала проверьте, что файл скопирован полностью и его размер совпадает с исходным. Попробуйте загрузить его на другом компьютере — иногда проблема в локальной установке платформы. Если файл повреждён, восстановить его нельзя: понадобится вторая копия. Именно поэтому перед обновлением рекомендуется иметь два независимых бэкапа.