Администрирование · 9 мин

Чем лучше бэкапить 1С: практическое руководство

Как правильно делать резервные копии 1С: выгрузка в dt, средства СУБД, облака. Сравнение способов, частота копирования, проверка восстановления и ошибки.

1С

1С-СправкаАдминистрирование

Справочный материал

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

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

Ниже разобраны рабочие способы резервного копирования 1С, их ограничения, рекомендуемая периодичность и порядок проверки того, что копия действительно восстанавливается.

Какой у вас режим работы: файловый или клиент-серверный

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

Проверить режим просто: откройте список информационных баз в стартовом окне 1С, выделите базу и нажмите «Изменить». Если путь указывает на каталог диска — база файловая. Если указаны сервер 1С и имя базы в кластере — клиент-серверная.

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

Способ 1. Выгрузка в dt через конфигуратор

Это универсальный и самый надёжный способ для файловых баз и обязательное дополнение для клиент-серверных. Откройте базу в конфигураторе, перейдите в меню «Администрирование → Выгрузить информационную базу» и укажите путь к файлу .dt. Выгрузка требует монопольного доступа: все пользователи должны выйти из базы.

Для регулярного выполнения удобно автоматизировать выгрузку пакетным запуском конфигуратора через планировщик задач Windows. Типовая команда выглядит так:

batch

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

Преимущества метода: файл .dt независим от СУБД, его можно развернуть на другом компьютере, другой версии платформы (в пределах совместимости) и даже перенести из файлового режима в клиент-серверный. Недостатки: выгрузка большой базы занимает заметное время, требует монопольного доступа и создаёт нагрузку на диск.

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

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

Если база работает на MS SQL Server или PostgreSQL, основной механизм резервного копирования — штатные средства СУБД. Они создают согласованную копию данных без остановки работы пользователей и позволяют настроить полные и разностные бэкапы.

Для MS SQL Server бэкап выполняется через SQL Server Management Studio (задача Back Up Database) или скриптом T-SQL. Для PostgreSQL используется утилита pg_dump или pg_basebackup. Пример для PostgreSQL:

bash

pg_dump -U postgres -Fc -f /backup/trade_$(date +%Y%m%d).dump trade_base

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

Способ 3. Копирование файловой базы и сторонние программы

Копирование каталога с файлом 1Cv8.1CD допустимо, но только когда база закрыта всеми пользователями. Копия, снятая во время работы, может содержать несогласованные данные и не открыться. Если выбираете этот способ, организуйте его как скрипт, который проверяет отсутствие сеансов, либо выполняйте копирование ночью после завершения всех сеансов и регламентных заданий.

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

Сравнение способов бэкапа 1С

Выгрузка в .dt

Подходит всем. Независима от СУБД, переносима. Требует монопольного доступа и времени на больших базах.

Бэкап средствами СУБД

Только клиент-серверные базы. Быстро, без остановки работы, но восстанавливается только в ту же СУБД.

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

Только файловые базы. Просто, но небезопасно при работающих пользователях и не защищает от логических повреждений.

Бэкап виртуальной машины

Дополнительная защита сервера целиком. Не гарантирует целостность данных СУБД без агентов в гостевой ОС.

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

Рабочий ориентир — правило 3-2-1: минимум три копии данных, на двух разных носителях, одна — вне основной площадки. На практике для 1С это означает: свежая копия на том же сервере (для быстрого отката), копия на другом устройстве в локальной сети (NAS, файловый сервер) и копия в облаке или на внешнем диске, который отключается после записи.

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

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

Как автоматизировать и проверять восстановление

Бэкап, который делается вручную «когда вспомнят», рано или поздно оказывается пропущенным именно в нужный день. Настройте автоматическое выполнение: планировщик задач Windows для пакетной выгрузки .dt, планы обслуживания в MS SQL, cron для pg_dump. Добавьте контроль результата — логирование и уведомление об ошибке, иначе о сбое вы узнаете только при попытке восстановления.

Не реже одного раза в месяц проверяйте восстановление: разверните свежую копию в тестовую базу, откройте её, выполните тестирование и исправление и убедитесь, что данные на месте. Такая проверка занимает 15–30 минут, но гарантирует, что в аварийной ситуации копия действительно сработает.

1
Определите режим базы: файловый или клиент-серверный.
2
Выберите основной способ: выгрузка в .dt или бэкап СУБД.
3
Напишите скрипт и настройте запуск по расписанию в нерабочее время.
4
Настройте копирование архивов на второй носитель и в облако или на съёмный диск.
5
Настройте логирование и уведомление о сбоях.
6
Раз в месяц восстанавливайте копию в тестовую базу и проверяйте данные.

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

Хранение всех копий на том же диске, где лежит база — при отказе диска теряется и база, и бэкапы.

Отсутствие проверки восстановления — о битом архиве узнают в момент аварии.

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

Папка с бэкапами доступна всем по сети — шифровальщик уничтожает и копии.

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

Достаточно ли одной выгрузки в .dt раз в неделю?

Для базы с небольшим числом ежедневных операций — приемлемо, но при потере данных за неделю восстановить их будет неоткуда. Оптимально — ежедневные копии. Если ежедневная выгрузка невозможна из-за объёма, делайте полную выгрузку еженедельно, а между ними — бэкапы средствами СУБД или копии файла базы.

Можно ли бэкапить 1С, пока пользователи работают?

Выгрузку в .dt — нет, она требует монопольного доступа. Бэкап средствами СУБД (MS SQL, PostgreSQL) — да, он выполняется без остановки работы и даёт согласованную копию. Копирование файла файловой базы во время работы недопустимо.

Чем отличается выгрузка в .dt от сохранения конфигурации в .cf?

Файл .cf содержит только конфигурацию — программную часть без данных. Файл .dt содержит и конфигурацию, и все данные. Для резервного копирования учёта нужен именно .dt; .cf используется для переноса доработок между базами.

Как проверить, что бэкап не повреждён?

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

Нужно ли бэкапить базу в облачном сервисе 1С (например, 1С:Фреш)?

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

Итог

Что важно запомнить

Файловую базу бэкапьте выгрузкой в .dt по расписанию, клиент-серверную — средствами СУБД плюс периодической выгрузкой в .dt. Храните копии минимум в двух независимых местах, изолируйте их от сети с потенциальными шифровальщиками и регулярно проверяйте восстановление в тестовую базу.