Перейти к основному содержимому
Версия: Next

Создание резервной копии и восстановление

Для создания резервной копии инсталляции платформы, необходимо сделать бэкапы:

  1. Состояния кластера и Persistent Volumes
  2. MongoDB
  3. PostgreSQL
tip

Создание резервной копии для баз данных MongoDB и PostgreSQL не требуется, если восстановление будет осуществляться в то же окружение, с теми же параметрами:

  • такие же имена ресурсов
  • такой же namespace
  • те же credentials

В этом случае достаточно резервной копии состояния кластера с Persistent Volumes

Создание резервной копии​

Состояние кластера и Persistent Volumes​

По умолчанию, вместе с платформой устанавливается оператор Velero, который путем создания Custom Resource может создавать резервные копии кластера и Persistent Volume как по требованию, так и по расписанию. По умолчанию настраивается ежедневное бэкапирование состояния кластера. Резервные копии сохраняются во внешнем S3-совместимом хранилище.

C4Component title Схема бэкапирования с помощью Velero ContainerDb(s3, "S3 Storage", "", "Внешнее хранилище бэкапов") Person(admin, "Администратор", "Сотрудник, занимающийся администрированием кластера") Boundary(k8sapi, "Kubernetes Cluster", "", "") { Component(velero, "Velero", "", "Velero backup controller", $link="https://www.google.com") Component(k8sapi, "Kubernetes API", "", "") ComponentDb(etcd, "etcd", "", "") Rel(velero, k8sapi, "Получает состояние кластера") Rel(k8sapi, etcd, "") Rel(velero, s3, "Сохраняет бэкапы") } Rel(admin, k8sapi, "velero backup create <...>") UpdateRelStyle(velero, k8sapi, $offsetY="20") UpdateRelStyle(admin, k8sapi, $offsetY="-40")

Для бэкапирования ресурсов кластера k8s и PV используется инструмент Velero

Исполнение процедуры бэкапирования осуществляется с помощью bash-скрипта размещенного на инстансе в k8s-кластере.

Для корректной работы bash-скрипта техническим администратором системы определяются следующие переменные:

  • NAMESPACE - Namespace который необходимо бэкапировать.

Путь по которому сохраняется бэкап кластера задается при конфигурировании Velero.

Скрипт бэкапирования должен запускаться ежедневно с помощью утилиты cron.

Далее представлен пример скрипта используемый для бэкапирования:

# Определение пользовательских переменных
NAMESPACE=yournamespace # Namespace для бэкапирования

# Определение технических переменных
BACKUP_NAME=backup-$(date +%Y%m%d%H%M) # Временная метка бэкапа

velero backup create $BACKUP_NAME --include-namespaces $NAMESPACE

База данных MongoDB​

Бэкапирование MongoDB осуществляется стандартными средствами, предусмотренными MongoDB. Исполнение процедуры бэкапирования и размещение бэкапа в постоянное хранилище осуществляется с помощью bash-скрипта размещенного на инстансе в k8s-кластере.

Для корректной работы bash-скрипта техническим администратором системы определяются следующие переменные:

  • NAMESPACE - Имя namespace котором развернута MongoDB
  • BACKUP_HOST_DIR - Путь до постоянного места хранения бэкапа.
note

В переменную BACKUP_HOST_DIR возможно указывать любой путь доступный с хоста на котором исполняется скрипт, в т.ч. удаленные хосты, S3-совместимые хранилища и т.д.

Скрипт бэкапирования должен запускаться ежедневно с помощью утилиты cron.

Скрипт реализует следующий сценарий:

  1. Стандартными средствами MongoDB создаются архивы схем MongoDB, внутри контейнера MongoDB
  2. Полученные архивы копируются в директорию указанную в переменной BACKUP_HOST_DIR
  3. Архивы созданные внутри контейнера MongoDB удаляются, чтобы избежать переполнения памяти постоянного хранилища сервера, на котором расположен контейнер с MongoDB

Далее представлен пример скрипта используемый для бэкапирования:

# Определение пользовательских переменных
NAMESPACE=yournamespace # Namespace в котором развернута MongoDB
BACKUP_HOST_DIR=~/backups/mongodb # Путь до постоянного места хранения бэкапа

# Определение технических переменных
# Временная метка "сейчас"
NOW=$(date +%Y%m%d%H%M)
# Название pod'а MongoDB в кластере
POD_NAME=$(kubectl -n $NAMESPACE get pod -l \
  app.kubernetes.io/instance=agg-ext,app.kubernetes.io/name=aggregion-externals-mongo-agg-ext \
  --no-headers -o custom-columns=":metadata.name")

mkdir -p $BACKUP_HOST_DIR # Создание директории для бэкапа
# создание бэкапа схемы Back-end API внутри pod'а MongoDB в кластере
kubectl -n $NAMESPACE exec -it $POD_NAME -- sh -c "mongodump --db=dmp --gzip --archive=/tmp/backup_dmp.gzip"
# создание бэкапа схемы DataService внутри pod'а MongoDB в кластере
kubectl -n $NAMESPACE exec -it $POD_NAME -- sh -c "mongodump --db=ds --gzip --archive=/tmp/backup_ds.gzip"
# копирование бэкапа из pod'а в директорию хоста хранилища бэкапа
kubectl cp $NAMESPACE/$POD_NAME:/tmp/backup_dmp.gzip $BACKUP_HOST_DIR/backup_dmp_$NOW.gzip
# копирование бэкапа из pod'а в директорию хоста хранилища бэкапа
kubectl cp $NAMESPACE/$POD_NAME:/tmp/backup_ds.gzip $BACKUP_HOST_DIR/backup_ds_$NOW.gzip
#удаление бэкапов из pod'а
kubectl -n $NAMESPACE exec -it $POD_NAME -- sh -c "rm -rf /tmp/*.gzip"

ESP​

Так как ESP поднят в докере и у него свой инстанс MongoDB, то процедура бекапа будет отличаться от представленной выше, но логика такая же.

ESP_MONGODB_CONTAINER_ID=$(docker ps --filter "name=session-provider.*mongodb" --format "{{.ID}}") # Определяем идентификатор контейнера с MongoDB
BACKUP_HOST_DIR=~/backups/mongodb # Путь до постоянного места хранения бэкапа
NOW=$(date +%Y%m%d%H%M)

mkdir -p $BACKUP_HOST_DIR

docker exec -ti $ESP_MONGODB_CONTAINER_ID sh -c "mongodump --db=sessionProvider --gzip --archive=/tmp/backup_esp.gzip"
docker cp $ESP_MONGODB_CONTAINER_ID:/tmp/backup_esp.gzip $BACKUP_HOST_DIR/esp.$NOW.gzip
docker exec -ti $ESP_MONGODB_CONTAINER_ID sh -c "rm -f /tmp/backup_esp.gzip"

База данных PostgreSQL​

Бэкапирование PostgreSQL осуществляется стандартными средствами, предусмотренными PostgreSQL. Исполнение процедуры бэкапирования и размещение бэкапа в постоянное хранилище осуществляется с помощью bash-скрипта размещенного на инстансе в k8s-кластере.

Для корректной работы bash-скрипта техническим администратором системы определяются следующие переменные:

  • DC_NAMESPACE - Имя namespace котором развернута PostgreSQL;
  • BACKUP_HOST_DIR - Путь до постоянного места хранения бэкапа.
note

В переменную BACKUP_HOST_DIR возможно указывать любой путь доступный с хоста на котором исполняется скрипт, в т.ч. удаленные хосты, S3-совместимые хранилища и т.д.

Скрипт бэкапирования должен запускаться ежедневно с помощью утилиты cron.

Скрипт реализует следующий сценарий:

  1. Стандартными средствами PostgreSQL создается .dump файл всех баз данных PostgreSQL, внутри pod'а PostgreSQL
  2. Полученные .dump файлы копируются в директорию указанную в переменной BACKUP_HOST_DIR
  3. .dump файлы созданные внутри pod'а PostgreSQL удаляются, чтобы избежать переполнения памяти постоянного хранилища кластера, на котором расположен pod с PostgreSQL

Далее представлен пример скрипта используемый для бэкапирования:


# Определение пользовательских переменных
DC_NAMESPACE=aggregion-dc # Namespace в котором развернута PostgreSQL
BACKUP_HOST_DIR=~/backups/postgres # Путь до постоянного места хранения бэкапа

# Определение технических переменных
NOW=$(date +%Y%m%d%H%M) # Временная метка "сейчас"
# Название pod'а PostgreSQL в кластере
POD_NAME=$(kubectl -n $DC_NAMESPACE get pod -l \
  app.kubernetes.io/instance=deploy-controller,app.kubernetes.io/name=aggregion-externals-postgres-deploy-controller \
  --no-headers -o custom-columns=":metadata.name")

# создание бэкапа внутри pod'а PostgreSQL в кластере
kubectl -n $DC_NAMESPACE exec -it $POD_NAME -- sh -c "pg_dumpall -U postgres > /tmp/postgres.dump"
# копирование бэкапа из pod'а в директорию хоста хранилища бэкапа
kubectl cp $DC_NAMESPACE/$POD_NAME:/tmp/postgres.dump $BACKUP_HOST_DIR/postgres.$NOW.dump
#удаление бэкапов из pod'а
kubectl -n $DC_NAMESPACE exec -it $POD_NAME -- sh -c "rm -rf /tmp/*.dump"

CAS​

Т.к. CAS использует свою, проприетарную внутренню СУБД, бекап делается путём копирования данных БД этого сервиса.

NOW=$(date +%Y%m%d%H%M)
TMP_BACKUP_DIR=/tmp/cas_data_$NOW
BACKUP_DIR=~/backups/cas

CAS_CONTAINER_ID=$(docker ps --filter "name=scone.*cas" --format "{{.ID}}") # Определяем идентификатор контейнера с CAS
CAS_DATA_PATH=$(docker inspect $CAS_CONTAINER_ID | jq -r '.[0].Mounts | map(select(.Destination | contains("/data"))) | .[0].Source')
CAS_CONFIG_PATH=$(dirname $(docker inspect $CAS_CONTAINER_ID | jq -r '.[0].Mounts | map(select(.Destination | contains("/etc/cas/cas.toml"))) | .[0].Source'))

mkdir -p $BACKUP_DIR
mkdir -p $TMP_BACKUP_DIR

cp -fR $CAS_DATA_PATH $TMP_BACKUP_DIR
cp -fR $CAS_CONFIG_PATH $TMP_BACKUP_DIR

cd $TMP_BACKUP_DIR
tar -czvf $BACKUP_DIR/cas_data.$NOW.tar.gz ./
rm -rf $TMP_BACKUP_DIR

Восстановление из резервной копии​

Далее описаны скрипты необходимые для восстановления из резервной копии. Этот алгоритм возможно использовать как при аварийно восстановительных работах, так и при плановом перемещении кластера на другие сервера.

caution

В случае восстановления или переезде системы настоятельно рекомендуется иметь только 1 инстанс подключенный к Blockchain, поскольку 2 одновременно рабочих инстанса могут создавать конкурентные записи в смарт-контрактах Blockchain от лица вашей компании.

Состояние кластера и Persistent Volumes​

Восстановление ресурсов k8s-кластера из бэкапа осуществляется с помощью Velero.

Для упрощения процесса восстановления ресурсов k8s-кластера из бэкапа реализован bash-скрипт предназначенный для переноса и применения бэкапов ресурсов k8s-кластера из постоянного хранилища бэкапов.

Для корректной работы bash-скрипта техническим администратором системы определяются следующие переменные:

  • BACKUP_NAME - наименование бэкапа в хранилище бэкапов
  • NAMESPACE - восстанавливаемый Namespace
# Определение пользовательских переменных
BACKUP_NAME=backup-202207251115 # Наименование бэкапа в хранилище бэкапов
NAMESPACE=yournamespace # восстанавливаемый Namespace

# Определение технических переменных
RESTORE_NAME=restore-$(date +%Y%m%d%H%M) # наименование оперции восстановления

# Восстановление данных
velero restore create $RESTORE_NAME --from-backup $BACKUP_NAME --namespace-mappings $NAMESPACE:$NAMESPACE-restored

MongoDB​

Восстановление данных MongoDB из бэкапа предусматривается с помощью стандартных средств MongoDB. Для упрощения процесса восстановления данных из бэкапа реализован bash-скрипт предназначенный для переноса и применения бэкапов MongoDB из постоянного хранилища бэкапов.

Для корректной работы bash-скрипта техническим администратором системы определяются следующие переменные:

  • NAMESPACE - Имя namespace котором развернута MongoDB;
  • BACKUP_HOST_DIR - Путь до постоянного места хранения бэкапа;
  • BACKUP_TIME - Временная метка которую необходимо восстановить.
note

В переменную BACKUP_HOST_DIR возможно указывать любой путь доступный с хоста на котором исполняется скрипт, в т.ч. удаленные хосты, S3-совместимые хранилища и т.д.

Скрипт реализует следующий сценарий:

  1. Копирование бэкап файла из постоянного хранилища бэкапов в pod с MongoDB;
  2. Восстановление данных из бэкапа стандартными средствами MongoDB.
caution

В случае если требуется восстановления данных только одной из схем, рекомендуется восстанавливать обе схемы, поскольку данные между ними связанны и восстановление только одной схемы может привести к неконсистентности данных!

caution

В случае восстановления данных из бэкапа рекомендуется остановить все сервисы взаимодействующие с MongoDB!

Список сервисов взаимодействующих с MongoDB возможно уточнить в описании компонентов по ссылке.

Далее представлен пример скрипта используемый для бэкапирования:

# Определение пользовательских переменных
NAMESPACE=yournamespace # Namespace в котором развернута MongoDB которую необходимо восстановить
BACKUP_HOST_DIR=~/backups/mongodb # Путь до источника бэкапа
BACKUP_TIME=202207251115 # Временная метка бэкапа, который необходимо восстановить

# Определение технических переменных
# Определение названия pod'а MongoDB в кластере
POD_NAME=$(kubectl -n $NAMESPACE get pod -l \
  app.kubernetes.io/instance=agg-ext,app.kubernetes.io/name=aggregion-externals-mongo-agg-ext \
  --no-headers -o custom-columns=":metadata.name")

# Копируем файлы в контейнер
# копирование бэкапа схемы для Back-end
kubectl cp $BACKUP_HOST_DIR/backup_dmp_$BACKUP_TIME.gzip $NAMESPACE/$POD_NAME:/tmp
# копирование бэкапа схемы для DataService
kubectl cp $BACKUP_HOST_DIR/backup_ds_$BACKUP_TIME.gzip $NAMESPACE/$POD_NAME:/tmp

# Восстанавливаем данные
# Восстановление данных схемы для Back-end
kubectl -n $NAMESPACE exec -it $POD_NAME sh -c "mongorestore -v --gzip --archive=/tmp/backup_dmp_$BACKUP_TIME.gzip"
# Восстановление данных схемы для DataService
kubectl -n $NAMESPACE exec -it $POD_NAME sh -c "mongorestore -v --gzip --archive=/tmp/backup_ds_$BACKUP_TIME.gzip"

ESP​

Так как ESP поднят в докере и у него свой инстанс MongoDB, то процедура восстановления бекапа будет отличаться от представленной выше, но логика такая же.

BACKUP_TIME=202207251115 # Временная метка бэкапа, который необходимо восстановить
BACKUP_HOST_DIR=~/backups/mongodb # Путь до источника бэкапа
ESP_MONGODB_CONTAINER_ID=$(docker ps --filter "name=session-provider.*mongodb" --format "{{.ID}}") # Определяем идентификатор контейнера с MongoDB

docker cp $BACKUP_HOST_DIR/esp.$BACKUP_TIME.gzip $ESP_MONGODB_CONTAINER_ID:/tmp/backup_esp.gzip
docker exec -ti $ESP_MONGODB_CONTAINER_ID sh -c "mongorestore -v --gzip --archive=/tmp/backup_esp.gzip"

PostgreSQL​

Восстановление данных PostgreSQL из бэкапа предусматривается с помощью стандартных средств PostgreSQL. Для упрощения процесса восстановления данных из бэкапа реализован bash-скрипт предназначенный для переноса и применения бэкапов PostgreSQL из постоянного хранилища бэкапов.

Для корректной работы bash-скрипта техническим администратором системы определяются следующие переменные:

  • NAMESPACE - Имя namespace котором развернута PostgreSQL;
  • BACKUP_HOST_DIR - Путь до постоянного места хранения бэкапа;
  • BACKUP_TIME - Временная метка которую необходимо восстановить.
note

В переменную BACKUP_HOST_DIR возможно указывать любой путь доступный с хоста на котором исполняется скрипт, в т.ч. удаленные хосты, S3-совместимые хранилища и т.д.

Скрипт реализует следующий сценарий:

  1. Копирование бэкап файла из постоянного хранилища бэкапов в pod с PostgreSQL;
  2. Восстановление данных из бэкапа стандартными средствами PostgreSQL.
caution

В случае восстановления данных из бэкапа рекомендуется остановить все сервисы взаимодействующие с PostgreSQL!

Список сервисов взаимодействующих с PostgreSQL возможно уточнить в описании компонентов по ссылке.

Далее представлен пример скрипта используемый для бэкапирования:

# Определение пользовательских переменных
NAMESPACE=yournamespace # Namespace в котором развернута PostgreSQL которую необходимо восстановить
BACKUP_HOST_DIR=~/backups/postgres # Путь до источника бэкапа
BACKUP_TIME=202207251115  # Временная метка бэкапа, который необходимо восстановить

# Определение технических переменных
# Определение названия pod'а MongoDB в кластере
POD_NAME=$(kubectl -n $DC_NAMESPACE get pod -l \
  app.kubernetes.io/instance=deploy-controller,app.kubernetes.io/name=aggregion-externals-postgres-deploy-controller \
  --no-headers -o custom-columns=":metadata.name")


# Копирование файлов в контейнер
kubectl cp $BACKUP_HOST_DIR/postgres.$BACKUP_TIME.dump $DC_NAMESPACE/$POD_NAME:/tmp

# Восстановление данных
kubectl -n $DC_NAMESPACE exec -it $POD_NAME sh -c "psql postgres < /tmp/postgres.$BACKUP_TIME.dump"

CAS​

Т.к. CAS использует свою, проприетарную внутренню СУБД, восстановление бекапа делается путём копирования данных БД этого сервиса из заранее подготовленного бекапа.

BACKUP_HOST_DIR=~/backups/cas # Путь до источника бэкапа
BACKUP_TIME=202207251115  # Временная метка бэкапа, который необходимо восстановить
CAS_VOLUME_PATH=/PATH/TO/CAS/VOLUME # Путь до места, которое будет монтироваться в контейнер

CAS_CONTAINER_ID=$(docker ps --filter "name=scone.*cas" --format "{{.ID}}") # Определяем идентификатор контейнера с CAS
docker stop $CAS_CONTAINER_ID # Останавливаем контейнер

tar -zxf $BACKUP_HOST_DIR/cas_data.$BACKUP_TIME.tar.gz --directory $CAS_VOLUME_PATH # Распаковываем данные в нужную директорию

docker start $CAS_CONTAINER_ID # Запускаем контейнер

BlockchainNode​

Скопируйте указанные ниже бинарные файлы на сервер, где поднимается копия

cd /usr/local/bin #Место копирования файлов
nodeos
cleos

Создание папки

cd /bc #Папка, где будет проводиться запись блоков BlockChain

Распакуем архив в папке /bc

tar -zxvf bc.tar.gz #Архив с другого сервера с актуальными данными BlockChain

Убеждаемся, что папки называются /bc/blockchain/

vi /usr/local/bin/blockchain #Название скрипта, который запустит процесс BlockChain

Пишем скрипт со следующим содержанием:

#/bin/bash

NODEOS=$(which nodeos)

$NODEOS --plugin eosio::chain_plugin \

--plugin eosio::chain_api_plugin \

--plugin eosio::http_plugin \

--access-control-allow-origin=* \

--http-validate-host=false \

--verbose-http-errors \

--http-server-address 0.0.0.0:8888 \

--p2p-listen-endpoint 0.0.0.0:9011 \

--p2p-peer-address 100.88.0.250:9011 \ #Обновляем данное значение, значением партнерской ноды, где доступен BlockChain

--p2p-max-nodes-per-host=30 \

--max-transaction-time=500 \

--contracts-console \

--abi-serializer-max-time-ms=1200 \

--http-max-response-time-ms=300 \

--data-dir /bc/blockchain/data \

--blocks-dir /bc/blockchain/blocks \

--config-dir /bc/blockchain/config

Скрипт для управления с помощью процесса systemd

server1:/ # vi /etc/systemd/system/blockchain.service #Путь к файлу

[Unit]

Description=Blockchain systemd service unit file.

Wants=network-online.target

After=network-online.target

[Service]

ExecStart=/bin/bash /usr/local/bin/blockchain.sh


[Install]

WantedBy=multi-user.target

Команды для запуска BlockChain


systemctl daemon-reload

systemctl enable blockchain.service #Автозапуск после рестарта BlockChain

systemctl start blockchain.service #start service

journalctl -f #check logs

После успешного запуска необходимо проверить логи в папке /bc/blockchain/data \