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

Потеря информационной базы 1С редко выглядит как «сломался компьютер». Чаще это сбой диска, ошибка при обновлении, случайное удаление документов, вирус-шифровальщик или поломка сервера. Учёт при этом может быть исправен «ещё вчера» — и недоступен сегодня. Резервная копия — это не удобная кнопка, а возможность вернуть работу бухгалтерии, склада и продаж к согласованной точке времени.
Специалисты «1С:БИЗНЕС РЕШЕНИЯ» помогают подобрать способ копирования под вариант работы базы (файловый или клиент-серверный), настроить расписание, место хранения и проверку восстановления. Ниже — полный набор рабочих способов, которые применяют на практике, и как выбрать среди них, а не держать «копию ради копии».
  
Зачем настраивать резервное копирование

Цель — иметь согласованный снимок учёта, из которого можно восстановить базу за приемлемое время, а не разбирать аварию «с нуля».
Типичные задачи бизнеса:

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

 
С какими конфигурациями 1С это работает

Штатные средства копирования в режиме «1С:Предприятие» есть во многих типовых решениях: раздел «Администрирование» (или «Настройки») → «Обслуживание» → «Резервное копирование и восстановление». Логика одна и та же, различаются названия разделов.
Чаще всего речь идёт о:

• 1С:Бухгалтерия;
• 1С:ЗУП;
• 1С:Управление торговлей, 1С:Комплексная автоматизация, 1С:ERP;
• 1С:УНФ и отраслевых решениях на той же платформе.

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

Три контура: от них зависит способ
Способ зависит от того, как хранится база, а не от названия конфигурации.

• Файловый вариант — данные в файле `1CV8.1CD`. Копию делают средствами программы, копированием файла или сервисом «1С:Облачный архив».
• Клиент-серверный вариант — данные в СУБД (Microsoft SQL Server, PostgreSQL и др.). Основной способ — резервное копирование средствами СУБД, без выгрузки «ради бэкапа» из конфигуратора.
• Облако фирмы «1С» и партнёра — копии ведёт сервис («1С:Предприятие через Интернет» / 1С:Фреш или частное облако). Пользователь не копирует файл на своём компьютере.

Отдельно существует выгрузка в файл `.dt` из конфигуратора. Это образ базы для переноса и передачи, а не рекомендованный фирмой «1С» регламент ежедневного копирования.
Ниже — каждый способ по сути, ограничениям и типичному применению.

Все рабочие способы

1. Штатное копирование в режиме «1С:Предприятие»

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

2. Копирование файла информационной базы

Фирма «1С» рекомендует для файлового варианта копировать файл `1CV8.1CD` в отдельный каталог — вручную, скриптом или программой резервного копирования. Такое копирование обычно быстрее выгрузки в `.dt` и даёт более полный снимок: при нарушениях в базе выгрузка может «потерять» часть данных, а файл сохранит их для последующего ремонта.

Обязательное условие целостности: пока идёт копирование, с базой никто не работает. Копия «на лету», когда открыт сеанс 1С, может оказаться повреждённой и не открыться.

3. Специализированные программы резервного копирования

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

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

4. Выгрузка информационной базы в файл `.dt`

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

Фирма «1С» не рекомендует строить на `.dt` регулярное резервное копирование: нужен однопользовательский режим, на больших базах простой долгий, а при ошибках в данных выгрузка может быть неполной. Для ежедневного регламента выбирают копирование файла или средства СУБД.
  
5. Средства СУБД: Microsoft SQL Server

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

Это основной рекомендуемый способ для SQL: точнее отражает состояние базы, чем выгрузка `.dt`, и не требует «выгнать всех из 1С» на время бэкапа.
 

6. Средства СУБД: PostgreSQL

Для баз на PostgreSQL используют средства самой СУБД: логические дампы и/или физические копии по принятой в организации схеме, обычно по расписанию на стороне сервера. Как и на SQL Server, цель — согласованная копия базы данных, а не файл `.dt` из конфигуратора.

Кому подходит: клиент-серверный контур на Linux или смешанный контур, где 1С уже работает с PostgreSQL.
  
7. Сервис «1С:Облачный архив»

Сервис фирмы «1С» (backup.1c.ru) автоматически или вручную копирует файловую информационную базу в облачное хранилище. Копии не занимают место на том же компьютере, доступны через интернет, процесс контролируется сервисом.

Ограничения: только файловый вариант; рабочие места на Windows; нужны права  администратора ОС и полные права в 1С. Клиент-серверную базу этим сервисом не закрывают.
 

8. Резервные копии в сервисе «1С:Предприятие через Интернет» (1С:Фреш)

Если база работает в сервисе 1cfresh.com (и аналогичных облаках на той же модели), копирование организует провайдер сервиса. Обычно доступны автоматические копии по расписанию сервиса и копия по требованию абонента. Восстановление, как правило, создаёт новое приложение с данными из выбранной копии.

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

9. Частное облако партнёра и хостинг 1С

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

Имеет смысл явно зафиксировать в договоре: как часто снимают копию, сколько хранят, как заказать внеплановую копию и как получить восстановление.
 

10. Снимки виртуальной машины и диска

Гипервизор умеет снимать снимок диска или всей виртуальной машины. Это удобно как дополнение: быстрый откат сервера перед обновлением платформы, сменой оборудования, работой на тестовой копии.

Ограничения: снимок «на лету» без учёта СУБД может быть несогласованным. Для клиент-серверной 1С надёжная схема — копия средствами SQL/PostgreSQL, а снимок виртуальной машины — второй контур (восстановление площадки), а не единственный бэкап учёта.
  
11. Образ сервера и копия всего тома

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

Для ежедневного регламента учёта всё равно нужен точечный способ из пунктов 1–8: быстрее создать и быстрее проверить восстановлением.
 

Что не заменяет резервную копию данных

• Выгрузка конфигурации в `.cf` / расширение в `.cfe` — это структура программы, без документов и остатков.
• Копия только папки с внешними отчётами и обработками.
• «База лежит в облаке почты / на флешке у главного бухгалтера» без расписания, без второй площадки и без проверки открытия.
• Работающий кластер 1С без бэкапа СУБД: устойчивость сеансов ≠ архив на вчерашний день.
   

Как выбрать способ и не ошибиться

Практичное правило: один основной способ по типу базы и один вынос копии с рабочей площадки.

• Файловая база на компьютере или в маленькой сети: штатное копирование или копирование `1CV8.1CD` + вынос на другой диск/сетевое хранилище; при желании — «1С:Облачный архив».
• Клиент-сервер: только СУБД как основа; `.dt` — для переноса и отдельных задач, не вместо плана SQL/PostgreSQL.
• Фреш и облако партнёра: опираться на копии сервиса и знать, как выгрузить экземпляр к себе.
• Перед обновлением конфигурации — отдельная копия, даже если ночное расписание уже есть.

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

Что получает клиент после настройки
 

1. Понятная схема: какой способ основной, какой запасной, куда пишутся файлы.
2. Расписание и глубина хранения под объём изменений в учёте.
3. Вынос копии с рабочего диска (второй носитель или облако).
4. Регламент «что делать перед обновлением» и «как восстанавливать».
5. Проверка восстановления на тестовой базе, а не только факт появления файла.
6. Инструкция для ответственного и краткое обучение тех, кто будет контролировать задание.

Как мы настраиваем резервное копирование

Работаем по понятным этапам:

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

При необходимости на этапе эксплуатации можем заложить сопровождение: разбирать сбои задания, менять расписание при росте базы, проверять восстановление после смены сервера.
 

Кому это особенно полезно

• компаниям на файловой базе, где копия до сих пор «на том же компьютере, что и учёт»;
• организациям, которые перешли на клиент-сервер, но продолжают выгружать `.dt` по ночам;
• бухгалтериям, которые обновляются без точки отката;
• тем, кто уже в 1С:Фреш или в облаке партнёра и хочет понять, какие копии даёт сервис, а какие нужно забирать себе;
• службам ИТ, которым нужен единый регламент на несколько баз 1С, а не набор папок «бэкап_финал_2».
   

Заключение
Резервное копирование 1С — это не одна кнопка на все случаи. Файловую базу сохраняют копированием файла и штатными средствами программы (и при необходимости облачным архивом). Клиент-серверную — средствами СУБД. Облачную — регламентом сервиса. Выгрузка `.dt` остаётся инструментом переноса. Снимки виртуальных машин дополняют схему, но не заменяют согласованную копию учёта.
Специалисты компании «1С:БИЗНЕС РЕШЕНИЯ» помогут оценить текущий контур, выбрать способ под вашу конфигурацию 1С и довести регламент до проверенного восстановления, а не до папки с непроверенными файлами.