Где хранить резервные копии 1С: практическое руководство

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

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

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

Какие виды копий бывают и что именно нужно хранить

Для файловой базы 1С резервная копия — это либо файл выгрузки .dt (делается через «Конфигуратор → Администрирование → Выгрузить информационную базу»), либо копия файла 1Cv8.1CD, снятая при отсутствии активных сеансов. Выгрузка .dt надёжнее: она гарантированно целостна, тогда как копирование .1CD при открытых сеансах может дать повреждённый файл.

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

Локальное хранение: второй диск, NAS, отдельный сервер

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

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

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

Удалённое хранение: облако и вторая площадка

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

При выборе облака учитывайте три момента: объём (выгрузки .dt могут занимать десятки гигабайт, и их нужно хранить в нескольких поколениях), скорость канала на отдачу (восстановление 50 ГБ через медленный интернет займёт часы) и возможность версионирования — чтобы случайно перезаписанный или зашифрованный файл можно было откатить к прежней версии.

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

Как организовать автоматическую выгрузку и ротацию

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

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Backup" /P"пароль" /DumpIB"E:\Backups\trade_%date:~6,4%-%date:~3,2%-%date:~0,2%.dt"

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

Настройте ротацию — автоматическое удаление старых копий. Практичная схема: ежедневные копии за последние 7–14 дней, еженедельные за 1–2 месяца, ежемесячные — за более длинный срок. Без ротации диск под бэкапы рано или поздно переполнится, и новые копии перестанут создаваться — незаметно для всех.

1. 1
   Создайте папку для копий на отдельном устройстве и ограничьте права доступа к ней
2. 2
   Напишите командный файл с выгрузкой .dt через пакетный режим конфигуратора
3. 3
   Добавьте задачу в планировщик Windows на ночное время от имени отдельной учётной записи
4. 4
   Настройте удаление копий старше заданного срока
5. 5
   Проверьте восстановление из свежей копии на тестовой базе

Проверка копий: как убедиться, что они восстанавливаются

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

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

Типичные ошибки и их последствия

Как выбрать схему под свой сценарий

Для небольшой файловой базы на одном компьютере достаточно связки: ежедневная выгрузка .dt на NAS или второй диск плюс синхронизация папки с облаком. Это закрывает правило 3-2-1 без серьёзных затрат.

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

Частые вопросы