Как сохранить 1С в облаке: инструкция по резервному копированию

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

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

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

Какие способы сохранения 1С в облаке существуют

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

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

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

Сначала определите режим работы базы. Файловая база хранится в одном файле 1Cv8.1CD в каталоге — её можно выгружать напрямую конфигуратором. Клиент-серверная база живёт в СУБД (MS SQL, PostgreSQL), и корректную копию нужно делать либо через выгрузку .dt, либо средствами самой СУБД.

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

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

Ручная выгрузка базы и загрузка в облако

Базовая процедура для файловой базы выглядит так. Запустите конфигуратор, откройте меню «Администрирование» и выберите пункт «Выгрузить информационную базу». Укажите путь и имя файла с понятной датой, например base_2026-01-15.dt. Дождитесь завершения выгрузки — для больших баз это может занять заметное время.

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

Как убедиться, что выгрузка корректна

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

1. 1
   Попросите пользователей выйти из базы и проверьте отсутствие активных сеансов
2. 2
   Откройте конфигуратор и выполните «Администрирование → Выгрузить информационную базу»
3. 3
   Дождитесь завершения и проверьте, что файл .dt создан без ошибок
4. 4
   Заархивируйте файл с паролем и загрузите архив в облачное хранилище
5. 5
   Периодически проверяйте копию тестовой загрузкой в пустую базу

Автоматическая выгрузка через планировщик задач

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

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

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F"D:\Bases\Trade" /NАдмин /PПароль /DumpIB "D:\Backup\trade_%date%.dt" /DisableStartupDialogs

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

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

Облачные сервисы резервного копирования и 1С:Фреш

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

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

Проверка копий и восстановление из облака

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

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

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

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

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

FAQ: частые вопросы о сохранении 1С в облаке