Резервное копирование 1С: настройка и проверка восстановления

Что бизнес должен получить от резервного копирования

До выбора программы согласуйте RPO — допустимую потерю изменений во времени, и RTO — целевое время возвращения сервиса. Например, при копии на 10:00 и сбое в 11:00 разрыв составляет час. Восстановление при этом может занять другое время. Это условный пример, а не обещание срока.

Какой способ выбрать для вашей базы 1С

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

Перед настройкой: составьте паспорт восстановления

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

• Версии: платформа, конфигурация, расширения, СУБД и необходимые компоненты.
• Расположение: файловый каталог или имя базы на сервере СУБД, объём и скорость роста.
• Зависимости: внешние файлы и вложения, публикации, обмены, задания, интеграции.
• Доступ: ответственные, права на резервное хранилище, порядок получения ключей и лицензий.
• Приёмка: кто проверяет документы, отчёты и возможность продолжить работу.

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

Файловая 1С: копируем 1Cv8.1CD без активных подключений

1. Уточните фактический путь базы в окне запуска 1С. Согласуйте окно и запретите новые подключения штатным способом вашей конфигурации.
2. Завершите пользовательские и фоновые подключения. Проверьте также веб-доступ и процессы, которые обращаются к этой базе.
3. Скопируйте файл 1Cv8.1CD в новый каталог. Журнал регистрации и внешние файлы, если они нужны по паспорту, сохраняйте отдельными заданиями.
4. Проверьте результат копирования, разрешите работу пользователей и перенесите копию в защищённое хранилище.

Пример для PowerShell на файловом сервере Windows. Каталог E:\BackupStaging создан заранее, ограничен по правам и используется как временная площадка; исходная база находится в D:\1C\Accounting. Команда не закрывает сеансы — это обязательное предварительное действие администратора.

$backupStamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$backupFolder = Join-Path 'E:\BackupStaging' $backupStamp
New-Item -ItemType Directory -Path $backupFolder -ErrorAction Stop | Out-Null
$backupFile = Join-Path $backupFolder '1Cv8.1CD'
Copy-Item -LiteralPath 'D:\1C\Accounting\1Cv8.1CD' -Destination $backupFile -ErrorAction Stop
Get-Item -LiteralPath $backupFile | Select-Object FullName, Length, LastWriteTime
Get-FileHash -LiteralPath $backupFile -Algorithm SHA256

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

Является ли выгрузка .dt резервной копией 1С

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

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

PostgreSQL: пример логического дампа

pg_dump делает согласованный логический снимок одной базы. Пример ниже — для небольшой базы и учебной проверки; для крупных рабочих систем заранее оцените нагрузку и длительность, рассмотрите физическое копирование с WAL. Клиентские утилиты берите из совместимой сборки, в этом примере — PostgreSQL 17. Справка pg_dump.

Выполняется в Linux от назначенной учётной записи копирования. Каталог /srv/backup-staging подготовлен с ограниченными правами; авторизация настроена отдельно, пароль в команду не включён. Подставьте свои узел, порт, пользователя и базу.

umask 077
pg_dump --version
backup_file="/srv/backup-staging/accounting-$(date +%Y%m%d-%H%M%S).dump"
pg_dump -h db01.example.internal -p 5432 -U backup_user \
  -d accounting -Fc -f "$backup_file" && \
pg_restore --list "$backup_file" > "$backup_file.list"

-Fc выбирает архивный формат. Успешное завершение и список содержимого — предварительная проверка; ошибки и предупреждения нужно сохранять в журнал задания. Этот дамп не включает общие роли кластера. Для них есть pg_dumpall с параметром --globals-only; результат может содержать чувствительные сведения и требует защищённого хранения. Состав прав копирования задайте по реальной базе, не выдавая их шире необходимого.

Восстановление PostgreSQL: только в тестовую базу

На отдельном изолированном сервере подготовьте необходимые роли, расширения, локаль и совместимое окружение. Имя accounting_restore_test должно быть свободным. Путь ниже — пример уже доставленного дампа, а не автоматически выбранная последняя копия.

createdb -h db-test.example.internal -p 5432 -U restore_admin \
  -O onec_user -T template0 accounting_restore_test
pg_restore -h db-test.example.internal -p 5432 -U restore_admin \
  --exit-on-error -d accounting_restore_test \
  /srv/restore-input/accounting-20261023-010000.dump

Первая команда создаёт новую базу, вторая загружает архив. Между действиями проверьте успешный результат создания; при ошибке не продолжайте. --exit-on-error останавливает восстановление при ошибке, но не гарантирует автоматическую отмену уже сделанного. Разберите журнал; для новой попытки подготовьте чистую тестовую цель по своему регламенту. Не перенаправляйте команду на рабочую базу. Справка pg_restore.

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

MS SQL Server: разовая копия и проверка файла

Пример для SSMS, запрос к нужному экземпляру SQL Server. Каталог E:\SQLBackup находится на сервере СУБД, а не на компьютере администратора; службе SQL Server нужны права записи. Для каждой попытки используйте новое имя файла.

BACKUP DATABASE [Accounting]
TO DISK = N'E:\SQLBackup\Accounting_copy_20261023_010000.bak'
WITH COPY_ONLY, CHECKSUM, STATS = 10;

RESTORE VERIFYONLY
FROM DISK = N'E:\SQLBackup\Accounting_copy_20261023_010000.bak'
WITH CHECKSUM;

COPY_ONLY подходит для дополнительной разовой полной копии: она не меняет базу дифференциального копирования. Это не готовая настройка регулярной цепочки. CHECKSUM добавляет проверку контрольных сумм при backup. Проверку файла запускайте после успешного завершения первого запроса. COPY_ONLY, создание полной копии.

RESTORE VERIFYONLY проверяет читаемость и комплектность набора, но не заменяет фактическое восстановление и проверку структуры данных. Ограничения VERIFYONLY.

1. В изолированном SSMS выберите восстановление из устройства и нужный .bak.
2. Укажите новое имя базы и отдельные пути файлов данных и журнала. Проверьте, что рабочие файлы не будут перезаписаны.
3. Восстановите, проверьте журнал и подключите тестовую базу к отдельному серверу 1С.

Для зашифрованных баз заранее сохраните необходимые сертификаты и ключи; проверьте также серверные логины и совместимость версий. Порядок восстановления через SSMS. Если требуется возврат между полными копиями, администратор проектирует цепочку full/differential/log под модель восстановления; пример выше её не создаёт.

Где хранить копии и как назначить расписание

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

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

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

Как перевести ручную проверку в регулярное задание

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

1. Служебная учётная запись. Выделите права чтения базы и записи на площадку, настройте защищённую авторизацию. Не вставляйте пароли в текст задания и общедоступный скрипт.
2. Расписание. Для файловой базы согласуйте окно без подключений; если это невозможно обеспечить, автоматический запуск простого Copy-Item не подходит. Для СУБД учитывайте нагрузку и пересечение с обслуживанием.
3. Результат каждой стадии. Сохраняйте stdout/stderr, время начала и окончания, имя базы, имя копии, размер и результат передачи. При ошибке не продолжайте цепочку как успешную.
4. Планировщик. На Windows можно использовать Планировщик заданий для проверенного сценария PowerShell; на Linux — systemd timer и службу. Укажите полный путь к утилитам и рабочему каталогу, запретите одновременные запуски одного задания.
5. Приёмка. Запустите задание от той же учётной записи, что будет работать по расписанию. Проверьте запуск без интерактивного ввода, отказ при неверных правах и доставку сообщения ответственному.
6. Хранение. Очистку выполняйте по отдельному проверенному правилу удержания. Не соединяйте первый тест копирования с удалением старых точек.

Короткая команда из статьи не содержит всего этого управления. Прежде чем считать настройку законченной, дождитесь успешного запуска по расписанию, проверьте внешний экземпляр и проведите восстановление именно из него.

Проверка восстановления: шесть шагов до результата

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

Измеряйте весь путь: получение доступа к копии, передачу, подготовку окружения, загрузку, запуск 1С и приёмку. Если загрузка заняла 20 минут, это ещё не означает RTO 20 минут. Повторите упражнение после существенной смены платформы, СУБД, схемы хранения или интеграций.

Что контролировать кроме зелёного статуса задания

Получатель уведомления и срок реакции должны быть определены заранее. Отчёт «копии создаются» дополните датой последнего успешного учебного восстановления и списком оставшихся ограничений.

Настроим копирование 1С и проверим сценарий возврата

Для начала сообщите вариант базы, её объём, версии платформы и СУБД, текущую схему копирования и допустимый простой. Подробнее о сопровождении — ИТ-аутсорсинг и обслуживание серверов.

Две памятки для настройки и приёмки

Вопросы о резервном копировании 1С