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



Как создается архив базы в PostgreSQL

Наиболее простой и распространенный способ бэкапирования — создание базовой копии инстанса (экземпляра) PostgreSQL, в котором размещаются базы 1С сервера. Полной архивации достаточно, если на сервере хранятся одна или несколько баз одной компании. Но если на каждом сервере у вас десятки, а то и сотни баз данных разных компаний, такой глобальный архив не совсем удобен при решении оперативных задач.

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

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

Для создания резервной копии отдельной базы используем утилиту pg_dump, которая входит в пакет PostgreSQL. Она позволяет выгрузить базу данных в виде скрипта или в архивном формате. Именно к этому бэкапу будет иметь доступ пользователь в течение 14 дней.

Как сохраняются данные в pg_dump

Бэкапировать базы через pg_dump для нас удобно, так как архивы занимают мало места. А при работе с большим количеством баз данных это очень важное преимущество. Информация переводится в команды и записывается в отдельный файл.

Чтобы развернуть архив, который, по сути, представляет собой набор sql-команд, понадобится система на PostgreSQL.

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

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

Все сценарии бэкапирования проходят автоматически и делятся на несколько этапов.

1. Специальный бот собирает информацию, что нужно заархивировать, и ставит задачи в очередь.
   
   
2. Запускаются файловые менеджеры — воркеры, которые берут задачи из очереди и создают архивы баз.
   
   
3. Если по какой-то причине боты бэкап так и не создали, то задача перенаправляется системному администратору и он уже вручную решает проблему.
   

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