В этой статье:
В рамках практического вебинара серии «Быстрый старт» мы разобрали защиту СУБД PostgreSQL средствами Кибер Бэкапа. В эфире показали, как развивалась наша СРК, какие возможности доступны сейчас и как проходят процессы резервного копирования и восстановления. Вебинар провел руководитель группы второй линии технической поддержки Алексей Герасимов.
Эволюция поддержки PostgreSQL в Кибер Бэкапе
Поддержка PostgreSQL в продукте развивалась поэтапно, закрывая новые требования бизнеса к скорости и надежности резервного копирования.
- Версия 15.0
Появилась базовая поддержка. Доступно только полное резервное копирование с сохранением на локальные диски.
- Версия 16.0
Добавлены инкрементные копии и новые схемы резервного копирования (всегда полная копия, еженедельно полная + ежедневно инкрементная, пользовательское расписание). Появилась поддержка сетевых хранилищ, узлов хранения и лент.
- Версия 16.5
Добавлено гранулярное восстановление (отдельных баз и таблиц), восстановление на момент времени (PITR), монтирование экземпляра для просмотра без полного развертывания и выгрузка в дамп-файл. Также реализована поддержка кластеров Patroni.
- Версия 17.0
Расширены возможности хранения: в качестве хранилища можно использовать Кибер Инфраструктуру и внешние S3-совместимые сервисы.
- Версия 17.1
Добавлена поддержка кластеров Patroni для базы данных самого сервера управления. Появились Pre- и Post- команды для выполнения скриптов до и после операций резервного копирования.
- Версия 17.3
Снято ограничение системной утилиты PostgreSQL на восстановление баз данных с большими объектами.
- Версия 18.0
Внедрена многопоточность для полного файлового резервного копирования и восстановления экземпляров PostgreSQL.
- Версии 18.5/18.6
Представлены новые схемы инкрементного резервного копирования (файловый инкремент, файловый инкремент + журнал транзакций). Они поддерживают многопоточность для экземпляров PostgreSQL и СУБД на его основе.
Базовые принципы защиты реляционных баз данных мы подробно разбирали в статье «Резервное копирование СУБД PostgreSQL».
Какие проблемы решали в версии 18.0/18.1
Изначально полное резервное копирование использовало механизм base backup через репликационное соединение. Это позволяло размещать агента удаленно, но накладывало ограничения на скорость.
-
Проблема 1: низкая производительность
Base backup работал в один поток. При росте объемов баз данных потолок копирования составлял около 20 ТБ за 8-часовое окно. Решение — переход на локальное многопоточное резервное копирование.
-
Проблема 2: долгое восстановление
При классической схеме инкрементов для восстановления на нужную дату СУБД приходилось «проигрывать» все накопленные журналы транзакций (WAL-файлы) за прошедшие дни. Это занимало много времени и напрямую влияло на показатели RTO.
Новый подход в версии 18.5/18.6
Инкременты на основе WAL-файлов заменили журнальными. Теперь резервная копия представляет собой совокупность изменившихся блоков файлов. Это дало ощутимый прирост:
-
Скорость резервного копирования выросла в 2–6 раз (в зависимости от хранилища).
-
Для восстановления нужно проигрывать в 7 раз меньше WAL-файлов. Рекомендуемая схема теперь выглядит так: «еженедельно полная, ежедневно инкрементная, ежечасно журналы».
Ограничением стало то, что для новых инкрементов агент должен быть установлен локально на сервере с базой данных, а поддержка симметричной работы с кластерами была временно утрачена (решение появилось в версии 19.0).
Практическая демонстрация
Для демонстрации защиты PostgreSQL использовался тестовый стенд: в инфраструктуру вошли сервер управления Кибер Бэкапа 18.6, standalone-хост с PostgreSQL, кластер Patroni на трех нодах и отдельная виртуальная машина для удаленного агента. Операционная система — РЕД ОС 7 и 8.
Подготовка к защите и установка агента
Перед началом резервного копирования необходимо установить агента и правильно настроить саму СУБД. Агент для PostgreSQL устанавливается из общего Linux-дистрибутива. Важно отметить: агент Postgres зависит от базового Linux-агента. При установке также необходимо проверить наличие системных пакетов для модуля SnapAPI, хотя для работы именно с базами данных они не критичны (понадобятся только для бэкапа томов).
Создание планов защиты
На демо показали разницу в настройке планов для одиночного сервера и для кластера. Для кластера Patroni использовалась схема с полной копией и журналами транзакций. При такой схеме создается репликационный слот, который удерживает WAL-файлы до следующего бэкапа.
Для standalone-хоста настроили схему «еженедельно полная и ежедневно инкрементная» с использованием нового механизма инкрементов. В этом случае Кибер Бэкап работает с измененными блоками файлов и не удерживает WAL-файлы. После создания планов запустили несколько копий для формирования наглядных цепочек восстановления.
Точки восстановления и слоты репликации
Начиная с Кибер Бэкапа 17.6 интерфейс архива стал удобнее. Если выполняется несколько копий журналов транзакций подряд, они отображаются не отдельными точками, а одной записью с указанием временного диапазона. Внутри этого диапазона можно выбрать конкретное время для восстановления.
В демонстрации также разобрали поведение слотов репликации. В схемах с журналами транзакций слот создается при полной копии и висит постоянно, удерживая WAL-файлы. В схемах только с полными копиями или инкрементами слот создается временно — только на период выполнения задания, а затем удаляется.
Механизм fallback
Что произойдет, если слот репликации удалить (случайно или намеренно)? В демонстрации сымитировали эту ситуацию. Продукт не завершил задание с ошибкой. Вместо этого сработал механизм отказоустойчивости: Кибер Бэкап создал новый слот и вместо запрошенной копии журнала выполнил полную резервную копию, завершив задание с предупреждением. Данные при этом остались защищены.
Восстановление экземпляра как файлы
Самый быстрый способ восстановления — развернуть весь экземпляр базы данных в виде файлов. В ходе демо показали, что для этого не обязательно использовать того же агента, который создавал резервную копию. Агент просто извлекает файлы из архива и помещает их в указанную локальную директорию. Это занимает меньше минуты (в условиях тестового стенда) и требует минимум вычислительных ресурсов.
Гранулярное восстановление
Если нужно восстановить только одну базу, следует использовать гранулярное восстановление. Для этого агенту требуется указать в конфигурационном файле путь до бинарных файлов PostgreSQL. В ходе демо также возникла ошибка нехватки места во временной директории (no space left on device). Показали, как перенастроить агента на использование другой папки с достаточным объемом памяти, и успешно завершили восстановление.
Монтирование экземпляра
Если данные не нужно восстанавливать, а нужно просто просмотреть их, используется монтирование. Экземпляр подключается напрямую из резервной копии за пару секунд. С ним можно работать, делать запросы, но изменения в него не сохраняются. Это безопасный способ работы с архивом. Для монтирования также важно следить за свободным местом во временной директории.
Сессия вопросов и ответов
В заключительной части вебинара Алексей Герасимов ответил на вопросы участников. Собрали главное из ответов на самые актуальные вопросы:
- О лицензировании нескольких баз на одном сервере
Лицензия привязана к экземпляру. Если на одном сервере работает пять экземпляров PostgreSQL, потребуется пять лицензий. Если же это кластер Patroni (один экземпляр на нескольких нодах) — потребуется только одна лицензия.
- Об использовании библиотеки
libpgprobackup
Она предназначена для работы с Postgres Pro (Standard и Enterprise версий 15-18). На ванильном PostgreSQL есть ограничения.
- Об ограничениях лент
С лент можно восстановить только весь экземпляр целиком в виде файлов. Гранулярное восстановление недоступно из-за архитектурных особенностей ленточных накопителей (последовательное чтение). Подробнее о том, насколько актуальны ленты сегодня, мы писали в статье «Магнитная лента: антикризисное управление для ваших данных».
- О больших базах (от 2,5 ТБ)
В тестах продукт с такими объемами работал, однако при возникновении проблем рекомендуется обращаться в техническую поддержку для детального анализа логов.
- Об уведомлениях
Система позволяет гибко настраивать оповещения на почту или в панель мониторинга — по ошибкам, предупреждениям или только по успешным заданиям.
Связанные статьи
26.11.2026 15:00 МСК
Вы успешно подписались на рассылку Киберпротект!
