Настройка интеграции Platform V CopyWala с внешними сервисами
Выполните настройку интеграции с необходимыми компонентами:
- KeyCloak.SE (KCSE) и IAM Proxy (AUTH))
- HashiCorp Vault / SecMan
- KMS HashiCorp Vault
- Prometheus / Grafana
- PostgreSQL / Platform V Pangolin DB
- Ansible
- SynGX
- Хранилище S3
- Platform V Monitor (OPM) и Единый клиент (SDK) Platform V Monitor (MSDK)
- Platform V Vector DB (VDB)
- DDBoost (Dell EMC Data Domain)
- AI-агент (LLM-провайдер)
KeyCloak.SE (KCSE) и IAM Proxy (AUTH)
Последовательность действий
к сведению
Указанные ниже действия 1 – 4 выполняются в веб-интерфейсе KeyCloak:
-
Создайте нового клиента:
Client ID: pbr
Client authentication: ON
Authentication flow: Direct access grants -
Добавьте в настройки клиента все доступные в системе роли:
database-administrator
backup-administrator
security-auditor -
Настройте scope:
basic - default (OpenID Connect scope for add all basic claims to the token)
roles - default (OpenID Connect scope for add user roles to the access token)
groups_membership - default # предварительно добавьте в общий Client scopes новый scope с mapper - Group Membership -
Назначьте пользователям необходимые роли через веб-интерфейс Keycloak:
- администратору БД — database-administrator;
- администратору СРК — backup-administrator;
- аудитору ИБ — security-auditor.
-
Сохраните Realm URL, Client ID и Client Secret (вкладка Credentials) для использования при первичной настройки CLI recovery-manager: для входа в систему и обновления токенов доступа.
Пример:
Realm URL: https://<your-realm-server>
Client Id: pbr
Client Secret: <key> -
После добавления нового клиента в Keycloak настройте параметры подключения через CLI recovery-manager:
$ recovery-manager config set --realm-url <your-realm-server>
$ recovery-manager config set --client-id pbr
$ recovery-manager config set --client-secret <key>
$ recovery-manager config set --open-id-trusted-certificate-path <path-to-certs> # не обязательно к заполнению
Проверка результата
Проверьте корректность настройки подключения к Keycloak, пройдя аутентификацию:
$ recovery-manager login
Username: <username>
Password: <password>
Положительным результатом проверки является вывод сообщения Successful login.
Platform V IAM SE
Настройка интеграции и проверка результата не отличаются от настройки интеграции с Platform V IAM SE (IAM): KeyCloak.SE (KCSE).
HashiCorp Vault / SecMan
Интеграция с хранилищем секретов настраивается с помощью полей в конфигурационном файле. Ниже пример заполненных полей конфигурационного файла для подключения к HashiCorp Vault.
Последовательность действий
Есть два способа указания секретного ключа (secret_id):
-
Ключ явно указывается непосредственно в конфигурационном файле:
vault: # настройки подключения
server: <vault-url>
namespace: <namespace>
path: <mount-path>
kv_version: v2
approle:
role_id: <role-id>
secret_id: <secret-id>
auth_method: approle -
Секрет находится в хранилище секретов и загружается приложением через метод распаковки секрета (
unwrap), токен для распаковки секрета необходимо записать в файл, а путь к нему указать в конфигурации (wrapping_secret_id_file_path). В таком случае ключ в самом конфигурационном файле не присутствует, переупаковка секрета (rewrap) происходит автоматически после успешного входа в хранилище секретов:vault: # настройки подключения
server: <vault-url>
namespace: <namespace>
path: <mount-path>
kv_version: v2
approle:
role_id: <role-id>
auth_method: approle
wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
По умолчанию в Vault отсутствует доступ к /sys/wrapping/rewrap endpoint, поэтому при использовании механизма распаковки/упаковки секрета secret_id важно проверить наличие прав на переупаковку секрета - rewrap:
path "sys/wrapping/rewrap" {
capabilities = ["update"]
}
Например, так:
$ echo "path \"sys/wrapping/rewrap\" { capabilities = [\"update\"] }" | vault policy write test-policy-rewrap -
$ vault write auth/approle/role/ test-role policies="test-policy-reader,test-policy-rewrap"
Проверка результата
Если Agent Manager, сконфигурированный через Vault, завершил выполнение без ошибок подключения/чтения ключей из Vault, то подключение произведено корректно.
Secret Management System
Настройка интеграции и проверка результата не отличаются от настройки интеграции с HashiCorp Vault.
KMS HashiCorp Vault
к сведению
Интеграция с KMS HashiCorp Vault необходима для доступа Copywala к ключам для возможности выполнения защитного преобразования в процессе резервного копирования и восстановления данных.
Последовательность действий
В зависимости от используемой целевой СУБД добавьте и заполните секцию kms в соответствующем конфигурационном файле:
- для Pangolin / PostgreSQL – в
copywala.yaml; - для Vector DB / Qdrant – в
copywala-vdb.yaml.
Важно
В секции kms необходимо указать только один способ аутентификации: approle или userpass. Одновременное использование обоих способов не поддерживается.
# --------------------------------------
# Настройка подключения к целевой БД
# --------------------------------------
target_db:
host: localhost
port: 5433
user: {username}
password: password
database: postgres
# опция получения секретов подключения к БД через утилиту pg_auth_config
is_pg_auth_config_enabled: false # параметр позволяет применять аутентификацию пользователей при помощи pg_auth_config # если значение выставлено true, то в данном разделе параметр password указывать не нужно
pg_auth_config_plugins_path: /usr/lib/pbr/copywala # путь к каталогу, содержащему плагины аутентификации
vault_database_engine_static_role: # имя статической роли в хранилище секретов для получения доступов к БД. Значение пустое по умолчанию
query_params: search_path=pbr # параметр позволяет настроить набор значений, специфичных для Pangolin/PostgreSQL, при подключении к базе данных
# по умолчанию применяется глобальный tls
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Возможность загрузки TLS-сертификатов из HashiCorp Vault / Secret Management System (SecMan)
# --------------------------------------
vault: # настройки подключения
server: "<vault-url>"
namespace: "<namespace>"
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата формата KV-хранилища
approle:
role_id: <role-id> # уникальный идентификатор роли
secret_id: <secret-id> # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Параметры подключения к KMS HashiCorp Vault
# --------------------------------------
kms:
server: "<vault-url>" # URL сервера KMS
namespace: "<namespace>" # пространство имен в KMS HashiCorp Vault
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата KV-хранилища
approle: # вариант авторизации в KMS по роли и ключа роли
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
userpass: # вариант авторизации в KMS по логину и паролю
# username:
# password:
# auth_method:
# --------------------------------------
# Настройки БД для хранения информации о выполненных задачах резервного копирования и восстановления данных
# --------------------------------------
pbra_db:
host: localhost
port: 5433
user: {username}
password: password
database: postgres
is_pg_auth_config_enabled: false # параметр позволяет применять аутентификацию пользователей при помощи pg_auth_config # если значение выставлено true, то в данном разделе параметр password указывать не нужно
vault_database_engine_static_role: # имя статической роли в хранилище секретов для получения доступов к БД. Значение пустое по умолчанию
query_params: search_path=pbr # параметр позволяет настроить набор значений, специфичных для Pangolin/PostgreSQL, при подключении к базе данных
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Назначение резервной копии (обязательный параметр без restore_data_path)
# --------------------------------------
# local-fs:///home/postgres/backups/
# ddboost://srv-10-15.host/storage-unit
# s3://srv-10-20.host/bucket-08-9992
# s2://srv-10-25.host:port
backup_destination_uri: local-fs:///home/postgres/backups/
# --------------------------------------
# Назначение директории для архивирования WAL-файлов
# --------------------------------------
# local-fs:///home/postgres/backups/wals/
# s3://srv-10-20.host/wals-bucket/
# s2://srv-10-25.host:port/wals/
wal_destination_uri: local-fs:///home/postgres/backups/wals/
# --------------------------------------
# Секция параметров multi-restore (механизм восстановления WAL-файлов из нескольких хранилищ)
# --------------------------------------
wal_restore:
multi_restore_wal_uris: ["s2://srv-10-25.host:29509/path1", "s2://srv-10-26.host:29509/path2"] # список хранилищ WAL-файлов. Значение параметра формируется автоматически при вызове copywala restore-wal prepare-multi-restore
multi_restore_cache_path: /var/pbr/copywala/multi-restore.wals.cache # путь к кеш-файлу с информацией о хранилищах и диапазонах WAL-файлов, которые в них находятся
# --------------------------------------
# Директория для восстановления данных (обязательный параметр без backup_destination_uri)
# --------------------------------------
restore_data_path: local-fs:///pgdata/06/data
# --------------------------------------
# Наименование экземпляра БД для восстановления
# --------------------------------------
restore_instance_name: NAME_UUID # пример: db1_0198ad69-1a19-7b7f-9f46-f200942fd61c
# --------------------------------------
# Настройка повторных попыток при возникновении ошибок при записи РК
# --------------------------------------
retrier:
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Размер WAL-файла (опционально, по умолчанию 16777216 (16MB))
# --------------------------------------
wal_segment_size: 16MB
# --------------------------------------
# Конфигурация S3
# --------------------------------------
s3:
region: ru-test # регион s3
access_id: <id> # идентификатор пользователя
secret_key: <key> # секретный ключ
use_path_style: false # если параметр имеет значение true, задействуется формат полного URL с указанием пути (path-style addressing); если false – название бакета включается непосредственно в доменное имя.
disable_request_checksums: false # проверка контрольных сумм запросов
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация S2
# --------------------------------------
s2:
checksum_algorithm: DISABLED # выбор алгоритма вычисления контрольной суммы. Допустимые значения: DISABLED (по умолчанию), CRC32
storage_path: "" # значение по умолчанию пустое. Задается пользователем для возможности выбора одного из дополнительных хранилищ, пример: /var/pbr/s2/backups
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
s2tp_enabled: true # флаг использования протокола S2TP для взаимодействия copywala и storage service (s2). По умолчанию – true. Используется только в рамках операций передачи данных при создании и восстановлении резервных копий. gRPC остается как основной протокол для взаимодействия с S2, кроме переноса данных.
# при значении false – используется gRPC для всех взаимодействий
s2tp:
addresses: # массив адресов сервера s2
- "<host_1:port_1>"
- "<host_2:port_2>"
# ...
# Важно: порты, указанные в этом массиве должны совпадать с портам из storage-service.yaml блока s2.s2tp.addresses.
# Хосты, указанные в этом массиве должны совпадать с значением параметра backup_destination_uri файла copywala.yaml.
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество открытых соединений к серверу (на все указанные в массиве s2tp.addresses адреса)
read_timeout: 5m # таймаут для операции чтения
write_timeout: 5m # таймаут для операции записи
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к учетным данным (защищенным преобразованием) для подключения к хранилищу DDBoost (заполняется опционально). При заданном значении параметры username и password в секции storage игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для copywala значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # автоматически создавать отдельное хранилище (storage_unit) в системе Data Domain для резервных копий, если оно еще не создано
storage:
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Настройки архивирования РК
# --------------------------------------
archive_settings:
upload_params:
part_payload_size: 32MB # размер парта передаваемых данных
checksum_algorithm: CRC32 # выбор алгоритма вычисления контрольной суммы. CRC32 – значение по умолчанию. Допустимые значения: DISABLED, CRC32, SHA256
compression_algorithm: S2 # выбор алгоритма сжатия данных при создании РК. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2
# --------------------------------------
# Политика исполнения резервного копирования
# --------------------------------------
backup_policy:
strategy: pbr.policy.backup.strategy.full # выбор стратегии резервного копирования. Также доступно – pbr.policy.backup.strategy.delta
fast_checkpoint: false # флаг для переключения типа контрольной точки, по умолчанию spread (протяженная), при включении запускает принудительное создание контрольной точки сразу при начале создания базовой РК
workers_no: 2 # количество параллельных потоков, осуществляющих чтение из каталога PGDATA с диска (не включая WAL-файлы)
max_pending_wals: -1 # задает режим работы очереди (включение/отключение) и ее максимальный лимит для WAL-файлов, обрабатываемых в текущий момент (по умолчанию «-1» – очередь включена без ограничения размера)
progress_latency: 0.025 # шаг в долях от размера резервной копии, на котором сообщается прогресс
use_temporary_replication_slot: true # флаг включения использования временного слота репликации при выполнении резервного копирования: при true – используется временный слот репликации, при значении false – используется постоянный слот репликации
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
write_direct_io: false # режим записи данных в файл без использования кеша ОС (актуально для локальных РК)
read_cache_size: # значение параметра должно быть кратно 4 КБ на Linux # используйте совместно с read_direct_io для РК произвольной папки (generic folder backup)
delta_max_steps: 3 # допустимое отставание реплики от главного узла при восстановлении, измеряемое количеством пропущенных шагов репликации
write_parts_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих операцию записи отдельных партов
write_wals_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих обработку WAL-файлов
verify_page_checksums: false # активация проверки контрольных сумм страниц во время исполнения РК
max_allowed_page_verification_failures: 0 # максимальное количество ошибок при проверке целостности страниц во время исполнения РК
backup_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
backup_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
wal_stream_tmp_dir: /tmp # директория для временного хранения WAL-файлов перед записью в резервную копию
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при создании резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
compress_tde: true # включает защитное преобразование на стороне copywala. Используется если включено сжатие (в copywala.yaml задан archive_settings.compression_algorithm) и в Pangolin включен TDE (в is_tde_on = on).
# Данный параметр игнорируется при резервном копировании чистого PostgreSQL, произвольных директорий (generic-folder) и других СУБД, в которых не используется защитное преобразование
extra_files: # список путей к дополнительным файлам, которые необходимо включить в резервную копию. По умолчанию пуст: это значит, что в архив резервной копии будут сохранены только данные из PGDATA и из связанных с ней табличных пространств
# файлы, указанные ниже, приведены для примера
- /etc/pangolin-pooler/pangolin-pooler.ini
- /etc/pangolin-manager/postgres.yml
# --------------------------------------
# Пример политики слияния (значения по умолчанию)
# --------------------------------------
merge_policy:
write_parts_workers_no: max(runtime.NumCPU()/2, 1) # количество одновременно работающих процессов для записи частей резервных копий. Устанавливается равным половине числа ядер CPU, но минимум один поток
read_parts_workers_no: max(runtime.NumCPU()/2, 1) # количество одновременно работающих процессов для чтения резервных копий. Равно половине количества ядер CPU, но не менее одного потока
verify_page_checksums: false # проверка контрольных сумм страниц PostgreSQL
max_allowed_page_verification_failures: 0 # максимальное число допустимых ошибок при проверке контрольных сумм страниц
verify_archive_checksums: true # проверка контрольных сумм всего архива резервной копии
read_direct_io: false # приложение будет использовать буферизованный ввод-вывод операционной системы при чтении данных
write_direct_io: false # приложение будет использовать буферизованный ввод-вывод операционной системы при записи данных
# --------------------------------------
# Параметры синхронизации узлов кластера БД
# --------------------------------------
catchup_policy:
strategy: pbr.policy.backup.strategy.full # стратегия синхронизации
# параметры для основного узла (primary)
master_params:
workers_no: 4 # количество параллельных рабочих процессов (workers), одновременно на одном воркере загружается только один файл
wals_workers_no: 4 # количество параллельных рабочих процессов (workers), необходимых для передачи WAL-файлов через репликационный протокол
max_pending_wals: -1 # размер очереди WAL-файлов на отправку. Останавливает синхронизацию (catchup), если лимит очереди WAL-файлов на отправку превышен. По умолчанию выключен
wal_stream_tmp_dir: # директория для временного хранения WAL-файлов
progress_latency: 0.1 # шаг в долях от размера резервной копии, на котором в логах отображается прогресс (0.1 - каждые 10%)
write_file_timeout: 30m # тайм-аут загрузки одного файла, если файл не успел загрузиться за это время, то синхронизация (catchup) обрывается
fast_checkpoint: false # флаг для переключения типа контрольной точки
allow_replica_hosts: # хосты всех узлов кластера, с которых мастеру разрешено подключаться к серверу реплики
- 10.40.48.109
s2tp:
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество TCP-соединений, которое может быть открыто при взаимодействии с сервером реплики одновременно
read_timeout: 5m # тайм-аут одного запроса на чтение, не учитывается при загрузке файла
write_timeout: 5m # тайм-аут одного запроса на запись, не учитывается при загрузке файла
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# параметры для узла-реплики (standby)
replica_params:
s2tp:
addresses: # адреса, на которых запускается сервер реплики и ожидаются подключения от primary. Если используется Pangolin Manager или другие инструменты управления кластером, убедитесь, что указанные адреса доступны с мастера
- 0.0.0.0:29505
mtls: false # флаг включения взаимодействия по mTLS
max_connections: 16 # максимальное количество TCP-соединений, которое может быть открыто при взаимодействии с сервером реплики одновременно
read_timeout: 5m # тайм-аут одного запроса на чтение, не учитывается при загрузке файла
write_timeout: 5m # тайм-аут одного запроса на запись, не учитывается при загрузке файла
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация архивирования WAL-файлов
# --------------------------------------
wal_archiving:
is_multi_wal_archiving_enabled: false # многопоточный режим архивации WAL-файлов
multi_wal_archiving_workers_no: 4 # количество потоков для параллельной передачи WAL-файлов в хранилище
wal_batch_size: 100 # 100 по умолчанию. Чтобы отключить ограничение размера пакета, установите значение равным 0 или любому отрицательному целому числу
# Archive WALs in CWL
is_wal_archiving_in_cwl_enabled: false # включение/отключение архивации журналов предзаписи WAL в CWL
wal_archiving_cwl_max_file_size: 1GB # максимальный размер CWL-архива с WAL-сегментами
force_switch_cwl_lock_timeout: 15s # Максимальное время ожидания командой copywala archive-wal force-switch-cwl освобождения эксклюзивной блокировки, удерживаемой процессом copywala archive-wal при архивировании WAL-файлов в CWL-архив
wal_compression_algorithm: S2 # алгоритм сжатия WAL-файлов. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2, LZ4
is_archive_logs_to_file_only: false # флаг отключения логирования сообщений уровня INFO в стандартный поток ошибок (stderr). При значении true – сообщения уровня INFO записываются только в журнал Copywala
dir_mode: 0700 # настройка прав доступа для каталогов создаваемых при архивировании
file_mode: 0600 # настройка прав доступа для архивируемых WAL-файлов
wal_file_mode: 0600 # числовое представление прав доступа на создаваемые файлы
wal_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
wal_prefetch_size: 0 # включение и регулировка многопоточной загрузки WAL-файлов. По умолчанию выключено
wal_prefetch_dir: "" # путь к директории для хранения предзагруженных WAL-файлов. По умолчанию пустое значение означает что, директория создается в каталоге pg_wal
# --------------------------------------
# Политика восстановления (ниже приведены значения по умолчанию)
# --------------------------------------
restore_policy:
workers_no: runtime.NumCPU()
jobs_queue_size: 16 # размер очереди задач на распаковку партов архива
progress_latency: 0.1 # шаг в долях от размера резервной копии, на котором сообщается прогресс (0.1 - каждые 10%)
reverse_restore: false # порядок восстановления резервных копий данных. При true – восстановление производится в обратном порядке, при false – восстановление идет последовательно
verify_page_checksums: false # активация проверки контрольных сумм страниц во время восстановления
max_allowed_page_verification_failures: 0 # максимальное количество ошибок при проверке целостности страниц во время восстановления
verify_archive_checksums: true # проверка контрольных сумм всего архива
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
write_direct_io: false # режим записи данных в файлы, исключая использование кеша ОС (не доступно для generic folder backups)
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при восстановлении из резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Конфигурация TLS используемая по умолчанию для всех сетевых соединений (DB, S2, S3, ...)
# --------------------------------------
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация Prometheus (подробное описание атрибутов по умолчанию и обязательных атрибутов каждого поля см. в документации)
# --------------------------------------
prometheus:
push_model:
jobname:
address:
process_collector_opts:
report_errors:
pid:
namespace:
frequency:
req_timeout:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
pull_model:
endpoint: /metrics
address:
process_collector_opts:
report_errors:
pid:
namespace:
handler_opts:
timeout:
max_requests_in_flight:
disable_compression:
log_errors:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Опциональные настройки приложения
# --------------------------------------
app:
agent_id_file_path: /etc/pbr/pbr.agent.id # путь к файлу, содержащему идентификатор агентcкого приложения
copywala_dir: /etc/pbr/copywala # рабочая директория
allow_concurrent_create_backup: false # управляет возможностью запуска нескольких операций создания резервных копий одновременно
agent_id_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
copywala_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
creds_private_key_path: /var/pbr/copywala/priv.key # путь к приватному ключу приложения
copywala_plugins_dir: /usr/lib/pbr/copywala # путь к директории, где находится плагин защитного преобразования
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# если параметр не указан в copywala.yaml, лимит памяти будет автоматически установлен в размере 1/4 от общего объема RAM, доступного в системе (например, при 32 ГБ оперативной памяти лимит составит 8 ГБ)
# если задано значение 0 – будут использоваться настройки Go по умолчанию
# при указании значения – будет установлен заданный лимит
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
# --------------------------------------
# Настройка параметров подключения к Platform V Monitor (OPM) и Единый клиент (SDK) Platform V Monitor (MSDK)
# --------------------------------------
audit:
central_audit: # секция с подключением к Platform V Monitor (OPM)
address: "<https://audit.example.com>"
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: "<tls/root.crt>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: "<tls/cert.crt>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: "<tls/cert.key>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
msdk_audit: # секция с подключением к Единый клиент (SDK) Platform V Monitor (MSDK)
address: "<https://audit.msdk.example.com>"
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: "<tls/root.crt>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: "<tls/cert.crt>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: "<tls/cert.key>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
retrier: # настройка повторных попыток при возникновении ошибок при отправке событий аудита
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
log:
path: /var/log/pbr/copywala.log # путь к лог-файлу
dir_mode: 0700 # настройка прав доступа на создаваемые каталоги. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
file_mode: 0600 # настройка прав доступа на создаваемые файлы. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
max_size: 100 # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # максимальный возраст лог-файла в днях
max_backups: 10 # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: true # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия
к сведению
Если в copywala.yaml в секциях kms и vault заданы одинаковые значения, будет использоваться один общий клиент для работы с обоими сервисами.
Проверка результата
Для проверки интеграции c KMS HashiCorp Vault выполните запуск создания резервной копии (copywala create-backup) с настроенной конфигурацией KMS.
- Если создание резервной копии успешно запустилось — интеграция с KMS настроена корректно.
- Если операция завершилась с ошибкой — проверьте параметры подключения и конфигурацию KMS.
Prometheus / Grafana
Последовательность действий
Подробнее о настройке интеграции в разделе «Мониторинг».
PostgreSQL / Platform V Pangolin DB
Последовательность действий
- Для хранения метаинформации необходимо создать базу данных и пользователя для сервисов Task Manager, Agent Manager и Storage Manager.
Проверка результата
Положительным результатом проверки является успешный запуск сервисов с настроенным подключением к базам данных.
Ansible
Последовательность действий
Не требуется настроек для интеграции.
SynGX
Последовательность действий
-
Воспользуйтесь официальной документацией для установки и настройки компонента SynGX для установки сервиса.
-
Измените конфигурационный файл согласно необходимым требованиям.
примечаниеКонфигурационный файл обычно находится по пути
/opt/syngx/conf/syngx.conf. -
После обновления конфигурационного файла перезапустите сервис:
$ systemctl syngx -s reload
Пример корректного syngx.conf
user syngx;
worker_processes auto;
worker_cpu_affinity auto;
error_log /opt/syngx/logs/error.log crit;
pid /opt/syngx/logs/syngx.pid;
#load_module /opt/syngx/modules/ndk_http_module.so;
#load_module /opt/syngx/modules/ngx_http_brotli_filter_module.so;
#load_module /opt/syngx/modules/ngx_http_brotli_static_module.so;
#load_module /opt/syngx/modules/ngx_http_js_module.so;
#load_module /opt/syngx/modules/ngx_http_lua_module.so;
#load_module /opt/syngx/modules/ngx_http_sslkeylog_module.so;
#load_module /opt/syngx/modules/ngx_http_stream_server_traffic_status_module.so;
#load_module /opt/syngx/modules/ngx_stream_js_module.so;
#load_module /opt/syngx/modules/ngx_stream_lua_module.so;
#load_module /opt/syngx/modules/ngx_stream_server_traffic_status_module.so;
#load_module /opt/syngx/modules/ngx_http_set_misc_module.so;
#load_module /opt/syngx/modules/ngx_hashicorp_vault_module.so;
events {
worker_connections 1024;
}
http {
include /opt/syngx/conf.d/*.conf;
client_body_buffer_size 16k;
client_header_buffer_size 1k;
client_max_body_size 16M;
large_client_header_buffers 4 8k;
access_log /opt/syngx/logs/access.log;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GSM-SHA-256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
server {
listen 29000;
server_name <DNS запись узла> <IP адрес узла>;
location /api/agent-manager/ {
proxy_pass http://{IP_ADDRESS}:29010;
# Если будет включен TLS и mTLS:
# proxy_ssl_certificate /opt/syngx/conf/cert.pem;
# proxy_ssl_certificate_key /opt/syngx/conf/key.pem;
# proxy_ssl_trusted_certificate /opt/syngx/conf/upstream_rootca.pem;
}
location /ws {
proxy_pass http://{IP_ADDRESS}:29015;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 86400;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_intercept_errors on;
proxy_redirect off;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
proxy_ssl_session_reuse off;
# Если будет включен TLS и mTLS:
# proxy_ssl_certificate /opt/syngx/conf/cert.pem;
# proxy_ssl_certificate_key /opt/syngx/conf/key.pem;
# proxy_ssl_trusted_certificate /opt/syngx/conf/upstream_rootca.pem;
}
location /api/storage-manager/ {
proxy_pass http://{IP_ADDRESS}:29030;
# Если будет включен TLS и mTLS:
# proxy_ssl_certificate /opt/syngx/conf/cert.pem;
# proxy_ssl_certificate_key /opt/syngx/conf/key.pem;
# proxy_ssl_trusted_certificate /opt/syngx/conf/upstream_rootca.pem;
}
location /api/task-manager/ {
proxy_pass http://{IP_ADDRESS}:29020;
# Если будет включен TLS и mTLS:
# proxy_ssl_certificate /opt/syngx/conf/cert.pem;
# proxy_ssl_certificate_key /opt/syngx/conf/key.pem;
# proxy_ssl_trusted_certificate /opt/syngx/conf/upstream_rootca.pem;
}
}
server {
listen 29001;
server_name <DNS запись узла> <IP адрес узла>;
location /metrics {
add_header Allow "GET, HEAD, OPTIONS" always;
if ( $request_method !~ ^(GET|HEAD|OPTIONS)$ ) {
return 405;
}
snx_http_extstatus_prometheus on;
allow all;
deny all;
}
location /metrics_json {
add_header Allow "GET, HEAD, OPTIONS" always;
if ( $request_method !~ ^(GET|HEAD|OPTIONS)$ ) {
return 405;
}
snx_http_extstatus_json on;
allow all;
deny all;
}
}
}
Проверка результата
-
Проверьте статус сервера:
$ systemctl status syngx.service. -
Положительным результатом проверки будут являться успешные записи в логах с выводом
status=0/SUCCESS:syngx.service - The SYNGX HTTP and reverse proxy server
Loaded: loaded (/etc/systemd/system/syngx.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/syngx.service.d
└─service.conf
Active: active (running) since Mon 2025-06-30 07:21:15 UTC; 5s ago
Process: 106 ExecStart=/usr/sbin/syngx (code=exited, status=0/SUCCESS)
Process: 105 ExecStartPre=/bin/bash -c chown syngx.syngx /opt/syngx/conf/syngx.conf.current (code=exited, status=0/SUCCESS)
Process: 103 ExecStartPre=/bin/bash -c /sbin/syngx -T > /opt/syngx/conf/syngx.conf.current (code=exited, status=0/SUCCESS)
Process: 99 ExecStartPre=/bin/bash -c VARTIME=`cat /proc/uptime | cut -d . -f 1`; if [ $VARTIME -le 300 ] ; then sleep 2; fi (code=exited, status=0/SUCCESS)
Process: 98 ExecStartPre=/usr/sbin/syngx -t (code=exited, status=0/SUCCESS)
Main PID: 107 (syngx)
Tasks: 5 (limit: 26213)
Memory: 4.6M
CGroups: <Позиция syngx в иерархии cgroups>
Jun 30 07:21:15 syngx2 systemd[1]: Starting The SYNGX HTTP and reverse proxy server...
Jun 30 07:21:15 syngx2 syngx[98]: syngx: the configuration file /opt/syngx/conf/syngx.conf syntax is ok
Jun 30 07:21:15 syngx2 syngx[98]: syngx: configuration file /opt/syngx/conf/syngx.conf test is successful
Jun 30 07:21:15 syngx2 bash[104]: syngx: the configuration file /opt/syngx/conf/syngx.conf syntax is ok
Jun 30 07:21:15 syngx2 bash[104]: syngx: configuration file /opt/syngx/conf/syngx.conf test is successful
Jun 30 07:21:15 syngx2 systemd[1]: Started The SYNGX HTTP and reverse proxy server.
Пример запроса для проверки корректной обработки Syngx:
$ curl -I http://<DNS запись узла>:29001/metrics
Положительный ответ:
HTTP/1.1 200 OK
Server: SynGX/3.0.2 (based on nginx-1.24.0)
Date: Tue, 01 Jul 2025 08:26:34 GMT
Content-Type: text/html
Content-Length: 278
Connection: close
Хранилище S3
Последовательность действий
Для интеграции Platform V CopyWala с хранилищем S3 необходимо:
-
Использовать хранилище, совместимое с интерфейсом S3 API (например, MinIO, Amazon AWS S3, Ceph и подобные решения);
-
В конфигурационном файле
copywala.yamlуказать следующие параметры:s3:
region: ru-test
access_id: <id> # идентификатор хранилища
secret_key: <key> # секретный ключ хранилища
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: tls/root.crt # путь к локальному файлу
vault_path: <path> # путь к секрету в HarhiCorp/SecMan
vault_key: <key> # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: tls/cert.crt
vault_path: <path> # путь к секрету в HarhiCorp/SecMan
vault_key: <key> # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: tls/cert.key
vault_path: <path> # путь к секрету в HarhiCorp/SecMan
vault_key: <key> # ключ внутри JSON-секрета -
При вызове соответствующей команды, обязательно укажите путь для доступа к S3-хранилищу. Конкретный параметр зависит от типа вызываемой команды.
Например, для создания резервной копии в конфигурационном файле copywala.yaml поле backup_destination_uri должно иметь следующий вид:
backup_destination_uri: s3://srv-10-20.host/bucket-08-9992
Где:
srv-10-20.host- путь к хранилищу;bucket-08-9992- имя бакета, в который будет загружен архив.
Внимание!
Для корректного взаимодействия с S3-хранилищем, необходимы права доступа для следующих операций:
HeadObject– проверка существования и получение метаданных объекта;GetObject– загрузка самого объекта из хранилища;HeadBucket– проверка существования и получение метаданных бакета;CreateBucket– создание нового бакета в хранилище;CreateMultipartUpload– инициализация загрузки большого объекта частями (multipart upload);UploadPart– передача частей загружаемого объекта;CompleteMultipartUpload– завершение многочастной загрузки объекта;AbortMultipart– отмена незавершенного процесса multi-part загрузки.
Проверка результата
Интеграция с хранилищем S3 считается успешно выполненной, если в журналах (логах) приложения отсутствуют записи об ошибках, связанных с подключением, передачей данных или операциями чтения-записи в объектном хранилище S3.
Platform V Monitor (OPM) и Единый клиент (SDK) Platform V Monitor (MSDK)
Интеграция с OPM и MSDK используется для отправки событий аудита.
Если OPM недоступен и настроена интеграция с MSDK, CopyWala автоматически переключается на него. MSDK обеспечивает гарантированную доставку событий в Platform V Monitor. Для этого события сохраняются в базе данных или Kafka компонента MSDK. После восстановления работы OPM накопленные события отправляются автоматически.
Для настройки интеграции с OPM и MSDK укажите в конфигурационном файле copywala.yaml следующие параметры:
# --------------------------------------
# Настройка подключения к целевой БД
# --------------------------------------
target_db:
host: localhost
port: 5433
user: {username}
password: password
database: postgres
# опция получения секретов подключения к БД через утилиту pg_auth_config
is_pg_auth_config_enabled: false # параметр позволяет применять аутентификацию пользователей при помощи pg_auth_config # если значение выставлено true, то в данном разделе параметр password указывать не нужно
pg_auth_config_plugins_path: /usr/lib/pbr/copywala # путь к каталогу, содержащему плагины аутентификации
vault_database_engine_static_role: # имя статической роли в хранилище секретов для получения доступов к БД. Значение пустое по умолчанию
query_params: search_path=pbr # параметр позволяет настроить набор значений, специфичных для Pangolin/PostgreSQL, при подключении к базе данных
# по умолчанию применяется глобальный tls
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Возможность загрузки TLS-сертификатов из HashiCorp Vault / Secret Management System (SecMan)
# --------------------------------------
vault: # настройки подключения
server: "<vault-url>"
namespace: "<namespace>"
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата формата KV-хранилища
approle:
role_id: <role-id> # уникальный идентификатор роли
secret_id: <secret-id> # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Параметры подключения к KMS HashiCorp Vault
# --------------------------------------
kms:
server: "<vault-url>" # URL сервера KMS
namespace: "<namespace>" # пространство имен в KMS HashiCorp Vault
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата KV-хранилища
approle: # вариант авторизации в KMS по роли и ключа роли
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
userpass: # вариант авторизации в KMS по логину и паролю
# username:
# password:
# auth_method:
# --------------------------------------
# Настройки БД для хранения информации о выполненных задачах резервного копирования и восстановления данных
# --------------------------------------
pbra_db:
host: localhost
port: 5433
user: {username}
password: password
database: postgres
is_pg_auth_config_enabled: false # параметр позволяет применять аутентификацию пользователей при помощи pg_auth_config # если значение выставлено true, то в данном разделе параметр password указывать не нужно
vault_database_engine_static_role: # имя статической роли в хранилище секретов для получения доступов к БД. Значение пустое по умолчанию
query_params: search_path=pbr # параметр позволяет настроить набор значений, специфичных для Pangolin/PostgreSQL, при подключении к базе данных
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Назначение резервной копии (обязательный параметр без restore_data_path)
# --------------------------------------
# local-fs:///home/postgres/backups/
# ddboost://srv-10-15.host/storage-unit
# s3://srv-10-20.host/bucket-08-9992
# s2://srv-10-25.host:port
backup_destination_uri: local-fs:///home/postgres/backups/
# --------------------------------------
# Назначение директории для архивирования WAL-файлов
# --------------------------------------
# local-fs:///home/postgres/backups/wals/
# s3://srv-10-20.host/wals-bucket/
# s2://srv-10-25.host:port/wals/
wal_destination_uri: local-fs:///home/postgres/backups/wals/
# --------------------------------------
# Секция параметров multi-restore (механизм восстановления WAL-файлов из нескольких хранилищ)
# --------------------------------------
wal_restore:
multi_restore_wal_uris: ["s2://srv-10-25.host:29509/path1", "s2://srv-10-26.host:29509/path2"] # список хранилищ WAL-файлов. Значение параметра формируется автоматически при вызове copywala restore-wal prepare-multi-restore
multi_restore_cache_path: /var/pbr/copywala/multi-restore.wals.cache # путь к кеш-файлу с информацией о хранилищах и диапазонах WAL-файлов, которые в них находятся
# --------------------------------------
# Директория для восстановления данных (обязательный параметр без backup_destination_uri)
# --------------------------------------
restore_data_path: local-fs:///pgdata/06/data
# --------------------------------------
# Наименование экземпляра БД для восстановления
# --------------------------------------
restore_instance_name: NAME_UUID # пример: db1_0198ad69-1a19-7b7f-9f46-f200942fd61c
# --------------------------------------
# Настройка повторных попыток при возникновении ошибок при записи РК
# --------------------------------------
retrier:
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Размер WAL-файла (опционально, по умолчанию 16777216 (16MB))
# --------------------------------------
wal_segment_size: 16MB
# --------------------------------------
# Конфигурация S3
# --------------------------------------
s3:
region: ru-test # регион s3
access_id: <id> # идентификатор пользователя
secret_key: <key> # секретный ключ
use_path_style: false # если параметр имеет значение true, задействуется формат полного URL с указанием пути (path-style addressing); если false – название бакета включается непосредственно в доменное имя.
disable_request_checksums: false # проверка контрольных сумм запросов
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация S2
# --------------------------------------
s2:
checksum_algorithm: DISABLED # выбор алгоритма вычисления контрольной суммы. Допустимые значения: DISABLED (по умолчанию), CRC32
storage_path: "" # значение по умолчанию пустое. Задается пользователем для возможности выбора одного из дополнительных хранилищ, пример: /var/pbr/s2/backups
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
s2tp_enabled: true # флаг использования протокола S2TP для взаимодействия copywala и storage service (s2). По умолчанию – true. Используется только в рамках операций передачи данных при создании и восстановлении резервных копий. gRPC остается как основной протокол для взаимодействия с S2, кроме переноса данных.
# при значении false – используется gRPC для всех взаимодействий
s2tp:
addresses: # массив адресов сервера s2
- "<host_1:port_1>"
- "<host_2:port_2>"
# ...
# Важно: порты, указанные в этом массиве должны совпадать с портам из storage-service.yaml блока s2.s2tp.addresses.
# Хосты, указанные в этом массиве должны совпадать с значением параметра backup_destination_uri файла copywala.yaml.
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество открытых соединений к серверу (на все указанные в массиве s2tp.addresses адреса)
read_timeout: 5m # таймаут для операции чтения
write_timeout: 5m # таймаут для операции записи
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к учетным данным (защищенным преобразованием) для подключения к хранилищу DDBoost (заполняется опционально). При заданном значении параметры username и password в секции storage игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для copywala значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # автоматически создавать отдельное хранилище (storage_unit) в системе Data Domain для резервных копий, если оно еще не создано
storage:
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Настройки архивирования РК
# --------------------------------------
archive_settings:
upload_params:
part_payload_size: 32MB # размер парта передаваемых данных
checksum_algorithm: CRC32 # выбор алгоритма вычисления контрольной суммы. CRC32 – значение по умолчанию. Допустимые значения: DISABLED, CRC32, SHA256
compression_algorithm: S2 # выбор алгоритма сжатия данных при создании РК. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2
# --------------------------------------
# Политика исполнения резервного копирования
# --------------------------------------
backup_policy:
strategy: pbr.policy.backup.strategy.full # выбор стратегии резервного копирования. Также доступно – pbr.policy.backup.strategy.delta
fast_checkpoint: false # флаг для переключения типа контрольной точки, по умолчанию spread (протяженная), при включении запускает принудительное создание контрольной точки сразу при начале создания базовой РК
workers_no: 2 # количество параллельных потоков, осуществляющих чтение из каталога PGDATA с диска (не включая WAL-файлы)
max_pending_wals: -1 # задает режим работы очереди (включение/отключение) и ее максимальный лимит для WAL-файлов, обрабатываемых в текущий момент (по умолчанию «-1» – очередь включена без ограничения размера)
progress_latency: 0.025 # шаг в долях от размера резервной копии, на котором сообщается прогресс
use_temporary_replication_slot: true # флаг включения использования временного слота репликации при выполнении резервного копирования: при true – используется временный слот репликации, при значении false – используется постоянный слот репликации
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
write_direct_io: false # режим записи данных в файл без использования кеша ОС (актуально для локальных РК)
read_cache_size: # значение параметра должно быть кратно 4 КБ на Linux # используйте совместно с read_direct_io для РК произвольной папки (generic folder backup)
delta_max_steps: 3 # допустимое отставание реплики от главного узла при восстановлении, измеряемое количеством пропущенных шагов репликации
write_parts_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих операцию записи отдельных партов
write_wals_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих обработку WAL-файлов
verify_page_checksums: false # активация проверки контрольных сумм страниц во время исполнения РК
max_allowed_page_verification_failures: 0 # максимальное количество ошибок при проверке целостности страниц во время исполнения РК
backup_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
backup_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
wal_stream_tmp_dir: /tmp # директория для временного хранения WAL-файлов перед записью в резервную копию
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при создании резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
compress_tde: true # включает защитное преобразование на стороне copywala. Используется если включено сжатие (в copywala.yaml задан archive_settings.compression_algorithm) и в Pangolin включен TDE (в is_tde_on = on).
# Данный параметр игнорируется при резервном копировании чистого PostgreSQL, произвольных директорий (generic-folder) и других СУБД, в которых не используется защитное преобразование
extra_files: # список путей к дополнительным файлам, которые необходимо включить в резервную копию. По умолчанию пуст: это значит, что в архив резервной копии будут сохранены только данные из PGDATA и из связанных с ней табличных пространств
# файлы, указанные ниже, приведены для примера
- /etc/pangolin-pooler/pangolin-pooler.ini
- /etc/pangolin-manager/postgres.yml
# --------------------------------------
# Пример политики слияния (значения по умолчанию)
# --------------------------------------
merge_policy:
write_parts_workers_no: max(runtime.NumCPU()/2, 1) # количество одновременно работающих процессов для записи частей резервных копий. Устанавливается равным половине числа ядер CPU, но минимум один поток
read_parts_workers_no: max(runtime.NumCPU()/2, 1) # количество одновременно работающих процессов для чтения резервных копий. Равно половине количества ядер CPU, но не менее одного потока
verify_page_checksums: false # проверка контрольных сумм страниц PostgreSQL
max_allowed_page_verification_failures: 0 # максимальное число допустимых ошибок при проверке контрольных сумм страниц
verify_archive_checksums: true # проверка контрольных сумм всего архива резервной копии
read_direct_io: false # приложение будет использовать буферизованный ввод-вывод операционной системы при чтении данных
write_direct_io: false # приложение будет использовать буферизованный ввод-вывод операционной системы при записи данных
# --------------------------------------
# Параметры синхронизации узлов кластера БД
# --------------------------------------
catchup_policy:
strategy: pbr.policy.backup.strategy.full # стратегия синхронизации
# параметры для основного узла (primary)
master_params:
workers_no: 4 # количество параллельных рабочих процессов (workers), одновременно на одном воркере загружается только один файл
wals_workers_no: 4 # количество параллельных рабочих процессов (workers), необходимых для передачи WAL-файлов через репликационный протокол
max_pending_wals: -1 # размер очереди WAL-файлов на отправку. Останавливает синхронизацию (catchup), если лимит очереди WAL-файлов на отправку превышен. По умолчанию выключен
wal_stream_tmp_dir: # директория для временного хранения WAL-файлов
progress_latency: 0.1 # шаг в долях от размера резервной копии, на котором в логах отображается прогресс (0.1 - каждые 10%)
write_file_timeout: 30m # тайм-аут загрузки одного файла, если файл не успел загрузиться за это время, то синхронизация (catchup) обрывается
fast_checkpoint: false # флаг для переключения типа контрольной точки
allow_replica_hosts: # хосты всех узлов кластера, с которых мастеру разрешено подключаться к серверу реплики
- 10.40.48.109
s2tp:
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество TCP-соединений, которое может быть открыто при взаимодействии с сервером реплики одновременно
read_timeout: 5m # тайм-аут одного запроса на чтение, не учитывается при загрузке файла
write_timeout: 5m # тайм-аут одного запроса на запись, не учитывается при загрузке файла
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# параметры для узла-реплики (standby)
replica_params:
s2tp:
addresses: # адреса, на которых запускается сервер реплики и ожидаются подключения от primary. Если используется Pangolin Manager или другие инструменты управления кластером, убедитесь, что указанные адреса доступны с мастера
- 0.0.0.0:29505
mtls: false # флаг включения взаимодействия по mTLS
max_connections: 16 # максимальное количество TCP-соединений, которое может быть открыто при взаимодействии с сервером реплики одновременно
read_timeout: 5m # тайм-аут одного запроса на чтение, не учитывается при загрузке файла
write_timeout: 5m # тайм-аут одного запроса на запись, не учитывается при загрузке файла
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация архивирования WAL-файлов
# --------------------------------------
wal_archiving:
is_multi_wal_archiving_enabled: false # многопоточный режим архивации WAL-файлов
multi_wal_archiving_workers_no: 4 # количество потоков для параллельной передачи WAL-файлов в хранилище
wal_batch_size: 100 # 100 по умолчанию. Чтобы отключить ограничение размера пакета, установите значение равным 0 или любому отрицательному целому числу
# Archive WALs in CWL
is_wal_archiving_in_cwl_enabled: false # включение/отключение архивации журналов предзаписи WAL в CWL
wal_archiving_cwl_max_file_size: 1GB # максимальный размер CWL-архива с WAL-сегментами
force_switch_cwl_lock_timeout: 15s # Максимальное время ожидания командой copywala archive-wal force-switch-cwl освобождения эксклюзивной блокировки, удерживаемой процессом copywala archive-wal при архивировании WAL-файлов в CWL-архив
wal_compression_algorithm: S2 # алгоритм сжатия WAL-файлов. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2, LZ4
is_archive_logs_to_file_only: false # флаг отключения логирования сообщений уровня INFO в стандартный поток ошибок (stderr). При значении true – сообщения уровня INFO записываются только в журнал Copywala
dir_mode: 0700 # настройка прав доступа для каталогов создаваемых при архивировании
file_mode: 0600 # настройка прав доступа для архивируемых WAL-файлов
wal_file_mode: 0600 # числовое представление прав доступа на создаваемые файлы
wal_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
wal_prefetch_size: 0 # включение и регулировка многопоточной загрузки WAL-файлов. По умолчанию выключено
wal_prefetch_dir: "" # путь к директории для хранения предзагруженных WAL-файлов. По умолчанию пустое значение означает что, директория создается в каталоге pg_wal
# --------------------------------------
# Политика восстановления (ниже приведены значения по умолчанию)
# --------------------------------------
restore_policy:
workers_no: runtime.NumCPU()
jobs_queue_size: 16 # размер очереди задач на распаковку партов архива
progress_latency: 0.1 # шаг в долях от размера резервной копии, на котором сообщается прогресс (0.1 - каждые 10%)
reverse_restore: false # порядок восстановления резервных копий данных. При true – восстановление производится в обратном порядке, при false – восстановление идет последовательно
verify_page_checksums: false # активация проверки контрольных сумм страниц во время восстановления
max_allowed_page_verification_failures: 0 # максимальное количество ошибок при проверке целостности страниц во время восстановления
verify_archive_checksums: true # проверка контрольных сумм всего архива
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
write_direct_io: false # режим записи данных в файлы, исключая использование кеша ОС (не доступно для generic folder backups)
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при восстановлении из резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Конфигурация TLS используемая по умолчанию для всех сетевых соединений (DB, S2, S3, ...)
# --------------------------------------
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация Prometheus (подробное описание атрибутов по умолчанию и обязательных атрибутов каждого поля см. в документации)
# --------------------------------------
prometheus:
push_model:
jobname:
address:
process_collector_opts:
report_errors:
pid:
namespace:
frequency:
req_timeout:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
pull_model:
endpoint: /metrics
address:
process_collector_opts:
report_errors:
pid:
namespace:
handler_opts:
timeout:
max_requests_in_flight:
disable_compression:
log_errors:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Опциональные настройки приложения
# --------------------------------------
app:
agent_id_file_path: /etc/pbr/pbr.agent.id # путь к файлу, содержащему идентификатор агентcкого приложения
copywala_dir: /etc/pbr/copywala # рабочая директория
allow_concurrent_create_backup: false # управляет возможностью запуска нескольких операций создания резервных копий одновременно
agent_id_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
copywala_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
creds_private_key_path: /var/pbr/copywala/priv.key # путь к приватному ключу приложения
copywala_plugins_dir: /usr/lib/pbr/copywala # путь к директории, где находится плагин защитного преобразования
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# если параметр не указан в copywala.yaml, лимит памяти будет автоматически установлен в размере 1/4 от общего объема RAM, доступного в системе (например, при 32 ГБ оперативной памяти лимит составит 8 ГБ)
# если задано значение 0 – будут использоваться настройки Go по умолчанию
# при указании значения – будет установлен заданный лимит
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
# --------------------------------------
# Настройка параметров подключения к Platform V Monitor (OPM) и Единый клиент (SDK) Platform V Monitor (MSDK)
# --------------------------------------
audit:
central_audit: # секция с подключением к Platform V Monitor (OPM)
address: "<https://audit.example.com>"
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: "<tls/root.crt>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: "<tls/cert.crt>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: "<tls/cert.key>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
msdk_audit: # секция с подключением к Единый клиент (SDK) Platform V Monitor (MSDK)
address: "<https://audit.msdk.example.com>"
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: "<tls/root.crt>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: "<tls/cert.crt>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: "<tls/cert.key>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
retrier: # настройка повторных попыток при возникновении ошибок при отправке событий аудита
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
log:
path: /var/log/pbr/copywala.log # путь к лог-файлу
dir_mode: 0700 # настройка прав доступа на создаваемые каталоги. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
file_mode: 0600 # настройка прав доступа на создаваемые файлы. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
max_size: 100 # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # максимальный возраст лог-файла в днях
max_backups: 10 # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: true # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия
Проверка результата
Интеграция с OPM считается успешно выполненной, если в журналах (логах) приложения отсутствуют записи об ошибках, связанных с подключением, передачей данных или операциями чтения-записи с API компонента Platform V Monitor.
Platform V Vector DB (VDB)
Для интеграции с VDB укажите в конфигурационном файле copywala-vdb.yaml следующие параметры:
# --------------------------------------
# Настройка подключения к целевой БД
# --------------------------------------
vdb:
http_address: "<https://host:port>"
auth_enabled: <true/false>
# Использование учетных данных в открытом виде
username: "<username>"
password: "<password>"
# Использование учетных данных, сохраненных в защищенном виде
use_enc_creds: <true/false>
enc_creds_path: "</var/pbr/copywala/vdb.creds>"
# Формирование резервной копии в режиме полного снимка (единый снепшот-файл, содержащий все коллекции базы данных)
full_snapshot: <true/false>
# Копирование снепшот-файлов напрямую из локальной файловой системы
copy_local_snapshots: <true/false>
local_snapshots_path: "</vdb/snapshots>"
# по умолчанию применяется глобальный tls
tls:
rootca:
local_path: "<tls/root.crt>" # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: "<tls/cert.crt>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: "<tls/cert.key>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Назначение резервной копии
# --------------------------------------
# local-fs:///home/postgres/backups/
# ddboost://srv-10-15.host/storage-unit
# s3://srv-10-20.host/bucket-08-9992
# s2://srv-10-25.host:port
backup_destination_uri: "<local-fs:///vdb/backups/>"
# --------------------------------------
# Директория для восстановления данных
# --------------------------------------
restore_data_path: "</vdb/data/>"
# --------------------------------------
# Наименование экземпляра БД для восстановления (уникальное имя экземпляра агента)
# --------------------------------------
restore_instance_name: ""
# --------------------------------------
# Настройка повторных попыток при возникновении ошибок при записи РК (ниже приведены значения по умолчанию)
# --------------------------------------
retrier:
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Возможность загрузки TLS-сертификатов из защищенного хранилища секретов
# --------------------------------------
vault: # настройки подключения
server: "<vault-url>"
namespace: "<namespace>"
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: "<v2>" # версия формата хранилища ключей-значений
approle:
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Параметры подключения к KMS HashiCorp Vault
# --------------------------------------
kms:
server: "<vault-url>" # URL сервера KMS
namespace: "<namespace>" # пространство имен в KMS HashiCorp Vault
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата KV-хранилища
approle: # вариант авторизации в KMS по роли и ключа роли
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
userpass: # вариант авторизации в KMS по логину и паролю
# username:
# password:
# auth_method:
# --------------------------------------
# Конфигурация S2
# --------------------------------------
s2:
checksum_algorithm: DISABLED # выбор алгоритма вычисления контрольной суммы. Допустимые значения: DISABLED (по умолчанию), CRC32
storage_path: "" # значение по умолчанию пустое. Задается пользователем для возможности выбора одного из дополнительных хранилищ, пример: /var/pbr/s2/backups
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
s2tp_enabled: true # флаг использования протокола S2TP для взаимодействия copywala и storage service (s2). По умолчанию – true. Используется только в рамках операций передачи данных при создании и восстановлении резервных копий. gRPC остается как основной протокол для взаимодействия с S2, кроме переноса данных
s2tp:
addresses: # массив адресов серверов s2
- "<host_1:port_1>"
- "<host_2:port_2>"
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество открытых соединений к серверу на один указанный адрес (в массиве addresses)
read_timeout: 5m # таймаут для операции чтения
write_timeout: 5m # таймаут для операции записи
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация S3
# --------------------------------------
s3:
region: "<ru-test>" # регион s3
access_id: "<id>" # идентификатор пользователя
secret_key: "<key>" # секретный ключ
use_path_style: <true/false> # если параметр имеет значение true, задействуется формат полного URL с указанием пути (path-style addressing); если false – название бакета включается непосредственно в доменное имя.
disable_request_checksums: <true/false> # проверка контрольных сумм запросов
tls: # опционально
rootca:
local_path: "<tls/root.crt>" # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: "<tls/cert.crt>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: "<tls/cert.key>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к зашифрованным учетным данным для подключения к хранилищу DDBoost (заполняется опционально). При заданном значении параметры username и password в секции storage игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для copywala значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # автоматически создавать отдельное хранилище (storage_unit) в системе Data Domain для резервных копий, если оно еще не создано
storage:
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Настройки архивирования РК (ниже приведены значения по умолчанию)
# --------------------------------------
archive_settings:
upload_params:
part_payload_size: 32MB # размер парта передаваемых данных
checksum_algorithm: CRC32 # выбор алгоритма вычисления контрольной суммы. CRC32 – значение по умолчанию. Допустимые значения: DISABLED, CRC32, SHA256
compression_algorithm: S2 # выбор алгоритма сжатия данных при создании РК. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2
# --------------------------------------
# Политика исполнения резервного копирования (ниже приведены значения по умолчанию)
# --------------------------------------
backup_policy:
write_parts_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих операцию записи отдельных партов
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при создании резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Политика восстановления (ниже приведены значения по умолчанию)
# --------------------------------------
restore_policy:
workers_no: runtime.NumCPU()
jobs_queue_size: 16 # размер очереди задач на распаковку партов архива
verify_archive_checksums: true # проверка контрольных сумм всего архива
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при восстановлении из резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Конфигурация TLS используемая по умолчанию для всех сетевых соединений
# --------------------------------------
tls:
rootca:
local_path: "<tls/root.crt>" # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: "<tls/cert.crt>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: "<tls/cert.key>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Опциональные настройки приложения (ниже приведены значения по умолчанию)
# --------------------------------------
app:
agent_id_file_path: /etc/pbr/pbr.agent.id # путь к файлу, содержащему идентификатор агентcкого приложения
agent_id_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
copywala_dir: /etc/pbr/copywala # рабочая директория
copywala_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
allow_concurrent_create_backup: false # управляет возможностью запуска нескольких операций создания резервных копий одновременно
creds_private_key_path: /var/pbr/copywala/priv.key #Путь к приватному ключу приложения
copywala_plugins_dir: /usr/lib/pbr/copywala # путь к директории, где находится плагин защитного преобразования
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# если параметр не указан в copywala.yaml, лимит памяти будет автоматически установлен в размере 1/4 от общего объема RAM, доступного в системе (например, при 32 ГБ оперативной памяти лимит составит 8 ГБ)
# если задано значение 0 – будут использоваться настройки Go по умолчанию
# при указании значения – будет установлен заданный лимит
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
# --------------------------------------
# Настройка ведения журналов приложения (ниже приведены значения по умолчанию)
# --------------------------------------
log:
path: /var/log/pbr/copywala.log # путь к лог-файлу
dir_mode: 0700 # настройка прав доступа на создаваемые каталоги. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
file_mode: 0600 # настройка прав доступа на создаваемые файлы. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
max_size: 100 # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # максимальный срок хранения лог-файла в днях
max_backups: 10 # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: true # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия
Проверка результата
Интеграция с VDB считается успешно выполненной, если в журналах (логах) приложения отсутствуют записи об ошибках, связанных с подключением, передачей данных или операциями чтения-записи с API Platform V Vector DB.
DDBoost (Dell EMC Data Domain)
к сведению
DDBoost — технология интеграции с системой хранения Dell EMC Data Domain, предназначенная для оптимизации резервного копирования и восстановления данных.
DDBoost выполняет предварительную дедупликацию данных, благодаря чему по сети передаются только уникальные блоки данных. Это позволяет:
- снизить нагрузку на сеть;
- уменьшить объем передаваемых данных;
- повысить производительность операций резервного копирования и восстановления данных;
- эффективнее использовать ресурсы системы хранения.
В зависимости от способа интеграции и компонента Platform V CopyWala, который необходимо подключить к DDBoost, перейдите к описанию в соответствующем разделе и выполните указанные шаги:
Компонент, подключаемый к DDBoost | Способ интеграции (ссылка на настройку) |
|---|---|
Copywala | |
Copywala | |
Copywala VDB | |
Copywala VDB |
к сведению
Режим подключения через Storage Service (S2) предназначен для возможности работы с DDBoost в условиях с повышенными требованиями к безопасности. В отличие от прямого подключения, при подключении через S2 учетные данные DDBoost используются только на стороне S2 и не предоставляются серверам, где установлена Copywala или Copywala VDB.
Прямое подключение компонента Copywala к DDBoost
Важно
Перед началом настройки убедитесь, что клиентская библиотека DDBoost libDDBoost.so установлена на хосте компонента copywala.
Также рекомендуется добавить директорию с libDDBoost.so в переменную окружения LD_LIBRARY_PATH.
Для настройки выполните шаги:
Шаг 1.Настройка параметров в copywala.yaml
-
В конфигурационном файле
copywala.yamlдобавьте секциюddboostс параметрами подключения к DDBoost.Параметры секции
ddboost# --------------------------------------
# Настройка подключения к целевой БД
# --------------------------------------
target_db:
host: localhost
port: 5433
user: {username}
password: password
database: postgres
# опция получения секретов подключения к БД через утилиту pg_auth_config
is_pg_auth_config_enabled: false # параметр позволяет применять аутентификацию пользователей при помощи pg_auth_config # если значение выставлено true, то в данном разделе параметр password указывать не нужно
pg_auth_config_plugins_path: /usr/lib/pbr/copywala # путь к каталогу, содержащему плагины аутентификации
vault_database_engine_static_role: # имя статической роли в хранилище секретов для получения доступов к БД. Значение пустое по умолчанию
query_params: search_path=pbr # параметр позволяет настроить набор значений, специфичных для Pangolin/PostgreSQL, при подключении к базе данных
# по умолчанию применяется глобальный tls
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Возможность загрузки TLS-сертификатов из HashiCorp Vault / Secret Management System (SecMan)
# --------------------------------------
vault: # настройки подключения
server: "<vault-url>"
namespace: "<namespace>"
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата формата KV-хранилища
approle:
role_id: <role-id> # уникальный идентификатор роли
secret_id: <secret-id> # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Параметры подключения к KMS HashiCorp Vault
# --------------------------------------
kms:
server: "<vault-url>" # URL сервера KMS
namespace: "<namespace>" # пространство имен в KMS HashiCorp Vault
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата KV-хранилища
approle: # вариант авторизации в KMS по роли и ключа роли
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
userpass: # вариант авторизации в KMS по логину и паролю
# username:
# password:
# auth_method:
# --------------------------------------
# Настройки БД для хранения информации о выполненных задачах резервного копирования и восстановления данных
# --------------------------------------
pbra_db:
host: localhost
port: 5433
user: {username}
password: password
database: postgres
is_pg_auth_config_enabled: false # параметр позволяет применять аутентификацию пользователей при помощи pg_auth_config # если значение выставлено true, то в данном разделе параметр password указывать не нужно
vault_database_engine_static_role: # имя статической роли в хранилище секретов для получения доступов к БД. Значение пустое по умолчанию
query_params: search_path=pbr # параметр позволяет настроить набор значений, специфичных для Pangolin/PostgreSQL, при подключении к базе данных
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Назначение резервной копии (обязательный параметр без restore_data_path)
# --------------------------------------
# local-fs:///home/postgres/backups/
# ddboost://srv-10-15.host/storage-unit
# s3://srv-10-20.host/bucket-08-9992
# s2://srv-10-25.host:port
backup_destination_uri: local-fs:///home/postgres/backups/
# --------------------------------------
# Назначение директории для архивирования WAL-файлов
# --------------------------------------
# local-fs:///home/postgres/backups/wals/
# s3://srv-10-20.host/wals-bucket/
# s2://srv-10-25.host:port/wals/
wal_destination_uri: local-fs:///home/postgres/backups/wals/
# --------------------------------------
# Секция параметров multi-restore (механизм восстановления WAL-файлов из нескольких хранилищ)
# --------------------------------------
wal_restore:
multi_restore_wal_uris: ["s2://srv-10-25.host:29509/path1", "s2://srv-10-26.host:29509/path2"] # список хранилищ WAL-файлов. Значение параметра формируется автоматически при вызове copywala restore-wal prepare-multi-restore
multi_restore_cache_path: /var/pbr/copywala/multi-restore.wals.cache # путь к кеш-файлу с информацией о хранилищах и диапазонах WAL-файлов, которые в них находятся
# --------------------------------------
# Директория для восстановления данных (обязательный параметр без backup_destination_uri)
# --------------------------------------
restore_data_path: local-fs:///pgdata/06/data
# --------------------------------------
# Наименование экземпляра БД для восстановления
# --------------------------------------
restore_instance_name: NAME_UUID # пример: db1_0198ad69-1a19-7b7f-9f46-f200942fd61c
# --------------------------------------
# Настройка повторных попыток при возникновении ошибок при записи РК
# --------------------------------------
retrier:
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Размер WAL-файла (опционально, по умолчанию 16777216 (16MB))
# --------------------------------------
wal_segment_size: 16MB
# --------------------------------------
# Конфигурация S3
# --------------------------------------
s3:
region: ru-test # регион s3
access_id: <id> # идентификатор пользователя
secret_key: <key> # секретный ключ
use_path_style: false # если параметр имеет значение true, задействуется формат полного URL с указанием пути (path-style addressing); если false – название бакета включается непосредственно в доменное имя.
disable_request_checksums: false # проверка контрольных сумм запросов
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация S2
# --------------------------------------
s2:
checksum_algorithm: DISABLED # выбор алгоритма вычисления контрольной суммы. Допустимые значения: DISABLED (по умолчанию), CRC32
storage_path: "" # значение по умолчанию пустое. Задается пользователем для возможности выбора одного из дополнительных хранилищ, пример: /var/pbr/s2/backups
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
s2tp_enabled: true # флаг использования протокола S2TP для взаимодействия copywala и storage service (s2). По умолчанию – true. Используется только в рамках операций передачи данных при создании и восстановлении резервных копий. gRPC остается как основной протокол для взаимодействия с S2, кроме переноса данных.
# при значении false – используется gRPC для всех взаимодействий
s2tp:
addresses: # массив адресов сервера s2
- "<host_1:port_1>"
- "<host_2:port_2>"
# ...
# Важно: порты, указанные в этом массиве должны совпадать с портам из storage-service.yaml блока s2.s2tp.addresses.
# Хосты, указанные в этом массиве должны совпадать с значением параметра backup_destination_uri файла copywala.yaml.
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество открытых соединений к серверу (на все указанные в массиве s2tp.addresses адреса)
read_timeout: 5m # таймаут для операции чтения
write_timeout: 5m # таймаут для операции записи
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к учетным данным (защищенным преобразованием) для подключения к хранилищу DDBoost (заполняется опционально). При заданном значении параметры username и password в секции storage игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для copywala значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # автоматически создавать отдельное хранилище (storage_unit) в системе Data Domain для резервных копий, если оно еще не создано
storage:
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Настройки архивирования РК
# --------------------------------------
archive_settings:
upload_params:
part_payload_size: 32MB # размер парта передаваемых данных
checksum_algorithm: CRC32 # выбор алгоритма вычисления контрольной суммы. CRC32 – значение по умолчанию. Допустимые значения: DISABLED, CRC32, SHA256
compression_algorithm: S2 # выбор алгоритма сжатия данных при создании РК. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2
# --------------------------------------
# Политика исполнения резервного копирования
# --------------------------------------
backup_policy:
strategy: pbr.policy.backup.strategy.full # выбор стратегии резервного копирования. Также доступно – pbr.policy.backup.strategy.delta
fast_checkpoint: false # флаг для переключения типа контрольной точки, по умолчанию spread (протяженная), при включении запускает принудительное создание контрольной точки сразу при начале создания базовой РК
workers_no: 2 # количество параллельных потоков, осуществляющих чтение из каталога PGDATA с диска (не включая WAL-файлы)
max_pending_wals: -1 # задает режим работы очереди (включение/отключение) и ее максимальный лимит для WAL-файлов, обрабатываемых в текущий момент (по умолчанию «-1» – очередь включена без ограничения размера)
progress_latency: 0.025 # шаг в долях от размера резервной копии, на котором сообщается прогресс
use_temporary_replication_slot: true # флаг включения использования временного слота репликации при выполнении резервного копирования: при true – используется временный слот репликации, при значении false – используется постоянный слот репликации
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
write_direct_io: false # режим записи данных в файл без использования кеша ОС (актуально для локальных РК)
read_cache_size: # значение параметра должно быть кратно 4 КБ на Linux # используйте совместно с read_direct_io для РК произвольной папки (generic folder backup)
delta_max_steps: 3 # допустимое отставание реплики от главного узла при восстановлении, измеряемое количеством пропущенных шагов репликации
write_parts_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих операцию записи отдельных партов
write_wals_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих обработку WAL-файлов
verify_page_checksums: false # активация проверки контрольных сумм страниц во время исполнения РК
max_allowed_page_verification_failures: 0 # максимальное количество ошибок при проверке целостности страниц во время исполнения РК
backup_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
backup_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
wal_stream_tmp_dir: /tmp # директория для временного хранения WAL-файлов перед записью в резервную копию
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при создании резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
compress_tde: true # включает защитное преобразование на стороне copywala. Используется если включено сжатие (в copywala.yaml задан archive_settings.compression_algorithm) и в Pangolin включен TDE (в is_tde_on = on).
# Данный параметр игнорируется при резервном копировании чистого PostgreSQL, произвольных директорий (generic-folder) и других СУБД, в которых не используется защитное преобразование
extra_files: # список путей к дополнительным файлам, которые необходимо включить в резервную копию. По умолчанию пуст: это значит, что в архив резервной копии будут сохранены только данные из PGDATA и из связанных с ней табличных пространств
# файлы, указанные ниже, приведены для примера
- /etc/pangolin-pooler/pangolin-pooler.ini
- /etc/pangolin-manager/postgres.yml
# --------------------------------------
# Пример политики слияния (значения по умолчанию)
# --------------------------------------
merge_policy:
write_parts_workers_no: max(runtime.NumCPU()/2, 1) # количество одновременно работающих процессов для записи частей резервных копий. Устанавливается равным половине числа ядер CPU, но минимум один поток
read_parts_workers_no: max(runtime.NumCPU()/2, 1) # количество одновременно работающих процессов для чтения резервных копий. Равно половине количества ядер CPU, но не менее одного потока
verify_page_checksums: false # проверка контрольных сумм страниц PostgreSQL
max_allowed_page_verification_failures: 0 # максимальное число допустимых ошибок при проверке контрольных сумм страниц
verify_archive_checksums: true # проверка контрольных сумм всего архива резервной копии
read_direct_io: false # приложение будет использовать буферизованный ввод-вывод операционной системы при чтении данных
write_direct_io: false # приложение будет использовать буферизованный ввод-вывод операционной системы при записи данных
# --------------------------------------
# Параметры синхронизации узлов кластера БД
# --------------------------------------
catchup_policy:
strategy: pbr.policy.backup.strategy.full # стратегия синхронизации
# параметры для основного узла (primary)
master_params:
workers_no: 4 # количество параллельных рабочих процессов (workers), одновременно на одном воркере загружается только один файл
wals_workers_no: 4 # количество параллельных рабочих процессов (workers), необходимых для передачи WAL-файлов через репликационный протокол
max_pending_wals: -1 # размер очереди WAL-файлов на отправку. Останавливает синхронизацию (catchup), если лимит очереди WAL-файлов на отправку превышен. По умолчанию выключен
wal_stream_tmp_dir: # директория для временного хранения WAL-файлов
progress_latency: 0.1 # шаг в долях от размера резервной копии, на котором в логах отображается прогресс (0.1 - каждые 10%)
write_file_timeout: 30m # тайм-аут загрузки одного файла, если файл не успел загрузиться за это время, то синхронизация (catchup) обрывается
fast_checkpoint: false # флаг для переключения типа контрольной точки
allow_replica_hosts: # хосты всех узлов кластера, с которых мастеру разрешено подключаться к серверу реплики
- 10.40.48.109
s2tp:
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество TCP-соединений, которое может быть открыто при взаимодействии с сервером реплики одновременно
read_timeout: 5m # тайм-аут одного запроса на чтение, не учитывается при загрузке файла
write_timeout: 5m # тайм-аут одного запроса на запись, не учитывается при загрузке файла
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# параметры для узла-реплики (standby)
replica_params:
s2tp:
addresses: # адреса, на которых запускается сервер реплики и ожидаются подключения от primary. Если используется Pangolin Manager или другие инструменты управления кластером, убедитесь, что указанные адреса доступны с мастера
- 0.0.0.0:29505
mtls: false # флаг включения взаимодействия по mTLS
max_connections: 16 # максимальное количество TCP-соединений, которое может быть открыто при взаимодействии с сервером реплики одновременно
read_timeout: 5m # тайм-аут одного запроса на чтение, не учитывается при загрузке файла
write_timeout: 5m # тайм-аут одного запроса на запись, не учитывается при загрузке файла
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация архивирования WAL-файлов
# --------------------------------------
wal_archiving:
is_multi_wal_archiving_enabled: false # многопоточный режим архивации WAL-файлов
multi_wal_archiving_workers_no: 4 # количество потоков для параллельной передачи WAL-файлов в хранилище
wal_batch_size: 100 # 100 по умолчанию. Чтобы отключить ограничение размера пакета, установите значение равным 0 или любому отрицательному целому числу
# Archive WALs in CWL
is_wal_archiving_in_cwl_enabled: false # включение/отключение архивации журналов предзаписи WAL в CWL
wal_archiving_cwl_max_file_size: 1GB # максимальный размер CWL-архива с WAL-сегментами
force_switch_cwl_lock_timeout: 15s # Максимальное время ожидания командой copywala archive-wal force-switch-cwl освобождения эксклюзивной блокировки, удерживаемой процессом copywala archive-wal при архивировании WAL-файлов в CWL-архив
wal_compression_algorithm: S2 # алгоритм сжатия WAL-файлов. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2, LZ4
is_archive_logs_to_file_only: false # флаг отключения логирования сообщений уровня INFO в стандартный поток ошибок (stderr). При значении true – сообщения уровня INFO записываются только в журнал Copywala
dir_mode: 0700 # настройка прав доступа для каталогов создаваемых при архивировании
file_mode: 0600 # настройка прав доступа для архивируемых WAL-файлов
wal_file_mode: 0600 # числовое представление прав доступа на создаваемые файлы
wal_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
wal_prefetch_size: 0 # включение и регулировка многопоточной загрузки WAL-файлов. По умолчанию выключено
wal_prefetch_dir: "" # путь к директории для хранения предзагруженных WAL-файлов. По умолчанию пустое значение означает что, директория создается в каталоге pg_wal
# --------------------------------------
# Политика восстановления (ниже приведены значения по умолчанию)
# --------------------------------------
restore_policy:
workers_no: runtime.NumCPU()
jobs_queue_size: 16 # размер очереди задач на распаковку партов архива
progress_latency: 0.1 # шаг в долях от размера резервной копии, на котором сообщается прогресс (0.1 - каждые 10%)
reverse_restore: false # порядок восстановления резервных копий данных. При true – восстановление производится в обратном порядке, при false – восстановление идет последовательно
verify_page_checksums: false # активация проверки контрольных сумм страниц во время восстановления
max_allowed_page_verification_failures: 0 # максимальное количество ошибок при проверке целостности страниц во время восстановления
verify_archive_checksums: true # проверка контрольных сумм всего архива
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
write_direct_io: false # режим записи данных в файлы, исключая использование кеша ОС (не доступно для generic folder backups)
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при восстановлении из резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Конфигурация TLS используемая по умолчанию для всех сетевых соединений (DB, S2, S3, ...)
# --------------------------------------
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация Prometheus (подробное описание атрибутов по умолчанию и обязательных атрибутов каждого поля см. в документации)
# --------------------------------------
prometheus:
push_model:
jobname:
address:
process_collector_opts:
report_errors:
pid:
namespace:
frequency:
req_timeout:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
pull_model:
endpoint: /metrics
address:
process_collector_opts:
report_errors:
pid:
namespace:
handler_opts:
timeout:
max_requests_in_flight:
disable_compression:
log_errors:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Опциональные настройки приложения
# --------------------------------------
app:
agent_id_file_path: /etc/pbr/pbr.agent.id # путь к файлу, содержащему идентификатор агентcкого приложения
copywala_dir: /etc/pbr/copywala # рабочая директория
allow_concurrent_create_backup: false # управляет возможностью запуска нескольких операций создания резервных копий одновременно
agent_id_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
copywala_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
creds_private_key_path: /var/pbr/copywala/priv.key # путь к приватному ключу приложения
copywala_plugins_dir: /usr/lib/pbr/copywala # путь к директории, где находится плагин защитного преобразования
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# если параметр не указан в copywala.yaml, лимит памяти будет автоматически установлен в размере 1/4 от общего объема RAM, доступного в системе (например, при 32 ГБ оперативной памяти лимит составит 8 ГБ)
# если задано значение 0 – будут использоваться настройки Go по умолчанию
# при указании значения – будет установлен заданный лимит
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
# --------------------------------------
# Настройка параметров подключения к Platform V Monitor (OPM) и Единый клиент (SDK) Platform V Monitor (MSDK)
# --------------------------------------
audit:
central_audit: # секция с подключением к Platform V Monitor (OPM)
address: "<https://audit.example.com>"
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: "<tls/root.crt>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: "<tls/cert.crt>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: "<tls/cert.key>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
msdk_audit: # секция с подключением к Единый клиент (SDK) Platform V Monitor (MSDK)
address: "<https://audit.msdk.example.com>"
tls: # (опционально) сертификаты для подключения к хранилищу через tls
rootca: # пути к сертификату удостоверяющего центра
local_path: "<tls/root.crt>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
cert: # пути к сертификату сервера
local_path: "<tls/cert.crt>"
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
key: # пути к ключу сервера
local_path: "<tls/cert.key>" # путь к локальному файлу
vault_path: "<path>" # путь к секрету в HashiCorp Vault/SecMan
vault_key: "<key>" # ключ внутри JSON-секрета
retrier: # настройка повторных попыток при возникновении ошибок при отправке событий аудита
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
log:
path: /var/log/pbr/copywala.log # путь к лог-файлу
dir_mode: 0700 # настройка прав доступа на создаваемые каталоги. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
file_mode: 0600 # настройка прав доступа на создаваемые файлы. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
max_size: 100 # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # максимальный возраст лог-файла в днях
max_backups: 10 # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: true # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия -
Заполните обязательные параметры:
Параметр Расположение Описание client_settings.ddboost_lib_pathФайл copywala.yaml, блокddboostПуть к динамической библиотеке DDBoost, по умолчанию — libDDBoost.so. Если не задана переменнаяLD_LIBRARY_PATHили в ней отсутствует нужный путь, укажите здесь полный путь к файлуbackup_destination_uriФайл copywala.yamlПуть к хранилищу DDBoost для резервных копий (например, ddboost://srv-10-15.host/storage-unit)Также обязательными в блоке
ddboostявляются параметры учетных данных для подключения к хранилищу DDBoost. Настройка учетных данных описана в отдельном шаге 2.примечаниеИспользование DDBoost возможно только для резервных копий. Хранение WAL-файлов не поддерживается.
Шаг 2. Настройка учетных данных
Учетные данные для подключения к хранилищу DDBoost задаются в конфигурационном файле copywala.yaml в секции ddboost.
Настройте учетные данные одним из способов:
-
Явная передача логина и пароля: задайте значения для параметров:
ddboost.storage.usernameddboost.storage.password
-
Использование локального хранилища секретов. Для этого:
-
Задайте значение для параметра
ddboost.enc_creds_path– путь, по которому будет создан зашифрованный файл с учетными данными. -
Запустите генерацию криптографических ключей командой
copywala init keys.Справка по команде
copywala init keysОписание:
Запускает генерацию пары криптографических ключей (приватного и публичного), необходимых для защитного преобразования учетных данных.
В результате выполнения будет сгенерирована пара ключей:
- приватный –
/var/pbr/copywala/priv.key; - публичный –
/var/pbr/copywala/priv.key.pub.
Ключи, необходимые для защитного преобразования, хранятся локально в зашифрованном виде и используются только внутренними механизмами copywala.
Путь к приватному ключу настраивается в конфигурационном файле
copywala.yamlпараметром:app:
creds_private_key_path: /var/pbr/copywala/priv.key # значение по умолчаниюПубличный ключ с постфиксом
.pubбудет сохранен в той же директории, что и приватный.Синтаксис:
copywala init keys [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to copywala config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala.yaml--forceПринудительная замена существующего файла с ключом (повторная генерация), если он уже существует ВажноПри принудительной повторной генерации (
--force) необходимо повторно инициализировать локальное хранилищеcopywala init credsтакже с флагом--force.В результате выполнения команды будет выведено:
$ copywala init keys
2026-05-18 20:48:57.659 [75866] INF run init keys key_path=/var/pbr/copywala/priv.key
2026-05-18 20:48:57.659 [75866] INF init keys completed - приватный –
-
Инициализируйте локальное хранилище секретов командой
copywala init creds ddboost, передав учетные данные одним из способов (подробнее – в справке по команде).Справка по команде
copywala init creds ddboostОписание:
Выполнение инициализации локального хранилища секретов c учетными данными для подключения к хранилищам DDBoost. Выполнение команды возможно только после запуска
copywala init keys, так как над файлом, который создается командойcopywala init creds ddboost, выполняется защитное преобразование с использованием ранее сгенерированного приватного ключа.В результате будет создан файл с учетными данными по пути, указанному в параметре
ddboost.enc_creds_pathконфигурационного файлаcopywala.yaml(пример значения):ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.credsВажноПеред выполнением команды убедитесь, что параметр
ddboost.enc_creds_pathконфигурационного файлаcopywala.yamlзаполнен.Синтаксис:
copywala init creds ddboost [flags]Обязательные параметры:
Нет.
В команде должны быть переданы учетные данные одним из способов:
-
Передача через стандартный ввод. Пример:
echo '{"username": "user_example", "password": "password_example"}' | copywala init creds ddboost -
Передача через файл с помощью флага
--file:copywala init creds ddboost --file ddboost.creds.jsonФайл должен быть в формате JSON и обязательно содержать поля
usernameиpassword:{
"username": "<user_example>",
"password": "<password_example>"
}
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to copywala config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala.yaml--forceПринудительная замена существующего файла с ключом, если он уже существует --file <path to file>Загрузка секретов из json-файла В результате выполнения команды будет выведено (ниже пример с передачей учетных данных через стандартный ввод):
$ echo '{"username": "user_example", "password": "password_example"}' | copywala init creds ddboost
2026-05-18 22:14:31.846 [84779] INF copywala 1.3.0 (aefa53e9) compiled at 2026-05-17_21:09:46
2026-05-18 22:14:31.846 [84779] INF run init ddboost creds creds_path=/var/pbr/copywala/ddboost.creds
2026-05-18 22:14:31.847 [84779] INF init ddboost creds completed -
-
Опциональный шаг. Выполните проверку возможности чтения из локального хранилища секретов командой
copywala init creds check.Справка по команде
copywala init creds checkОписание:
Запускает проверку возможности чтения из локального хранилища секретов. В результате выполнения команды отображается загруженное из хранилища имя пользователя.
Синтаксис:
copywala init creds check [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to copywala config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala.yaml--forceДанный флаг не применим к этой команде --file <path to file>Проверка секретов из json-файла В результате выполнения команды будет выведено (ниже приведен пример с передачей учетных данных через стандартный ввод):
$ copywala init creds check
2026-05-18 22:26:51.331 [86121] INF copywala 1.3.0 (aefa53e9) compiled at 2026-05-17_21:09:46
2026-05-18 22:26:51.331 [86121] INF check ddboost creds creds_path=/var/pbr/copywala/ddboost.creds
2026-05-18 22:26:51.331 [86121] INF ddboost username: user_example
2026-05-18 22:26:51.331 [86121] INF check ddboost creds completed
-
Шаг 3. Настройка TLS (опциональный)
- Для взаимодействия с хранилищем DDBoost по протоколу TLS добавьте в секцию
ddboost.storageфайлаcopywala.yamlуказанные ниже параметры и задайте для них необходимые значения:
Параметр | Описание | Значение по умолчанию |
|---|---|---|
| Флаг включения взаимодействия по TLS. Установите значение |
|
| Режим TLS. Возможные значения:
Пример конфигурации:
Пример конфигурации:
Пример конфигурации: |
|
| Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения:
|
|
| В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения:
Флаги можно комбинировать, например, при значении |
|
к сведению
Более подробное описание параметров и их допустимых значений смотрите в официальной документации DDBoost.
- Также в
copywala.yamlзаполните секциюddboost.storage.tlsисходя из заданных на предыдущем шаге параметровuse_tlsиauth_mode.
Проверка результата
Для проверки корректности подключения к хранилищу DDBoost выполните команду:
copywala healthcheck ddboost
В результате выполнения команды будет выведен статус подключения (пример вывода):
+--------------------------+--------+
| URI | RESULT |
+--------------------------+--------+
| ddboost://server1.domain | OK |
+--------------------------+--------+
| All | OK |
+--------------------------+--------+
Подключение компонента Copywala к DDBoost через Storage Service (S2)
Важно
Перед началом настройки убедитесь, что клиентская библиотека DDBoost libDDBoost.so установлена на хосте компонента storage-service.
Также рекомендуется добавить директорию с libDDBoost.so в переменную окружения LD_LIBRARY_PATH.
Шаг 1. Настройка параметров в copywala.yaml
примечание
Использование DDBoost возможно только для резервных копий. Хранение WAL-файлов не поддерживается.
В файле copywala.yaml задайте значение для параметра backup_destination_uri согласно указанному ниже формату:
backup_destination_uri: s2://<s2-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unit?driver=ddboost&data_domain_host=<ddboost-host>
Описание параметров:
<s2-host>— хост S2;<ddboost-storage-unit>— имя хранилища DDBoost;/path/in/ddboost/storage/unit— путь внутри хранилища;driver=ddboost— включает использование драйвера DDBoost;data_domain_host=<ddboost-host>— адрес хранилища (Data Domain хоста).
Важно
Заполнять в copywala.yaml секцию ddboost не требуется, так как вся работа с DDBoost выполняется через Storage Service (S2), который самостоятельно обрабатывает взаимодействие с DDBoost.
Шаг 2. Настройка параметров в storage-service.yaml
-
В конфигурационном файле
storage-service.yamlдобавьте секциюddboostс параметрами подключения к DDBoost.Параметры секции
ddboost# --------------------------------------
# Настройки для взаимодействия с API Gateway
# --------------------------------------
api_gateway:
http_address: https://localhost:29000 # адрес для подключения Storage Service к сервисам инфраструктуры
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Параметры подключения к HarhiCorp/SecMan
# --------------------------------------
vault: # настройки подключения
server: <vault-url>
namespace: <namespace>
path: <mount-path> # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата хранилища ключей-значений
approle:
role_id: <role-id> # уникальный идентификатор роли
secret_id: <secret-id> # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
auth_method: approle # метод аутентификации
wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Опциональные настройки приложения
# --------------------------------------
app:
work_dir: /var/pbr/storage-service # рабочий каталог приложения для хранения временных файлов, журналов и т.д.
work_dir_mode: 0700 # права доступа к рабочему каталогу. 0700 означает, что полный доступ к этому каталогу имеет только владелец файла.
creds_private_key_path: /var/pbr/copywala/priv.key # путь к приватному ключу приложения
go_mem_limit: 0 # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
go_gc_percent: 0 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
go_mem_limit: 0 # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# при указании значения будет установлен соответствующий лимит памяти. По умолчанию используется значение 0, при котором применяются стандартные настройки Go
go_gc_percent: 0 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
zero_copy: true # флаг для использования методов zero-copy (нулевого копирования) записи данных
# --------------------------------------
# Пример политики слияния (значения по умолчанию)
# --------------------------------------
merge_policy:
write_parts_workers_no: max(runtime.NumCPU()/2, 1) # определяет количество рабочих потоков, используемых для одновременной записи частей файла.
read_parts_workers_no: max(runtime.NumCPU()/2, 1) # определяет количество потоков для параллельной обработки чтения частей файла.
write_direct_io: false # если false, приложение будет использовать буферизованный ввод-вывод операционной системы при записи данных.
read_direct_io: false # если false, приложение будет использовать буферизованный ввод-вывод операционной системы при чтении данных.
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к зашифрованным учетным данным для подключения для подключения к хранилищам DDBoost (заполняется опционально). При заданном значении enc_creds_path параметры username и password в секции storages игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для storage-service значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # при запуске сервиса автоматически проверять наличие отдельных хранилищ в системе Data Domain, указанных в storage-service.yaml в параметрах storage_path и allowed_storage_paths. Если хранилища отсутствуют, они будут созданы автоматически
storages: # секция со списком хранилищ (Data Domain) с их параметрами подключения
- address: "<ip_address>" # IP-адрес хранилища
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в storage-service.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в storage-service.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
- ... # список хранилищ
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Параметры gRPC-сервера Storage Service
# --------------------------------------
grpc:
address: 0.0.0.0:29509
mtls: false # необходимость проверки сертификатов клиента
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Параметры s2tp-сервера Storage Service
# --------------------------------------
s2tp:
addresses: # массив для указания используемых адресов сетевых интерфейсов для работы серверов. Если массив не задан, используется значение параметра backup_destination_uri из файла copywala.yaml, к которому автоматически добавляются порты по умолчанию: 29500 и 29501
- 0.0.0.0:29500
- 0.0.0.0:29501
# ...
mtls: false # необходимость проверки сертификатов клиента
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
max_connections: 256 # максимальное количество подключений для одного адреса, указанного выше
read_timeout: 5m # тайм-аут для операции чтения
write_timeout: 5m # тайм-аут для операции записи
# --------------------------------------
# Путь к основному хранилищу
# --------------------------------------
storage_path: /var/pbr/backups # если в файле copywala.yaml не настроен параметр storage_path, то резервные копии должны сохраняться по пути, указанному в данной конфигурации (storage_path - значение по умолчанию)
# ddboost://1.2.3.4/storage-unit/sub/dir
# --------------------------------------
# Список дополнительных хранилищ, разрешенных для установки со стороны клиента
# --------------------------------------
allowed_storage_paths:
- /mnt/nfs-001
- /mnt/nfs-002
- /mnt/nfs-003
# Примеры значений allowed_storage_paths:
# - /mnt/nfs/backups
# - /mnt/ci/backups
# - local-fs:///mnt/ff/backups
# - ddboost://1.2.3.4/storage-unit/sub/dir
is_allowed_storage_paths_only: true # включает проверку хранилища, полученного от copywala (задается в copywala.yaml параметром storage_path) на наличие списке разрешенных хранилищ (определяется параметром allowed_storage_paths):
# true — запись выполняется только если storage_path входит в список разрешенных хранилищ
# false — запись выполняется без проверки storage_path
# --------------------------------------
# Максимальное количество одновременных потоков на одного клиента
# --------------------------------------
max_concurrent_streams: 256
# --------------------------------------
# Конфигурация TLS
# --------------------------------------
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация Prometheus (подробное описание атрибутов по умолчанию и обязательных атрибутов каждого поля см. в документации)
# --------------------------------------
prometheus:
push_model:
jobname:
address:
process_collector_opts:
report_errors:
pid:
namespace:
frequency:
req_timeout:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
pull_model:
endpoint: /metrics
address:
process_collector_opts:
report_errors:
pid:
namespace:
handler_opts:
timeout:
max_requests_in_flight:
disable_compression:
log_errors:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
log:
path: /var/log/pbr/storage-service.log # обязательно к заполнению
max_size: 100 # мегабайты # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # дни # максимальный возраст лог-файла в днях
max_backups: 10 # шт # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: false # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатияВажноDDBoost имеет ограничение на количество соединений: один процесс может использовать одновременно не более 64 соединений.
При настройке нескольких хранилищ необходимо учитывать суммарное значение параметра
ddboost.storages.max_conns_no(файлstorage-service.yaml) для всех подключений. Контроль и валидация этого ограничения на уровне приложения не выполняются.Также необходимо учитывать взаимосвязь параметров:
- значение параметра
restore_policy.workers_noв файлеcopywala.yamlдолжно быть меньше или равно значению параметраs2.ddboost.max_conns_noв файлеstorage-service.yaml.
При работе с пулом соединений важно учитывать следующие особенности:
- соединения переиспользуются и являются общими для всех команд и операций;
- пул используется не только для многопоточного восстановления данных, но и для любых других запросов, например
copywala cwl info; - при одновременном выполнении нескольких операций с одним хранилищем значение
max_conns_noраспределяется между всеми активными задачами.
- значение параметра
-
В секции
ddboostзаполните:-
параметр
ddboost_lib_path– путь к динамической библиотеке DDBoost, по умолчанию —libDDBoost.so. Если не задана переменнаяLD_LIBRARY_PATHили в ней отсутствует нужный путь, укажите здесь полный путь к файлу. -
массив
ddboost.storages– содержит параметры подключения к хранилищам. Пример заполнения:примечаниеНа данном шаге в массиве
ddboost.storagesзаполните только параметрыaddress. Описание настройки параметров учетных данных (usernameиpassword) описано в отдельном шаге 3.ddboost:
storages:
- address: <ip_address_1> # IP-адрес хранилища 1
username: <"user_example_1"> # имя пользователя для подключения к хранилищу 1 DDBoost
password: <"password_example_1"> # пароль для подключения к хранилищу 1 DDBoost
- address: <ip_address_2> # IP-адрес хранилища 2
username: <"user_example_2"> # имя пользователя для подключения к хранилищу 2 DDBoost
password: <"password_example_2"> # пароль для подключения к хранилищу 2 DDBoost
-
-
Также в файле
storage-service.yamlзадайте значения для параметров:-
storage_path– путь к хранилищу DDBoost для резервных копий (например,ddboost://1.2.3.4/storage-unit/sub/dir). -
allowed_storage_paths– массив URI разрешенных хранилищ. Важно: значение, заданное в параметреbackup_destination_uriфайлаcopywala.yamlдолжно согласовываться минимум с одним из массиваallowed_storage_paths. Например, если вcopywala.yaml:backup_destination_uri: s2://<s2-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unit?driver=ddboost&data_domain_host=<ddboost-host>то в массиве
allowed_storage_pathsфайлаstorage-service.yamlдолжно быть указано хранилище в таком формате:allowed_storage_paths:
- ddboost://<ddboost-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unitВажно, чтобы в параметрах
backup_destination_uriиallowed_storage_pathsбыли идентичными значения для:- Хостов (в примере выше –
<ddboost-host>); - Путей (в примере выше –
<ddboost-storage-unit>/path/in/ddboost/storage/unit).
- Хостов (в примере выше –
ВажноВ
storage_pathиallowed_storage_pathsможно указывать только те URI, хост которых есть либо вenc_creds_path(подробнее проenc_creds_pathв шаге 3), либо в секцииddboost.storages. -
Шаг 3. Настройка учетных данных
Учетные данные для подключения к хранилищу DDBoost также задаются в конфигурационном файле storage-service.yaml в секции ddboost.
Настройте учетные данные одним из способов:
-
Явная передача логина и пароля: для каждого из перечисленных в блоке
storagesхранилищ задайте значения для параметров:ddboost.storages.usernameddboost.storages.password
-
Использование локального хранилища секретов. Для этого:
-
Задайте значение для параметра
ddboost.enc_creds_path– путь, по которому будет создан файл с учетными данными, прошедшими защитное преобразование. -
Запустите генерацию криптографических ключей командой
storage-service init keys.Справка по команде
storage-service init keysОписание:
Запускает генерацию пары криптографических ключей (приватного и публичного), необходимых для защитного преобразования учетных данных.
В результате выполнения будет сгенерирована пара ключей:
- приватный –
/var/pbr/storage-service/priv.key; - публичный –
/var/pbr/storage-service/priv.key.pub.
Ключи, необходимые для защитного преобразования, хранятся локально в зашифрованном виде и используются только внутренними механизмами storage-service.
Путь к приватному ключу настраивается в конфигурационном файле
storage-service.yamlпараметром:app:
creds_private_key_path: /var/pbr/storage-service/priv.key # значение по умолчаниюПубличный ключ с постфиксом
.pubбудет сохранен в той же директории, что и приватный.Синтаксис:
storage-service init keys [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceПринудительная замена существующего файла с ключом (повторная генерация), если он уже существует ВажноПри принудительной повторной генерации (
--force) необходимо повторно инициализировать локальное хранилищеstorage-service init ddboost-credsтакже с флагом--force. - приватный –
-
Инициализируйте локальное хранилище секретов командой
storage-service init ddboost-creds, передав учетные данные одним из способов (подробнее – в справке по команде).Справка по команде
storage-service init ddboost-credsОписание:
Выполнение инициализации локального хранилища секретов c учетными данными для подключения к хранилищам DDBoost. Выполнение команды возможно только после запуска
storage-service init keys, так как над файлом, который создается командойstorage-service init ddboost-creds, выполняется защитное преобразование с использованием ранее сгенерированного приватного ключа.В результате будет создан файл с учетными данными по пути, указанному в параметре
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yaml(пример значения):ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.credsВажно- Перед выполнением команды убедитесь, что параметр
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yamlзаполнен. - Если выполняется Добавление хранилищ DDBoost без остановки Storage Service (S2) и для имеющихся хранилищ DDBoost уже используется локальное хранилище секретов, то перед выполнением
storage-service init ddboost-credsне требуется предварительно запускатьstorage-service init keys.
Синтаксис:
storage-service init ddboost-creds [flags]Обязательные параметры:
Нет. В команде должны быть переданы учетные данные одним из способов:
-
Передача через стандартный ввод. Пример:
echo '{"creds": [{"address": "ip_adress_1", "username": "user_example_1", "password": "password_example_1"}, {"address": "ip_adress_2", "username": "user_example_2", "password": "password_example_2"}]}' | storage-service init ddboost-creds -
Передача через файл с помощью флага
--file:storage-service init ddboost-creds --file ddboost.creds.jsonФайл должен быть в формате JSON и обязательно содержать поля
address,usernameиpassword:{
"creds": [
{
"address": "<ip_address_1>",
"username": "<user_example_1>",
"password": "<password_example_1>"
},
{
"address": "<ip_address_2>",
"username": "<user_example_2>",
"password": "<password_example_2>"
}
// ...
]
}Важно- Значение поля
addressдля каждого хранилища должно совпадать со значением параметраddboost.storages.addressиз файлаstorage-service.yamlдля соответствующего хранилища. - При добавлении учетных данных для новых хранилищ передайте полный список учетных данных: как для уже зарегистрированных, так и для новых хранилищ. Это правило действует как при использовании флага
--file, так и при передаче данных через стандартный ввод.
- Значение поля
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceПринудительная замена существующего файла с учетными данными --file <path to file>Загрузка секретов из json-файла - Перед выполнением команды убедитесь, что параметр
-
Опциональный шаг. Выполните проверку возможности чтения из локального хранилища секретов командой
storage-service init ddboost-creds check.Справка по команде
storage-service init ddboost-creds checkОписание:
Запускает проверку возможности чтения из локального хранилища секретов. В результате выполнения команды отображается загруженное из хранилища имя пользователя.
Синтаксис:
storage-service init ddboost-creds check [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceДанный флаг не применим к этой команде --file <path to file>Проверка секретов из json-файла
-
Шаг 4. Настройка TLS (опциональный)
- Для взаимодействия с хранилищем DDBoost по протоколу TLS добавьте в секцию
ddboost.storageфайлаstorage-service.yamlуказанные ниже параметры и задайте для них необходимые значения:
Параметр | Описание | Значение по умолчанию |
|---|---|---|
| Флаг включения взаимодействия по TLS. Установите значение |
|
| Режим TLS. Возможные значения:
Пример конфигурации:
Пример конфигурации:
Пример конфигурации: |
|
| Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения:
|
|
| В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения:
Флаги можно комбинировать, например, при значении |
|
к сведению
Более подробное описание параметров и их допустимых значений смотрите в официальной документации DDBoost.
- Также в
storage-service.yamlзаполните секциюddboost.storages.tlsисходя из заданных на предыдущем шаге параметровuse_tlsиauth_mode.
Проверка результата
Интеграция с хранилищем DDBoost считается успешной, если при запуске Storage Service не возникло соответствующей ошибки.
Добавление хранилищ DDBoost без остановки Storage Service (S2)
Для подключения новых хранилищ DDBoost не требуется останавливать или перезапускать Storage Service. Для этого добавьте параметры новых хранилищ в конфигурационный файл storage-service.yaml и инициируйте перечитывание конфигурации без перезапуска сервиса.
Такой подход позволяет динамически расширять список доступных хранилищ. Резервное копирование и другие операции не прерываются, время простоя системы снижается.
Storage Service поддерживает обработку сигнала SIGHUP для применения изменений. Сигнал инициирует повторное чтение конфигурационного файла и подключение новых хранилищ DDBoost.
Важно
Механизм динамического обновления поддерживает только добавление новых хранилищ DDBoost. Изменять или удалять параметры (например, адрес, учетные данные или другие настройки подключения) для уже зарегистрированных хранилищ DDBoost нельзя. Для этого требуется перезапуск Storage Service с обновленной конфигурацией.
Последовательность действий
-
В конфигурационном файле
storage-service.yamlдобавьте новые хранилища в массивddboost.storages::caption: Пример
ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.creds
storages:
- address: "192.0.2.0" # IP-адрес имеющегося ранее хранилища
username: "<username_for_first_storage>"
password: "<password_for_first_storage>"
max_conns_no: 16
max_idle_time: 5m
- address: "192.0.2.1" # IP-адрес нового хранилища 1, которое необходимо добавить
username: "<username_for_second_storage>"
password: "<password_for_second_storage>"
max_conns_no: 16
max_idle_time: 5m
- address: "192.0.2.2" # IP-адрес нового хранилища 2, которое необходимо добавить
username: "<username_for_second_storage>"
password: "<password_for_second_storage>"
max_conns_no: 16
max_idle_time: 5mпримечаниеНа данном шаге в массиве
ddboost.storagesзаполните только параметрыaddress. Описание настройки параметров учетных данных (usernameиpassword), будет описано далее в шаге 3. -
При необходимости добавьте пути к новым хранилищам в секцию
allowed_storage_paths::caption: Пример
allowed_storage_paths:
- ddboost://192.0.2.0/storage-unit-001 # имеющийся ранее путь
- ddboost://192.0.2.1/storage-unit-002 # новый путь
- ddboost://192.0.2.2/storage-unit-003 # новый путь -
Настройте учетные данные для подключения Storage Service к новым хранилищам одним из способов:
-
Явная передача логина и пароля. Для каждого из перечисленных в блоке
storagesхранилищ задайте значения для параметров:ddboost.storages.usernameddboost.storages.password
-
Локальное хранилище секретов. Обновите в хранилище файл учетных данных командой
storage-service init ddboost-credsс флагом--force(ознакомьтесь со справкой по команде ниже):Справка по команде
storage-service init ddboost-credsОписание:
Выполнение инициализации локального хранилища секретов c учетными данными для подключения к хранилищам DDBoost. Выполнение команды возможно только после запуска
storage-service init keys, так как над файлом, который создается командойstorage-service init ddboost-creds, выполняется защитное преобразование с использованием ранее сгенерированного приватного ключа.В результате будет создан файл с учетными данными по пути, указанному в параметре
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yaml(пример значения):ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.credsВажно- Перед выполнением команды убедитесь, что параметр
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yamlзаполнен. - Если выполняется Добавление хранилищ DDBoost без остановки Storage Service (S2) и для имеющихся хранилищ DDBoost уже используется локальное хранилище секретов, то перед выполнением
storage-service init ddboost-credsне требуется предварительно запускатьstorage-service init keys.
Синтаксис:
storage-service init ddboost-creds [flags]Обязательные параметры:
Нет. В команде должны быть переданы учетные данные одним из способов:
-
Передача через стандартный ввод. Пример:
echo '{"creds": [{"address": "ip_adress_1", "username": "user_example_1", "password": "password_example_1"}, {"address": "ip_adress_2", "username": "user_example_2", "password": "password_example_2"}]}' | storage-service init ddboost-creds -
Передача через файл с помощью флага
--file:storage-service init ddboost-creds --file ddboost.creds.jsonФайл должен быть в формате JSON и обязательно содержать поля
address,usernameиpassword:{
"creds": [
{
"address": "<ip_address_1>",
"username": "<user_example_1>",
"password": "<password_example_1>"
},
{
"address": "<ip_address_2>",
"username": "<user_example_2>",
"password": "<password_example_2>"
}
// ...
]
}Важно- Значение поля
addressдля каждого хранилища должно совпадать со значением параметраddboost.storages.addressиз файлаstorage-service.yamlдля соответствующего хранилища. - При добавлении учетных данных для новых хранилищ передайте полный список учетных данных: как для уже зарегистрированных, так и для новых хранилищ. Это правило действует как при использовании флага
--file, так и при передаче данных через стандартный ввод.
- Значение поля
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceПринудительная замена существующего файла с учетными данными --file <path to file>Загрузка секретов из json-файла - Перед выполнением команды убедитесь, что параметр
-
-
Отправьте сигнал
SIGHUPработающему процессу Storage Service:sudo kill -SIGHUP $(pidof storage-service)Утилита
pidofвозвращает идентификатор процесса (PID) указанного сервиса. В данном случае команда находит PID процесса Storage Service и передает ему сигналSIGHUPдля повторного чтения конфигурации.к сведениюСигнал
SIGHUPможно отправить в любой момент работы Storage Service, в том числе во время выполнения резервного копирования на уже подключенные хранилища DDBoost. -
Убедитесь, что конфигурация успешно перечитана, просмотрев журнал Storage Service:
:caption: Пример команды
sudo tail -f /var/log/pbr/storage-service.logВ начале перечитывания конфигурации появится сообщение:
reloading config...После успешного завершения проверки доступности новых хранилищ и их регистрации в логах будет выведено сообщение:
reload config success.Внимание!- Если проверка подключения для какого-либо из новых серверов не пройдена или при добавлении этого сервера возникла другая ошибка, сервер будет проигнорирован и Storage Service продолжит добавлять оставшиеся серверы.
- Использовать новые хранилища DDBoost можно только после появления в журнале сообщения
reload config success.
Прямое подключение компонента Copywala VDB к DDBoost
Важно
Перед началом настройки убедитесь, что клиентская библиотека DDBoost libDDBoost.so установлена на хосте компонента copywala-vdb.
Также рекомендуется добавить директорию с libDDBoost.so в переменную окружения LD_LIBRARY_PATH.
Для настройки выполните шаги:
Шаг 1.Настройка параметров в copywala-vdb.yaml
-
В конфигурационном файле
copywala-vdb.yamlдобавьте секциюddboostс параметрами подключения к DDBoost.Параметры секции
ddboost# --------------------------------------
# Настройка подключения к целевой БД
# --------------------------------------
vdb:
http_address: "<https://host:port>"
auth_enabled: <true/false>
# Использование учетных данных в открытом виде
username: "<username>"
password: "<password>"
# Использование учетных данных, сохраненных в защищенном виде
use_enc_creds: <true/false>
enc_creds_path: "</var/pbr/copywala/vdb.creds>"
# Формирование резервной копии в режиме полного снимка (единый снепшот-файл, содержащий все коллекции базы данных)
full_snapshot: <true/false>
# Копирование снепшот-файлов напрямую из локальной файловой системы
copy_local_snapshots: <true/false>
local_snapshots_path: "</vdb/snapshots>"
# по умолчанию применяется глобальный tls
tls:
rootca:
local_path: "<tls/root.crt>" # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: "<tls/cert.crt>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: "<tls/cert.key>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Назначение резервной копии
# --------------------------------------
# local-fs:///home/postgres/backups/
# ddboost://srv-10-15.host/storage-unit
# s3://srv-10-20.host/bucket-08-9992
# s2://srv-10-25.host:port
backup_destination_uri: "<local-fs:///vdb/backups/>"
# --------------------------------------
# Директория для восстановления данных
# --------------------------------------
restore_data_path: "</vdb/data/>"
# --------------------------------------
# Наименование экземпляра БД для восстановления (уникальное имя экземпляра агента)
# --------------------------------------
restore_instance_name: ""
# --------------------------------------
# Настройка повторных попыток при возникновении ошибок при записи РК (ниже приведены значения по умолчанию)
# --------------------------------------
retrier:
timeout: 10s # максимальное время выполнения запроса
retries: 5 # максимальное количество попыток
delay_period: 1s # период задержки
# --------------------------------------
# Возможность загрузки TLS-сертификатов из защищенного хранилища секретов
# --------------------------------------
vault: # настройки подключения
server: "<vault-url>"
namespace: "<namespace>"
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: "<v2>" # версия формата хранилища ключей-значений
approle:
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Параметры подключения к KMS HashiCorp Vault
# --------------------------------------
kms:
server: "<vault-url>" # URL сервера KMS
namespace: "<namespace>" # пространство имен в KMS HashiCorp Vault
path: "<mount-path>" # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата KV-хранилища
approle: # вариант авторизации в KMS по роли и ключа роли
role_id: "<role-id>" # уникальный идентификатор роли
secret_id: "<secret-id>" # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
# auth_method: approle # метод аутентификации
# wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
# wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
userpass: # вариант авторизации в KMS по логину и паролю
# username:
# password:
# auth_method:
# --------------------------------------
# Конфигурация S2
# --------------------------------------
s2:
checksum_algorithm: DISABLED # выбор алгоритма вычисления контрольной суммы. Допустимые значения: DISABLED (по умолчанию), CRC32
storage_path: "" # значение по умолчанию пустое. Задается пользователем для возможности выбора одного из дополнительных хранилищ, пример: /var/pbr/s2/backups
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
s2tp_enabled: true # флаг использования протокола S2TP для взаимодействия copywala и storage service (s2). По умолчанию – true. Используется только в рамках операций передачи данных при создании и восстановлении резервных копий. gRPC остается как основной протокол для взаимодействия с S2, кроме переноса данных
s2tp:
addresses: # массив адресов серверов s2
- "<host_1:port_1>"
- "<host_2:port_2>"
enable_tls: true # флаг использования TLS-протокола
max_connections: 16 # максимальное количество открытых соединений к серверу на один указанный адрес (в массиве addresses)
read_timeout: 5m # таймаут для операции чтения
write_timeout: 5m # таймаут для операции записи
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация S3
# --------------------------------------
s3:
region: "<ru-test>" # регион s3
access_id: "<id>" # идентификатор пользователя
secret_key: "<key>" # секретный ключ
use_path_style: <true/false> # если параметр имеет значение true, задействуется формат полного URL с указанием пути (path-style addressing); если false – название бакета включается непосредственно в доменное имя.
disable_request_checksums: <true/false> # проверка контрольных сумм запросов
tls: # опционально
rootca:
local_path: "<tls/root.crt>" # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: "<tls/cert.crt>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: "<tls/cert.key>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к зашифрованным учетным данным для подключения к хранилищу DDBoost (заполняется опционально). При заданном значении параметры username и password в секции storage игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для copywala значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # автоматически создавать отдельное хранилище (storage_unit) в системе Data Domain для резервных копий, если оно еще не создано
storage:
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в copywala.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Настройки архивирования РК (ниже приведены значения по умолчанию)
# --------------------------------------
archive_settings:
upload_params:
part_payload_size: 32MB # размер парта передаваемых данных
checksum_algorithm: CRC32 # выбор алгоритма вычисления контрольной суммы. CRC32 – значение по умолчанию. Допустимые значения: DISABLED, CRC32, SHA256
compression_algorithm: S2 # выбор алгоритма сжатия данных при создании РК. S2 – значение по умолчанию. Допустимые значения: DISABLED, ZSTD, S2
# --------------------------------------
# Политика исполнения резервного копирования (ниже приведены значения по умолчанию)
# --------------------------------------
backup_policy:
write_parts_workers_no: 4 # количество параллельных рабочих процессов (workers), выполняющих операцию записи отдельных партов
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при создании резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Политика восстановления (ниже приведены значения по умолчанию)
# --------------------------------------
restore_policy:
workers_no: runtime.NumCPU()
jobs_queue_size: 16 # размер очереди задач на распаковку партов архива
verify_archive_checksums: true # проверка контрольных сумм всего архива
read_direct_io: false # режим чтения данных из файлов, исключая использование кеша ОС
protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при восстановлении из резервной копии
local_path: "<local-path>"
# vault_path: <path>
# vault_key: <key>
# --------------------------------------
# Конфигурация TLS используемая по умолчанию для всех сетевых соединений
# --------------------------------------
tls:
rootca:
local_path: "<tls/root.crt>" # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: "<tls/cert.crt>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: "<tls/cert.key>"
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Опциональные настройки приложения (ниже приведены значения по умолчанию)
# --------------------------------------
app:
agent_id_file_path: /etc/pbr/pbr.agent.id # путь к файлу, содержащему идентификатор агентcкого приложения
agent_id_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
copywala_dir: /etc/pbr/copywala # рабочая директория
copywala_dir_mode: 0700 # числовое представление прав доступа на создаваемые каталоги
allow_concurrent_create_backup: false # управляет возможностью запуска нескольких операций создания резервных копий одновременно
creds_private_key_path: /var/pbr/copywala/priv.key #Путь к приватному ключу приложения
copywala_plugins_dir: /usr/lib/pbr/copywala # путь к директории, где находится плагин защитного преобразования
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
go_mem_limit: 2GB # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# если параметр не указан в copywala.yaml, лимит памяти будет автоматически установлен в размере 1/4 от общего объема RAM, доступного в системе (например, при 32 ГБ оперативной памяти лимит составит 8 ГБ)
# если задано значение 0 – будут использоваться настройки Go по умолчанию
# при указании значения – будет установлен заданный лимит
go_gc_percent: 100 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
# --------------------------------------
# Настройка ведения журналов приложения (ниже приведены значения по умолчанию)
# --------------------------------------
log:
path: /var/log/pbr/copywala.log # путь к лог-файлу
dir_mode: 0700 # настройка прав доступа на создаваемые каталоги. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
file_mode: 0600 # настройка прав доступа на создаваемые файлы. Значения необходимо задавать в восьмеричной системе счисления с ведущим нулем.
max_size: 100 # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # максимальный срок хранения лог-файла в днях
max_backups: 10 # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: true # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия -
Заполните обязательные параметры:
Параметр Расположение Описание client_settings.ddboost_lib_pathФайл copywala-vdb.yaml, блокddboostПуть к динамической библиотеке DDBoost, по умолчанию — libDDBoost.so. Если не задана переменнаяLD_LIBRARY_PATHили в ней отсутствует нужный путь, укажите здесь полный путь к файлуbackup_destination_uriФайл copywala-vdb.yamlПуть к хранилищу DDBoost для резервных копий (например, ddboost://srv-10-15.host/storage-unit)Также обязательными в блоке
ddboostявляются параметры учетных данных для подключения к хранилищу DDBoost. Настройка учетных данных описана в отдельном шаге 2.
Шаг 2. Настройка учетных данных
Учетные данные для подключения к хранилищу DDBoost также задаются в конфигурационном файле copywala-vdb.yaml в секции ddboost.
Настройте учетные данные одним из способов:
-
Явная передача логина и пароля: задайте значения для параметров
ddboost.storage.usernameиddboost.storage.password. -
Использование локального хранилища секретов. Для этого:
-
Задайте значение для параметра
ddboost.enc_creds_path– путь, по которому будет создан зашифрованный файл с учетными данными. -
Запустите генерацию криптографических ключей командой
copywala-vdb init keys.Справка по команде
copywala-vdb init keysОписание:
Запускает генерацию пары криптографических ключей (приватного и публичного), необходимых для защитного преобразования учетных данных.
В результате выполнения будет сгенерирована пара ключей:
- приватный –
/var/pbr/copywala/priv.key; - публичный –
/var/pbr/copywala/priv.key.pub.
Ключи защитного преобразования хранятся локально в зашифрованном виде и используются только внутренними механизмами copywala-vdb.
Путь к приватному ключу настраивается в конфигурационном файле
copywala-vdb.yamlпараметром:app:
creds_private_key_path: /var/pbr/copywala/priv.key # значение по умолчаниюПубличный ключ с постфиксом
.pubбудет сохранен в той же директории, что и приватный.Синтаксис:
copywala-vdb init keys [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to copywala-vdb config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala-vdb.yaml--forceПринудительная замена существующего файла с ключом (повторная генерация), если он уже существует ВажноПри принудительной повторной генерации (
--force) необходимо повторно инициализировать локальное хранилищеcopywala-vdb init creds vdbтакже с флагом--force.В результате выполнения команды будет выведено:
$ copywala-vdb init keys
2026-04-02 14:29:30.049 [870020] INF run init keys key_path=/var/pbr/copywala/priv.key
2026-04-02 14:29:30.050 [870020] INF init keys completed - приватный –
-
Инициализируйте локальное хранилище секретов командой
copywala-vdb init creds ddboost, передав учетные данные одним из способов (подробнее – в справке по команде).Справка по команде
copywala-vdb init creds ddboostОписание:
Выполнение инициализации локального хранилища секретов c учетными данными для подключения к хранилищам DDBoost. Выполнение команды возможно только после запуска
copywala-vdb init keys, так как над файлом, который создается командойcopywala-vdb init creds ddboost, выполняется защитное преобразование с использованием ранее сгенерированного приватного ключа.В результате будет создан зашифрованный файл с учетными данными по пути, указанному в параметре
ddboost.enc_creds_pathконфигурационного файлаcopywala-vdb.yaml(пример значения):ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.credsВажноПеред выполнением команды убедитесь, что в
copywala-vdb.yamlзадано значение для параметраddboost.enc_creds_path.Синтаксис:
copywala-vdb init creds ddboost [flags]Обязательные параметры:
Нет.
В команде должны быть переданы учетные данные одним из способов:
-
Передача через стандартный ввод. Пример:
echo '{"username": "user_example", "password": "password_example"}' | copywala-vdb init creds ddboost -
Передача через файл с помощью флага
--file:copywala-vdb init creds ddboost --file ddboost.creds.jsonФайл должен быть в формате JSON и обязательно содержать поля
usernameиpassword:{
"username": "<user_example>",
"password": "<password_example>"
}
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to copywala-vdb config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala-vdb.yaml--forceПринудительная замена существующего файла с учетными данными --file <path to file>Загрузка секретов из json-файла В результате выполнения команды будет выведено (ниже пример с передачей учетных данных через стандартный ввод):
$ echo '{"username": "user_example", "password": "password_example"}' | copywala-vdb init creds ddboost
2026-05-18 22:14:31.846 [84779] INF copywala 1.3.0 (aefa53e9) compiled at 2026-05-17_21:09:46
2026-05-18 22:14:31.846 [84779] INF run init ddboost creds creds_path=/var/pbr/copywala/ddboost.creds
2026-05-18 22:14:31.847 [84779] INF init ddboost creds completed -
-
Опциональный шаг. Выполните проверку возможности чтения из локального хранилища секретов командой
copywala-vdb init creds check.Справка по команде
copywala-vdb init creds checkОписание:
Запускает проверку возможности чтения из локального хранилища секретов. В результате выполнения команды отображается загруженное из хранилища имя пользователя.
Синтаксис:
copywala-vdb init creds check [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to copywala-vdb config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala-vdb.yaml--forceДанный флаг не применим к этой команде --file <path to file>Проверка секретов из json-файла В результате выполнения команды будет выведено (ниже пример с передачей учетных данных через стандартный ввод):
$ copywala-vdb init creds check
2026-04-02 14:47:41.559 [877652] INF check vdb creds creds_path=/var/pbr/copywala/vdb.creds
2026-04-02 14:47:41.559 [877652] INF vdb username: backup_user
2026-04-02 14:47:41.559 [877652] INF check vdb creds completed
-
Шаг 3. Настройка TLS (опциональный)
- Для взаимодействия с хранилищем DDBoost по протоколу TLS добавьте в секцию
ddboost.storageфайлаcopywala-vdb.yamlуказанные ниже параметры и задайте для них необходимые значения:
Параметр | Описание | Значение по умолчанию |
|---|---|---|
| Флаг включения взаимодействия по TLS. Установите значение |
|
| Режим TLS. Возможные значения:
Пример конфигурации:
Пример конфигурации:
Пример конфигурации: |
|
| Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения:
|
|
| В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения:
Флаги можно комбинировать, например, при значении |
|
к сведению
Более подробное описание параметров и их допустимых значений смотрите в официальной документации DDBoost.
- Также в
copywala-vdb.yamlзаполните секциюddboost.storage.tlsисходя из заданных на предыдущем шаге параметровuse_tlsиauth_mode.
Проверка результата
Выполните команду copywala-vdb cwl info, указав путь к несуществующему архиву. Если интеграция с DDBoost настроена корректно, команда вернет ошибку о том, что архив не существует. Если есть проблемы с интеграцией с DDBoost, будет отображено другое сообщение об ошибке.
Справка по команде copywala-vdb cwl info
Описание:
Выводит информацию о CWL-архиве.
Синтаксис:
copywala-vdb cwl info <path to cwl archive> [flags]
Обязательные параметры:
<path to cwl archive> – путь к CWL-архиву резервной копии о котором необходимо посмотреть информацию.
Опциональные параметры:
[flags] – доступны следующие флаги:
| Флаг | Описание |
|---|---|
-h|--help | Показать справку по команде |
-c|--config <path to copywala-vdb config> | Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/copywala-vdb.yaml |
Подключение компонента Copywala VDB к DDBoost через Storage Service (S2)
Важно
Перед началом настройки убедитесь, что клиентская библиотека DDBoost libDDBoost.so установлена на хосте компонента copywala-vdb.
Также рекомендуется добавить директорию с libDDBoost.so в переменную окружения LD_LIBRARY_PATH.
Шаг 1. Настройка параметров в copywala-vdb.yaml
В файле copywala-vdb.yaml задайте значения для параметра backup_destination_uri. Используйте следующий формат URI:
backup_destination_uri: s2://<s2-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unit?driver=ddboost&data_domain_host=<ddboost-host>
Описание параметров:
<s2-host>— хост S2;<ddboost-storage-unit>— имя хранилища DDBoost;/path/in/ddboost/storage/unit— путь внутри хранилища;driver=ddboost— включает использование драйвера DDBoost;data_domain_host=<ddboost-host>— адрес хранилища (Data Domain хоста).
Важно
Заполнять в copywala-vdb.yaml секцию ddboost не требуется, так как вся работа с DDBoost выполняется через слой S2, который самостоятельно обрабатывает взаимодействие с DDBoost.
Шаг 2. Настройка параметров в storage-service.yaml
-
В конфигурационном файле
storage-service.yamlдобавьте секциюddboostс параметрами подключения к DDBoost.Параметры секции
ddboost# --------------------------------------
# Настройки для взаимодействия с API Gateway
# --------------------------------------
api_gateway:
http_address: https://localhost:29000 # адрес для подключения Storage Service к сервисам инфраструктуры
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Параметры подключения к HarhiCorp/SecMan
# --------------------------------------
vault: # настройки подключения
server: <vault-url>
namespace: <namespace>
path: <mount-path> # путь к точке монтирования хранилища секретов
kv_version: v2 # версия формата хранилища ключей-значений
approle:
role_id: <role-id> # уникальный идентификатор роли
secret_id: <secret-id> # секретный ключ роли. Либо указывается явно, либо прописывается wrapping_secret_id_file_path
auth_method: approle # метод аутентификации
wrapping_secret_id_file_path: /var/pbr/cw.wrapped.secret.vlt # путь к файлу для хранения wrapping token
wrapping_secret_id_ttl: 8h # время жизни wrapping token (например, 10m - 10 минут, 6h - 6 часов)
# --------------------------------------
# Опциональные настройки приложения
# --------------------------------------
app:
work_dir: /var/pbr/storage-service # рабочий каталог приложения для хранения временных файлов, журналов и т.д.
work_dir_mode: 0700 # права доступа к рабочему каталогу. 0700 означает, что полный доступ к этому каталогу имеет только владелец файла.
creds_private_key_path: /var/pbr/copywala/priv.key # путь к приватному ключу приложения
go_mem_limit: 0 # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
go_gc_percent: 0 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
go_mem_limit: 0 # мягкий лимит heap-памяти для сборщика мусора Go. При достижении лимита сборщик мусора начинает работать с большей частотой, чтобы удерживать потребление памяти в заданных пределах (в документации go – GOMEMLIMIT)
# при указании значения будет установлен соответствующий лимит памяти. По умолчанию используется значение 0, при котором применяются стандартные настройки Go
go_gc_percent: 0 # процент роста heap-памяти перед запуском сборки мусора. Значение 100 означает, что сборка мусора запускается после увеличения объёма heap в 2 раза относительно объема после предыдущей сборки (в документации go – GOGC)
# более подробное описание параметров приведено в документации go https://go.dev/doc/gc-guide (см. GOMEMLIMIT и GOGC)
zero_copy: true # флаг для использования методов zero-copy (нулевого копирования) записи данных
# --------------------------------------
# Пример политики слияния (значения по умолчанию)
# --------------------------------------
merge_policy:
write_parts_workers_no: max(runtime.NumCPU()/2, 1) # определяет количество рабочих потоков, используемых для одновременной записи частей файла.
read_parts_workers_no: max(runtime.NumCPU()/2, 1) # определяет количество потоков для параллельной обработки чтения частей файла.
write_direct_io: false # если false, приложение будет использовать буферизованный ввод-вывод операционной системы при записи данных.
read_direct_io: false # если false, приложение будет использовать буферизованный ввод-вывод операционной системы при чтении данных.
# --------------------------------------
# Конфигурация DDBoost (Data Domain Boost)
# --------------------------------------
ddboost:
enc_creds_path: "<path-to-enc-creds-file>" # путь к зашифрованным учетным данным для подключения для подключения к хранилищам DDBoost (заполняется опционально). При заданном значении enc_creds_path параметры username и password в секции storages игнорируются
client_settings:
ddboost_lib_path: libDDBoost.so # путь к динамической библиотеке DDBoost (по умолчанию — libDDBoost.so). Если не задана переменная LD_LIBRARY_PATH или в ней отсутствует нужный путь, укажите здесь полный путь к файлу
read_client_side_decompress: false # флаг включения распаковки на стороне клиента. При значении false распаковка выполняется на стороне сервера. При значении true – на стороне клиента, что позволяет снизить нагрузку на сеть
client_type: 0 # тип клиента, который подключается к DDBoost. Для storage-service значение менять не требуется
buffer_size: 0 # размер буфера ввода-вывода. 0 означает использование размер буфера по умолчанию
auto_create_storage_unit: true # при запуске сервиса автоматически проверять наличие отдельных хранилищ в системе Data Domain, указанных в storage-service.yaml в параметрах storage_path и allowed_storage_paths. Если хранилища отсутствуют, они будут созданы автоматически
storages: # секция со списком хранилищ (Data Domain) с их параметрами подключения
- address: "<ip_address>" # IP-адрес хранилища
username: "<username>" # имя пользователя для подключения к хранилищу DDBoost. Игнорируется если в storage-service.yaml задан параметр enc_creds_path
password: "<password>" # пароль для подключения к хранилищу DDBoost. Игнорируется если в storage-service.yaml задан параметр enc_creds_path
max_conns_no: 16 # максимальное количество одновременных соединений с DDBoost; соединения переиспользуются из пула, если они не простаивали дольше max_idle_time, иначе при необходимости создается новое соединение, если не превышен лимит max_conns_no
max_idle_time: 5m # допустимое время простоя соединения, после которого неактивное подключение закрывается и удаляется из пула соединений
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
- ... # список хранилищ
# Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
use_tls: false # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storage.tls или секции глобального TLS («Конфигурация TLS используемая по умолчанию для всех сетевых соединений»)
auth_mode: 0 # режим TLS: 1 - односторонний, 2 - двусторонний, 3 - анонимный
encr_strength: 0 # уровень TLS-шифрования: 1 - слабый, 2 - сильный
cert_verify_flag: 0 # битовая комбинация флагов проверки TLS-сертификатов и FQDN клиента/сервера: 0 – отключить проверку сертификатов, 1 – проверять FQDN сервера, 2 – проверять FQDN клиента. Например, при значении 3 будет проверяться FQDN и сервера и клиента
# --------------------------------------
# Параметры gRPC-сервера Storage Service
# --------------------------------------
grpc:
address: 0.0.0.0:29509
mtls: false # необходимость проверки сертификатов клиента
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Параметры s2tp-сервера Storage Service
# --------------------------------------
s2tp:
addresses: # массив для указания используемых адресов сетевых интерфейсов для работы серверов. Если массив не задан, используется значение параметра backup_destination_uri из файла copywala.yaml, к которому автоматически добавляются порты по умолчанию: 29500 и 29501
- 0.0.0.0:29500
- 0.0.0.0:29501
# ...
mtls: false # необходимость проверки сертификатов клиента
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
max_connections: 256 # максимальное количество подключений для одного адреса, указанного выше
read_timeout: 5m # тайм-аут для операции чтения
write_timeout: 5m # тайм-аут для операции записи
# --------------------------------------
# Путь к основному хранилищу
# --------------------------------------
storage_path: /var/pbr/backups # если в файле copywala.yaml не настроен параметр storage_path, то резервные копии должны сохраняться по пути, указанному в данной конфигурации (storage_path - значение по умолчанию)
# ddboost://1.2.3.4/storage-unit/sub/dir
# --------------------------------------
# Список дополнительных хранилищ, разрешенных для установки со стороны клиента
# --------------------------------------
allowed_storage_paths:
- /mnt/nfs-001
- /mnt/nfs-002
- /mnt/nfs-003
# Примеры значений allowed_storage_paths:
# - /mnt/nfs/backups
# - /mnt/ci/backups
# - local-fs:///mnt/ff/backups
# - ddboost://1.2.3.4/storage-unit/sub/dir
is_allowed_storage_paths_only: true # включает проверку хранилища, полученного от copywala (задается в copywala.yaml параметром storage_path) на наличие списке разрешенных хранилищ (определяется параметром allowed_storage_paths):
# true — запись выполняется только если storage_path входит в список разрешенных хранилищ
# false — запись выполняется без проверки storage_path
# --------------------------------------
# Максимальное количество одновременных потоков на одного клиента
# --------------------------------------
max_concurrent_streams: 256
# --------------------------------------
# Конфигурация TLS
# --------------------------------------
tls:
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Конфигурация Prometheus (подробное описание атрибутов по умолчанию и обязательных атрибутов каждого поля см. в документации)
# --------------------------------------
prometheus:
push_model:
jobname:
address:
process_collector_opts:
report_errors:
pid:
namespace:
frequency:
req_timeout:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
pull_model:
endpoint: /metrics
address:
process_collector_opts:
report_errors:
pid:
namespace:
handler_opts:
timeout:
max_requests_in_flight:
disable_compression:
log_errors:
tls: # опционально
rootca:
local_path: tls/root.crt # путь к локальному файлу
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
cert:
local_path: tls/cert.crt
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
key:
local_path: tls/cert.key
# vault_path: <path> # путь к секрету в HarhiCorp/SecMan
# vault_key: <key> # ключ внутри json-секрета
# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
log:
path: /var/log/pbr/storage-service.log # обязательно к заполнению
max_size: 100 # мегабайты # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # дни # максимальный возраст лог-файла в днях
max_backups: 10 # шт # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: false # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатияВажноDDBoost имеет ограничение на количество соединений: один процесс может использовать одновременно не более 64 соединений.
При настройке нескольких хранилищ необходимо учитывать суммарное значение параметра
ddboost.storages.max_conns_no(файлstorage-service.yaml) для всех подключений. Контроль и валидация этого ограничения на уровне приложения не выполняются.Также необходимо учитывать взаимосвязь параметров:
- значение параметра
restore_policy.workers_noв файлеcopywala-vdb.yamlдолжно быть меньше или равно значению параметраs2.ddboost.max_conns_noв файлеstorage-service.yaml.
При работе с пулом соединений важно учитывать следующие особенности:
- соединения переиспользуются и являются общими для всех команд и операций;
- пул используется не только для многопоточного восстановления данных, но и для любых других запросов, например
copywala cwl info; - при одновременном выполнении нескольких операций с одним хранилищем значение
max_conns_noраспределяется между всеми активными задачами.
- значение параметра
-
В секции
ddboostзаполните обязательные параметры:-
ddboost_lib_path– путь к динамической библиотеке DDBoost, по умолчанию —libDDBoost.so. Если не задана переменнаяLD_LIBRARY_PATHили в ней отсутствует нужный путь, укажите здесь полный путь к файлу. -
в
ddboost.storages:- В массиве
- addressзадайте значение IP-адреса хранилища. - Если будет использоваться несколько хранилищ – добавьте соответствующее количество массивов
- addressи заполните IP-адреса хранилищ.
- В массиве
-
параметры учетных данных для подключения к хранилищу DDBoost. Настройка учетных данных описана в отдельном шаге 3.
-
-
Также в файле
storage-service.yamlзадайте значения для параметров:-
storage_path– путь к хранилищу DDBoost для резервных копий (например,ddboost://1.2.3.4/storage-unit/sub/dir). -
allowed_storage_paths– список URI разрешенных хранилищ. Важно: URI-ресурсы для DDBoost в данном списке должны согласовываться со значением, указанным в параметреbackup_destination_uriфайлаcopywala-vdb.yaml.Например, если в
copywala-vdb.yaml:backup_destination_uri: s2://<s2-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unit?driver=ddboost&data_domain_host=<ddboost-host>то в
storage-service.yamlзначение параметраallowed_storage_pathsдолжно быть следующим:allowed_storage_paths: ddboost://<ddboost-host>/<ddboost-storage-unit>/path/in/ddboost/storage/unitВажно, чтобы в параметрах
backup_destination_uriиallowed_storage_pathsбыли идентичными значения для:- Хостов (в примере выше –
<ddboost-host>); - Путей (в примере выше –
<ddboost-storage-unit>/path/in/ddboost/storage/unit).
- Хостов (в примере выше –
ВажноВ
storage_pathиallowed_storage_pathsможно указывать только те URI, хост которых есть либо вenc_creds_path(подробнее проenc_creds_pathв шаге 3), либо в секцииddboost.storages. -
Шаг 3. Настройка учетных данных
Учетные данные для подключения к хранилищу DDBoost также задаются в конфигурационном файле storage-service.yaml в секции ddboost.
Настройте учетные данные одним из способов:
-
Явная передача логина и пароля: для каждого из перечисленных в блоке
storagesхранилищ задайте значения для параметров:ddboost.storages.usernameddboost.storages.password
-
Использование локального хранилища секретов. Для этого:
-
Задайте значение для параметра
ddboost.enc_creds_path– путь, по которому будет создан файл с учетными данными, прошедшими защитное преобразование. -
Запустите генерацию криптографических ключей командой
storage-service init keys.Справка по команде
storage-service init keysОписание:
Запускает генерацию пары криптографических ключей (приватного и публичного), необходимых для защитного преобразования учетных данных.
В результате выполнения будет сгенерирована пара ключей:
- приватный –
/var/pbr/storage-service/priv.key; - публичный –
/var/pbr/storage-service/priv.key.pub.
Ключи, необходимые для защитного преобразования, хранятся локально в зашифрованном виде и используются только внутренними механизмами storage-service.
Путь к приватному ключу настраивается в конфигурационном файле
storage-service.yamlпараметром:app:
creds_private_key_path: /var/pbr/storage-service/priv.key # значение по умолчаниюПубличный ключ с постфиксом
.pubбудет сохранен в той же директории, что и приватный.Синтаксис:
storage-service init keys [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceПринудительная замена существующего файла с ключом (повторная генерация), если он уже существует ВажноПри принудительной повторной генерации (
--force) необходимо повторно инициализировать локальное хранилищеstorage-service init ddboost-credsтакже с флагом--force. - приватный –
-
Инициализируйте локальное хранилище секретов командой
storage-service init ddboost-creds, передав учетные данные одним из способов (подробнее – в справке по команде).Справка по команде
storage-service init ddboost-credsОписание:
Выполнение инициализации локального хранилища секретов c учетными данными для подключения к хранилищам DDBoost. Выполнение команды возможно только после запуска
storage-service init keys, так как над файлом, который создается командойstorage-service init ddboost-creds, выполняется защитное преобразование с использованием ранее сгенерированного приватного ключа.В результате будет создан файл с учетными данными по пути, указанному в параметре
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yaml(пример значения):ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.credsВажно- Перед выполнением команды убедитесь, что параметр
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yamlзаполнен. - Если выполняется Добавление хранилищ DDBoost без остановки Storage Service (S2) и для имеющихся хранилищ DDBoost уже используется локальное хранилище секретов, то перед выполнением
storage-service init ddboost-credsне требуется предварительно запускатьstorage-service init keys.
Синтаксис:
storage-service init ddboost-creds [flags]Обязательные параметры:
Нет. В команде должны быть переданы учетные данные одним из способов:
-
Передача через стандартный ввод. Пример:
echo '{"creds": [{"address": "ip_adress_1", "username": "user_example_1", "password": "password_example_1"}, {"address": "ip_adress_2", "username": "user_example_2", "password": "password_example_2"}]}' | storage-service init ddboost-creds -
Передача через файл с помощью флага
--file:storage-service init ddboost-creds --file ddboost.creds.jsonФайл должен быть в формате JSON и обязательно содержать поля
address,usernameиpassword:{
"creds": [
{
"address": "<ip_address_1>",
"username": "<user_example_1>",
"password": "<password_example_1>"
},
{
"address": "<ip_address_2>",
"username": "<user_example_2>",
"password": "<password_example_2>"
}
// ...
]
}Важно- Значение поля
addressдля каждого хранилища должно совпадать со значением параметраddboost.storages.addressиз файлаstorage-service.yamlдля соответствующего хранилища. - При добавлении учетных данных для новых хранилищ передайте полный список учетных данных: как для уже зарегистрированных, так и для новых хранилищ. Это правило действует как при использовании флага
--file, так и при передаче данных через стандартный ввод.
- Значение поля
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceПринудительная замена существующего файла с учетными данными --file <path to file>Загрузка секретов из json-файла - Перед выполнением команды убедитесь, что параметр
-
Опциональный шаг. Выполните проверку возможности чтения из локального хранилища секретов командой
storage-service init ddboost-creds check.Справка по команде
storage-service init ddboost-creds checkОписание:
Запускает проверку возможности чтения из локального хранилища секретов. В результате выполнения команды отображается загруженное из хранилища имя пользователя.
Синтаксис:
storage-service init ddboost-creds check [flags]Обязательные параметры:
Нет.
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceДанный флаг не применим к этой команде --file <path to file>Проверка секретов из json-файла
-
Шаг 4. Настройка TLS (опциональный)
- Для взаимодействия с хранилищем DDBoost по протоколу TLS добавьте в секцию
ddboost.storageфайлаstorage-service.yamlуказанные ниже параметры и задайте для них необходимые значения:
Параметр | Описание | Значение по умолчанию |
|---|---|---|
| Флаг включения взаимодействия по TLS. Установите значение |
|
| Режим TLS. Возможные значения:
Пример конфигурации:
Пример конфигурации:
Пример конфигурации: |
|
| Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения:
|
|
| В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения:
Флаги можно комбинировать, например, при значении |
|
к сведению
Более подробное описание параметров и их допустимых значений смотрите в официальной документации DDBoost.
- Также в
storage-service.yamlзаполните секциюddboost.storages.tlsисходя из заданных на предыдущем шаге параметровuse_tlsиauth_mode.
Проверка результата
Интеграция с хранилищем DDBoost считается успешной, если при запуске Storage Service не возникло соответствующей ошибки.
Добавление хранилищ DDBoost без остановки Storage Service (S2)
Для подключения новых хранилищ DDBoost не требуется останавливать или перезапускать Storage Service. Для этого добавьте параметры новых хранилищ в конфигурационный файл storage-service.yaml и инициируйте перечитывание конфигурации без перезапуска сервиса.
Такой подход позволяет динамически расширять список доступных хранилищ. Резервное копирование и другие операции не прерываются, время простоя системы снижается.
Storage Service поддерживает обработку сигнала SIGHUP для применения изменений. Сигнал инициирует повторное чтение конфигурационного файла и подключение новых хранилищ DDBoost.
Важно
Механизм динамического обновления поддерживает только добавление новых хранилищ DDBoost. Изменять или удалять параметры (например, адрес, учетные данные или другие настройки подключения) для уже зарегистрированных хранилищ DDBoost нельзя. Для этого требуется перезапуск Storage Service с обновленной конфигурацией.
Последовательность действий
-
В конфигурационном файле
storage-service.yamlдобавьте новые хранилища в массивddboost.storages::caption: Пример
ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.creds
storages:
- address: "192.0.2.0" # IP-адрес имеющегося ранее хранилища
username: "<username_for_first_storage>"
password: "<password_for_first_storage>"
max_conns_no: 16
max_idle_time: 5m
- address: "192.0.2.1" # IP-адрес нового хранилища 1, которое необходимо добавить
username: "<username_for_second_storage>"
password: "<password_for_second_storage>"
max_conns_no: 16
max_idle_time: 5m
- address: "192.0.2.2" # IP-адрес нового хранилища 2, которое необходимо добавить
username: "<username_for_second_storage>"
password: "<password_for_second_storage>"
max_conns_no: 16
max_idle_time: 5mпримечаниеНа данном шаге в массиве
ddboost.storagesзаполните только параметрыaddress. Описание настройки параметров учетных данных (usernameиpassword), будет описано далее в шаге 3. -
При необходимости добавьте пути к новым хранилищам в секцию
allowed_storage_paths::caption: Пример
allowed_storage_paths:
- ddboost://192.0.2.0/storage-unit-001 # имеющийся ранее путь
- ddboost://192.0.2.1/storage-unit-002 # новый путь
- ddboost://192.0.2.2/storage-unit-003 # новый путь -
Настройте учетные данные для подключения Storage Service к новым хранилищам одним из способов:
-
Явная передача логина и пароля. Для каждого из перечисленных в блоке
storagesхранилищ задайте значения для параметров:ddboost.storages.usernameddboost.storages.password
-
Локальное хранилище секретов. Обновите в хранилище файл учетных данных командой
storage-service init ddboost-credsс флагом--force(ознакомьтесь со справкой по команде ниже):Справка по команде
storage-service init ddboost-credsОписание:
Выполнение инициализации локального хранилища секретов c учетными данными для подключения к хранилищам DDBoost. Выполнение команды возможно только после запуска
storage-service init keys, так как над файлом, который создается командойstorage-service init ddboost-creds, выполняется защитное преобразование с использованием ранее сгенерированного приватного ключа.В результате будет создан файл с учетными данными по пути, указанному в параметре
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yaml(пример значения):ddboost:
enc_creds_path: /var/pbr/copywala/ddboost.credsВажно- Перед выполнением команды убедитесь, что параметр
ddboost.enc_creds_pathконфигурационного файлаstorage-service.yamlзаполнен. - Если выполняется Добавление хранилищ DDBoost без остановки Storage Service (S2) и для имеющихся хранилищ DDBoost уже используется локальное хранилище секретов, то перед выполнением
storage-service init ddboost-credsне требуется предварительно запускатьstorage-service init keys.
Синтаксис:
storage-service init ddboost-creds [flags]Обязательные параметры:
Нет. В команде должны быть переданы учетные данные одним из способов:
-
Передача через стандартный ввод. Пример:
echo '{"creds": [{"address": "ip_adress_1", "username": "user_example_1", "password": "password_example_1"}, {"address": "ip_adress_2", "username": "user_example_2", "password": "password_example_2"}]}' | storage-service init ddboost-creds -
Передача через файл с помощью флага
--file:storage-service init ddboost-creds --file ddboost.creds.jsonФайл должен быть в формате JSON и обязательно содержать поля
address,usernameиpassword:{
"creds": [
{
"address": "<ip_address_1>",
"username": "<user_example_1>",
"password": "<password_example_1>"
},
{
"address": "<ip_address_2>",
"username": "<user_example_2>",
"password": "<password_example_2>"
}
// ...
]
}Важно- Значение поля
addressдля каждого хранилища должно совпадать со значением параметраddboost.storages.addressиз файлаstorage-service.yamlдля соответствующего хранилища. - При добавлении учетных данных для новых хранилищ передайте полный список учетных данных: как для уже зарегистрированных, так и для новых хранилищ. Это правило действует как при использовании флага
--file, так и при передаче данных через стандартный ввод.
- Значение поля
Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде -c|--config <path to storage-service config>Использовать конфигурационный файл, отличный от файла по умолчанию: /etc/pbr/storage-service.yaml--forceПринудительная замена существующего файла с учетными данными --file <path to file>Загрузка секретов из json-файла - Перед выполнением команды убедитесь, что параметр
-
-
Отправьте сигнал
SIGHUPработающему процессу Storage Service:sudo kill -SIGHUP $(pidof storage-service)Утилита
pidofвозвращает идентификатор процесса (PID) указанного сервиса. В данном случае команда находит PID процесса Storage Service и передает ему сигналSIGHUPдля повторного чтения конфигурации.к сведениюСигнал
SIGHUPможно отправить в любой момент работы Storage Service, в том числе во время выполнения резервного копирования на уже подключенные хранилища DDBoost. -
Убедитесь, что конфигурация успешно перечитана, просмотрев журнал Storage Service:
:caption: Пример команды
sudo tail -f /var/log/pbr/storage-service.logВ начале перечитывания конфигурации появится сообщение:
reloading config...После успешного завершения проверки доступности новых хранилищ и их регистрации в логах будет выведено сообщение:
reload config success.Внимание!- Если проверка подключения для какого-либо из новых серверов не пройдена или при добавлении этого сервера возникла другая ошибка, сервер будет проигнорирован и Storage Service продолжит добавлять оставшиеся серверы.
- Использовать новые хранилища DDBoost можно только после появления в журнале сообщения
reload config success.
AI-агент (LLM-провайдер)
к сведению
Интеграция с AI-агентом необходима для работы AI-Advisor — подсистемы CLI-утилиты Recovery Manager, которая предоставляет рекомендации по настройке политики резервного копирования на основе анализа исторических телеметрических данных и целевых показателей RTO/RPO.
AI-Advisor использует большую языковую модель (LLM), доступ к которой осуществляется через AI-агент (LLM-провайдер), предоставляющий OpenAI-compatible API.
Последовательность действий
-
Обратитесь к администратору AI-агента для получения:
- API-ключа — уникальный токен для аутентификации.
- URL — базовый адрес сервиса (например,
https://api.ai.exmpl/openai/v1). - Идентификатора модели — название модели LLM (например,
GigaChat-2).
-
Откройте конфигурационный файл
recovery-manager.yamlдобавьте секциюaiи заполните параметры:# --------------------------------------
# Настройки для взаимодействия с API Gateway
# --------------------------------------
api_gateway:
address: http://api.pbr.host:29000 # Адрес API Gateway
trusted_ca: root.crt # Путь к доверенному сертификату для безопасного взаимодействия с API Gateway
# --------------------------------------
# Общие настройки приложения
# --------------------------------------
common:
timeout: 10s # Максимальное время выполнения запроса
# --------------------------------------
# Настройки для взаимодействия с OpenID
# --------------------------------------
open_id:
realm_url: https://keycloak.host/realms/realm-name
client_id: some-client-id # Идентификатор клиента из keycloak
client_secret: some-client-secret # Секрет из keycloak
trusted_ca: root.crt # Путь к доверенному сертификату для безопасного взаимодействия с OpenID
# --------------------------------------
# Настройки для взаимодействия с AI-агентом (LLM-провайдером)
# --------------------------------------
ai:
api_key: copywala@sbertech.ru|some-api-key # API-ключ для аутентификации в LLM-провайдере
base_url: https://api.ai.sbt/openai/v1 # Базовый URL LLM-провайдера (OpenAI-compatible endpoint)
model: GigaChat-2 # Идентификатор LLM
# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
log:
path: /var/log/pbr/recovery-manager.log # путь к лог-файлу
max_size: 100 # максимальный размер лог-файла в мегабайтах. По умолчанию `100 МБ`
max_age: 90 # максимальный возраст лог-файла в днях
max_backups: 10 # максимальное количество резервных копий лог-файлов, которые будут храниться. Если выбрано 0, то количество файлов не ограничено
use_local_time: true # параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации. Если выбрано true, используется локальное системное время, при false (и по умолчанию) – `UTС`.
compress_backups: false # параметр определяет необходимость сжатия файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия
Проверка результата
-
Выполните команду получения рекомендации
recovery-manager advisor recommend(ознакомьтесь со справкой по команде ниже).Справка по команде
recovery-manager advisor recommendОписание:
Запрос рекомендации по настройке политики резервного копирования для заданного агента PBR-Agent на основании целевых значений RPO (Recovery Point Objective) и RTO (Recovery Time Objective). Если значения RPO и RTO не переданы в команде флагами
--rpoи--rto, используются значения по умолчанию: RPO =15m(15 минут), RTO =1h(1 час).Команда анализирует последние 500 задач резервного копирования, агрегирует результаты по уникальным конфигурациям политик и с помощью AI-агента (внешнего LLM-провайдера) формирует рекомендацию с оценкой уверенности модели и уровня риска.
Синтаксис:
recovery-manager advisor recommend <agent-id> [flags]Обязательные параметры:
<agent-id>– уникальный идентификатор агента PBR-Agent, для которого необходимо получить рекомендацию.Опциональные параметры:
[flags]– доступны следующие флаги:Флаг Описание -h|--helpПоказать справку по команде --rto <duration>Целевой Recovery Time Objective (по умолчанию: 1h). Пример значений:4h,30m--rpo <duration>Целевой Recovery Point Objective (по умолчанию: 15m). Пример значений:15m,1h
Успешный ответ в формате YAML с полями model_confidence, risk_level, recommendation_reason, backup_policy подтверждает корректную интеграцию с AI-агентом.
:caption: Пример
$ advisor recommend 019f0349-47b7-737a-8d33-fddbba8649a9
recommendation_reason: Данная конфигурация демонстрирует 100% успешность выполнения (100 задач) без единого сбоя. Дифференциальные и инкрементальные резервные копии завершаются за 4–18 минут, что укладывается в целевые окна RPO и RTO. Политику рекомендуется из-за максимальной наблюдаемой надежности и наибольшего объема подтвержденных данных в телеметрии.
backup_policy:
fast_checkpoint: true
workers_no: 8
read_direct_io: true
write_direct_io: true
write_parts_workers_no: 16
write_wals_workers_no: 4
verify_page_checksums: true
model_confidence: 0.95
risk_level: LOW
Возможные проблемы
| Проблема | Решение |
|---|---|
failed to get configuration | Проверьте, что все три параметра секции ai заполнены в файле конфигурации recovery-manager.yaml |
401 Unauthorized | Проверьте валидность API-ключа. При необходимости запросите новый |
failed to create chat completion | Убедитесь, что URL доступен из текущей сети |
chat completion returned no choices | Модель не вернула ответ. Обратитесь к администратору LLM-провайдера |