Кибер Бэкап: резервное копирование БД

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

UPD: Данная статья написана по 15-й версии продукта Кибер Бэкап, в 16-й версии произошли изменения для резервного копирования PostgreSQL, с которыми можно ознакомиться в статье Кибер Бэкап 16: заметочка о мажорчике

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

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

1. Выше скорость резервного копирования
2. Мы не используем дата сеть для передачи резервных копий с сервера
3. Попутно защищаем сервер БД, помимо самих БД

Для корректной работы резервного копирования необходимо, что бы UAC был отключен на машине. Если политики безопасности компании не позволяют отключить UAC, то при настройке резервного копирования необходимо предоставить для работы учётку доменного администратора для корректной работы.

Помимо standalone инсталляции MSSQL также поддерживается резервное копирование Always On SQL Server (AAG). Прочие конфигурации кластера, такие как Failover Cluster Instances, не поддерживаются. Кластер можно бекапить только в агентском режиме и агенты должны быть установлены на всех узлах кластера.

Резервного копирования журналов транзакций нет, соответственно, никакой поддержки Point-In-Time при восстановлении нет, только по тем точкам, когда выполнялось резервное копирование всей базы. Но есть возможность после прохождения резервного копирования обрезать журнал транзакций (при чём независимо от того в каком из режимов вы бекапите базу).

Резервное копирование может осуществляться в 2 вариантах, в зависимости от того из какого раздела вы запускаете создание плана. Если вы делаете это из разделов «Все устройства/Машины с агентами/гипервизор», то в этом случае вы будете делать резервное копирование всей машины + резервное копирование баз MSSQL. Если же создавать план из раздела «Microsoft SQL», то, соответственно, здесь уже будет создаваться только резервная копия самих баз.

Если используется безагентский бекап, то единственный доступный метод восстановления — восстановить базы данных как файлы. Невозможно восстановить базы данных с помощью агента для VMware, требуется установка агента внутрь операционной системы. Без установленного агента невозможно даже увидеть внутри бекапа доступные БД.

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

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

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

MySQL/MariaDB
Чтобы защитить физическую или виртуальную машину, на которой запущены экземпляры MySQL или MariaDB, с помощью резервного копирования с поддержкой приложений, необходимо установить агент для MySQL/MariaDB на этой машине (вручную, на самой машине), как сказано в документации. Хотя никакой гранулярности резервного копирования нет и восстанавливаются все базы целиком, и до конца не ясно, в чём именно состоит поддержка MySQL/MariaDB, если консистентный бекап файлов БД мы можем сделать имея возможность делать снепшот файловой системы. Возможно агент стопает БД целиком на момент создания снепшота?
Резервное копирование должно осуществляться из под root. Кластеры не поддерживаются, также не поддерживаются базы, работающие внутри контейнеров или поверх BTRFS.

Системные базы данных (sys, mysql, information-schema, и performance_schema) и базы данных, которые не содержат никаких таблиц, не могут быть восстановлены в запущенные экземпляры. Однако эти базы данных могут быть восстановлены в виде файлов при восстановлении всего экземпляра.

Вообще резервное копирование MySQL/MariaDB самое простое и писать о нём особо нечего ввиду минимума функционала, который предоставляет сама БД для её резервного копирования и восстановления. Даже путь, куда восстанавливать базу, как это есть в случае с MSSQL при восстановлении MySQL/MariaDB, отсутствует. И самое забавное, что при попытке восстановить копию БД из бекапа на тот же сервер уже не возникает никаких проблем, не нужно указывать другой путь или создать отдельные директории, всё прекрасно восстанавливается автоматически.

Здесь присутствует только та же беда, что и при работе с бекапом MSSQL — необходимо использовать машину с агентом, для просмотра резервных копий MySQL/MariaDB, иначе вы их просто не увидите и не сможете запустить восстановление. Но есть и приятное отличие — если для MSSQL при восстановлении минимальной точкой является именно конкретная база, то при восстановлении MySQL/MariaDB минимальной точкой восстановления является таблица конкретной базы.

PostgreSQL
И так, у нас следующий тип базы данных. Тут уже есть отступления от процесса настройки, которые мы опробовали на MSSQL и MySQL/MariaDB. Первым делом нам необходимо поставить на машину Linux-агента и агента PostgreSQL, после этого снова войти в раздел «Все устройства» на сервере управления и добавить уже PostgreSQL.

Выбирается машина, на которую предварительно были установлены агенты, дальше работа с приложением идёт от лица локально установленного агента, соответственно, в качестве адреса подключения мы используем 127.0.0.1 и учётку, которая может работать с нашим сервером PostgreSQL. После этого в разделе PostgreSQL у нас появится этот сервер, но есть одно «но»

Обратите внимание, что в данном разделе у нас отображается не имя сервера, на котором установлен агент, а адрес хоста, который мы указывали в виде 127.0.0.1, и если мы добавим хотя бы 2 сервера PostgreSQL нам придётся просматривать сведения по каждому из них, что бы увидеть к какому же серверу относится этот PostgreSQL.

Наверное можно добавлять сервер по внешнему ip адресу/dns имени, но я так понимаю, для этого придётся выставлять наш pg сервер портами наружу, что совершенно не есть хорошо с точки зрения безопасности.

План защиты для PostgreSQL должен создаваться из раздела «PostgreSQL», а не из раздела «Машины с агентами», иначе у нас просто не будет возможности делать резервное копирование именно приложения. В данном случае, этот подход отличается и от бекапа MSSQL и от MySQL/MariaDB.

Ещё одно главное отличие в том, что резервные копии PostgreSQL можно сохранять только на тот же сервер, где работает PostgreSQL и установлен агент. Резервное копирование во внешние хранилища не поддерживается вообще.

С восстановлением всё ещё более грустно. Резервная копия восстанавливается в директорию на локальном сервере в виде файлов.

А вот дальше мы забываем про Киберпротект и идём ковыряться уже непосредственно с базой. К сожалению (или наоборот) в Киберпротекте считают, что администратор системы резервного копирования имеет знания/компетенции по ручному восстановлению PostgreSQL или в компании есть эксперт по БД, поэтому даже не потрудились этот процесс в документации как-то отразить. Расстраивает то, что нет никакой интеграции с PostgreSQL при восстановлении у нас нет, а вся резервная копия, это просто копия директории /var/lib/postgresql/12/main/. При этом в документации я прочитал рекомендации при файловом бекапе исключать из бекапа директории pg_wal и pg_replslot, т.к. они могут помешать корректному восстановлению базы.

И так, что же нам делать с тем, что у нас уже есть? Предположим, что мы случайно дропнули базу

1. Останавливаем PostgreSQL
2. По именам директорий сложно определить какая из них к какой БД относится, но в нашем случае — мы просто дропнули базу и её нет, так что путём сравнения двух директорий base мы можем найти пропажу (ну либо удаляем вообще всё из директории /var/lib/postgresql/12/main/ и переносим туда всё из резервной копии)
   
   Также не стоит забывать и о правах на файлы, которые мы достали из резервной копии
   
3. Далее нам необходимо создать в директории с БД файл recovery.signal, который при запуске PostgreSQL сообщит ему, что он должен запуститься в режиме восстановления.
4. Следующим шагом будет указать в конфигурационном файле движку базы что мы хотим, чтобы он сделал при запуске в режиме восстановления. Нам необходимо чтобы он перечитал журналы транзакций и для этого мы в конфигурационный файл postgresql.conf (обратите внимание, что конфигурационный файл находится не в той же директории, что и сама база) добавляем следующую команду:
   restore_command = ‘cp /var/lib/postgresql/12/main/pg_wal/%f «%p»‘
   пусть /var/lib/postgresql/12/main/pg_wal/ соответствует размещению файлов транзакций. Если вы храните его где-то отдельно, необходимо указать верный путь, иначе при запуске он не сможет прочитать журналы
5. Запускаем PostgreSQL и наблюдаем за процессом в лог файле. Должно быть что-то типа
   LOG: restored log file «00000003.history» from archive
   LOG: restored log file «00000003000000000000000F» from archive
   LOG: consistent recovery state reached at 0/F000278
6. Удаляем из postgresql.conf нашу restore_command, файл recovery.signal уже должен быть автоматически удалён
7. Снова перезапускаем PostgreSQL уже в обычном режиме

В конце у меня возникает один вопрос — зачем вообще нужен такой бекап, при том, что сам PostgreSQL имеет набор инструментов, которые это делают реально лучше — pg_dump, pg_basebackup, wal-g, ну или использовать какой-нибудь pgAdmin.

UPD: Данная статья написана по 15-й версии продукта Кибер Бэкап, в 16-й версии произошли изменения для резервного копирования PostgreSQL, с которыми можно ознакомиться в статье Кибер Бэкап 16: заметочка о мажорчике

И так, что же мне не нравится во всём этом многообразии

1. Отсутствие возможности безагентского восстановления MSSQL
2. Отсутствие безагентского бекапа и, соответственно, восстановления для MySQL/MariaDB/PostgreSQL
3. Разный подход к резервному копированию баз и его настройки, различия в самом процесс восстановления (без учёта особенностей каждой из БД)
4. Невозможность использовать сам сервер управления для просмотра резервных копий, содержащих БД и запуск процесса восстановления (пусть он восстанавливается при помощи агента на целевом сервере, но по крайней мере позволит просмотреть и запустить процесс восстановления с сервера управления, что сильно облегчит жизнь администратора РК)
5. Необходимость при просмотре резервной копии в хранилище для каждой копии выбирать при помощи какого сервера просматривать резервные копии. Во-первых — это само по себе не удобно, во-вторых — это прибавит сложностей в случае большой инфраструктуры
6. Для установки агента необходимо тащить на сервер полный дистрибутив в 1.5Гб. При этом ещё очень расстраивает, что при скачивании агента, ссылка на него выглядит как https://192.168.1.27:9877/api/ams/links/agents/redirect?language=multi&system=linux&architecture=64&productType=enterprise&login=S-1-5-21-463410400-1718700978-1441927102-500, и ни с wget, ни с curl, мне не удалось победить редирект. Приходилось напускать скачивание со своей машины, останавливать и копировать ссылку на скачиваемый файл, которая оказывалась просто ссылкой на последнюю версию линуксового инсталятора с сайта Киберпротект (а если выход в инет с серверов закрыт)? В общем так и не понял зачем всё это нужно и почему нельзя сделать возможность прямого скачивания агента с сервера управления куда в агента в любом случае должен быть сетевой доступ