# Резервное копирование и восстановление баз данных внешними средствами > [HTML Version](dump_db.html) Для полного резервного копирования и дальнейшего восстановления ELMA365 необходимо использовать данные следующих компонентов: - PostgreSQL — содержит основные данные системы: пользователей, элементы приложений, процессы, страницы, виджеты, задачи, события, настройки приложений, разделов и другие настройки конфигурации. Предсумотрено два варианта копирования и восстановления PosgreSQL: - для всего кластера — копия создаётся с помощью утилиты `pg\_basebackup`. При восстановлении можно указать дату и время, чтобы получить состояние кластера на этот момент; - для отдельной базы данных кластера — применяются утилиты `pg\_dump` и `pg\_restore`; - MongoDB — содержит неструктурированные системные настройки, данные чатов и ленты. Для копирования базы данных используется утилита `mongodump`, для восстановления — `mongorestore`; - S3 Object Storage — хранит файлы любого типа и объёма: документы, фотографии, аудио- и видеофайлы. Эти данные можно скопировать и восстановить с помощью утилиты `mc`. В статье рассмотрим подготовку к копированию и восстановлению баз данных, а также порядок выполнения этих действий для каждого компонента с помощью специальных утилит. ## Подготовиться к резервному копированию баз данных 1. Для получения доступа к базам данных внутри кластера необходимо пробросить порт соответствующих сервисов: ```` 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- 9000:9000 --address 0.0.0.0 2. ```` Для получения информации о строках подключения к базам данных выполните следующую команду с помощью установленного пакета **jq**. Выберите команду в зависимости от способа установки ELMA365: - если ELMA365 установлена Helm-пакетом в Kubernetes-кластер: ```` 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 Утилита `pg\_basebackup` позволяет делать резервную копию на уровне файловой системы. Её можно использовать для восстановления на определённый момент времени, предварительно настроив **Point-in-time-recovery** (PITR), обеспечивающий непрерывное резервное копирование данных таблиц. Резервные копии всегда создаются для всего кластера базы данных, резервное копирование отдельных баз данных невозможно. ```` начало внимание ```` Резервное копирование выполняется через обычное соединение PostgreSQL и использует протокол репликации. Соединение должно быть выполнено с правами суперпользователя или пользователя с разрешениями REPLICATION. ```` конец внимание ```` Чтобы начать физическое копирование PostgreSQL, выполните следующие шаги: 1. Для создания полной резервной копии примените команду: ```` pg\_basebackup -h -p 5432 -U postgres -D /backup/ -Ft -z -Xs -P 2. ```` Чтобы использовать команду `pg\_basebackup` с удалённого сервера (например, адрес сервера 192.168.1.10), нужно разрешить это подключение. Для этого в файл `pg\_hba.conf` добавьте строку: ```` host replication all 192.168.1.10/32 md5 3. ```` После внесения изменений в `pg\_hba.conf` перезапустите PostgreSQL для их применения. 4. Для непрерывного (**PiTR**) архивирования PostgreSQL требуется включить архивирование **WAL**. Для этого в конфигурационном файле `/etc/postgresql/10/main/postgresql.conf` настройте следующие параметры: ```` wal\_level = replica archive\_mode = on archive\_command = 'test \! -f /backup//postgresql\_archives/%f \&\& cp %p /backup//postgresql\_archives/%f' archive\_timeout = 300 ```` Там же необходимо установить значение параметра `data\_directory`, если оно не определено. Иначе модуль резервного копирования не сможет определить местоположение файлов СУБД, например для PostgreSQL 10: ```` data\_directory = '/var/lib/postgresql/10/main' 5. ```` После внесения изменений перезапустите PostgreSQL при помощи команды: ```` service postgresql restart ```` Значение параметра `archive\_command` должно содержать в файловой системе сервера PostgreSQL каталог, в который будут копироваться архивируемые сегменты **WAL**. ### Выполнить логическое копирование PostgreSQL Утилита `pg\_dump`** **создаёт за один раз резервную копию только одной базы данных, и она не включает информацию о ролях и табличных пространствах. Во время работы `pg\_dump` будут заблокированы только операции, требующие эксклюзивной блокировки. В итоге изменения, вносимые в базу во время работы `pg\_dump`, не будут добавляться в выходной файл архива. Чтобы создать резервную копию введите следующую команду: ```` pg\_dump -C -c --if-exists -F directory -f /backup/ ### ```` Выполнить резервное копирование MongoDB Утилита `mongodump` — это базовый инструмент логического резервного копирования, входящий в состав MongoDB, который создает двоичный экспорт содержимого базы данных или коллекций. Чтобы начать копирование: 1. Используйте команду для создания резервной копии MongoDB: ```` mongodump --uri --gzip --quiet --out /backup/ 2. ```` Если выполняется резервное копирование реплик, включите флаг `--oplog`. Преимущество этого заключается в том, что выходные данные также будут включать в файл `oplog.bson` записи `oplog`, которые фиксируют данные, возникающие во время операции `mongodump`. Файл `oplog.bson` создаётся как часть вывода `mongodump`. Файл содержит записи, которые произошли во время операции `mongodump`. Это обеспечивает эффективный моментальный снимок состояния экземпляра mongod на момент времени. Эта опция работает только для узлов, поддерживающих oplog, т. е. для всех членов набора реплик. ### Выполнить резервное копирование S3 Копирование файлов можно выполнять при помощи любой утилиты, которая подключается к S3, например `mc`. Для этого: 1. Добавьте хост в конфигурации `mc`: ```` mc alias set --api 2. ```` Синхронизируйте содержимое корзины в каталог локальной файловой системы. ```` mc mirror / /backup/ ## ```` Подготовиться к восстановлению баз данных 1. Остановите все сервисы приложения и дождитесь их завершения, например, при помощи команды: ```` kubectl scale deploy --replicas=0 --all -l 'app notin (minio)' \[--namespace \] 2. ```` Пересоздайте базы PostgreSQL и MongoDB. Подробнее об этом читайте в статьях [«PostgreSQL»](postgresql.md#prepare-to-recovery) и [«MongoDB»](mongodb.md#prepare-to-recovery). После этого выполните восстановление баз данных. ## Восстановить базы данных ### Восстановить физическую копию PostgreSQL 1. Для восстановления или запуска на новом месте резервной копии, полученной в результате работы `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//base.tar.gz -C /var/lib/postgresql/10/main tar xvf /backup//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 2. ```` Для восстановления кластера PostgreSQL до состояния, в котором он находился в определённый момент времени, необходимо остановить сервер PostgreSQL, восстановить последнюю полную резервную копию, смонтировать файловую систему с архивными файлами **WAL** и создать файл** **`/var/lib/postgresql/10/main/recovery.conf` со следующим содержимым: ```` restore\_command = 'cp /backup//postgresql\_archives/%f%p' recovery\_target\_time = '2022-02-08 11:20:00 UTC' recovery\_target\_inclusive = false 3. ```` Затем запустите сервер PostgreSQL. При запуске он будет неоднократно вызывать `restore\_command` скрипт получения файлов **WAL** для восстановления базы данных на определенный момент времени. ### Восстановить логическую копию PostgreSQL Чтобы восстановить резервную копию, созданную с помощью `pg\_dump`, используйте утилиту `pg\_restore`: ```` pg\_restore -d -j 1 -F directory /backup/ ### ```` Восстановить MongoDB 1. Для восстановления базы данных выполните команду с утилитой `mongorestore`: ```` mongorestore --uri --dir /backup/ --drop --gzip --preserveUUID ```` Восстановить MongoDB для версии системы ниже 2025.2 Если вы работаете с версией ELMA365 ниже 2025.2, при восстановлении базы данных исключите представление `head.settings.view` с помощью параметра `--excludeCollection`. Это предотвратит возможные ошибки в работе настроек ELMA365 после восстановления. Для этого выполните команду: ```` mongorestore --uri --dir /backup/ --drop --gzip --preserveUUID --excludeCollection=head.settings.view ```` 2. ```` Для восстановления базы данных до состояния, в котором она находилась в определённый момент времени, примените Oplogs. Для этого скопируйте в каталог для восстановления только файл `oplog.bson`, полученный ранее с помощью команды: ```` mongodump --oplog 3. ```` Запустите `mongorestore` с параметром `--oplogReplay`. Убедитесь, что каталог содержит только `oplog.bson`: ```` mongorestore --uri --oplogReplay --dir /backup/ ### ```` Восстановить S3 Восстановление файлов можно выполнять при помощи любой утилиты, которая подключается к S3, например `mc`: 1. Добавьте хост в конфигурации `mc`: ```` mc alias set --api 2. ```` Синхронизируйте содержимое корзины в каталог локальной файловой системы. ```` mc mirror /backup/ / 3. ```` После восстановления резервной копии баз данных необходимо запустить все сервисы приложения, используя команду: ```` kubectl scale deploy --replicas=1 --all \[--namespace \] ```` ``