Рекомендации по администрированию CopyWala

• Активация проверки контрольных сумм страниц
• Проверка целостности резервных копий
• Настройка прав доступа через конфигурационный файл copywala.yaml
• Использование защитного преобразования данных для резервных копий

Активация проверки контрольных сумм страниц

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

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

Результат:

Параметр max_allowed_page_verification_failures в конфигурационном файле определяет поведение системы при обнаружении поврежденных страниц в ходе резервного копирования (по умолчанию — 0):

• Если параметр имеет значение минус один, система будет только логировать факт обнаружения поврежденных страниц, не прерывая процесс создания резервной копии.

• Если параметр равен нулю, система немедленно прервет выполнение операции создания резервной копии с ошибкой при обнаружении первой поврежденной страницы.

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

Проверка целостности резервных копий

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

Механизм проверки контроля целостности резервных копий по умолчанию включен и настроен на вычисление контрольных сумм по алгоритму CRC32. Кроме CRC32 поддерживается расчет контрольных сумм по алгоритму SHA256, который можно настроить, указав в конфигурационном файле:

backup_policy:
    checksum_algorithm: SHA256

Чтобы отключить проверку целостности на момент создания резервной копии, укажите в конфигурационном файле: checksum_algorithm: DISABLED.

При проверке целостности резервной копии через CLI компонента Copywala командой copywala cwl verify <backup-uri> необходимо, чтобы резервное копирование выполнялось с активированной опцией контроля целостности метаданных.

На этапе восстановления проверка контрольных сумм отдельных файлов не проводится. Осуществляется только проверка чексумм метаданных архива. Однако после завершения восстановления всей цепочки резервных копий (включая случаи, когда цепочка состоит из одного архива), выполняется дополнительная проверка контрольных сумм восстановленных файлов.

примечание

Например, если цепочка резервных копий состоит из трех РК, то при восстановлении второй РК ошибка контрольной суммы файла не выявится сразу, но появится после завершения восстановления всей цепочки.

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

restore_policy:
    verify_archive_checksums: false

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

Также учтите следующее правило: если параметр verify_archive_checksums раздела restore_policy установлен в true, но при выполнении резервного копирования алгоритм вычисления контрольных сумм не был указан (не был установлен параметр checksum_algorithm раздела backup_policy), то проверка чексумм проводиться не будет.

Настройка прав доступа через конфигурационный файл copywala.yaml

Права устанавливаются для файлов и каталогов, созданных локально.

Добавьте следующие параметры в конфигурационный файл copywala.yaml:

backup_policy:
  backup_file_mode: 0400 # числовое представление прав доступа на создаваемые файлы
  backup_dir_mode: 0700  # числовое представление прав доступа на создаваемые каталоги

wal_archiving:
  wal_file_mode: 0600   # числовое представление прав доступа на создаваемые файлы
  wal_dir_mode: 0700    # числовое представление прав доступа на создаваемые каталоги

app:
  agent_id_file_mode: 0400  # числовое представление прав доступа на создаваемые файлы
  copywala_dir_mode: 0700   # числовое представление прав доступа на создаваемые каталоги

к сведению

Важно учитывать, что операционная система применяет маску прав доступа, настраиваемую посредством утилиты umask. Например, если значение umask равно 0022, а в конфигурации указан параметр backup_policy.backup_dir_mode: 0777, то при первой операции резервирования (copywala create-backup) с локальной файловой системой итоговые права каталога будут равны 0755.

При выполнении же команд архивации (archive_command) инструмент запускается с учетом настроек маски PostgreSQL (umask=0077), что ограничивает доступ для групповых пользователей и всех остальных. Так, при значении параметра wal_archiving.wal_file_mode: 0644 файлы архива WAL получат права доступа именно 0600.

Использование защитного преобразования данных для резервных копий

Обзор

Copywala поддерживает защитное преобразование архивов резервных копий.

Защитное преобразование используется для повышения безопасности и оптимизации хранения резервных копий. Оно позволяет:

• обеспечить эффективное сжатие архивов резервных копий при использовании в целевой БД Pangolin функциональности TDE (Transparent Data Encryption – прозрачное защитное преобразование данных);
• защитить архивы резервных копий, если в целевой СУБД не используется шифрование данных (например, в чистом PostgreSQL, Pangolin без включенного TDE или других СУБД без шифрования данных).

Ограничения

• Функциональность защитного преобразования не поддерживается для архивов WAL-файлов.
• Восстановление БД с помощью драйвера FUSE не поддерживается для резервных копий, над которыми было выполнено защитное преобразование (независимо от того используется ли защитное преобразование в целевой СУБД).

Настройка Copywala

В зависимости от сценария выполните соответствующие настройки параметров Copywala:

Сценарий	Настройка
В качестве целевой СУБД используется Pangolin c включенным TDE	В конфигурационном файле copywala.yaml в секции app добавьте и заполните значение для параметра copywala_plugins_dir: app: copywala_plugins_dir: /usr/lib/pbr/copywala # путь к директории, где находится плагин защитного преобразования Важно Copywala и Pangolin должны использовать один и тот же плагин шифрования, иначе сжатие будет не эффективным. Убедитесь, что в copywala_plugins_dir указан путь к плагину, который используется в Pangolin.
В качестве целевой СУБД используется Pangolin c выключенным TDE или другая СУБД, в которой не используется шифрование данных	Настройте интеграцию с KMS HashiCorp Vault согласно описанию в руководстве по установке, Настройка интеграции Platform V CopyWala с внешними сервисами, раздел – KMS HashiCorp Vault. В конфигурационном файле copywala.yaml или copywala-vdb.yaml (в зависимости от целевой СУБД) задайте значение для параметра protection_key_path, расположенного в секциях backup_policy и restore_policy: backup_policy: protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при создании резервной копии local_path: "<local-path>" # vault_path: <path> # vault_key: <key> restore_policy: protection_key_path: # путь к ключу в KMS HashiCorp Vault, необходимому для защитного преобразования при восстановлении из резервной копии local_path: "<local-path>" # vault_path: <path> # vault_key: <key>

Поведение работы защитного преобразования данных в Copywala в зависимости от целевой СУБД

В таблице ниже показано поведение защитного преобразования в Copywala для разных сценариев в зависимости от указанных в столбцах условий:

Подсказка по обозначениям в таблице

Указанные в таблице ниже параметры задаются в конфигурационных файлах в зависимости от целевой СУБД:

• для Pangolin / PostgreSQL – в copywala.yaml;
• для Vector DB / Qdrant – в copywala-vdb.yaml.

Знак «–» в таблице означает, что для данного сценария данный параметр заполнять не требуется.

Сценарий	Целевая СУБД	Cжатие включено через параметр archive_settings.compression_algorithm	Заполнена секция kms	Задан параметр protection_key_path	Задан параметр app.copywala_plugins_dir	Задан параметр backup_policy.compress_tde	Защитное преобразование выполняется в Copywala
1	Pangolin с включенным TDE	да	–	–	да	true	да
2	Pangolin с включенным TDE	да	–	–	да	false	нет
3	Pangolin с выключенным TDE	нет	да	да	–	–	да
4	Другая СУБД без шифрования (чистый PostgreSQL, Vector DB или Qdrant)	не важно (любое значение)	да	да	–	–	да
5	Pangolin с выключенным TDE или другая СУБД без шифрования	не важно (любое значение)	нет	нет	–	–	нет

Восстановление данных / проверка целостности CWL-архива

Перед восстановлением данных из резервной копии или проверкой целостности CWL-архива проверьте выполнение указанных ниже условий:

• Если резервная копия была создана из Pangolin с включенным TDE, то убедитесь, что:

  1. В конфигурационном файле copywala.yaml в секции app заполнено значение для параметра copywala_plugins_dir.
  2. На сервере СУБД, на котором будет выполняться восстановление, выполнена настройка подключения к KMS HashiCorp Vault (например с помощью утилиты setup_kms_credentials).

• Если резервная копия была создана из Pangolin c выключенным TDE или другой СУБД, в которой не используется шифрование данных, то убедитесь, что:

  1. Настроена интеграция с KMS HashiCorp Vault.
  2. В copywala.yaml или copywala-vdb.yaml (в зависимости от целевой СУБД) в секции restore_policy задан параметр protection_key_path.

Для проверки того, было ли применено защитное преобразование к архиву, используйте команду copywala cwl info <path to cwl archive>. В результате вызова команды обратите внимание на поля:

Поле	Описание
archive_encryption_key_kms_label	Метка ключа (в KMS) защитного преобразования архива резервной копии. Если она есть в заголовке, значит для архива использовалось защитное преобразование
backup_info:pangolin_info:tde_master_key_kms_label	Метка ключа (в KMS) для защитного преобразования TDE. Если она есть в архиве, значит было выполнено защитное преобразование на стороне Copywala и TDE в базе включено. Если метки нет, это не значит, что TDE в базе выключено. Это значит, что на стороне Copywala не выполнялось защитное преобразование

Выключение защитного преобразования данных

Для выключения защитного преобразования данных в Copywala используется параметр в copywala.yaml:

backup_policy:
    compress_tde: true # включает защитное преобразование данных на стороне copywala. По умолчанию – true.
                       # Используется только при одновременном выполнении двух условий:
                       # - включено сжатие (archive_settings.compression_algorithm в copywala.yaml);
                       # - в Pangolin включен TDE (is_tde_on = on).
                       # Для резервного копирования чистого PostgreSQL, произвольных директорий (generic-folder) и других СУБД, не использующих защитное преобразование, параметр игнорируется.

Важно

Для Pangolin с включенным TDE и compress_tde=false сжатие и защитное преобразование средствами Copywala не выполняются — файлы резервной копии сохраняются в исходном виде.