Резервное копирование ELMA365 должно выполняться в составе:
- PostgreSQL — в базе данных хранятся основные данные системы: пользователи, элементы приложений, настройки приложений, разделов, процессы, страницы, виджеты, задачи, события и другие настройки конфигурации;
- MongoDB — в базе данных хранятся неструктурированные системные настройки, данные чатов и ленты;
- S3 Object Storage — в объектном хранилище находятся загружаемые и создаваемые в ELMA365 файлы любого типа и объема, такие как документы, фотографии, аудио и видео файлы.
Для получения доступа к базам данных внутри кластера необходимо пробросить порт соответствующих сервисов:
kubectl port-forward postgres-0 5432:5432 --address 0.0.0.0
kubectl port-forward mongo-0 27017:27017 --address 0.0.0.0
kubectl port-forward minio-<name-pod> 9000:9000 --address 0.0.0.0
Для получения информации о строках подключения к базам данных выполните следующую команду. Для выполнения команды необходимо установить пакет jq.
Для установки ELMA365 чартами в уже существующий Kubernetes-кластер:
kubectl get secrets/elma365-db-connections -o json | jq '.data | map_values(@base64d)'
Для установки ELMA365 в MicroK8s:
microk8s kubectl get secrets/elma365-db-connections -o json | jq '.data | map_values(@base64d)'
Для установки ELMA365 в Kubernetes-in-Docker:
docker exec elma365 kubectl get secrets/elma365-db-connections -o json | jq '.data | map_values(@base64d)'
Резервное копирование
Резервное копирование PostgreSQL
Имеется несколько вариантов создания резервных копий баз данных PostgreSQL.
Вариант 1: Физическое копирование
Утилита pg_basebackup позволяет делать резервную копию на уровне файловой системы. Её можно использовать для восстановления на определённый момент времени, предварительно настроив Point-in-time-recovery (PITR), обеспечивающий непрерывное резервное копирование данных таблиц. Резервные копии всегда создаются для всего кластера базы данных, резервное копирование отдельных баз данных невозможно.
начало внимание
Резервное копирование выполняется через обычное соединение PostgreSQL и использует протокол репликации. Соединение должно быть выполнено с правами суперпользователя или пользователя с разрешениями REPLICATION.
конец внимание
Полная резервная копия создается следующей командой:
pg_basebackup -h <postgresql-server-address> -p 5432 -U postgres -D /backup/<backup-postgresql-folder-name> -Ft -z -Xs -P
Чтобы выполнить команду pg_basebackup с удаленного сервера (например, адрес сервера 192.168.1.10), нужно разрешить это подключение. Для этого в файл pg_hba.conf добавьте строку:
host replication all 192.168.1.10/32 md5
После внесения изменений в pg_hba.conf перезапустите PostgreSQL для их применения.
Для непрерывного (PiTR) архивирования PostgreSQL требуется включить архивирование WAL. Для этого в конфигурационном файле /etc/postgresql/10/main/postgresql.conf настройте следующие параметры:
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /backup/<backup-postgresql-folder-name>/postgresql_archives/%f && cp %p /backup/<backup-postgresql-folder-name>/postgresql_archives/%f'
archive_timeout = 300
Там же необходимо установить значение параметра data_directory, если оно не определено. Иначе модуль резервного копирования не сможет определить местоположение файлов СУБД, например для PostgreSQL 10:
data_directory = '/var/lib/postgresql/10/main'
После внесения изменений перезапустите PostgreSQL при помощи команды:
service postgresql restart
Значение параметра archive_command должно содержать в файловой системе сервера PostgreSQL каталог, в который будут копироваться архивируемые сегменты WAL.
Вариант 2: Логическое копирование
Утилита pg_dump создает за один раз резервную копию только одной базы данных, и она не включает информацию о ролях и табличных пространствах. Во время работы pg_dump будут заблокированы только операции, требующие эксклюзивной блокировки. В итоге изменения, вносимые в базу во время работы pg_dump, не будут добавляться в выходной файл архива.
Резервная копия создается следующей командой:
pg_dump <postgresqlURL> -C -c --if-exists -F directory -f /backup/<backup-postgresql-folder-name>
Резервное копирование MongoDB
Утилита mongodump — это базовый инструмент логического резервного копирования, входящий в состав MongoDB, который создает двоичный экспорт содержимого базы данных или коллекций.
Резервная копия создаётся следующей командой:
mongodump --uri <mongodbURL> --gzip --quiet --out /backup/<backup-mongodb-folder-name>
Можно также включить флаг --oplog в случае резервного копирования набора реплик. Преимущество этого заключается в том, что выходные данные также будут включать в файл oplog.bson записи oplog, которые фиксируют данные, возникающие во время операции mongodump.
Файл oplog.bson создаётся как часть вывода mongodump. Файл содержит записи, которые произошли во время операции mongodump. Это обеспечивает эффективный моментальный снимок состояния экземпляра mongod на момент времени. Эта опция работает только для узлов, поддерживающих oplog, т. е. для всех членов набора реплик.
Резервное копирование S3
Копирование файлов можно выполнять при помощи любой утилиты, которая подключается к S3, например mc.
Добавьте хост в конфигурации mc:
mc alias set <alias> <s3-endpoint> <access-key> <secret-key> --api <api-signature>
Синхронизируйте содержимое корзины в каталог локальной файловой системы.
mc mirror <alias>/<bucket> /backup/<backup-s3-folder-name>
Восстановление из резервной копии
Перед восстановлением баз данных необходимо остановить все сервисы приложения и дождаться их завершения, например, при помощи следующих команд:
kubectl scale deploy --replicas=0 --all -l 'app notin (minio)' [--namespace <elma365-namespace>]
kubectl [--namespace <elma365-namespace>] patch daemonset billing -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}'
Пересоздать базы PostgreSQL и MongoDB. Подробнее об этом читайте в статьях «Установка PostgreSQL» и «Установка MongoDB».
После этого выполните восстановление баз данных.
Восстановление PostgreSQL
Восстановление физической копии PostgreSQL
Для восстановления или запуска на новом месте резервной копии, полученной в результате работы pg_basebackup, достаточно остановить PostgreSQL-сервер, распаковать и подменить содержимое его директории данных базовой резервной копией и архивом WAL. Например, для PostgreSQL версии 10:
systemctl stop postgresql
mv /var/lib/postgresql/10/main /var/lib/postgresql/10/main.old
mkdir /var/lib/postgresql/10/main
tar xvf /backup/<backup-postgresql-folder-name>/base.tar.gz -C /var/lib/postgresql/10/main
tar xvf /backup/<backup-postgresql-folder-name>/pg_wal.tar.gz -C /var/lib/postgresql/10/main/pg_wal
chown -R postgres:postgres /var/lib/postgresql
chmod -R go-rwx /var/lib/postgresql/
systemctl start postgresql
Для восстановления кластера PostgreSQL до состояния, в котором он находился в определённый момент времени, необходимо остановить сервер PostgreSQL, восстановить последнюю полную резервную копию, смонтировать файловую систему с архивными файлами WAL и создать файл /var/lib/postgresql/10/main/recovery.conf со следующим содержимым:
restore_command = 'cp /backup/<backup-postgresql-folder-name>/postgresql_archives/%f%p'
recovery_target_time = '2022-02-08 11:20:00 UTC'
recovery_target_inclusive = false
Затем запустите сервер PostgreSQL. При запуске он будет неоднократно вызывать restore_command сценарий получения файлов WAL для восстановления базы данных на определенный момент времени.
Восстановление логической копии PostgreSQL
Утилита pg_restore восстанавливает резервную копию, созданную утилитой pg_dump.
pg_restore -d <postgresqlURL> -j 1 -F directory /backup/<backup-postgresql-folder-name>
Восстановление MongoDB
Для восстановления базы данных используется утилита mongorestore. Восстановление выполняется следующим образом:
mongorestore --uri <mongodbURL> --dir /backup/<backup-mongodb-folder-name> --drop --gzip --preserveUUID --excludeCollection=head.settings.view
Для восстановления базы данных на момент времени применяется Oplogs. Скопируйте в каталог для восстановления только файл oplog.bson, полученный ранее с помощью команды:
mongodump --oplog
Запустите mongorestore с параметром --oplogReplay (убедитесь, что каталог содержит только oplog.bson)
mongorestore --uri <mongodbURL> --oplogReplay --dir /backup/<backup-mongodb-olplog-folder-name>
Восстановление S3
Восстановление файлов можно выполнять при помощи любой утилиты, которая подключается к S3, например mc.
Добавьте хост в конфигурации mc:
mc alias set <alias> <s3-endpoint> <access-key> <secret-key> --api <api-signature>
Синхронизируйте содержимое корзины в каталог локальной файловой системы.
mc mirror /backup/<backup-s3-folder-name> <alias>/<bucket>
После восстановления резервной копии баз данных необходимо запустить все сервисы приложения, используя следующие команды:
kubectl scale deploy --replicas=1 --all [--namespace <elma365-namespace>]
kubectl [--namespace <elma365-namespace>] patch daemonset billing --type json -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'