Резервное копирование файловых баз 1С:Предприятие в S3 хранилище

Данную заметку мы начнем с описания проблематики, потому как она достаточно специфична и именно ей обусловлены принятые нами при разработке скрипта решения.

Файловые базы – это малый или даже средний бизнес, вполне нормальные и платежеспособные клиенты, но с одной особенностью – 1С:Предприятие нужна только для отчетности и зарплаты, поэтому работают с ней пару-тройку человек, преимущественно удаленно.

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

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

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

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

И если веб-сеансы мы можем относительно безопасно для базы отключить, то завершить локальный сеанс безопасно невозможно, только завершением процесса 1С. А это может привести к совершенно разным последствиям.

Поэтому нам нужно выгружать копию безопасно и не выгоняя пользователей, такой способ есть – Автономный сервер 1С:Предприятие, он позволяет выгрузить дамп базы – DT, не выгоняя пользователей.

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

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

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

Но ровно тоже самое вы получите и при использовании pg_dump или простой модели восстановления MS SQL, так что тут полный паритет. Да и не нужно небольшим базам восстановление на момент времени.

Также стоит помнить, что DT – это сырой дамп, а не резервная копия и сам вендор обращает на это внимание, вы можете спокойно выгрузить DT из поврежденной базе, который потом не сможете загрузить.

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

В то время как сам файл базы зовется исключительно 1Cv8.1CD и ничего не стоит перепутать файлы или заменить не тот файл, а такие случаи на нашем опыте случались не раз и не два.

Теперь почему S3 – сегодня это самый дешевый способ внешнего хранения данных и один из самых безопасных, особенно если хранилище поддерживает версионирование.

В итоге, собрав все эти требования воедино и приведя к единому знаменателю мы совместно с Claude написали и отладили скрипт. Скрипт писали «по-взрослому», все настройки хранятся в отдельных файлах, сам скрипт вам трогать не нужно.

В комплекте у вас будет 4 файла:

▫️Backup-1C-ToS3.ps1 – сам скрипт
▫️Backup-1C-ToS3.bat – файл-стартер для ручного запуска
▫️config.ini – настройки подключения к S3-хранилищу
▫️databases.lst – список файловых баз, пути к ним и учетные данные для входа

Все файлы отлично прокомментированы и содержат краткие инструкции по применению. Единственный момент, так как писалось все это конкретно под S3 Selectel, то в комментах и примерах фигурирует именно он, но скрипт будет работать с любым S3 хранилищем.

Из зависимостей вам потребуется Автономный сервер (устанавливается с компонентой сервера 1С, если сервер не нужен снимите флаг его установки в качестве службы) и AWS CLI.