Роль Ansible для Borgbackup

Эта роль предназначена для реализации полностью управляемой настройки borg. В данный момент в список функций входят:

• Конфигурация клиента и сервера, каждый клиент получает собственное хранилище.
• Поддержка автоматического создания хранилищ на borgbase.com.
• Резервные копии выполняются от непривилегированного пользователя.
• Автоматическая конфигурация known_hosts, чтобы даже первоначальные соединения проходили успешно.
• Инициализация хранилища на клиентах.
• Опциональный режим append-only, а также управление конфигурацией для доступа администратора.
• Запланировано с помощью systemd timers.
• Конфигурация (в настоящее время приветствуются PR) использует repokey-blake2 и резервное копирование с использованием --compression lz4.

Другие роли могут дополнительно добавлять следующие настройки (см. примеры ниже):

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

Переменные роли

Общие переменные

Роль позволяет установку через менеджер пакетов ОС (по умолчанию) и напрямую из репозитория (через релизы Github):

borgbackup_install_method: system|upstream

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

borgbackup_upstream_version: 1.1.15
borgbackup_upstream_checksum: sha256:7848d1788b5d7f2ae99a599a87992cab4f01584fe5eb393819fceaecf076433b

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

borgbackup_user: borg

Для клиентских машин это пользователь, выполняющий borgbackup, а для серверных машин - пользователь, запускающий borg serve, когда клиент к нему подключается через SSH.

Внимание: Эта роль не создает выбранного вами пользователя; это нужно сделать вручную до использования этой роли. Например:

- name: Создать пользователя для borgbackup
  user:
    name: "{{ borgbackup_user }}"
    state: present

Переменные клиента

Необходимо установить директории для резервного копирования, а также пароль для каждого клиента:

borgbackup_passphrase: XXX_SECRET_XXX
borgbackup_directories: ["{{ borgbackup_home }}/data"] # по умолчанию

Если сервер управляется при помощи ansible, хранилище можно настроить, указав

borgbackup_repository_server: some_inventory_hostname

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

Если сервер управляется вне ansible, необходимо настроить реальное хранилище для резервного копирования, а также ключи хоста сервера:

borgbackup_repository: ssh://[email protected]/~/storage
borgbackup_known_hosts:
  - "borgbackup.cloud ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIElvcKplWycItag/MP7gYUCy95WIhMM1OFKbZ/j/ykFE"
borgbackup_hostkey_checking: ask/off/accept-new # (Соответствует строгой проверке ключей SSH, по умолчанию ask)

Обратите внимание, что значение по умолчанию для borgbackup_hostkey_checking установлено на ask, чтобы гарантировать проверку ключей хостов, т.е. настроено через borgbackup_known_hosts. Также можно установить его на accept-new для активации поведения "доверять при первом использовании".

Следующий пример демонстрирует, как настроить дополнительные параметры:

borgbackup_calendar_spec: "*-*-* 2:00:00" # по умолчанию, шаблон в формате systemd-timer и описывает, когда запускать borgbackup
borgbackup_exclude_patterns: [] # по умолчанию, см. справку borg по шаблонам, использует формат fnmatch
borgbackup_append_only: yes # по умолчанию, соответствует поведению borg append-only
borgbackup_use_cap_dac_read_search: no # по умолчанию
borgbackup_remote_ratelimit: 0 # ограничение ширины канала при создании резервной копии (kiByte/s, требуется Borg 1.1)
borgbackup_systemd_onfailure_unit: email-user.service # без значения по умолчанию, настраивает свойство `OnFailure` сервисов systemd

Внимание: Рекомендуется использовать либо root, либо выделенного пользователя для резервного копирования (по умолчанию используется borg). Поскольку непривилегированный пользователь borg может читать только свои собственные файлы, borgbackup_use_cap_dac_read_search можно установить на yes, что даст пользователям, выполняющим, разрешение на чтение всех файлов при выполнении через systemd-timer.

Поддержка borgbase.com

Чтобы включить поддержку borgbase.com, необходимо определить следующие переменные:

borgbackup_bb_repo: имя репозитория borgbase
borgbackup_bb_apikey: ключ API borgbase
borgbackup_hostkey_checking: accept-new # В противном случае проверка ключа хоста не удастся, так как мы не знаем ключ хоста
                                        # Либо подключиться вручную через ssh после запуска плейбука и принять ключ хоста

После их установки borgbackup_repository будет определено автоматически. Обратите внимание, что эта роль только создает репозиторий и ключ на borgbase.com, она никогда не модифицирует существующее хранилище. Это означает, что вы можете (и должны) использовать ограниченный токен API с разрешением Только на создание. Это также означает, что вам нужно одно хранилище на сервер, что хорошо, чтобы предотвратить конфликты блокировки.

Кроме того, создание хранилища borgbase можно контролировать через:

borgbackup_bb_quota: 1000 # в ГБ (по умолчанию не определено, что приводит к отсутствию квоты)
borgbackup_bb_region: eu/us (по умолчанию eu)
borgbackup_bb_alertdays: 1 (по умолчанию не определено, что приводит к отсутствию уведомлений)

Переменные сервера

Конфигурация сервера довольно простая, она позволяет указать корневую директорию для хранения через

borgbackup_repository_storage: /some/path

и в настоящее время требуется для "срабатывания" поведения сервера этой роли.

Если клиент использует borgbackup_append_only, можно настроить сервер для разрешения специальным ключам администратора доступ ко всем репозиториям:

borgbackup_management_keys:
  - "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIElvcKplWycItag/MP7gYUCy95WIhMM1OFKbZ/j/ykFE adminuser"

Регистрация дополнительных папок для резервного копирования, а также предварительных задач/программ резервного копирования

Роль написана так, чтобы ее можно было динамически расширять другими ролями. Единственное требование заключается в том, чтобы роль apollo13.borgbackup была запущена один раз перед тем, как другие роли могут ее расширить.

Для расширения функциональности резервного копирования из вымышленной роли postgresql можно сделать следующее (внутри tasks/main.yml роли postgresql):

include_role:
  name: apollo13.borgbackup
  tasks_from: configure.yml
vars:
  service: postgresql_dump # Должен быть уникальным среди всех сервисов на хосте
  backup_user: postgresql # Опционально, пользователь для выполнения команды резервного копирования
  # Команда резервного копирования используется в юните systemd, поэтому используйте sh, если требуется перенаправление
  backup_command: /bin/sh -c "pg_dumpall > /var/lib/postgresql/backup/db.out"
  # Дополнительный путь для добавления в резервную копию
  paths:
    - /var/lib/postgresql/backup/

Приведенный выше пример конфигурирует дополнительный юнит systemd, который выполняется перед резервным копированием, чтобы выполнить pg_dumpall как postgresql и добавляет /var/lib/postgresql/backup/ к пути для резервного копирования.

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

Поскольку все выполняется через systemd, статус можно легко проверить с помощью систем мониторинга. Соответствующие юниты:

• borgbackup.service - фактическое выполнение borgbackup.
• borgbackup-tasks.service - это плейсхолдер, который собирает статус завершения предварительных программ резервного копирования.
• borgbackup-tasks@<task_name.service> - Индивидуальные задачи резервного копирования, зарегистрированные в примере выше.