Экономичная реализация создания резервных копий баз данных PostgreSQL по правилу 3-2-1-1-0 в среде Astra Linux v.1.8.x

В публикации //infostart.ru/1c/reports/2598528/ был представлен проект «Концепция защищенной IT инфраструктуры малого предприятия и пошаговая реализация под Astra Linux + 1c+ PostgresSQL + Ideco UTM + Zabbix», а в публикациях  //infostart.ru/1c/tools/2601755/, //infostart.ru/1c/tools/2620149/ и //infostart.ru/1c/tools/2621823/   размещены   три согласованных скрипта на языках python и bash: сценарий для автоматизации процессов установки и обновления СУБД PostgreSQL +1с в Astra Linux 1.8), архивирование баз данных PostgreSQL на Linux Astra и  сценарий для восстановления баз данных PostgreSQL в Linux .

В проекте было автоматизировано создание резервных копий баз данных по правилу 3-2-1, которое является классической стратегией резервного копирования. В современных реалиях информационной безопасности классическая стратегия перестала быть надежным решением создания резервных копий. Правило «3-2-1-1-0» — это современная эволюция классической стратегии резервного копирования «3-2-1». Оно дополняет проверенную временем схему двумя ключевыми элементами, которые обеспечивают защиту от современных угроз, таких как программы-вымогатели, и гарантируют надежность резервных копий (бэкапов).

Для удобства чтения ниже приведена расшифровка правила 3-2-2-1-0:

• «3»: Три копии данных. Должны быть одна рабочая копия (оригинал) и как минимум две резервные. Это исключает ситуацию, когда повреждение одной копии нарушает информационную безопасность.
• «2»: Два разных типа носителей. Необходимо хранить копии как минимум на двух физически разных типах устройствах.
• «1»: Одна копия вне основной площадки. Одна из копий должна физически находиться в другом месте (вне серверной комнаты). 
• «1» (дополнительная копия): Одна изолированная (Air-gapped) копия. Самое важное дополнение. Одна из копий должна храниться изолированно, на устройстве, физически отключенном от сети. Физическая изоляция подразумевает, что носитель с данными физически отключен от сети и подключается только на время создания бэкапа. Если злоумышленник или вредоносная программа получает доступ ко всем сетевым системам, то возможно удаление или шифрование всего к чему есть доступ, включая большинство бэкапов.
• «0»: Ноль ошибок при восстановлении. Резервная копия, которую невозможно восстановить, не имеет смысла. Эта цифра означает требование регулярно проверять бэкапы. Необходимо периодически выполнять пробное восстановление баз данных из копий, чтобы убедиться в их целостности и работоспособности.

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

Предлагаемое решение не является гарантом отказоустойчивости информационной системы и предполагает, что деловые процессы позволяют прерывать работу пользователей по вводу или обновлению данных информационной системы. Например, подсистема бухгалтерского учета среднестатистического предприятия работает по будним дням от хх часов до yy часов.  Причем, работы по обслуживанию информационной системы и ежедневного архивирования проводятся ночное время. В таком случае, при внезапном отказе информационной системы утраченные данные в пределе могут составлять до одного рабочего дня во временном интервале. Следует заметить, частота создания резервных копий задается в параметрахc планировщика задач cron, см. //infostart.ru/1c/reports/2598528/

Исходные данные:

• Основной сервер под управлением Astra Linux v.1.8.x, на котором установлены сервер 1С, СУБД postgreSQL, скрипты для создания ротационных резервных копий баз данных по правилу 3-2-1 и т.д. Именно этот сервер обслуживает запросы пользователей информационной системы.
• Подчиненный сервер (сервер холодного резервирования основного) с идентичным программным обеспечением, клон основного за исключением актуальности баз данных. Платформа сервера (материнская плата) поддерживает технологию включения по сети wake_on_line.

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

Обобщенно автоматическое включение и последующее выключение подчиненного сервера происходит следующим образом:

• Подчиненный сервер

• В BIOS/UEFI включается функция Wake-on-LAN на сетевой интерфейсе
• В ОС Astra Linux также включается функция Wake-on-LAN на этой же интерфейсе
• Определяется MAC адрес этой сетевой платы
• При выходе из режима гибернации автоматически запускается скрипт sync_and_hibernate_nocipher.sh службой postgres-backup-sync.service, зеркалирующий каталог основного сервера, содержащий резервные копии баз данных, и затем переводящий сервер в режим гибернации (S4).
  • Скрипт перед зеркалированием проверяет признак (флаг, скрытый файл .mirror_allowed), расположенный на основном сервере о том, что некий актуальный архив прошел все проверки на основном сервере, т.е. был восстановлен в тестовую базу, неизменен вирусом шифровальщиком и т.д. Если флаг не содержит текст ALLOWED, то зеркалирование пропускается, соответственно копии архивов не замещаются плохими резервными копиями, и сервер переводится в режим гибернации.

• Основной сервер

• Устанавливается утилита, которая отправляет «магический пакет», включающий подчиненный сервер, находящийся в режиме гибернации (S4) по сети, параметром для утилиты пробуждения служит MAC адрес подчиненного сервера).
• Настраивается задание расписания в планировщике cron:
  • Которое запускает создание ротационных резервных копий баз данных (ежедневные, еженедельные, ежемесячные) на втором накопителе, копирует архивы баз данных на другой сервер в сети
  • Восстанавливает актуальную (ежедневную) резервную копию в тестовую базу данных, тестирует восстановленную базу на признаки работы вируса шифровальщика, проверяет целостность и т.д. Если тестирование успешно, т.е. архив успешно восстановлен и проверен, то в файл .mirror_allowed записывается текст ALLOWED. Если тестирование не успешно, файл  .mirror_allowed удаляется.
  • Автоматически выводит подчиненный сервер из режима гибернации путем отправки магического пакета по сети.

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

В файле nastroika.docx находится:

• Настройка подчиненного сервера
• Скрипт синхронизации бэкапов с основным сервером и гибернации
• Настройка основного сервера
• Скрипт для вспомогательного  сервера