Общее описание

Для перехода со схемы, использующей однохостовую установку, на схему с резервированием требуется выполнить миграцию данных БД. Это необходимо, т. к. контейнер БД PostgreSQL, предназначенный для работы в схеме с резервированием БД имеет отдельный образ, в состав которого включен "Replication manager for PostgreSQL clusters" (далее repmng).

Данная особенность образа БД, предназначенного для использования в схеме с резервированием, не позволяет выполнить прямую миграцию данных. Для этого требуется выполнить резервное копирование БД, развернуть БД с резервированием с "нуля" и выполнить восстановление БД.

Версия NAICEНазвание образа и версия
1.1postgres: 1.1.5
1.1postgres-repmgr: 1.1.5

Данное обновление работает только в рамках одной версии. Если требуется обновиться на новую версию и перейти на схему с резервированием, то сначала необходимо выполнить обновление NAICE до актуальной версии, после чего выполнить обновление.

Предварительные действия по подготовке к переходу на схему с резервированием

  1. Необходимо определить IP-адресацию новых нод NAICE.
  2. Определить какая из схем резервирования будет использоваться: v1.1_3.4 Установка с резервированием (c использованием VRRP) или v1.1_3.5 Установка с резервированием (без использования VRRP).
    1. Решить, будет ли использовать в качестве VIP-адреса IP-адрес однохостовой установки, если используется схема с резервированием с VRRP.
    2. Решить, будет ли использовать в качестве IP-адреса одной из нод IP-адрес однохостовой установки, если используется схема с резервированием без VRRP.
  3. В зависимости от изменений IP-адресации заранее настроить сетевое оборудование:
    1. В ходе выполнения перехода планируется развернуть новые виртуальные машины для работы в схеме с резервированием, IP-адресация NAICE измениться и не будет совпадать с ранее настроенной на сетевом оборудовании. В этом случае потребуется указать в настройках сетевого оборудования новый адрес NAICE для настроек взаимодействия по протоколам RADIUS и TACACS+, если используется схема с резервированием c VRRP; либо указать два адреса взаимодействия (реальный IP-адрес каждой ноды NAICE), если была развернута схема с резервированием без VRRP.

      При выборе данной стратегии рекомендуется заранее указать на сетевом оборудовании новые IP-адреса для взаимодействия с NAICE с более низким приоритетом.

    2. Будет выполнен переход на схему с резервированием с использованием VRRP, используемый VIP-адрес будет совпадать с ранее используемым IP-адресом однохостовой установки NAICE. В этом случае никаких дополнительных действий по изменению настроек сетевого оборудования не потребуется.
    3. Будет выполнен переход на схему с резервированием без использования VRRP, IP-адрес одной из нод NAICE будет совпадать с ранее используемым IP-адресом однохостовой установки NAICE. На сетевом оборудовании потребуется дополнительно указать IP-адрес второй ноды NAICE в качестве RADIUS и TACACS+ сервера, что бы иметь возможность переключения между настроенными адресами в случае отказа одной из нод  NAICE.
  4. Т.к. при переходе на схему с резервированием будет перерыв связи - запланировать техническое окно для выполнения работ и необходимых проверок течении не менее 3-х часов.
  5. Сделать снапшот виртуальной машины с однохостовой установкой NAICE для возможности отката изменений.
  6. Подготовить виртуальные машины для разворачивания NAICE в схеме с резервированием в соответствии с системными требованиями.

Переход на схему с резервированием

Перед выполнением миграции БД, в зависимости от используемого функционала NAICE необходимо остановить обработку RADIUS и TACACS+ пакетов. Это требуется для того, что бы предотвратить потерю информации и RADIUS и TACACS+ сессиях, которые могут быть записаны в БД после выполнения её резервного копирования. Для этого требуется подключиться к хосту с NAICE по ssh и выполнить в папке установки NAICE (по умолчанию /etc/docker-naice) остановку сервисов, отвечающих за данные процессы. Пример:

cd /etc/docker-naice/
sudo docker compose stop naice-radius
sudo docker compose stop naice-aquila

Порядок миграции БД

Переход БД с версии однохостовой установки на версию с резервированием включает в себя следующие этапы:

Этап 1. Выгрузка файла бэкапа текущих настроек БД.

Этап 2. Разворачивание на новых хостах кластера БД PostgreSQL.

Этап 3. Загрузка ранее выгруженного бэкапа данных в кластер БД PostgreSQL.

Выполнение миграции БД

Этап 1. Выгрузка файла бэкапа текущих данных БД однохостовой установки

1. Передать в контейнер postgres команду на запуск скрипта для формирования бэкапа:

sudo docker exec -it naice-postgres /scripts/backup/backup.sh


$ sudo docker exec -it naice-postgres /scripts/backup/backup.sh
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.71] INFO  ==> Validation required env variables for backup
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.73] INFO  ==> Checking variables..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.74] DEBUG ==>   'BACKUPS_DIR' = /var/backups
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.74] DEBUG ==>   'POSTGRES_USER' = postgres
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.74] DEBUG ==>   'POSTGRES_PASSWORD' = postgres
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.74] INFO  ==> Ok, all required variables are set
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.74] INFO  ==> Directory for backups from env. variable '$BACKUPS_DIR:/var/backups'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.75] INFO  ==> Creating directory '/var/backups'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.75] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.75] INFO  ==> ok, directory is created
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.75] INFO  ==> Starting backup of database 'ursus' to /var/backups/ursus_2026-02-28_10-59-49_717.sql with excluded data for tables events..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:49.76] DEBUG ==> Call 'PGPASSWORD=postgres pg_dump -U postgres -d ursus -f /var/backups/ursus_2026-02-28_10-59-49_717.sql --inserts -c --if-exists --exclude-table-data events'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.00] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.00] INFO  ==> Ok, backup is created.
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.00] INFO  ==> Starting backup of database 'lepus' to /var/backups/lepus_2026-02-28_10-59-49_717.sql..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.00] DEBUG ==> Call 'PGPASSWORD=postgres pg_dump -U postgres -d lepus -f /var/backups/lepus_2026-02-28_10-59-49_717.sql --inserts -c --if-exists'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.13] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.13] INFO  ==> Ok, backup is created.
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.13] INFO  ==> Starting backup of database 'aquila' to /var/backups/aquila_2026-02-28_10-59-49_717.sql with excluded data for tables tacacs_sessions|tacacs_accounting..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.13] DEBUG ==> Call 'PGPASSWORD=postgres pg_dump -U postgres -d aquila -f /var/backups/aquila_2026-02-28_10-59-49_717.sql --inserts -c --if-exists --exclude-table-data tacacs_sessions|tacacs_accounting'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.26] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.27] INFO  ==> Ok, backup is created.
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.27] INFO  ==> Starting backup of database 'mustela' to /var/backups/mustela_2026-02-28_10-59-49_717.sql with excluded data for tables events..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.27] DEBUG ==> Call 'PGPASSWORD=postgres pg_dump -U postgres -d mustela -f /var/backups/mustela_2026-02-28_10-59-49_717.sql --inserts -c --if-exists --exclude-table-data events'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.39] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.40] INFO  ==> Ok, backup is created.
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.40] INFO  ==> Starting backup of database 'ovis' to /var/backups/ovis_2026-02-28_10-59-49_717.sql with excluded data for tables radius_sessions..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.40] DEBUG ==> Call 'PGPASSWORD=postgres pg_dump -U postgres -d ovis -f /var/backups/ovis_2026-02-28_10-59-49_717.sql --inserts -c --if-exists --exclude-table-data radius_sessions'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.54] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.55] INFO  ==> Ok, backup is created.
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.55] INFO  ==> Starting backup of database 'phoca' to /var/backups/phoca_2026-02-28_10-59-49_717.sql..
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.55] DEBUG ==> Call 'PGPASSWORD=postgres pg_dump -U postgres -d phoca -f /var/backups/phoca_2026-02-28_10-59-49_717.sql --inserts -c --if-exists'
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.68] 
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.69] INFO  ==> Ok, backup is created.
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.69] INFO  ==> Start compressing backups to file naice_2026-02-28_10-59-49_717.tar.gz
[BACKUP] [2026-02-28_10-59-49_717] [10:59:50.74] INFO  ==> The backup was successfully compressed to '/var/backups/naice_2026-02-28_10-59-49_717.tar.gz'

Выгрузка резервной копии БД выполняется на хост в папку <путь установки NAICE>/backups. По умолчанию это папка /etc/docker-naice/backups/, файл имеет формат naice_ГГГГ-ММ-ДД_ЧЧ-ММ-СС_XXX.tar.gz.

2. Убедиться, что в папке присутствует файл с резервной копией БД с именем, которое отображалось в логах при создании резервной копии.

3. Выгрузить файл с резервной копией БД на машину администратора или в специальное хранилище для предотвращения его потери в ходе дальнейших действий с виртуальной машиной, на которой выполнена однохостовая установка.

Этап 2. Разворачивание на новых хостах кластера БД PostgreSQL

  1. Если планируется повторно использовать хост текущей однохостовой установки в качестве части кластера, то предварительно необходимо перенести файл резервной копии из папки установки NAICE (по умолчанию - /etc/docker-naice/backups), остановить все сервисы NAICE и удалить эту папку: 
    $ sudo mv /etc/docker-naice/backups/naice_2025-11-14_08-25-02_318.tar.gz ~
$ docker compose -f /etc/docker-naice/docker-compose.yml down
$ sudo rm -rfv /etc/docker-naice/
  2. Установить кластер БД в соответствии с инструкцией и выбранной схемой резервирования v1.1_3.4 Установка с резервированием (c использованием VRRP) или v1.1_3.5 Установка с резервированием (без использования VRRP) в разделе Установка кластера СУБД PostgreSQL. 

    Сервисы NAICE на данном этапе устанавливать не нужно!

Этап 3. Загрузка ранее выгруженного бэкапа данных в кластер БД PostgreSQL

Внимание! Загрузка резервной копии данных в БД, использующую кластерную схему резервирования, возможна только на ноде, находящейся в состоянии Primary!

  1. Определить, какая нода находится в состоянии Primary (описано в v1.1_3.4 Установка с резервированием (c использованием VRRP) в разделе Проверка состояния кластера PostgreSQL).
  2. Перенести ранее выгруженный файл данных с сервера с однохостовой установкой на ноду кластера БД PostgreSQL в состоянии Primary.
  3. Файл с резервной копией необходимо поместить в папку <путь к БД>/postgres/backups. Эта папка доступна пользователю с правами root.
    $ sudo scp tester@100.110.3.35:/etc/docker-naice/backups/naice_2026-02-28_10-59-49_717.tar.gz /etc/docker-naice/postgres/backups
The authenticity of host '100.110.3.35 (100.110.3.35)' can't be established.
ED25519 key fingerprint is SHA256:0xB2cJjNA/FUZfBr+Z1q3npqNtd0gELjat2XkQwxT0E.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '100.110.3.35' (ED25519) to the list of known hosts.
tester@100.110.3.35's password: 
naice_2026-02-28_10-59-49_717.tar.gz                                                                                                                                                                       100%   93KB  25.6MB/s   00:00                                                                                                                              100%   21KB   8.3MB/s   00:00
  4. В зависимости от того, какая надо находится в состоянии Primary, передать в контейнер команду на запуск скрипта для восстановления данных из резервной копии:
    1. Пример команда для ноды 1 кластера PostgreSQL:
      sudo docker exec -it naice-postgres-1 /home/worker/scripts/backup/restore.sh -f /var/backups/<имя файла из которого выполняется восстановление БД>
    2. Пример команда для ноды 2 кластера PostgreSQL:
      sudo docker exec -it naice-postgres-2 /home/worker/scripts/backup/restore.sh -f /var/backups/<имя файла из которого выполняется восстановление БД>
    3. В конце лога выполнения команды появится сообщение:
      [RESTORE] [naice_2026-02-28_10-59-49_717] [11:10:19.39] INFO  ==> Ok, restoring is completed.
[RESTORE] [naice_2026-02-28_10-59-49_717] [11:10:19.40] INFO  ==> All databases were successfully restored from available dumps.

Установка сервисов NAICE в схеме с резервированием

  1. Выполнить установку сервисов NAICE в соответствии с инструкцией и выбранной схемой резервирования v1.1_3.4 Установка с резервированием (c использованием VRRP) или v1.1_3.5 Установка с резервированием (без использования VRRP) в разделе Установка кластера NAICE.
  2. Проверить доступность и работоспособность сервисов NAICE.
  3. Если в конфигурации сетевого оборудования остался IP-адрес взаимодействия с однохостовой установкой NAICE, который более не используется - удалить его из конфигурации оборудования.

Откат в случае неудачной установки 

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

  1. Остановить вирутальные машины с нодами NAICE и СУБД PostgreSQL
  2. Выполнить восстановление из ранее сделанного снапшота виртуальной машины с однохостовой установкой NAICE.
  3. Проверить доступность и работоспособность сервисов NAICE.