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

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

Для файловых баз копия — это выгрузка в формате DT через конфигуратор или прямое копирование файла 1Cv8.1CD при завершённых сеансах. Для клиент-серверных баз на SQL Server или PostgreSQL копирование файлов базы не работает корректно: нужен штатный дамп средствами СУБД. В обоих случаях результат — файл, который нужно разместить в надёжном хранилище.

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

Какие копии вообще нужно хранить

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

Для клиент-серверных баз используйте штатные средства СУБД: pg_dump для PostgreSQL или задания обслуживания (Maintenance Plan) для MS SQL Server. Копировать файлы данных SQL-сервера напрямую нельзя — копия получится несогласованной и при восстановлении база может не открыться.

Дополнительно стоит периодически сохранять сам дистрибутив конфигурации (файл CF) и список установленных расширений. Если база восстанавливается на новый сервер, отсутствие нужной версии платформы и конфигурации превратит восстановление в многочасовой поиск дистрибутивов.

Локальный диск: удобно, но недостаточно

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

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

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

Сетевое хранилище и второй сервер

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

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

Если в компании два офиса, хранилище можно разместить во втором офисе и копировать туда по VPN или через репликацию. Это закрывает сценарий пожара или кражи оборудования в основном помещении без затрат на облако.

Внешние диски и съёмные носители

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

Для небольших баз (до нескольких гигабайт) подойдут и флеш-накопители, но у них ограниченный ресурс перезаписи и выше риск потери или физической поломки. Используйте минимум два носителя с ротацией: чётные дни — один диск, нечётные — второй. Тогда при отказе одного носителя у вас остаётся копия максимум двухдневной давности.

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

Облачное хранение: когда оправдано

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

Обратите внимание на ограничения. Синхронизация папки — палка о двух концах: если шифровальщик изменит локальные файлы копий, изменения уйдут в облако и перезапишут исправные версии. Выбирайте сервисы с версионированием файлов или неизменяемым (immutable) хранилищем, где старые версии нельзя удалить или перезаписать в течение заданного срока.

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

Сравнение вариантов хранения

Второй диск на сервере

Быстро и дёшево. Не защищает от отказа сервера, пожара и шифровальщика. Только как оперативная копия.

NAS или второй сервер

Хороший баланс скорости и надёжности. Требует изоляции учётных данных и желательно размещения в другом помещении.

Внешний диск с отключением

Дёшево, защищает от шифровальщика при отключении. Требует дисциплины: диск нужно подключать, отключать и ротировать.

Облако

Защита от локальных катастроф. Зависит от канала, требует шифрования и версионирования, возможна абонентская плата.

Правило 3-2-1 и глубина хранения

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

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

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

1. 1
   Создайте отдельную папку для копий на NAS или втором диске и настройте доступ только для служебной учётной записи.
2. 2
   Напишите скрипт: завершение сеансов, выгрузка DT через конфигуратор в пакетном режиме, архивация с датой в имени файла.
3. 3
   Добавьте в скрипт копирование архива на второе хранилище (NAS или облачную папку).
4. 4
   Настройте ротацию: удаление копий старше заданного срока, например 14 дней.
5. 5
   Поставьте задание в планировщик на ночное время и настройте уведомление об ошибке выполнения.
6. 6
   Раз в месяц выполняйте тестовое восстановление копии в отдельную базу.

Автоматизация и проверка восстановления

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

Копия, которую никто не восстанавливал, — это предположение, а не гарантия. Регулярно, хотя бы раз в месяц, загружайте свежую выгрузку DT в тестовую базу и проверяйте: база открывается, отчёты строятся, данные за последние дни на месте. Для SQL-баз тестовое восстановление дампа на отдельный сервер — единственный способ убедиться, что бэкап рабочий.

Контрольные точки

Как проверить, что копирование работает

Журнал задания копирования

Норма

Задание завершается без ошибок, файл создаётся с актуальной датой

Тревожный признак

Ошибки в журнале, файл не обновляется несколько дней

Размер файла копии

Норма

Размер сопоставим с предыдущими копиями и растёт вместе с базой

Тревожный признак

Резкое уменьшение размера или нулевой файл

Тестовое восстановление

Норма

База открывается, данные актуальны, отчёты строятся

Тревожный признак

Ошибка загрузки DT или отсутствие свежих документов

Свободное место на хранилище

Норма

Запас места с учётом роста базы

Тревожный признак

Диск заполнен, ротация не работает

Типичные ошибки и ограничения

Самая частая ошибка — копия на том же диске или в постоянно подключённой сетевой папке. Вторая по частоте — отсутствие контроля выполнения: задание падает месяцами, а об этом узнают в момент аварии. Третья — копирование файловой базы средствами файловой системы во время работы пользователей: файл 1Cv8.1CD копируется в несогласованном состоянии, и такая копия может не открыться.

Отдельно отметим облачную синхронизацию самой рабочей базы (папки с файлом 1Cv8.1CD) через Dropbox, Яндекс.Диск и подобные клиенты. Это не резервное копирование: клиент синхронизации может конфликтовать с работой 1С, а несогласованная копия в облаке бесполезна. Синхронизировать можно только готовые выгрузки DT.

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

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

Достаточно ли хранить копии только в облаке?

Нет. Облако зависит от интернет-канала: восстановление большой базы может занять часы. Кроме того, при компрометации учётной записи облачного сервиса копии могут быть удалены. Держите минимум одну локальную копию на отдельном устройстве для быстрого восстановления.

Как часто нужно делать копии базы 1С?

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

Можно ли копировать файл 1Cv8.1CD простым копированием?

Только когда все сеансы завершены и файл никем не открыт. При работающих пользователях копия получится несогласованной. Безопаснее использовать выгрузку DT через конфигуратор — она штатно обеспечивает целостность данных.

Нужно ли шифровать копии перед отправкой в облако?

Да, если в базе есть персональные данные сотрудников, данные контрагентов или коммерческая информация. Используйте архиватор с шифрованием (например, 7-Zip с AES-256) и храните пароль отдельно от скриптов копирования. Потерянный пароль означает невосстановимую копию.

Что делать, если база большая и копия не помещается в облако?

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

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

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