Резервное копирование базы 1С 2026: как проверить бэкап, а не просто создать файл

Резервное копирование 1С считается рабочим только после тестового восстановления. Файл .dt, архив 1Cv8.1CD, pg_dump или .bak SQL Server сам по себе ещё не доказывает, что компания сможет открыть базу после сбоя диска, ошибочного удаления документов или неудачного обновления.

Практический минимум для 2026 года: понять тип базы 1С, выбрать правильный способ копирования, хранить копии отдельно от рабочей базы, получать уведомление об ошибке и хотя бы раз в месяц поднимать копию на тестовом контуре. Всё остальное — расписание, облако, Telegram и ротация — имеет смысл только после этой проверки.

Ключевые факты

• Для файловой 1С важно копировать именно файл 1Cv8.1CD в момент, когда пользователи и фоновые задания не пишут в базу. Простая копия во время активной работы может оказаться несогласованной.
• Для клиент-серверной 1С резервная копия обычно делается средствами СУБД: PostgreSQL, Microsoft SQL Server или другой поддерживаемой базы данных, а не простым копированием каталога 1С.
• Выгрузка .dt через конфигуратор удобна для переноса и небольших баз, но для больших рабочих баз часто требует монопольного режима и длинного окна простоя.
• PostgreSQL pg_dump создаёт согласованную логическую копию базы и не блокирует чтение/запись пользователей, но выгружает одну базу; роли и общие объекты кластера проверяются отдельно.
• Microsoft SQL Server рекомендует строить стратегию из регулярных бэкапов, тестовых восстановлений, хранения копий отдельно от файлов базы и проверки носителя через штатные механизмы.
• Правило 3-2-1 остаётся хорошим базовым ориентиром: 3 копии важных данных, 2 разных типа носителя, 1 копия вне офиса или основной инфраструктуры.
• Настройка контура резервного копирования через Синхрон1С стоит 30 000 ₽ за проект: расписание, ротация, облачное хранилище, Telegram-уведомления и тест восстановления.

Что именно копировать в разных вариантах 1С

Если база маленькая и используется 1-2 пользователями, часто хватает ночной копии 1Cv8.1CD с закрытием сеансов и еженедельного теста открытия. Если база серверная, с кассами, маркетплейсами или обменами, нужен контур СУБД: полный бэкап, журнал/дифференциальные копии по требованиям бизнеса, контроль результата и отдельное хранилище.

Практическая диагностика: как мы проверяем бэкап 1С

В нашей практике первый вопрос не «куда складывать архивы», а «сколько данных компания готова потерять и за сколько часов должна вернуться в работу». Для бухгалтерии иногда допустим откат на ночь. Для склада с заказами маркетплейсов потеря даже 2-4 часов уже приводит к ручной сверке остатков, отгрузок и оплат.

Перед настройкой мы фиксируем 10 пунктов:

1. Тип базы: файловая, PostgreSQL, Microsoft SQL Server или облачный сервис.
2. Размер рабочей базы и средний прирост за месяц.
3. Окно, когда пользователи не работают, а регламентные задания можно остановить.
4. RPO: сколько данных можно потерять при аварии — 15 минут, 1 час, ночь, сутки.
5. RTO: за какое время надо поднять базу — 30 минут, 2 часа, рабочий день.
6. Где лежит рабочая база и на каком физическом диске лежат бэкапы.
7. Есть ли внешняя копия: S3, Яндекс.Диск, NAS вне сервера, другой дата-центр.
8. Кто получает уведомление об успехе и ошибке.
9. Когда последний раз делали тест восстановления.
10. Кто имеет право восстанавливать копию и где записана инструкция.

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

Типовой контур автоматического бэкапа

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

• ночная полная копия в локальную папку не на том же разделе, где лежит база;
• выгрузка второй копии в облачное или внешнее хранилище;
• ротация: например, ежедневные копии за 14-30 дней, недельные за 2-3 месяца;
• Telegram-сообщение после каждой попытки: база, статус, размер файла, длительность, путь хранения, первая строка ошибки;
• отдельная проверка свободного места, чтобы бэкап не «успешно» умер из-за заполненного диска;
• ежемесячный тест восстановления на копии.

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

Риски и диагностика

Как часто делать резервные копии

Частота зависит не от «лучшей практики в интернете», а от цены потери данных. Для небольшой бухгалтерской базы обычно достаточно ежедневной ночной копии и копии перед обновлением. Для склада, интернет-магазина или активных обменов с маркетплейсами лучше считать RPO: если за час проходит 200 заказов, ночной бэкап означает ручное восстановление всего дня.

Ориентир для обсуждения:

Как мы настраиваем через Синхрон1С

Шаг 1. Вы пишете в Telegram @onoutnoxon: тип 1С, где стоит база, примерный размер, сколько пользователей и куда сейчас складываются копии.

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

Шаг 3. Настраиваем скрипт/регламент, Telegram-уведомления, ротацию, проверку размера и тест восстановления. Если база серверная, работаем через администратора СУБД или даём точный список команд, которые нужно выполнить на вашей стороне.

Стоимость базовой настройки — 30 000 ₽ за проект. Поддержка после запуска, изменение расписания, добавление новых баз и разбор ошибок — по отдельной договорённости.

Смотрите также

• 1С ошибка базы данных: диагностика и восстановление
• Мониторинг 1С: уведомления в Telegram
• Регламентные задания 1С
• Автоматическая выгрузка из 1С по расписанию
• Ошибка доступа к файлу 1С: причины и решение

FAQ

Что лучше для 1С: .dt или копия средствами СУБД?

Для файловой небольшой базы .dt может быть удобен, особенно перед обновлением. Для клиент-серверной 1С рабочий бэкап обычно делают средствами СУБД: PostgreSQL или Microsoft SQL Server. .dt не должен быть единственным способом защиты большой рабочей базы.

Можно ли делать бэкап 1С без остановки пользователей?

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

Как понять, что резервная копия 1С рабочая?

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

Куда хранить бэкапы 1С?

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

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

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

Резервное копирование заменяет синхронизацию или репликацию?

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

Что делать, если бэкап не создался ночью?

Не ждать следующей ночи. Нужно проверить свободное место, права сервисного пользователя, доступность СУБД/папки, код завершения команды и последнюю ошибку. Поэтому мы отправляем в Telegram не только «ошибка», но и базу, время, длительность, размер и первую диагностическую строку.

Александр Руин, основатель habab.ru. Обновлено: 2026-05-04.

Источники

• 1С:Предприятие 8, рекомендации по резервному копированию информационной базы: https://its.1c.ru/db/content/metod8dev/src/admins/i8102922.htm
• 1С:Предприятие 8.3, руководство администратора, резервное копирование информационной базы: https://its.1c.ru/db/v8323doc/bookmark/adm/TI000000121
• 1С:Предприятие 8.3, клиент-серверный вариант, создание резервной копии: https://its.1c.ru/db/v8313doc/bookmark/cs/TI000000136
• PostgreSQL documentation, pg_dump: https://www.postgresql.org/docs/17/app-pgdump.html
• Microsoft Learn, SQL Server backup and restore: https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver17
• CISA / US-CERT, Data Backup Options and 3-2-1 backup rule: https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf

AI-инструмент помог перестроить черновик и сверить источники; практический диагностический блок, риск-таблицу, CTA и финальную редактуру выполнил Александр Руин, основатель habab.ru.