Резервное копирование базы 1С и CRM — это регулярная копия данных, которую можно развернуть на чистом сервере и открыть. Для этого нужны три вещи: копия самой базы, копия файлов и настроек вокруг неё и проверка восстановления по расписанию. Копия, которую ни разу не разворачивали, остаётся предположением.
Коротко
Общую схему 3-2-1 и понятия RTO и RPO мы разобрали в статье о восстановлении IT-систем после сбоев. Здесь — практика для баз данных: что именно копировать, каким способом, как часто и как убедиться, что копия рабочая.
В копию входит всё, без чего базу не открыть на новом сервере: не только файл или дамп базы, но и файлы рядом с ней, конфигурация и настройки окружения.
| Что копировать | Где лежит | Что потеряете без копии |
|---|---|---|
| База 1С | Файл базы в файловом режиме или база в СУБД в клиент-серверном | Учёт, документы, остатки, взаиморасчёты |
| Конфигурация и расширения | Хранилище конфигурации, файлы расширений | Доработки под вашу компанию |
| База CRM | СУБД на сервере | Сделки, история общения, задачи |
| Файлы пользователей | Каталоги вложений, шаблоны, печатные формы | Сканы договоров, шаблоны документов |
| Настройки сервера | Конфигурационные файлы, расписания заданий, сертификаты | Время на повторную настройку окружения |
| Ключи и лицензии | Ключ защиты, файлы лицензий, доступы к сервисам | Простой до восстановления прав на ПО |
Совет Составьте список «что копируем» на одной странице и храните его вне сервера. В день аварии именно он подскажет, чего не хватает для запуска.
Способ выбирают по СУБД, объёму базы и тому, сколько данных компания готова потерять между копиями. Клиент-серверные базы 1С и CRM работают на СУБД, например PostgreSQL или Microsoft SQL Server, и для них действуют правила этих СУБД.
В документации PostgreSQL описаны три подхода: SQL-дамп, копия файлов на уровне файловой системы и непрерывное архивирование с восстановлением на момент времени.
| Способ | Что даёт | Ограничение |
|---|---|---|
| Выгрузка (дамп) | Переносимая копия, удобно для небольших баз и переноса на другой сервер | Возвращает состояние только на момент выгрузки; чем больше база, тем дольше разворачивается |
| Копия файлов СУБД | Физическая копия, быстрее разворачивается | Нужна согласованность файлов, поэтому делается строго по документации СУБД |
| Непрерывное архивирование | Возврат на любой момент после базовой копии | Нужна непрерывная цепочка архивных журналов и мониторинг процесса |
Для последнего способа в документации PostgreSQL сказано: восстановить базу можно на состояние в любой момент после базовой копии, но нужна непрерывная последовательность архивных файлов журнала. Поэтому архивирование настраивают и проверяют до первой базовой копии, а сам процесс держат под наблюдением.
Там же уточнено, что pg_dump не создаёт копию уровня файловой системы и не годится для непрерывного архивирования: такие дампы логические и не содержат данных, достаточных для воспроизведения журнала. Две схемы не смешивают, а выбирают осознанно.
Важно Файловая база 1С — это один файл, и копировать его в момент, когда в базе работают пользователи, опасно: копия может оказаться несогласованной. Копию файла делают, когда сеансы закрыты, а выгрузку базы средствами 1С считают дополнительной, пока не проведено пробное восстановление.
Частота копий равна допустимой потере данных (RPO): если бизнес готов потерять работу за час, копии нужны не реже раза в час, если за сутки — раз в сутки. Назначает это число руководитель, а не администратор.
У разных систем цифра разная. База учёта с проведением документов в течение дня теряет больше от ночной копии, чем справочник контрагентов, который меняется раз в неделю. CRM с активной перепиской и звонками стоит копировать чаще, чем базу, в которую заходят раз в месяц.
Копию проверяют только одним способом — разворачивают её на отдельной машине и работают в базе. Запись в журнале «задание завершено» доказывает, что файл создан, а не то, что из него можно вернуть данные.
Проверки СУБД помогают, но не заменяют пробного восстановления. В документации Microsoft SQL Server сказано, что RESTORE VERIFYONLY проверяет полноту копии, читаемость томов и контрольную сумму, но не проверяет структуру данных внутри копии.
В рекомендациях CISA для малого и среднего бизнеса добавлено: проверять и полное, и частичное восстановление и убедиться, что данные можно откатить как минимум на семь дней.
Копии хранят так, чтобы одна авария не уничтожила и базу, и все её копии. CISA описывает схему 3-2-1 в тех же рекомендациях.
При атаке шифровальщика важна ещё одна копия, до которой нельзя дотянуться из рабочей сети. В руководстве CISA по реагированию на программы-вымогатели восстановление данных описано из офлайн-копий с шифрованием, с предупреждением: не заразите чистые системы при восстановлении.
Копия содержит те же данные, что и рабочая база, поэтому место хранения проверяют по тем же правилам. По статье 27-1 закона «О персональных данных» № ЗРУ-547 в редакции закона № ЗРУ-1125 от 26.03.2026 в Узбекистане обязательно хранить биометрические и генетические данные и данные пользователей операторов связи, работающих в стране. Базы с такими данными по статье 20 подлежат регистрации в Государственном реестре баз персональных данных.
Остальные персональные данные можно хранить за рубежом при условиях закона. Подробнее о том, какое облако выбрать, мы писали в статье об облаке и сервере в Узбекистане. Для базы с биометрией копию кладут в стране, а схему согласуют с юристом.
Начинают с инвентаризации и первого пробного восстановления, а не с покупки хранилища: пока неизвестно, что именно защищаем, любое решение будет угадыванием.
Регламент делает копирование процессом, а не разовой настройкой: в нём названо, кто отвечает, что копируется и как проверяется результат. Хватает одной страницы.
Чаще всего копия подводит не из-за сложной технической причины, а из-за организационной ошибки, которую видно заранее.
В Syntra Systems мы начинаем с расчёта: для каждой базы определяем RPO и RTO вместе с вами, затем разделяем копии на базу, файлы и настройки, выбираем способ под вашу СУБД и размещаем копии в разных местах. Серверы Syntra Cloud стоят в дата-центре на территории Узбекистана: сервер под сайт или CRM — от 30 $ в месяц.
Дальше копирование нужно сопровождать: следить за заданиями и проводить пробные восстановления. На странице поддержки указано, что тариф от 250 $ в месяц включает обновления, копии и мониторинг, а срок реакции на критичный сбой зависит от тарифа и фиксируется в приложении к договору. Подробнее о том, как устроена поддержка и SLA, — в статье о технической поддержке IT-инфраструктуры.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
По рекомендациям CISA: три копии на двух типах носителей, одна из них вне площадки, и возможность откатить данные минимум на семь дней. Конкретную глубину хранения задаёт RPO каждой системы.
Для файловой базы лучше выбрать время без работы: копия файла, который в этот момент меняется, может оказаться несогласованной. Для клиент-серверной базы используют средства СУБД: выгрузку, копию файлов по её документации или архивирование журнала.
Подойдёт как второй тип носителя рядом с дисками сервера, если её хранят отдельно от рабочей сети и проверяют восстановление. CISA советует сочетать, например, жёсткий диск и облако, а одну копию держать вне площадки.
Восстанавливать данные из офлайн-копий с шифрованием и не заразить чистые системы при восстановлении, как сказано в руководстве CISA. Поэтому одну копию держат недоступной из рабочей сети.
Нет: по документации Microsoft SQL Server команда проверяет полноту копии, читаемость томов и контрольную сумму, но не структуру данных внутри. Итог даёт только пробное восстановление на тестовой машине.
По статье 20 закона о персональных данных регистрируют базы с данными, которые обязательно хранятся в Узбекистане: биометрическими, генетическими и данными абонентов связи. Для остальных баз такого требования в статье нет.
Источники
