Облачный архив для баз 1С: схема работы, восстановление и выбор хранилища

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

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

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

Как данные попадают в облако: схема передачи

Любой облачный архив делает три шага: получает копию базы , готовит её к отправке и передаёт на сторону.

Откуда берётся копия

Источник копии зависит от типа базы:

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

Выгрузка в .dt проще всего, но на время выгрузки базу лучше закрыть для пользователей. Резервная копия на уровне СУБД делается на работающей базе и не мешает людям, поэтому для больших серверных баз применяется чаще.

Подготовка к отправке

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

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

Канал и объём трафика

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

Пример с числами. Архив весит 12 ГБ, исходящий канал офиса — 50 Мбит/с, это около 6 МБ/с в реальности.

1. 12 ГБ — это примерно 12 000 МБ.
2. 12 000 МБ ÷ 6 МБ/с = 2000 секунд.
3. 2000 секунд — это около 33 минут.

Если канал 10 Мбит/с (реально около 1,2 МБ/с), та же отправка займёт почти три часа. Поэтому полную копию обычно отправляют ночью, а днём передают только небольшие изменения, если провайдер умеет работать с приращениями.

Схемы резервного копирования и хранение версий

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

Полные и инкрементные копии

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

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

Универсального числа нет, но рабочая схема «дед — отец — сын» выглядит так:

• 📅 ежедневные копии за последние 7–14 дней;
• 🗓 еженедельные за последние 1–2 месяца;
• 📆 ежемесячные за год, в том числе копия на закрытие периода .

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

Контроль целостности

Копия, которую не пробовали восстанавливать, считается неработающей. Раз в месяц выгрузите архив во временную папку, создайте из него тестовую базу и откройте несколько документов. Это занимает 20–30 минут и показывает, что файл не побит.

Процесс восстановления данных из облака

Восстановление — ради него всё и затевалось. Выглядит оно так же для любого провайдера.

Порядок действий

1. Определите, до какой даты нужно вернуться. Не берите последнюю копию автоматически: если ошибка появилась три дня назад, последняя копия её уже содержит.
2. Скачайте нужную версию из облака в отдельный каталог на сервере.
3. Распакуйте архив и расшифруйте его ключом, который был задан при настройке.
4. Создайте новую пустую информационную базу, не трогая рабочую.
5. Загрузите в неё данные: через конфигуратор пункт загрузки информационной базы для .dt либо восстановите резервную копию средствами СУБД.
6. Откройте базу, проверьте остатки и последние документы.
7. Только после проверки решите, подменять ли рабочую базу, или перенести недостающие документы вручную.

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

Сколько времени займёт восстановление

Время складывается из четырёх частей: скачивание, распаковка, загрузка в базу, проверка. Скачивание того же архива в 12 ГБ при входящем канале 100 Мбит/с занимает около 15 минут, загрузка в базу на сервере со средним диском — от получаса до двух часов в зависимости от объёма и структуры базы.

Частичное восстановление

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

Безопасность и шифрование информации

В базе 1С лежат зарплата, контрагенты, банковские реквизиты. Отправлять её на чужой сервер без защиты нельзя.

Что должно быть зашифровано

Проверьте три слоя:

• 🔒 В пути — передача только по защищённому каналу (HTTPS или аналог), не по открытому FTP.
• 🔐 На хранении — архив лежит в зашифрованном виде.
• 🔑 Ключ — кто им владеет.

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

Права доступа и персональные данные

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

Защита от шифровальщиков

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

1. Хранилище поддерживает неизменяемые версии: удалить или перезаписать копию нельзя в течение заданного срока.
2. Учётная запись, под которой идёт отправка, не имеет права удалять старые версии.

Интеграция с разными конфигурациями и типами баз

Облачный архив почти не зависит от прикладного решения: Бухгалтерия, ЗУП, Управление торговлей — для хранилища это просто файл. Различия не в конфигурации, а в типе базы и способе копирования.

Что копировать кроме базы

База — не единственное, что надо сохранить. Заведите в архив ещё:

• 📎 внешние отчёты и обработки, которые подключены из файлов;
• 🧩 файлы расширений, если вы храните их отдельно;
• 🖼 каталог с томами хранения файлов, если присоединённые файлы вынесены из базы на диск;
• ⚙ список пользователей и настройки публикации на веб-сервере.

Тома хранения файлов забывают чаще всего. Базу восстановили, а вложенные сканы лежат в пустой папке.

Две базы — один архив

Если у вас рабочая и тестовая базы, тестовую в облако отправлять не обязательно: её можно создать заново из рабочей. Это экономит место и деньги, особенно при оплате за объём.

Стоимость владения и выбор провайдера

Платить приходится за три вещи: место в хранилище, трафик на скачивание при восстановлении и время администратора. Цены ориентировочные и зависят от провайдера, поэтому считайте на своих объёмах.

Из чего складывается цена

• 💾 Хранение — обычно оплата за гигабайт в месяц. У коммерческих облачных хранилищ в России ориентир порядка нескольких рублей за ГБ в месяц, то есть для 100 ГБ архива выходит от нескольких сотен до тысячи-двух рублей в месяц.
• 📥 Скачивание — у многих площадок входящий трафик бесплатен, исходящий оплачивается. Для архива это важно только в момент восстановления.
• 🛠 Настройка и сопровождение — разовая работа специалиста плюс время на ежемесячную проверку.

Пример расчёта. Две базы по 8 ГБ в сжатом виде, хранятся 30 ежедневных копий. Объём: 2 × 8 × 30 = 480 ГБ. При цене 3 рубля за ГБ в месяц получаем 480 × 3 = 1440 рублей в месяц. Если перейти на схему «7 ежедневных + 8 еженедельных + 12 месячных», то 27 копий вместо 30 почти ничего не экономят, а вот глубина хранения вырастает с месяца до года. Считайте не число копий, а глубину.

Критерии выбора

Сравнивайте провайдеров не по цене за гигабайт, а по списку:

Облако или свой второй сервер

Облачное хранение не единственный вариант. Второй сервер в другом здании или внешний диск, который раз в неделю уносят домой, тоже работают. Облако выигрывает автоматизацией и тем, что не нужно держать собственное оборудование. Свой сервер выигрывает скоростью восстановления: копия лежит рядом по локальной сети. На практике надёжнее всего правило «3-2-1»: три копии, на двух разных носителях, одна из них во внешнем месте. Облачный архив как раз закрывает последний пункт.

Типичные ошибки при настройке облачного архива

• ❌ Копия есть, но её никогда не открывали. Сделайте тестовое восстановление сразу после настройки, а не в день аварии.
• ❌ Архив отправляется с рабочей станции. Компьютер выключили, расписание не сработало, а вы узнаёте об этом через месяц.
• ❌ Копируют только файл базы. Тома файлов, расширения и внешние отчёты остаются без защиты.
• ❌ Ключ шифрования лежит рядом с архивом. Тогда шифрование бессмысленно.
• ❌ Не следят за остатком места. Хранилище заполнилось, новые копии не пишутся, а оповещений нет.

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

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