Postgres Operator on Azure Kubernetes Service (2)

AKS (Azure Kubernetes Service) のお勉強にあわせて、[Postgres Operator](https://access.crunchydata.com/documentation/postgres-operator/latest/) を触ってみています。

今回はバックアップ周りについて調べてみました。

なお、Postgres Operator のインストールや Postgres クラスターの作成などについては、[前回の記事](https://zenn.dev/08thse/articles/28-aks-postgres-operator) を参照してくださいませ。

# 環境

* AKS (v1.21.1)
* Postgres Operator (v4.7.0)
* WSL 2 (Ubuntu 20.04)

# バックアップ

クラスター全体のバックアップと、`pg_dump` を使ったテーブル等の論理バックアップとがあります。`pg_dump` は "おなじみ" かなと思うので、ここではクラスター全体のバックアップを試してみました。

## バックアップ方法

詳細は [ドキュメント](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/disaster-recovery/#backups) を見ていただければと思いますが、コマンドひとつでバックアップすることができます。

```
$ pgo backup lb-rep-db --backup-opts="-type=full"
created Pgtask backrest-backup-lb-rep-db
```

※上記の `lb-rep-db` が、Postgres クラスター名です。

`pgo show backup` コマンドで、バックアップの詳細を確認することができます。

```
$ pgo show backup lb-rep-db

cluster: lb-rep-db
storage type: posix

stanza: db
    status: ok
    cipher: none

    db (current)
        wal archive min/max (13-1)

        full backup: 20210605-022042F
            timestamp start/stop: 2021-06-05 11:20:42 +0900 JST / 2021-06-05 11:21:12 +0900 JST
            wal start/stop: 000000010000000000000002 / 000000010000000000000002
            database size: 31.2MiB, backup size: 31.2MiB
            repository size: 3.8MiB, repository backup size: 3.8MiB
            backup reference list:

        incr backup: 20210605-022042F_20210611-142819I
            timestamp start/stop: 2021-06-11 23:28:19 +0900 JST / 2021-06-11 23:28:26 +0900 JST
            wal start/stop: 000000020000000000000006 / 000000020000000000000006
            database size: 31.2MiB, backup size: 119.2KiB
            repository size: 3.9MiB, repository backup size: 16.1KiB
            backup reference list: 20210605-022042F
```

## 定期バックアップ

上記のバックアップ処理を定期的に実行させることができます。ドキュメントは [こちら](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/disaster-recovery/#scheduling-backups)。

下記のように、`pgo create schedule` コマンドの `--schedule` オプションに cron 形式のスケジュールを渡してやれば OK です。

```
pgo create schedule lb-rep-db --schedule="0 1 * * *" \
  --schedule-type=pgbackrest  --pgbackrest-backup-type=full
```

# リストア

リストア方法としては、「既存のクラスターに上書きして適用する方法」と「バックアップから新しくクラスターを作成する方法」とがあります。Kubernetes をはじめとした Immutable Infrastructure 的には、後者に慣れておくと良いでしょうか。

## 既存のクラスターに上書きして適用する方法

`pgo restore` コマンドにて、戻したい日時を `--pitr-target` に渡して実行します。

```
pgo restore <cluster> --pitr-target="2020-12-31 11:59:59.999999+00" \
  --backup-opts="--type=time"
```

なお、上記のコマンドではリストア完了後に読み書き可能な状態になってしまうため、それを防ぎたい場合は `--backup-opts` オプションに `--target-action=pause` を追加しておくと良いとのこと。

## バックアップから新しくクラスターを作成する方法

クラスターを作成する `pgo create cluster` コマンドの `--restore-from` オプションに、リストア元のクラスター名を指定すれば OK。こちらも必要があればリカバリポイントの日時指定も可能なようです。

```
pgo create cluster newcluster \
  --restore-from oldcluster \
  --restore-opts "--type=time --target='2019-12-31 11:59:59.999999+00'"
```

ドキュメントは [こちら](https://access.crunchydata.com/documentation/postgres-operator/latest/architecture/disaster-recovery/#restores) をご覧くださいませ。

-----

AWS の S3 や GCP の GCS であれば直接バックアップ先として指定できるようですが、Azure はまだみたいですかね…。このあたりも実装されてきたら、また触ってみたいかなーと思います。