Vinchin: резервное копирование PostgreSQL
Если вы интересуетесь новыми для нашего рынка продуктами для резервного копирования вместо ушедших европейских вендоров, то про Vinchin вы уже скорее всего слышали, а возможно даже читали обзоры (раз, два) на Хабре. Но эти статьи больше обзорные, из серии — «всё поддерживается, но для работы нужно поковыряться и пообщаться с поддержкой». Я же люблю копать и рассказывать в глубину, чтобы статью можно было использовать как некое руководство, которое кому-то возможно сэкономит немного времени и будет полезно. Поэтому сегодня будем говорить о том, как резервное копирование PostgreSQL в Vinchin не всегда работает из коробки.
Начну с признания — я не DBA, совсем не DBA. Для меня база данных — это набор таблиц, а что там кроется за всем этим я представляю довольно слабо, поэтому в рамках тестового стенда я прибегаю к наиболее простейшей установке. Но стоит сразу оговориться — на сегодняшний день (версия 6.7) Vinchin поддерживает резервное копирование PostgreSQL только на базе CentOS 7 и CentOS 8. У нас в компании множество проектов с PostgreSQL, но я не работаю с ними очень активно, и тем более не работаю в роли DBA, так что у меня нет статистики по используемым версиям, поэтому я решил пойти наиболее простым путём и взял последнюю версию из 13-й ветки:
dnf module list postgresql dnf module enable postgresql:13 dnf install postgresql-server postgresql-setup --initdb
Вот моя база и готова, я даже закинул туда немного тестовых данных. Дальше, как любой нормальный человек, я не пошёл читать документацию 🙂 Я стал искать — где же найти агента для PostgreSQL? На сайте ничего не нашёл, полазил по интерфейсу Vinchin и тоже ничего не нашёл. Пришлось всё-таки читать документацию.
Вот скажите мне — кто додумался скачивание агентов разместить на странице авторизации???
Конечно же после развёртывания системы при первом логине я поставил галочку «запомнить пароль» (благо в домашней лабе это не нарушает политики безобразности) и никогда больше форму эту не видел. Уже на этом этапе я стал понимать, что тут с подходом в стиле Veeam Next-Next-Finish делать нечего и стоит внимательнее смотреть в документацию (хотя честно — Vinchin во многом напоминает мне Veeam). Тут я ещё побомблю, как и в случае со скачиванием агентов Кибербекапа — ну почему нельзя дать ссылку, вместо скачивания архива с агентом? Ведь намного проще скопировать ссылку и на целевой машине сделать wget link, ну а если у нас порты закрыты или ещё что-то, в браузере просто кликаем по ссылке и уже скачиваем файл. Ну ведь удобно же? Или это только мне так кажется? Но тут хотя бы любой желающий может зайти по адресу серверу правления и без необходимости авторизации скачать нужного агента.
Ладно, вернёмся к основной части. И так, у нас есть плагин под Linux для PostgreSQL. Как говорят ребята из Vinchin — это универсальный агент, который должен подходить для любых инсталляций, но как показала практика — это не так (мне не удалось от них добиться чёткого ответа, связку каких версий ОС и PostgreSQL он поддерживает). В частности, как я понял, связка CentOS 8 Stream + PostgreSQL 13.7, которую я у себя развернул — не поддерживается текущим агентом, и ребята из Vinchin выслали мне отдельный плагин под них с номером 6.0.7.23718 (с портала Vinchin скачивается версия 6.7.0.22042). Поддержка заверяет, что с выходом Vinchin версии 7, этот плагин будет иметь бОльшую совместимость и таких проблем возникать не должно (лично я надеюсь на расширение поддержки операционных систем).
Агент устанавливается очень просто — распаковываем архив и запускаем ./db_backup_agent_install. Но, как пишет поддержка:
The plug-in needs to be stored in the /root directory and installed with the root user, otherwise the restoration job cannot be performed when it involves creating a directory and changing directory permissions.
Далее стоит проверить, что службы Vinchin запустились
После этого переходим в сам Vinchin и по инструкции добавляем наш сервер
Присваиваем лицензию
Но если сейчас мы попытаемся авторизоваться в нашем инстансе — мы получим ошибку
Отсюда и начинаются наши основные приключения. Заключаются они в том, что конфигурацию базы нужно привести к определённому виду, а именно:
В pg_hba.conf должна быть выставлена авторизация md5 или scram-sha-256. Причём она так же должна быть и для IPv6, даже если вы его не используете. Также необходимо добавить
host all all 0.0.0.0/0 trust
Не готов комментировать это с точки зрения ИБ, лично у меня это вызывает вопросы, но это рекомендация вендора;
Теперь postgresql.conf
listen_addresses должен содержать адрес вашего сервера, помимо localhost, т.е. его нужно привести к виду
listen_addresses = '192.168.1.36,localhost'
идём дальше
wal_level = replica archive_mode = on archive_command = 'test ! -f /var/lib/pgsql/archivedir/%f && cp %p /var/lib/pgsql/archivedir/%f'
здесь важно следить за путями, у меня pgsql находится в /var/lib/, но у вас путь может отличаться. Все подробности по данным параметрам можно найти в документации. Также важно отметить, что директории archivedir по-умолчанию не существует и её нужно создать и самое главное — дать на неё права юзеру postgres.
Так же следует проверить где находится бинарник postgres в вашей системе
У меня это /usr/bin/, соответственно, его и необходимо указывать в настройках подключения в Vinchin
Несмотря на то, что при подключении мы указываем конкретную базу данных, Vinchin будет видеть их все
Также вендор рекомендует использовать учётную запись postgres, но я бы всё-таки выбрал путь создания отдельной учётной записи с аналогичными правами для резервного копирования.
После удачного подключения мы получаем нашего агента — лицензированного и в состоянии online
После чего можно перейти уже к непосредственному процессу настройки резервного копирования.
Что необходимо упомянуть относительно самих заданий на бекап и восстановление:
- Бекапится инстанс целиком, т.е. все базы сразу, гранулярно поставить на бекап одну или несколько баз не получится
- Нет и гранулярного восстановления баз и таблиц, восстанавливается весь инстанс целиком
- У нас есть 2 режима бекапа БД — полный и бекап Archive Log. Если сходу взглянуть на настройки расписания, можно не понять, как именно настроить ежечасное (к примеру) резервное копирование логов, а делается это при помощи переключателя Repeat вот таким образом
Восстановление данных не вызвало затруднений и работает так, как описано в документации. На этой позитивной ноте я сегодня и закончу.
