Перейти к основному содержимому

Использование Кибер Бэкап в инфраструктуре СУБД Pangolin

В данном разделе подробно рассматриваются следующие сценарии использования внешнего инструмента Кибер Бэкап в инфраструктуре СУБД Pangolin:

  • создание резервной копии СУБД Pangolin в конфигурации cluster и standalone;
  • восстановление СУБД Pangolin из резервной копии в тех же конфигурациях.

Установка Кибер Бэкап и подключение клиентов СУБД Pangolin​

Для взаимодействия Кибер Бэкап с СУБД Pangolin требуется:

  • наличие пользователя с правами суперпользователя;
  • разрешение на подключение данного пользователя с параметром replication в файле pg_hba.conf.

При отсутствии прав суперпользователя Кибер Бэкап Management Server не сможет запуститься, а в журнале появится ошибка формата: backend ERROR: permission denied for table pg_proc.

Пример настройки доступа для роли cyber_backup с правами суперпользователя в файле pg_hba.conf:

hostssl        all             cyber_backup       {IP-Address}/32       scram-sha-256
hostssl        replication     cyber_backup       {IP-Address}/32       scram-sha-256

Для пользователя должна быть указана схема public. При отсутствии требуемой схемы Кибер Бэкап не сможет выполнить инициализацию базы данных.

Настройка схемы в search_path:

ALTER USER cyber SET search_path = public;

В процессе установки Кибер Бэкап создает набор служебных баз данных:

Список создаваемых баз данных
cyberprotect_account_server                  | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_agent_manager                   | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_alert_manager                   | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_backup_manager                  | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_credentials_store               | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_data                            | cyber    | UTF8     | C           | C           |            | libc            |
cyberprotect_dml_archives                    | cyber    | UTF8     | C           | C           |            | libc            |
cyberprotect_dml_objects                     | cyber    | UTF8     | C           | C           |            | libc            |
cyberprotect_monitoring_agents               | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_auth                 | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_collections_storage  | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_metric_meta          | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_metric_registry      | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_metrics_data_storage | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_objects              | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_rta_rules_storage    | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_rta_storage          | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_search               | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_monitoring_units                | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_scheduler                       | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_task_manager                    | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_task_manager_shard              | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |
cyberprotect_vault_manager                   | cyber    | UTF8     | en_US.utf-8 | en_US.utf-8 |            | libc            |

Для обеспечения возможности восстановления клиентов СУБД Pangolin необходимо внести дополнительные параметры СУБД в конфигурационные файлы агента Кибер Бэкап (в зависимости от используемой версии ядра СУБД Pangolin — версии 13 (5.x.x) и 15 (6.x.x)):

quota_file = 'pg_quota.conf'
enabled_extra_auth_methods = 'cert,trust'

После внесения изменений необходимо перезапустить агент Кибер Бэкап:

aakore restart

Резервное копирование с синхронной реплики​

Резервное копирование невозможно выполнить с реплики, находящейся в статусе Sync Standby. В этом случае задача завершится аварийно, а в журнале агента появится сообщение search nodes for full between all nodes by strategy replicaOnly: no replicafound.

Чтобы выполнить такое резервное копирование в кластере СУБД Pangolin, необходимо временно исключить имя реплики из параметра synchronous_standby_names:

Изменения параметра

Статус реплики до изменений:

$ list

+ Cluster: clustername (7379250002936599153) --------+--------------+-----------+----+-----------+
| Member                | Host                       | Role         | State     | TL | Lag in MB |
+-----------------------+----------------------------+--------------+-----------+----+-----------+
| <ServerName1> | <ServerName1>:<Port> | Leader       | running   |  6 |           |
| <ServerName2> | <ServerName2>:<Port> | Sync Standby | streaming |  6 |         0 |
+-----------------------+----------------------------+--------------+-----------+----+-----------+

Просмотр параметра synchronous_standby_names:

$ psql -c "SHOW synchronous_standby_names;"

 synchronous_standby_names
---------------------------
 "<ServerName2>"
(1 row)

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

$ pg_ctl reload

Изменение параметра synchronous_standby_names:

$ psql -c 'ALTER SYSTEM SET synchronous_standby_names = '"'"'"null"'"'"';'

ALTER SYSTEM

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

$ psql -c 'SELECT pg_reload_conf();'

 pg_reload_conf
----------------
 t
(1 row)

Статус реплики после внесения изменений:

$ list

+ Cluster: clustername (7379250002936599153) --------+---------+-----------+----+-----------+
| Member                | Host                       | Role    | State     | TL | Lag in MB |
+-----------------------+----------------------------+---------+-----------+----+-----------+
| <ServerName1> | <ServerName1>:<Port> | Leader  | running   |  6 |           |
| <ServerName2> | <ServerName2>:<Port> | Replica | streaming |  6 |         0 |
+-----------------------+----------------------------+---------+-----------+----+-----------+
Внимание!

Следует учитывать, что в таком режиме невозможно выполнить switchover на реплику.

Сценарии использования​

В сценариях используется:

  • СУБД Pangolin версии 6.2.0: PRODUCT_VERSION = Platform V Pangolin 6.2.0;
  • пользователь cyber (роль cyber_backup), под которым будет выполняться создание всех БД и объектов необходимых для Кибер Бэкап, а так же для дальнейшей его работы.

Для сценариев создан план резервного копирования с отключенным расписанием: pangolin_backup.

к сведению

В Кибер Бэкап один и тот же план может применяться для полной и инкрементальной резервной копии. Тип выполняемой копии определяется автоматически — в зависимости от состояния системы и параметров слота репликации.

В интерфейсе Кибер Бэкап невозможно вручную запустить инкрементальную копию (кнопка запуска отсутствует).

Для запуска инкрементальной копии необходимо кратковременно включить и отключить расписание — это активирует возможность запуска.

Cлот репликации в СУБД Pangolin создаваемый Кибер Бэкапом является уникальным для каждого плана, например:

slot_name           | cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg
plugin              |
slot_type           | physical
datoid              |
database            |
temporary           | f
active              | f
active_pid          |
xmin                |
catalog_xmin        |
restart_lsn         | 1/FA01D1D0
confirmed_flush_lsn |
wal_status          | reserved
safe_wal_size       |
two_phase           | f

Пример логов при выполнении полной резервной копии:

Логи СУБД Pangolin
2024-06-19 15:40:50 MSK [133570]: [1-1] app=[unknown],user=[unknown],db=[unknown],client={IP-Address},type=not initialized LOG:  connection received: host={IP-Address} port=36100
2024-06-19 15:40:50 MSK [133570]: [2-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  connection authenticated: identity="cyber_backup" method=scram-sha-256 (/pgdata/06/data/pg_hba.conf:2)
2024-06-19 15:40:50 MSK [133570]: [3-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  connection authorized: user=cyber_backup database=postgres SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)
2024-06-19 15:40:50 MSK [133570]: [4-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  AUDIT: SESSION, CONNECTION, OPEN,database = postgres,user = cyber_backup
2024-06-19 15:40:50 MSK [133570]: [5-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  disconnection: session time: 0:00:00.025 user=cyber_backup database=postgres host={IP-Address} port=36100
2024-06-19 15:40:50 MSK [133572]: [1-1] app=[unknown],user=[unknown],db=[unknown],client={IP-Address},type=not initialized LOG:  connection received: host={IP-Address} port=36104
2024-06-19 15:40:50 MSK [133572]: [2-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  connection authenticated: identity="cyber_backup" method=scram-sha-256 (/pgdata/06/data/pg_hba.conf:3)
2024-06-19 15:40:50 MSK [133572]: [3-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  replication connection authorized: user=cyber_backup SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)
2024-06-19 15:40:50 MSK [133572]: [4-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  received replication command: CREATE_REPLICATION_SLOT cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg  PHYSICAL   RESERVE_WAL
2024-06-19 15:40:50 MSK [133572]: [5-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender STATEMENT:  CREATE_REPLICATION_SLOT cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg  PHYSICAL   RESERVE_WAL
2024-06-19 15:40:50 MSK [133572]: [6-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  received replication command: BASE_BACKUP(PROGRESS, CHECKPOINT 'fast', WAIT false, TABLESPACE_MAP)
2024-06-19 15:40:50 MSK [133572]: [7-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender STATEMENT:  BASE_BACKUP(PROGRESS, CHECKPOINT 'fast', WAIT false, TABLESPACE_MAP)
2024-06-19 15:40:50 MSK [133551]: [1-1] app=checkpointer,user=,db=,client=[bgworker],type=checkpointer LOG:  checkpoint starting: immediate force wait
2024-06-19 15:40:50 MSK [133570]: [6-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  AUDIT: SESSION, CONNECTION, CLOSED, session time: 0:00:00.639,database = postgres,user = cyber_backup
2024-06-19 15:40:50 MSK [133551]: [2-1] app=checkpointer,user=,db=,client=[bgworker],type=checkpointer LOG:  checkpoint complete: wrote 10 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.014 s, sync=0.002 s, total=0.045 s; sync files=5, longest=0.002 s, average=0.001 s; distance=16383 kB, estimate=16383 kB
2024-06-19 15:40:50 MSK [133573]: [1-1] app=[unknown],user=[unknown],db=[unknown],client={IP-Address},type=not initialized LOG:  connection received: host={IP-Address} port=36110
2024-06-19 15:40:50 MSK [133573]: [2-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  connection authenticated: identity="cyber_backup" method=scram-sha-256 (/pgdata/06/data/pg_hba.conf:3)
2024-06-19 15:40:50 MSK [133573]: [3-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  replication connection authorized: user=cyber_backup SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)
2024-06-19 15:40:50 MSK [133573]: [4-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  received replication command: IDENTIFY_SYSTEM
2024-06-19 15:40:50 MSK [133573]: [5-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender STATEMENT:  IDENTIFY_SYSTEM
2024-06-19 15:40:50 MSK [133573]: [6-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  received replication command: START_REPLICATION SLOT cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg PHYSICAL 1/F9000000 TIMELINE 1
2024-06-19 15:40:50 MSK [133573]: [7-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender STATEMENT:  START_REPLICATION SLOT cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg PHYSICAL 1/F9000000 TIMELINE 1
2024-06-19 15:40:58 MSK [133572]: [8-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  disconnection: session time: 0:00:07.833 user=cyber_backup database= host={IP-Address} port=36104
2024-06-19 15:41:00 MSK [133573]: [8-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  disconnection: session time: 0:00:09.846 user=cyber_backup database= host={IP-Address} port=36110

Пример логов при выполнении инкрементальной резервной копии:

Логи СУБД Pangolin
2024-06-19 15:58:50 MSK [133797]: [1-1] app=[unknown],user=[unknown],db=[unknown],client={IP-Address},type=not initialized LOG:  connection received: host={IP-Address} port=43886
2024-06-19 15:58:50 MSK [133797]: [2-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  connection authenticated: identity="cyber_backup" method=scram-sha-256 (/pgdata/06/data/pg_hba.conf:2)
2024-06-19 15:58:50 MSK [133797]: [3-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  connection authorized: user=cyber_backup database=postgres SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)
2024-06-19 15:58:50 MSK [133797]: [4-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  AUDIT: SESSION, CONNECTION, OPEN,database = postgres,user = cyber_backup
2024-06-19 15:58:50 MSK [133797]: [5-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  disconnection: session time: 0:00:00.023 user=cyber_backup database=postgres host={IP-Address} port=43886
2024-06-19 15:58:50 MSK [133799]: [1-1] app=[unknown],user=[unknown],db=[unknown],client={IP-Address},type=not initialized LOG:  connection received: host={IP-Address} port=43900
2024-06-19 15:58:50 MSK [133799]: [2-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  connection authenticated: identity="cyber_backup" method=scram-sha-256 (/pgdata/06/data/pg_hba.conf:3)
2024-06-19 15:58:50 MSK [133799]: [3-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  replication connection authorized: user=cyber_backup SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256)
2024-06-19 15:58:50 MSK [133799]: [4-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  received replication command: IDENTIFY_SYSTEM
2024-06-19 15:58:50 MSK [133799]: [5-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender STATEMENT:  IDENTIFY_SYSTEM
2024-06-19 15:58:50 MSK [133799]: [6-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  received replication command: START_REPLICATION SLOT cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg PHYSICAL 1/FA000150 TIMELINE 1
2024-06-19 15:58:50 MSK [133799]: [7-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender STATEMENT:  START_REPLICATION SLOT cp_o03ndepvqnun7do0foulsg_y7l0iguiryktpb_vpk8ycg PHYSICAL 1/FA000150 TIMELINE 1
2024-06-19 15:58:50 MSK [133797]: [6-1] app=[unknown],user=cyber_backup,db=postgres,client={IP-Address},type=client backend LOG:  AUDIT: SESSION, CONNECTION, CLOSED, session time: 0:00:00.801,database = postgres,user = cyber_backup
2024-06-19 15:58:54 MSK [133799]: [8-1] app=[unknown],user=cyber_backup,db=[unknown],client={IP-Address},type=walsender LOG:  disconnection: session time: 0:00:03.787 user=cyber_backup database= host={IP-Address} port=43900

Проверка создания полной резервной копии​

  1. Создайте базу данных cyber_test_db:

    $ PGOPTIONS='-c role=db_admin' psql -c "CREATE DATABASE cyber_test_db"

    CREATE DATABASE

  2. Создайте таблицу cyber_test_tbl:

    $ psql -d cyber_test_db -c "CREATE TABLE cyber_test_tbl (text text);"

    CREATE TABLE

  3. Внесите данные в таблицу (10000000 строк):

    $ psql -d cyber_test_db -c "INSERT INTO cyber_test_tbl SELECT concat(md5(random()::text)) FROM generate_series(1, 10000000);"

    INSERT 0 10000000

  4. Проверьте размер таблицы после вставки:

    $ psql -d cyber_test_db -c "SELECT pg_size_pretty(pg_relation_size('cyber_test_tbl'));"

     pg_size_pretty
    ----------------
     657 MB
    (1 row)

  5. Снимите чек-суммы данных из таблицы для проверки копии после восстановления:

    $ psql -d cyber_test_db -c "SELECT md5(array_to_string(array_agg(cyber_test_tbl::text), ';')) FROM cyber_test_tbl;"

                   md5
    ----------------------------------
     73856d86b7f199a41575732830fc0f74
    (1 row)

  6. Для ручного запуска поочередного резервного копирования в Web-консоли Кибер Бэкап выполните следующие действия:

    1. Откройте раздел Устройства → PostgreSQL → Все серверы PostgreSQL.

    2. Дважды кликните по нужному экземпляру.

    3. Нажмите Запустить сейчас → выберите тип копии:

      • полное — для создания первичной копии базы;
      • инкрементальное — для копирования изменений с момента последнего бэкапа.

    Интерфейс запуска резервного копирования:

    Интерфейс запуска резервного копирования

    После успешного завершения обеих операций в разделе Web-консоли Кибер Бэкап – Хранилище резервных копий → Хранилища → srv-66-183 → {IP-Address}:{port}_database.pg_pangolin_backup – должны появиться две копии — полная и инкрементальная:

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

  1. В Web-консоли Кибер Бэкап перейдите по пути Хранилище резервных копий → Хранилища → srv-66-183 → {IP-Address}:{port}_database.pg_pangolin_backup.

  2. Выберите копию с типом резервного копирования «Полное» и нажмите кнопку «Восстановить данные PostgreSQL».

    В качестве целевой машины для восстановления можно выбрать любую машину, подключенную в качестве клиента PostgreSQL.

  3. После успешного завершения задания проверьте наличие восстановленной базы данных:

    $ psql -c "SELECT oid,datname,datctype,datacl FROM pg_database WHERE datname='cyber_test_db_restored';"

      oid  |        datname         |  datctype   | datacl
    -------+------------------------+-------------+--------
     38565 | cyber_test_db_restored | en_US.utf-8 |
    (1 row)

  4. Снимите чек-суммы восстановленной таблицы:

    $ psql -d cyber_test_db_restored -c "SELECT md5(array_to_string(array_agg(cyber_test_tbl::text), ';')) FROM cyber_test_tbl;"

                   md5
    ----------------------------------
     73856d86b7f199a41575732830fc0f74
    (1 row)

    Сравнение чек-сумм до создания полной копии и после ее восстановления:

    md5 hash
    До создания копии73856d86b7f199a41575732830fc0f74
    После восстановления73856d86b7f199a41575732830fc0f74

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

Проверка создания инкрементальной резервной копии​

  1. Создайте базу данных cyber_test_db2:

    $ PGOPTIONS='-c role=db_admin' psql -c "CREATE DATABASE cyber_test_db2"

    CREATE DATABASE

  2. Создайте таблицу cyber_test_tbl:

    $ psql -d cyber_test_db2 -c "CREATE TABLE cyber_test_tbl (text text);"

    CREATE TABLE

  3. Внесите строку set1 в таблицу:

    $ psql -d cyber_test_db2 -c "INSERT INTO cyber_test_tbl values ('set1');"

    INSERT 0 1

  4. Выполните полное резервное копирование базы данных cyber_test_db2 через Web-консоль Кибер Бэкап.

После успешного завершения полного резервного копирования базы данных cyber_test_db2 необходимо убедиться, что система корректно выполняет инкрементальные копии при изменении данных:

  1. Добавьте новую строку set2 в таблицу cyber_test_tbl:

    $ psql -d cyber_test_db2 -c "INSERT INTO cyber_test_tbl values ('set2');"

    INSERT 0 1

    Успешный результат – запись создана:

    $ psql -d cyber_test_db2 -c "SELECT * FROM cyber_test_tbl;"

     text
    ------
     set1
     set2
    (2 rows)

  2. Выполните инкрементальное резервное копирование.

    Статус копии можно увидеть в Web-консоли Кибер Бэкап:

  3. После завершения добавьте еще одну строку set3:

    $ psql -d cyber_test_db2 -c "INSERT INTO cyber_test_tbl values ('set3');"

    INSERT 0 1

    Успешный результат – запись создана:

    $ psql -d cyber_test_db2 -c "SELECT * FROM cyber_test_tbl;"

     text
    ------
     set1
     set2
     set3
    (3 rows)

  4. Выполните инкрементальное резервное копирование.

    Статус копии можно увидеть в Web-консоли Кибер Бэкап:

Проверка восстановления из инкрементальной резервной копии​

  1. Поочередно восстановите базу данных cyber_test_db2 на момент добавления строк set2 и set3 через Web-консоль Кибер Бэкап.

  2. После успешного завершения задач по восстановлению проверьте содержимое восстановленных таблиц:

    • Восстановление на момент set2:

      $ psql -d cyber_test_db2_set2 -c "SELECT * FROM cyber_test_tbl;"

       text
      ------
       set1
       set2
      (2 rows)

    • Восстановление на момент set3:

      $ psql -d cyber_test_db2_set3 -c "SELECT * FROM cyber_test_tbl;"

       text
      ------
       set1
       set2
       set3
      (3 rows)

    Как видно из вывода psql успешно восстановлены таблица на момент добавления строк set2 и set3.

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

После успешного завершения задания проверьте содержимое тестовой таблицы в пересозданной базе данных:

$ psql -d cyber_test_db2_set2 -c "SELECT * FROM cyber_test_tbl;"

 text
------
 set1
 set2
 set3
(3 rows)

Проверка, что база данных была пересоздана из резервной копии:

  • до восстановления:

    $ psql -c "SELECT oid,datname FROM pg_database WHERE datname='cyber_test_db2_set2';"

      oid  |       datname
    -------+---------------------
     26651 | cyber_test_db2_set2
    (1 row)

  • после восстановления:

    $ psql -c "SELECT oid,datname FROM pg_database WHERE datname='cyber_test_db2_set2';"

      oid  |       datname
    -------+---------------------
     26756 | cyber_test_db2_set2
    (1 row)

Успешный результат – сменился OID базы данных.

Проверка создания и восстановления резервной копии с TDE​

Полное и инкрементальное резервное копирование успешно выполняется при включенном TDE (прозрачном защитном преобразовании данных).

Создание копии осуществляется утилитой pg_basebackup через стандартное подключение к СУБД Pangolin, используя протокол репликации. Механика работы агента Кибер Бэкап обеспечивает корректную работу с засекреченными данными на этапе резервного копирования.

Внимание!

Восстановление резервной копии не поддерживается при включенном TDE в следующих режимах:

  • Восстановление на определенный момент времени (PITR);
  • Восстановление в формате pg_dump;
  • Восстановление конкретной базы данных из кластера.

Единственный доступный вариант восстановления — режим «Восстановить как файлы».

Проблемы возникают на этапе монтирования резервной копии через FUSE. После подключения к хранилищу секретов (KMS), для корректного восстановления СУБД Pangolin требуется изменить файл global/enc_settings.cfg. Так как FUSE не поддерживает необходимые операции, попытка изменения файла приводит к ошибке и аварийному завершению:

postgres.recover: 2024-06-27 16:55:19.146 GMT [2239296] LOG:  Keyring initialization is started.
postgres.recover: 2024-06-27 16:55:19.146 GMT [2239296] LOG:  Master key initialization is started.
postgres.recover: 2024-06-27 16:55:19.148 GMT [2239296] LOG:  Parameter 'initial_mk_create_mode' is not set in config. Default value is: TRUE.
postgres.recover: 2024-06-27 16:55:19.149 GMT [2239296] WARNING:  Could not save parts of path to parameters in KMS to file. Error: -1 (SaveConfigFile(): Could not set permissions for file 'global/enc_settings.cfg'. Error: common error)
postgres.recover: 2024-06-27 16:55:19.149 GMT [2239296] FATAL:  Could not initialize AdminMasterKey. Error: -1 (SaveConfigFile(): Could not set permissions for file 'global/enc_settings.cfg'. Error: common error)
chmod: changing permissions of 'global/enc_settings.cfg': Function not implemented

Восстановление из резервной копии в файловом режиме с включенным TDE​

На сервере, куда будет происходить восстановление из резервной копии с TDE и последующим запуском экземпляра СУБД Pangolin необходимо подключение к хранилищу секретов (KMS) с нужным cluster ID.

Пример корректного подключения к хранилищу секретов (KMS):

### Под системным пользователем "kmadmin_pg"

$ setup_kms_credentials show --plain

Pangolin cluster ID: cyber_test_cl
Root CA path: /pg_ssl
Suffix: postgresql
+----------------------------------------------------------------------------------------------------------------------------------+
|  # | protocol |        host  |  port  | prefix | namespace |            cred type | auth point |              id |        status |
-----+----------+--------------+--------+--------+-----------+----------------------+------------+-----------------+----------------
|  0 |    https | {IP-Address} | {port} |     kv |           | Userpass Auth Method |   userpass | adminencryption |            Ok |
+----------------------------------------------------------------------------------------------------------------------------------+

  1. Создайте базу данных cyber_tde_test_db при включенном TDE:

    $ PGOPTIONS='-c role=db_admin' psql -c "CREATE DATABASE cyber_tde_test_db"

    CREATE DATABASE

  2. Создайте таблицу cyber_tde_test_tbl:

    $ psql -d cyber_tde_test_db -c "CREATE TABLE cyber_tde_test_tbl (text text);"

    CREATE TABLE

  3. Внесите данные в таблицу (100 строк):

    $ psql -d cyber_tde_test_db -c "INSERT INTO cyber_tde_test_tbl SELECT concat(md5(random()::text)) FROM generate_series(1, 100);"

    INSERT 0 100

  4. Снимите чек-суммы данных из таблицы для проверки копии после восстановления:

    $ psql -d cyber_tde_test_db -c "SELECT md5(array_to_string(array_agg(cyber_tde_test_tbl::text), ';')) FROM cyber_tde_test_tbl;"

                   md5
    ----------------------------------
     8a9164fc1cf789f279c332b970e5e4d4
    (1 row)

  5. Выполните резервное копирование:

  6. Создайте каталог, куда будет восстанавливаться резервная копия:

    $ mkdir /cyber/cyber_tde_test_tbl_recovered

  7. Восстановите резервную копию:

  8. Проверьте наличие восстановленных файлов после завершения задания в Кибер Бэкап:

    $ ls -al /cyber/cyber_tde_test_tbl_recovered

    total 188
    -rw------- 1 root root   213 Jun 27 21:51 backup_label
    drwx------ 6 root root  4096 Jun 27 21:51 base
    -rw------- 1 root root    56 Jun 27 21:51 current_logfiles
    drwx------ 2 root root  4096 Jun 27 21:51 global
    drwx------ 2 root root  4096 Jun 27 21:51 pg_auth
    .....
    -rw------- 1 root root     3 Jun 27 21:51 PG_VERSION
    drwx------ 3 root root  4096 Jun 27 21:51 pg_wal
    drwx------ 2 root root  4096 Jun 27 21:51 pg_xact
    -rw------- 1 root root    88 Jun 27 21:51 postgresql.auto.conf
    -rw------- 1 root root 39707 Jun 27 21:51 postgresql.base.conf
    -rw------- 1 root root  6428 Jun 27 21:51 postgresql.conf
    -rw------- 1 root root    26 Jun 27 21:51 PRODUCT_VERSION
    -rw------- 1 root root    70 Jun 27 21:51 tablespace_map
    drwx------ 2 root root  4096 Jun 27 21:51 tracing

  9. Измените права на каталог копии и файлы для возможности запустить экземпляр СУБД Pangolin:

    $ chmod 700 /cyber/cyber_tde_test_tbl_recovered
    $ chown -R postgres:postgres /cyber/cyber_tde_test_tbl_recovered

  10. Исправьте СУБД Pangolin порт и порт auth процесса (так как на этом сервере на стандартных портах уже запущен экземпляр):

    $ sed -i 's/5433/5434/g; s/5544/5545/g' postgresql.conf

  11. Запустите экземпляр (под пользователем postgres):

    $ postgres -D /cyber/cyber_tde_test_tbl_recovered
    ...

  12. Проверьте чек-сумму таблицы после восстановления:

    psql -p 5434 -d cyber_tde_test_db -c "SELECT md5(array_to_string(array_agg(cyber_tde_test_tbl::text), ';')) FROM cyber_tde_test_tbl;"

                   md5
    ----------------------------------
     8a9164fc1cf789f279c332b970e5e4d4
    (1 row)

    Сравнение чек-сумм до создания полной копии и после ее восстановления:

    md5 hash
    До создания копии8a9164fc1cf789f279c332b970e5e4d4
    После восстановления8a9164fc1cf789f279c332b970e5e4d4

    Совпадение чек-сумм подтверждает, что данные восстанавливаются корректно и полностью соответствуют состоянию на момент создания резервной копии при включенном TDE.