Сегодня мы рассмотрим утилиту PG Back Web. Это инструмент для управления резервным копированием PostgreSQL.
Разберём, что умеет это решение и как выглядит его интерфейс. А бонусом покажу примеры развёртывания PG Back Web в Kubernetes.
О продукте
Open Source-решение PG Back Web используют для настройки резервного копирования и управления восстановлением баз данных, работающих под PostgreSQL.
В качестве средства самого резервного копирования PG Back Web использует pg_dump (format=plain). При восстановлении используется вызов psql -f.
PG Back Web также включает в себя средства, с помощью которых можно мониторить доступность базы данных и успешность выполнения заданий резервного копирования.
Лицензия: MIT license.
Поддерживаемые СУБД: PostgreSQL 13, 14, 15 и 16-й версий.
Возможности
Ключевые особенности PG Back Web:
отлично продуманный веб-интерфейс, о котором расскажем подробнее в следующем блоке;
простота развёртывания и настройки;
поддержка резервного копирования как в S3-совместимое объектное хранилище, так и в локальный каталог;
резервное копирование как по требованию, так и по расписанию;
управление жизненным циклом резервных копий;
поддержка шифрования собственных чувствительных данных с помощью PGP;
мониторинг успешного выполнения резервного копирования;
мониторинг доступности PostgreSQL и объектного хранилища;
возможность подключения мониторинга к системе управления инцидентами;
Cloud Ready: решение полностью готово для развёртывания в Kubernetes.
При этом у данного решения есть и недостатки, так как у него отсутствуют:
поддержка резервного копирования PostgreSQL 17 (скоро планируется добавить);
многопользовательский режим с разделением прав;
возможность управления всеми параметрами вызова pg_dump, в том числе невозможно задать
--format=custom;возможность создать резервную копию всех БД экземпляра PostgreSQL средствами pg_dumpall либо pg_basebackup;
поддержка pg_basebackup в принципе;
возможность организовать PITR;
ручные фильтры в списке резервных копий.
Однако я хотел бы отметить, что подавляющее большинство этих недостатков во многом является следствием достоинств решения, а именно — его простоты и универсальности. Используемая модель прекрасно вписывается в идеологию облачных баз данных с подходом «Один экземпляр СУБД = одна база данных». Кроме того, применяемый метод резервного копирования полностью независим от того, где и как развёрнута СУБД и кем она управляется.
Обзор интерфейса
Интерфейс понятен и лаконичен, состоит из основных разделов:
Databases
Destinations
Backups
Executions
Restorations
Webhooks
Databases
Раздел для управления соединениями с базами данных:
Через кнопку «Create database» можно добавить новое соединение. В появившейся форме нужно указать имя, версию PostgreSQL и строку подключения:
Ещё можно перейти в список резервных копий (Executions), отфильтрованных по нужной базе данных:
Destinations
Раздел для управления соединениями с объектными хранилищами:
Через кнопку «Create destination» можно добавить новое соединение. В открывшейся форме нужно указать имя, имя бакета, эндпоинт, регион, ключ доступа и секретный ключ:
Backups
Раздел для управления расписаниями резервного копирования:
При создании расписания нужно указать:
название задания резервного копирования;
выбор одной из настроенных в Databases баз данных;
бэкап в локальный каталог или объектное хранилище:
если бэкап не локальный, то выбор одного из настроенных в Destinations объектных хранилищ;
если локальный, то нужно задать путь к каталогу для бэкапов (Destination directory);
расписание в стандартном формате cron;
время жизни резервных копий.
Время жизни можно указать только в днях. Проверка на актуальность хранимых бэкапов выполняется при каждом старте. Например, если снятие бэкапа настроено раз в час, а срок хранения бэкапов — 1 день, то при каждом успешном выполнении бэкапа будет удален бэкап, сделанный 25 часов назад.
При необходимости можно задать некоторые параметры pg_dump:
У PG Back Web нет доступа к физич��ским серверам, и при настройке бэкапа типа Local подразумевается сохранение резервных копий на диск экземпляра самого PG Back Web. При задании Destination directory для бэкапа типа Local задаётся путь к подкаталогу /backups.
Например, если в настройках указан путь:
...то на диске резервные копии будут храниться здесь:
ls -1 /backups/tmp/tribute/2024/12/27/ dump-20241227-005000-7dc0a663-8562-417c-8be6-f103b71533cd.zip
Если PG Back Web развёрнут в Kubernetes, в каталог /backups должен быть смонтирован volume для хранения дампов.
Из раздела Backups можно вызвать выполнение резервного копирования принудительно, а также перейти в раздел Executions с фильтрацией по конкретному расписанию:
Executions
Раздел со списком всех вызовов операций резервного копирования и удаления резервных копий:
Для операций, завершившихся с ошибкой, можно посмотреть сообщение об ошибке без необходимости обращения к логу пода с приложением:
Кроме того, интерфейс позволяет скачать успешно выполненный дамп:
Restorations
Раздел со списком всех вызовов операций восстановления из резервной копии:
Сама же операция восстановления инициируется из раздела Executions. Для восстановления необходимо выбрать нужную резервную копию, в её контекстном меню выбрать Restore execution и в качестве места назначения восстановления либо выбрать одну из настроенных в разделе Databases БД, либо указать произвольный адрес подключения:
Если PG Back Web развёрнут в Kubernetes, в каталог /tmp должен быть смонтирован volume, так как при восстановлении PG Back Web загружает в этот каталог выбранный дамп, разархивирует его и выполняет вызов вида:
/usr/lib/postgresql/13/bin/psql postgresql://pgbackweb:*******@192.168.199.69:5433/myth -f /tmp/pbw-restore-1423349472/dump.sql
Webhooks
Раздел для настройки мониторинга выполнения резервного копирования, а также для мониторинга доступности баз данных и объектных хранилищ.
Пример настройки мониторинга доступности базы данных с доставкой информации в систему управления инцидентами:
Ошибки выполнения резервного копирования активируют вебхук по факту возникновения инцидента. Проверки доступности баз данных и объектных хранилищ выполняются по расписанию раз в 10 минут.
Для проверки работоспособности резервного копирования, а также для проверки доступности баз данных и объектных хранилищ можно настроить обратную проверку типа Dead Man Switch. Этот механизм подразумевает, что система мониторинга будет получать подтверждение работоспособности каждые 10 минут. Если подтверждение не будет получено в течение установленного времени, система автоматически сгенерирует предупреждение (алерт). Пример настройки DMS:
Пример развёртывания PG Back Web в Kubernetes
StatefulSet приложения:
apiVersion: apps/v1 kind: StatefulSet metadata: name: pgbackweb spec: serviceName: pgbackweb selector: matchLabels: app: pgbackweb replicas: 1 template: metadata: labels: app: pgbackweb spec: containers: - name: pgbackweb image: eduardolat/pgbackweb:0.3.0 envFrom: - secretRef: name: pgbackweb volumeMounts: - name: backup mountPath: /backups - name: tmp mountPath: /tmp resources: requests: cpu: 5m memory: 1Gi limits: memory: 1Gi livenessProbe: failureThreshold: 3 httpGet: path: / port: http scheme: HTTP initialDelaySeconds: 20 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 2 readinessProbe: failureThreshold: 3 httpGet: path: / port: http scheme: HTTP initialDelaySeconds: 10 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 2 ports: - containerPort: 8085 name: http protocol: TCP volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: backup spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi storageClassName: ceph-ssd volumeMode: Filesystem - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: tmp spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi storageClassName: ceph-ssd volumeMode: Filesystem
Secret приложения:
apiVersion: v1 kind: Secret type: Opaque metadata: name: pgbackweb data: PBW_ENCRYPTION_KEY: bGFjaEFrSm9zZGVkcnlzcHlhSG9sdnl1OUZsaWN5YXA= PBW_POSTGRES_CONN_STRING: cG9zdGdyZXNxbDovL3BnYmFja3dlYjppdHNwYXNzd29yZEBwb3N0Z3Jlczo1NDMyL3BnYmFja3dlYj9zc2xtb2RlPWRpc2FibGU= TZ: RXVyb3BlL01vc2Nvdw==
В Secret все значения закодированы в Base64. На всякий случай напомню, что при кодировании значений переменных для Secrets в Base64 необходимо убирать символы переноса строки.
Пример:
echo -n "my_secret_string" | base64 bXlfc2VjcmV0X3N0cmluZw==
Service приложения:
apiVersion: v1 kind: Service metadata: name: pgbackweb spec: clusterIP: None selector: app: pgbackweb ports: - name: http port: 8085
Ingress приложения:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: pgbackweb spec: rules: - host: pgbackweb.mydomain.com http: paths: - path: / pathType: Prefix backend: service: name: pgbackweb port: name: http tls: - hosts: - pgbackweb.mydomain.com secretName: pgbackweb-tls
Здесь следует понимать, что ключ шифрования, задаваемый переменной окружения PBW_ENCRYPTION_KEY, служит не для шифрования резервных копий. Он предназначен для шифрования чувствительных данных пользовательских настроек, которые хранятся в служебной базе данных PostgreSQL. Это необходимо, поскольку доступ к служебной базе данных PG Back Web может иметь не только администратор резервного копирования.
Пример хранения connection string:
postgres=# \c pgbackweb You are now connected to database "pgbackweb" as user "postgres". pgbackweb=# select * from databases limit 1; -[ RECORD 1 ]-----+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- id | 48844f37-6ed2-4456-b424-252d90a76038 name | myth connection_string | \xc30d040703025c1d84c186e9e04e73d2690167eef67bc473e9da442300e2bd3ced1e34d98e67eae0340a6bfc4fd0891e2551e0b6cd3f52878be559a907856a4b3d92d2e2c8d06c69171d8d20ee8c16ef5c81270080010203923a8046d6d264a1d854f24211e95ffcc8a6d8cb4a9cbf3c42edeb868c50111b7b1b pg_version | 13 created_at | 2024-12-19 10:16:33.642688+00 updated_at | 2024-12-28 05:00:00.028803+00 test_ok | t test_error | last_test_at | 2024-12-28 05:00:00.028803+00
Вывод
PG Back Web полностью Cloud Ready, отличается прекрасно продуманным веб-интерфейсом и стабильной работой. Это решение великолепно подойдёт для управления резервным копированием баз данных относительно небольшого размера, работающих под управлением PostgreSQL, то есть в случаях, когда не требуется получения бинарной копии файлов кластера либо задания custom-формата для резервных копий.
P. S.
Читайте также в нашем блоге:
