DDBoost (Dell EMC Data Domain)

к сведению

DDBoost — технология интеграции с системой хранения Dell EMC Data Domain, предназначенная для оптимизации резервного копирования и восстановления данных.

DDBoost выполняет предварительную дедупликацию данных, благодаря чему по сети передаются только уникальные блоки данных. Это позволяет:

снизить нагрузку на сеть;
уменьшить объем передаваемых данных;
повысить производительность операций резервного копирования и восстановления данных;
эффективнее использовать ресурсы системы хранения.

В зависимости от способа интеграции и компонента Platform V CopyWala, который необходимо подключить к DDBoost, перейдите к описанию в соответствующем разделе и выполните указанные шаги:

Компонент, подключаемый к DDBoost	Способ интеграции (ссылка на настройку)
Copywala	Прямое подключение: Copywala → DDBoost
Copywala	Через S2: Copywala → Storage Service → DDBoost
Copywala VDB	Прямое подключение: Copywala VDB → DDBoost
Copywala VDB	Через S2: Copywala VDB → Storage Service → DDBoost

к сведению

Режим подключения через Storage Service (S2) предназначен для возможности работы с DDBoost в условиях с повышенными требованиями к безопасности. В отличие от прямого подключения, при подключении через S2 учетные данные DDBoost используются только на стороне S2 и не предоставляются серверам, где установлена Copywala или Copywala VDB.

Прямое подключение компонента Copywala к DDBoost

Важно

Перед началом настройки убедитесь, что клиентская библиотека DDBoost libDDBoost.so установлена на хосте компонента copywala.

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

chmod a+rx libDDBoost.so

Также рекомендуется добавить директорию с 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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key
        # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key
        # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        cert:
          local_path: tls/cert.crt
          # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        key:
          local_path: tls/cert.key
          # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        cert:
          local_path: tls/cert.crt
          # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        key:
          local_path: tls/cert.key
          # vault_path: <path>     # путь к секрету в HashiCorp/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

  # Параметры отложенной доставки WAL-файлов
  force_local: false                               # переключение на локальное накопление WAL-файлов. При значении true WAL-файлы сохраняются в локальную директорию (wal_local_destination_uri) с суффиксом .upload-ready и могут быть выгружены в удаленное хранилище командой copywala archive-wal upload-wals
  wal_local_destination_uri: <path/to/local/wals/> # путь к локальной директории (local-fs://...) для накопления WAL-файлов, например, local-fs:///pgarclogs/copywala/). Обязателен при force_local: true
  upload_wals_workers_no: 4                        # количество параллельных рабочих процессов (workers) для выгрузки накопленных WAL-файлов командой copywala archive-wal upload-wals
  upload_wals_batch_size: 100                      # количество 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>     # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>       # ключ внутри json-секрета
  cert:
    local_path: tls/cert.crt
    # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>       # ключ внутри json-секрета
  key:
    local_path: tls/cert.key
    # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key
        # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета

# --------------------------------------
# Опциональные настройки приложения
# --------------------------------------
app:
  agent_id_file_path: /etc/pbr/pbr.agent.id          # путь к файлу, содержащему идентификатор агентского приложения
  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 # период задержки

# -------------------------------------------
# Переменные окружения для внешних библиотек
# -------------------------------------------
lib_envs:
  - name: PG_LICENSE_PATH                # путь к директории с файлами лицензий Pangolin
                                         # используется утилитами для получения данных об используемой лицензии
    value: /opt/pangolin_license         # значение по умолчанию определяется автоматически в зависимости от установленной версии Pangolin: /opt/pangolin-license или /opt/pangolin_license
  - name: PG_PLUGINS_PATH                # путь к директории с динамическими библиотеками (плагинами) Pangolin
    value: /usr/lib/pbr/copywala         # значение по умолчанию /usr/lib/pbr/copywala

# --------------------------------------
# Настройка ведения журналов приложения
# --------------------------------------
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 (и по умолчанию) – `UTC`.
  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.username
- ddboost.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 указанные ниже параметры и задайте для них необходимые значения:

Параметр	Описание	Значение по умолчанию
`use_tls`	Флаг включения взаимодействия по TLS. Установите значение `true` если в файле `copywala.yaml` в `ddboost.storage.tls` или секции глобального TLS (`tls`) указан хоть один сертификат (`rootca` / `cert` / `key`)	`false`
`auth_mode`	Режим TLS. Возможные значения: `0` – выключен. `1` – односторонний TLS. Требует обязательного заполнения параметра `rootca` в секции `tls`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt use_tls: true auth_mode: 1` `2` – двусторонний TLS. Требует обязательного заполнения всех параметров секции `tls` – `rootca` / `cert` / `key`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt cert: local_path: tls/cert.crt key: local_path: tls/cert.key use_tls: true auth_mode: 2` `3` – анонимный TLS. Заполнение параметров `rootca` / `cert` / `key` в секции `tls` не требуется. Пример конфигурации: `ddboost: storage: use_tls: true auth_mode: 3`	`0`
`encr_strength`	Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения: `0` – шифрование отключено `1` – низкий уровень `2` – высокий уровень	`0`
`cert_verify_flag`	В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения: `0` – отключить проверку сертификатов `1` – проверять FQDN сервера `2` – проверять FQDN клиента Флаги можно комбинировать, например, при значении `3` будет проверяться FQDN и сервера и клиента	`0`

к сведению

Более подробное описание параметров и их допустимых значений смотрите в официальной документации 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.

Проверьте, что для библиотеки установлены права на чтение и выполнение. При необходимости назначьте права с помощью команды:
```
chmod a+rx libDDBoost.so
```
Также рекомендуется добавить директорию с libDDBoost.so в переменную окружения LD_LIBRARY_PATH.
При интеграции с внешними СРК важно соблюдать в конфигурационных файлах copywala.yaml и storage-service.yaml одинаковые отступы на каждом уровне вложенности.

Шаг 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>               # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>                 # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt           # путь к локальному файлу
      # vault_path: <path>               # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>                 # ключ внутри json-секрета
    key:
      local_path: tls/cert.key           # путь к локальному файлу
      # vault_path: <path>               # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>                 # ключ внутри json-секрета

# --------------------------------------
# Параметры подключения к HashiCorp/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)
                   # при указании значения будет установлен соответствующий лимит памяти. По умолчанию используется значение 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>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        cert:
          local_path: tls/cert.crt # путь к локальному файлу
          # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        key:
          local_path: tls/cert.key # путь к локальному файлу
          # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
      # Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
      use_tls: false      # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storages.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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
  max_connections: 256         # максимальное количество подключений для одного адреса, указанного выше
  read_timeout: 5m             # тайм-аут для операции чтения
  write_timeout: 5m            # тайм-аут для операции записи

# --------------------------------------
# Путь к основному хранилищу
# --------------------------------------
storage_path: /var/pbr/backups # путь к хранилищу резервных копий, который используется по умолчанию, если не задан путь в `copywala.yaml` в параметрах `storage_path` или `backup_destination_uri`
# 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>     # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>       # ключ внутри json-секрета
  cert:
    local_path: tls/cert.crt # путь к локальному файлу
    # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>       # ключ внутри json-секрета
  key:
    local_path: tls/cert.key # путь к локальному файлу
    # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/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 (и по умолчанию) – `UTC`.
  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 распределяется между всеми активными задачами.

В файле storage-service.yaml заполните обязательные параметры:

:

Параметр	Описание
`ddboost.ddboost_lib_path`	Путь к динамической библиотеке DDBoost, по умолчанию — `libDDBoost.so`. Если не задана переменная `LD_LIBRARY_PATH` или в ней отсутствует нужный путь, укажите в значении данного параметра полный путь к файлу

{info} Изменение ddboost_lib_path и последующая перезагрузка конфигурации с помощью SIGHUP не приводит к загрузке библиотеки. Чтобы применить изменение, необходимо перезапустить storage-service. :::

ddboost.storages

Массив, содержащий параметры подключения к хранилищам. Пример заполнения:

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 

примечание

На данном шаге в массиве ddboost.storages заполните только параметры address. Описание настройки параметров учетных данных (username и password) описано в отдельном шаге 3.

- storage_path
- Путь к хранилищу DDBoost для резервных копий, который используется по умолчанию, если не задан путь в copywala.yaml в параметрах storage_path или backup_destination_uri. Пример: ddboost://1.2.3.4/storage-unit/sub/dir ::::

В файле storage-service.yaml задайте значения параметров allowed_storage_paths и is_allowed_storage_paths_only.
- Параметр allowed_storage_paths задает массив URI разрешенных хранилищ. Значение, заданное в параметре backup_destination_uri файла copywala.yaml, должно соответствовать минимум одному из URI массива allowed_storage_paths.
- Параметр is_allowed_storage_paths_only определяет, требуется ли проверять хранилище, полученное от Copywala (путь к хранилищу задается в copywala.yaml в параметре backup_destination_uri или storage_path), на соответствие списку в allowed_storage_paths:
  - true — запись в хранилище выполняется только в том случае, если значение storage_path (или путь из backup_destination_uri) в copywala.yaml соответствует одному из разрешенных хранилищ, указанных в allowed_storage_paths;
  - false — проверка storage_path (и пути из backup_destination_uri) из copywala.yaml на соответствие allowed_storage_paths не выполняется. При данном значении заполнять allowed_storage_paths не требуется.
Пример
Допустим, в 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>
В этом случае в 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 были идентичными значения для:
1. Хостов (в примере выше – <ddboost-host>);
2. Путей (в примере выше – <ddboost-storage-unit>/path/in/ddboost/storage/unit).
Важно
В storage_path и allowed_storage_paths можно указывать только те URI, хост которых есть либо в enc_creds_path, либо в секции ddboost.storages (подробнее про enc_creds_path в шаге 3).

Шаг 3. Настройка учетных данных

Учетные данные для подключения к хранилищу DDBoost также задаются в конфигурационном файле storage-service.yaml в секции ddboost.

Настройте учетные данные одним из способов:

Явная передача логина и пароля: для каждого из перечисленных в блоке storages хранилищ задайте значения для параметров:
- ddboost.storages.username
- ddboost.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 запускается от имени пользователя pbr, поэтому файлы ключей должны быть доступны этому пользователю.

После инициализации ключей проверьте владельца сгенерированных файлов и при необходимости назначьте владельцем файлов пользователя pbr и группу pbr:

chown pbr:pbr /var/pbr/storage-service/priv.key
chown pbr:pbr /var/pbr/storage-service/priv.key.pub

Инициализируйте локальное хранилище секретов командой 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 указанные ниже параметры и задайте для них необходимые значения:

Параметр	Описание	Значение по умолчанию
`use_tls`	Флаг включения взаимодействия по TLS. Установите значение `true` если в файле `storage-service.yaml` в `ddboost.storages.tls` или секции глобального TLS (`tls`) указан хоть один сертификат (`rootca` / `cert` / `key`)	`false`
`auth_mode`	Режим TLS. Возможные значения: `0` – выключен. `1` – односторонний TLS. Требует обязательного заполнения параметра `rootca` в секции `tls`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt use_tls: true auth_mode: 1` `2` – двусторонний TLS. Требует обязательного заполнения всех параметров секции `tls` – `rootca` / `cert` / `key`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt cert: local_path: tls/cert.crt key: local_path: tls/cert.key use_tls: true auth_mode: 2` `3` – анонимный TLS. Заполнение параметров `rootca` / `cert` / `key` в секции `tls` не требуется. Пример конфигурации: `ddboost: storage: use_tls: true auth_mode: 3`	`0`
`encr_strength`	Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения: `0` – шифрование отключено `1` – низкий уровень `2` – высокий уровень	`0`
`cert_verify_flag`	В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения: `0` – отключить проверку сертификатов `1` – проверять FQDN сервера `2` – проверять FQDN клиента Флаги можно комбинировать, например, при значении `3` будет проверяться FQDN и сервера и клиента	`0`

к сведению

Более подробное описание параметров и их допустимых значений смотрите в официальной документации DDBoost.

Также в storage-service.yaml заполните секцию ddboost.storages.tls исходя из заданных на предыдущем шаге параметров use_tls и auth_mode.

Проверка результата

Интеграция с хранилищем DDBoost считается успешной, если при запуске Storage Service не возникло соответствующей ошибки.

Для проверки корректности подключения к хранилищу DDBoost выполните команду:

storage-service healthcheck ddboost

В результате выполнения команды будет выведен статус подключения (пример вывода):

+--------------------------+--------+
| HOST                     | RESULT |
+--------------------------+--------+
| 198.51.100.42            | OK     |
+--------------------------+--------+
| All                      | OK     |
+--------------------------+--------+

к сведению

Команда storage-service healthcheck ddboost проверяет доступность хранилищ DDBoost, используя адреса и учетные данные из двух источников:

Зашифрованное хранилище — адреса и учетные данные из файла, указанного в параметре enc_creds_path файла storage-service.yaml.
Явно заданные логин и пароль — учетные данные из секции ddboost.storages, где для каждого хранилища указаны IP-адрес и учетные данные в явном виде.

Если для одного и того же хранилища учетные данные указаны и в зашифрованном хранилище, и в явном виде в storage-service.yaml, приоритет имеют данные из зашифрованного хранилища.

Добавление хранилищ DDBoost без остановки Storage Service (S2)

Для подключения новых хранилищ DDBoost не требуется останавливать или перезапускать Storage Service. Для этого добавьте параметры новых хранилищ в конфигурационный файл storage-service.yaml и инициируйте перечитывание конфигурации без перезапуска сервиса.

Такой подход позволяет динамически расширять список доступных хранилищ. Резервное копирование и другие операции не прерываются, время простоя системы снижается.

Storage Service поддерживает обработку сигнала SIGHUP для применения изменений. Сигнал инициирует повторное чтение конфигурационного файла и подключение новых хранилищ DDBoost.

Важно

Механизм динамического обновления поддерживает только добавление новых хранилищ DDBoost. Изменять или удалять параметры (например, адрес, учетные данные или другие настройки подключения) для уже зарегистрированных хранилищ DDBoost нельзя. Для этого требуется перезапуск Storage Service с обновленной конфигурацией.

Последовательность действий

В конфигурационном файле storage-service.yaml добавьте новые хранилища в массив ddboost.storages:

Пример
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:

Пример
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.username
- ddboost.storages.password

Локальное хранилище секретов. Обновите в хранилище файл учетных данных командой storage-service init ddboost-creds с флагом --force (ознакомьтесь со справкой по команде ниже):

Справка по команде storage-service init ddboost-creds

Описание:

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:
Пример команды
```
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.

chmod a+rx libDDBoost.so

Также рекомендуется добавить директорию с 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>         # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>           # ключ внутри json-секрета
    cert:
      local_path: "<tls/cert.crt>" # путь к локальному файлу
      # vault_path: <path>         # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>           # ключ внутри json-секрета
    key:
      local_path: "<tls/cert.key>" # путь к локальному файлу
      # vault_path: <path>         # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/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>         # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>           # ключ внутри json-секрета
    cert:
      local_path: "<tls/cert.crt>" # путь к локальному файлу
      # vault_path: <path>         # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>           # ключ внутри json-секрета
    key:
      local_path: "<tls/cert.key>" # путь к локальному файлу
      # vault_path: <path>         # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/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>         # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>           # ключ внутри json-секрета
  cert:
    local_path: "<tls/cert.crt>" # путь к локальному файлу
    # vault_path: <path>         # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>           # ключ внутри json-секрета
  key:
    local_path: "<tls/cert.key>" # путь к локальному файлу
    # vault_path: <path>         # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>           # ключ внутри json-секрета

# --------------------------------------
# Опциональные настройки приложения (ниже приведены значения по умолчанию)
# --------------------------------------
app:
  agent_id_file_path: /etc/pbr/pbr.agent.id          # путь к файлу, содержащему идентификатор агентского приложения
  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)
                      # если параметр не указан в 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 (и по умолчанию) – `UTC`.
  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`)

Шаг 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 указанные ниже параметры и задайте для них необходимые значения:

Параметр	Описание	Значение по умолчанию
`use_tls`	Флаг включения взаимодействия по TLS. Установите значение `true` если в файле `copywala-vdb.yaml` в `ddboost.storage.tls` или секции глобального TLS (`tls`) указан хоть один сертификат (`rootca` / `cert` / `key`)	`false`
`auth_mode`	Режим TLS. Возможные значения: `0` – выключен. `1` – односторонний TLS. Требует обязательного заполнения параметра `rootca` в секции `tls`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt use_tls: true auth_mode: 1` `2` – двусторонний TLS. Требует обязательного заполнения всех параметров секции `tls` – `rootca` / `cert` / `key`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt cert: local_path: tls/cert.crt key: local_path: tls/cert.key use_tls: true auth_mode: 2` `3` – анонимный TLS. Заполнение параметров `rootca` / `cert` / `key` в секции `tls` не требуется. Пример конфигурации: `ddboost: storage: use_tls: true auth_mode: 3`	`0`
`encr_strength`	Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения: `0` – шифрование отключено `1` – низкий уровень `2` – высокий уровень	`0`
`cert_verify_flag`	В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения: `0` – отключить проверку сертификатов `1` – проверять FQDN сервера `2` – проверять FQDN клиента Флаги можно комбинировать, например, при значении `3` будет проверяться FQDN и сервера и клиента	`0`

к сведению

Более подробное описание параметров и их допустимых значений смотрите в официальной документации 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)

В файле 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>               # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>                 # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt           # путь к локальному файлу
      # vault_path: <path>               # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>                 # ключ внутри json-секрета
    key:
      local_path: tls/cert.key           # путь к локальному файлу
      # vault_path: <path>               # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>                 # ключ внутри json-секрета

# --------------------------------------
# Параметры подключения к HashiCorp/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)
                   # при указании значения будет установлен соответствующий лимит памяти. По умолчанию используется значение 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>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        cert:
          local_path: tls/cert.crt # путь к локальному файлу
          # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
        key:
          local_path: tls/cert.key # путь к локальному файлу
          # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
          # vault_key: <key>       # ключ внутри json-секрета
      # Дополнительные параметры настройки TLS для DDBoost. Подробное описание параметров и допустимых значений смотрите в официальной документации DDBoost
      use_tls: false      # включает TLS. Обязательно установите true, если указан хоть один сертификат в секции ddboost.storages.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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    cert:
      local_path: tls/cert.crt # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
    key:
      local_path: tls/cert.key # путь к локальному файлу
      # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
      # vault_key: <key>       # ключ внутри json-секрета
  max_connections: 256         # максимальное количество подключений для одного адреса, указанного выше
  read_timeout: 5m             # тайм-аут для операции чтения
  write_timeout: 5m            # тайм-аут для операции записи

# --------------------------------------
# Путь к основному хранилищу
# --------------------------------------
storage_path: /var/pbr/backups # путь к хранилищу резервных копий, который используется по умолчанию, если не задан путь в `copywala.yaml` в параметрах `storage_path` или `backup_destination_uri`
# 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>     # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>       # ключ внутри json-секрета
  cert:
    local_path: tls/cert.crt # путь к локальному файлу
    # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
    # vault_key: <key>       # ключ внутри json-секрета
  key:
    local_path: tls/cert.key # путь к локальному файлу
    # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/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>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      cert:
        local_path: tls/cert.crt # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/SecMan
        # vault_key: <key>       # ключ внутри json-секрета
      key:
        local_path: tls/cert.key # путь к локальному файлу
        # vault_path: <path>     # путь к секрету в HashiCorp/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 (и по умолчанию) – `UTC`.
  compress_backups: false                # параметр определяет необходимость сжатия резервных копий лог-файлов. Если выбрано true, лог-файлы будут сжаты, если false, лог-файлы будут храниться без сжатия

Важно

Также необходимо учитывать взаимосвязь параметров:

значение параметра 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:
  1. В массиве - address задайте значение IP-адреса хранилища.
  2. Если будет использоваться несколько хранилищ – добавьте соответствующее количество массивов - 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 были идентичными значения для:
  1. Хостов (в примере выше – <ddboost-host>);
  2. Путей (в примере выше – <ddboost-storage-unit>/path/in/ddboost/storage/unit).
Важно
В storage_path и allowed_storage_paths можно указывать только те URI, хост которых есть либо в enc_creds_path (подробнее про enc_creds_path в шаге 3), либо в секции ddboost.storages.

Шаг 3. Настройка учетных данных

Настройте учетные данные одним из способов:

Явная передача логина и пароля: для каждого из перечисленных в блоке storages хранилищ задайте значения для параметров:
- ddboost.storages.username
- ddboost.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.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`	Принудительная замена существующего файла с ключом (повторная генерация), если он уже существует

Важно

chown pbr:pbr /var/pbr/storage-service/priv.key
chown pbr:pbr /var/pbr/storage-service/priv.key.pub

Справка по команде storage-service init ddboost-creds

Описание:

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 [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 указанные ниже параметры и задайте для них необходимые значения:

Параметр	Описание	Значение по умолчанию
`use_tls`	Флаг включения взаимодействия по TLS. Установите значение `true` если в файле `storage-service.yaml` в `ddboost.storages.tls` или секции глобального TLS (`tls`) указан хоть один сертификат (`rootca` / `cert` / `key`)	`false`
`auth_mode`	Режим TLS. Возможные значения: `0` – выключен. `1` – односторонний TLS. Требует обязательного заполнения параметра `rootca` в секции `tls`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt use_tls: true auth_mode: 1` `2` – двусторонний TLS. Требует обязательного заполнения всех параметров секции `tls` – `rootca` / `cert` / `key`. Пример конфигурации: `ddboost: storage: tls: rootca: local_path: tls/root.crt cert: local_path: tls/cert.crt key: local_path: tls/cert.key use_tls: true auth_mode: 2` `3` – анонимный TLS. Заполнение параметров `rootca` / `cert` / `key` в секции `tls` не требуется. Пример конфигурации: `ddboost: storage: use_tls: true auth_mode: 3`	`0`
`encr_strength`	Уровень шифрования. Зависит от используемых алгоритмов шифрования. Возможные значения: `0` – шифрование отключено `1` – низкий уровень `2` – высокий уровень	`0`
`cert_verify_flag`	В параметре задается флаг проверки TLS-сертификатов и FQDN клиента/сервера. Возможные значения: `0` – отключить проверку сертификатов `1` – проверять FQDN сервера `2` – проверять FQDN клиента Флаги можно комбинировать, например, при значении `3` будет проверяться FQDN и сервера и клиента	`0`

к сведению

Более подробное описание параметров и их допустимых значений смотрите в официальной документации DDBoost.

Также в storage-service.yaml заполните секцию ddboost.storages.tls исходя из заданных на предыдущем шаге параметров use_tls и auth_mode.

Проверка результата

Для проверки корректности подключения к хранилищу DDBoost выполните команду:

storage-service healthcheck ddboost

В результате выполнения команды будет выведен статус подключения (пример вывода):

+--------------------------+--------+
| HOST                     | RESULT |
+--------------------------+--------+
| 198.51.100.42            | OK     |
+--------------------------+--------+
| All                      | OK     |
+--------------------------+--------+

к сведению

Зашифрованное хранилище — адреса и учетные данные из файла, указанного в параметре enc_creds_path файла storage-service.yaml.
Явно заданные логин и пароль — учетные данные из секции ddboost.storages, где для каждого хранилища указаны IP-адрес и учетные данные в явном виде.

Добавление хранилищ DDBoost без остановки Storage Service (S2)

Важно

Последовательность действий

В конфигурационном файле storage-service.yaml добавьте новые хранилища в массив ddboost.storages:

Пример
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

примечание

При необходимости добавьте пути к новым хранилищам в секцию allowed_storage_paths:

Пример
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.username
- ddboost.storages.password

Справка по команде storage-service init ddboost-creds

Описание:

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:
Пример команды
```
sudo tail -f /var/log/pbr/storage-service.log
```
В начале перечитывания конфигурации появится сообщение:
```
reloading config...
```
После успешного завершения проверки доступности новых хранилищ и их регистрации в логах будет выведено сообщение:
```
reload config success.
```
Внимание!
- Если проверка подключения для какого-либо из новых серверов не пройдена или при добавлении этого сервера возникла другая ошибка, сервер будет проигнорирован и Storage Service продолжит добавлять оставшиеся серверы.
- Использовать новые хранилища DDBoost можно только после появления в журнале сообщения reload config success.

Прямое подключение компонента Copywala к DDBoost​

Проверка результата​

Подключение компонента Copywala к DDBoost через Storage Service (S2)​

Проверка результата​

Добавление хранилищ DDBoost без остановки Storage Service (S2)​

Прямое подключение компонента Copywala VDB к DDBoost​

Проверка результата​

Подключение компонента Copywala VDB к DDBoost через Storage Service (S2)​

Проверка результата​

Добавление хранилищ DDBoost без остановки Storage Service (S2)​

Прямое подключение компонента Copywala к DDBoost

Проверка результата

Подключение компонента Copywala к DDBoost через Storage Service (S2)

Проверка результата

Добавление хранилищ DDBoost без остановки Storage Service (S2)

Прямое подключение компонента Copywala VDB к DDBoost

Проверка результата

Подключение компонента Copywala VDB к DDBoost через Storage Service (S2)

Проверка результата

Добавление хранилищ DDBoost без остановки Storage Service (S2)