バックアップ役割

Coopdevsプロジェクトのバックアップおよび復元戦略

要件

この役割は、Resticを使用し、restic-ansibleの助けを借ります。

役割変数

# Resticのバージョン
backups_role_restic_version: '0.16.4'

# スクリプトの場所
backups_role_path: '/opt/backup'
backups_role_script_dir: "{{ backups_role_path }}/bin"

# 生成するテンプレートの上書き可能な名前
# "+"は"prepare"スクリプトで、レンダリングされたスクリプト`backups_role_script_path`に組み込まれます
backups_role_script_prepare_template: "cron-prepare.sh.j2"

# backups_role_script_prepare_templateを変更した場合は、デフォルトのスクリプトテンプレートを使用していないことを意味し、
# Postgresのロールを作成する必要がなくなるかもしれません。
# したがって、タスクをデフォルトで無効にします。
# ただし、これらのタスクを有効にしたい場合は、それに対応する変数をtrueに設定します。
backups_role_postgresql_enabled:
backups_role_sudoers_enabled:

# メイン、prepare、およびuploadによって形成されるレンダリングされたスクリプトの完全なパス
backups_role_script_path: "{{ backups_role_script_dir }}/backup.sh"

# cronジョブによって生成されたファイルの場所
backups_role_tmp_path: '/tmp/backups'

# バックアップするパスのリスト
backups_role_assets_paths: []

# システムユーザー及びその所属グループ
# スクリプト、Restic、およびcronジョブを実行する人
# ディレクトリおよびファイルの所有者
backups_role_user_name: 'backups'
backups_role_user_group: 'backups'
backups_role_user_groups: ''

# ダンプを実行するためのPostgreSQL内部の読み取り専用ロール
backups_role_postgresql_user_name: "{{ backups_role_user_name }}"
# PostgreSQLの内部管理ロール
postgresql_user: "postgres"
backups_role_db_names: [ "postgres" ]

# 異なるResticリポジトリを指定する必要がある場合にのみ使用されるResticリポジトリ名
backups_role_restic_repo_name: {{ escaped_inventory_hostname }}

#########################################
### 警告！ 敏感な変数が以下にあります ###
#########################################
### これらを保護するために、ansaible-vault内に置くことを検討してください。 ###
### 例としては、defaults/secrets.yml.exampleを参照してください。 ###
#########################################

# PostgreSQLの特権のないバックアップユーザーのパスワード
backups_role_postgresql_user_password:

# バックアップを暗号化するために提供するResticリポジトリのパスワード
backups_role_restic_repo_password:

# Restic形式のリモートバケットURL
# Backblazeの例: "b2:bucketname:path/to/repo"。おそらく
#   "b2:bucketname:/" が使えるでしょう。
# ローカルリポジトリの例: "/var/backups/repo"
backups_role_restic_repo_url:

# 前述のバケットに制限されたBackblazeのアプリケーションキー
# 詳細は例のシークレットファイルで確認してください。
backups_role_b2_app_key_id:
backups_role_b2_app_key:

依存関係

• coopdevs.ansible_restic

使用法

上記の変数を持つホストのインベントリを準備する必要があります。例えば、inventory/hostsに。

優れたPostgreSQLプレイブックとバックアップ

# playbooks/main.yml
---
- name: 自動バックアップ付きのPostgreSQLをインストール
  hosts: servers
  become: yes
  roles:
    - role: geerlingguy.postgresql
    - role: coopdevs.backups_role

コントローラーにバックアップを復元するためのプレイブック

# playbooks/restore.yml
---
- name: ローカルにバックアップを復元
  hosts: servers
  connection: local
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-controller.yml

ホストにバックアップを復元するためのプレイブック

# playbooks/restore-in-situ.yml
---
- name: ホストにバックアップを復元
  hosts: servers
  tasks:
  - import_role:
      name: coopdevs.backups_role
      tasks_from: restore-to-host.yml

上記のプレイブックを使用してスナップショットを復元

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers

このプレイブックは、グローバルにバイナリをインストールすることはありませんが、root権限が必要です。したがって、sudoパスワードの提供が必要になる場合があります：

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers --ask-become-pass

デフォルトでは、Restic用のディレクトリと便利なラッパー、最新のスナップショットの復元を作成します。最後に、資格情報が入っているため、ラッパーを安全に削除します。ただし、ラッパーを手動でインストールしたい場合は、installタグを付けてプレイブックを実行できます：

ansible-playbook playbooks/restore.yml -i inventory/hosts -l servers --tags install

カスタムバックアップスクリプト

アプリがPostgreSQLを使用していない場合やバックアップスクリプトがニーズに合わない場合は、backups_role_script_prepare_templateに新しいテンプレートを渡して独自のスクリプトを提供できます。logやrunなどのヘルパーメソッドを使用できます。詳細は cron-main.sh.j2 を参照してください。

オブジェクトストレージにバックアップをアップロードすることはカスタマイズできないため、スクリプトでバックアップファイルが残るパスをbackups_role_assets_pathsで指定する必要があります。この変数の名前はbackups_role_file_to_uploadのようなものであるべきです。詳細は cron-upload.sh.j2 を参照してください。

注意ですが、この場合には適用されませんが、この変数はcron-prepare.shでもその目的に使用され、混乱する可能性があります。異なる2つの用途を持っています。

生産向けの例は、https://github.com/coopdevs/donalo/pull/82 や https://gitlab.com/coopdevs/odoo-provisioning/-/tree/master/roles/backups を参照してください。

敏感な変数

上記の「敏感な変数」の下にある変数は少なくとも保護してください。そのためには、Ansible Vaultを使用して、これらの変数を含む設定ファイルをパスフレーズで暗号化します。

Backblaze

Backblazeは、アカウントまたはマスターキーとアプリケーションキーの2種類のキーを提供します。アカウントキーは1つだけで、他のすべてのキーとすべてのバケットに対する権限があります。アプリケーションキーは多数作ることができ、すべてまたは正確に1つのバケットにrwアクセスを持つことができます。

バケットにアクセスするためにアカウントキーを使用したり、アプリケーションキーを再利用したりするべきではありません。Resticのパスワードが異なっていても、バケットが異なっていても、あるサーバーが他のサーバーのバックアップを削除したり、バケットを作成して埋め込んだりして請求書を回す可能性があります。

したがって、マスターキーの代わりにアプリケーションキーを使用します。ansible-resticは、キーの種類に関係なく、資格情報をResticに渡すだけです。実際には、ansible-resticのb2_account_key（マスターキーの使用を推奨）をbackup-roleのbackups_role_b2_app_key（アプリケーションキーの使用を推奨）で設定します。

Resticが呼ぶ「アカウントキー」は、B2ウェブで「マスターアプリケーションキー」として表示されます。

新しいバケットと制限されたアプリケーションキーを作成したい場合は、Backblazeバケットとキースクリプトを使用できます。

Restic

Resticは、Ansibleのプロビジョニング中に「リポジトリ」を作成します。これは、バケットの内部にディレクトリのように見え、backups_role_bucket_urlの一部を':'で区切ったものがバケット内部のパスとなります。ルートに配置したい場合は、b2:mybucket:/のようなものを試してください。詳細はResticドキュメントを参照してください。外部から見ると：
config data index keys locks snapshots

復号化すると、例えばマウントする際：
hosts ids snapshots tags

ただし、特定のスナップショットをリポジトリから復元したい場合は、restic restoreを使用します。復元したいスナップショットIDと解凍先のディレクトリを指定する必要があります。スナップショットを確認するには、restic snapshotsを実行します。特に、最新のスナップショットを復元するには、スナップショットIDとしてlatestを使用できます。

全体のリポジトリではなく、最新のスナップショットから特定のファイルを復元するには、dumpサブコマンドを使用します：restic dump latest myfile > /home/user/myfile

すべてのResticコマンドは、どこに通信するのか、どの資格情報を使用するかを知る必要があります。そのため、パラメータとして渡すか、環境変数としてエクスポートする必要があります。この場合、次のようにします：

export RESTIC_REPOSITORY="b2:mybucketname:/"
export RESTIC_PASSWORD="長い文で少なくとも7単語"
export B2_ACCOUNT_ID="アプリケーションキーID"
export B2_ACCOUNT_KEY="非常に長く、数字と大文字が含まれるアプリケーションキー"

ライセンス

GPLv3