pgBackRestを使用したPostgreSQLインクリメンタルバックアップ。パート2。暗号化、S3への起動、新しいサーバーへの復元、PITR

この記事は、記事「pgbackrestを使用したPostgresqlインクリメンタルバックアップ-開発者からの若い戦士のコース」の続きです。



最初の部分では、増分バックアップを作成し、それらをリモートサーバー（バックアップのあるリポジトリ）にアップロードして、最後のバックアップにロールバックする方法を学びました。

この記事では、バックアップを暗号化し、（2番目のリポジトリサーバーではなく）S3互換ストレージにアップロードし、クリーンクラスターに回復し、最後にポイントインタイム回復（PITR）に復元する方法を学習します。

瞬間



作者はDBAのふりをしませんが、自分ですべてを設定して見るのが好きな場合があります。

トレーニング

このマニュアルを複製するには、次のものが必要です。

1. データベースを備えたサーバー（pgbackrestをインストールします）。
2. S3ストレージ（AmazonまたはS3互換の任意のS3を使用できます。AmazonS3を使用します）。
3. 3番目のサーバー。オプション。その上で、postgresqlとpgbackrestを最初からデプロイし、S3ストレージから既存のバックアップをデプロイする練習をします（サーバーの焼き切れ、移動など）。

postgresqlがすでにインストールされていることを前提としているため、postgresユーザーも存在します。



前回の記事でpgbackrestのインストールプロセスについて説明しましたが、再度複製する場合に備えて（インストールする前に、自分用のsudoユーザーを作成してください-pgbackrestユーザー名のsudoユーザーを使用します）。



指示を再現する際の問題を少なくするために、記事を書いたりチェックしたりするときに、どのユーザーがどの権限でコマンドを実行したかをイタリック体で記述します。



次のパスに従います



。postgresqlとpgbackrestを構成し

ます。バックアップの暗号化を構成します（2行）

バックアップしてS3ストレージに送信する方法を学びます（5行）

バックアップを作成します

クラスターを壊し、新しいサーバーにデプロイし、既存のS3リポジトリに接続して、バックアップをロールアップするとします

。PITR（ポイントインタイムリカバリ）を見てみましょう。特定の時点にリカバリします（pgbackrestがすでにドロップテーブルをバックアップしているとしましょう。ただし、4時間ロールバックする必要があります）。看板がまだ残っていたら）



行こう！

pgBackRestのインストール

sudo userまたはroot：



1。pgbackrestからアーカイブをダウンロードし、その内容を/ buildフォルダーに転送します。

sudo mkdir /build
sudo wget -q -O - \
       https://github.com/pgbackrest/pgbackrest/archive/release/2.18.tar.gz | \
       sudo tar zx -C /build

2.ビルドに必要な依存関係をインストールします。

sudo apt-get update
sudo apt-get install build-essential libssl-dev libxml2-dev libperl-dev zlib1g-dev \
       libpq-dev

3. pgbackrestをまとめる：

cd /build/pgbackrest-release-2.18/src && sudo ./configure
sudo make -s -C /build/pgbackrest-release-2.18/src

4.実行可能ファイルを/ usr / binディレクトリにコピーします。

sudo cp /build/pgbackrest-release-2.18/src/pgbackrest /usr/bin
sudo chmod 755 /usr/bin/pgbackrest

5.pgBackRestにはperlが必要です。インストール：

sudo apt-get install perl

6.ログ用のディレクトリを作成し、特定の権限を付与します。

sudo mkdir -p -m 770 /var/log/pgbackrest
sudo chown postgres:postgres /var/log/pgbackrest
sudo mkdir -p /etc/pgbackrest
sudo mkdir -p /etc/pgbackrest/conf.d
sudo touch /etc/pgbackrest/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest/pgbackrest.conf
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

7.チェック：

pgbackrest version

postgresqlとpgBackRestの設定

sudo userまたはroot：



1。pgBackRestが機能するために、postgresql.conf（/ etc / postgresql / 11 /メインフォルダーにあります）で必要な設定を行います。

archive_command = 'pgbackrest --stanza=main archive-push %p' #  main -  .   postgres    main.
archive_mode = on
max_wal_senders = 3
wal_level = replica

2. pgbackrest構成ファイル（/etc/pgbackrest/pgbackrest.conf）で必要な設定を行いましょう。

[main]
pg1-path=/var/lib/postgresql/11/main

[global]
log-level-file=detail
repo1-cipher-pass=tr5+BXdfdoxeyUqfo6AzLTrW+c+Jfd/1QbQj2CDMMBwtB0YGH3EJajry4+Eeen6D
repo1-cipher-type=aes-256-cbc
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2 # ,     . ..           ,      .    "     " -     .
repo1-type=s3
repo1-s3-bucket=pgbackrest-part2-tutorial
repo1-s3-endpoint=s3.us-east-1.amazonaws.com
repo1-s3-region=us-east-1
repo1-s3-key=9wdS3G8U5wz7kNsFWVGck7DDZ7DtVDtbM
repo1-s3-key-secret=A9zRmW16zXKt2vVA8mmNsFWy2mUAPYHa
start-fast=y

[global:archive-push]
compress-level=3

ご理解のとおり、ここではすぐに暗号化を構成し、S3ストレージのサポートを構成しました。



PS設定にコメントはありません。

PS強力な暗号化キーを生成するには、次のコマンドを使用できます。

openssl rand -base64 48

リポジトリの作成

sudoユーザーまたはroot：

sudo mkdir -m 770 /var/lib/pgbackrest
sudo chown -R postgres /var/lib/pgbackrest/
sudo -u postgres pgbackrest --stanza=main stanza-create

すべてがうまくいった場合、S3バケットにpgbackrestによって生成されたファイルが表示されます。

バックアップの作成：

sudoユーザーまたはroot：

sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup

pgBackRestは最初の完全バックアップを作成します。必要に応じて、backupコマンドを再度実行し、システムが増分バックアップを作成することを確認できます。



完全バックアップを再作成する場合は、追加のフラグを指定します。

sudo -u postgres pgbackrest --log-level-console=info --stanza=main --type=full backup

次のコマンドを使用して、バックアップのリストを表示できます。

sudo -u postgres pgbackrest --stanza=main info

バックアップの復元：

sudo userまたはroot：



1。実行中のクラスターを停止します。

sudo pg_ctlcluster 11 main stop

2.バックアップからの回復：

sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate restore

データベースを最後の完全バックアップの状態に復元するには、recovery_targetを指定せずに次のコマンドを使用します。

sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta restore

重要！リカバリ後、データベースがリカバリモードでハングすることが判明する場合があります（ERROR：読み取り専用トランザクションでDROP DATABASEを実行できません）などのエラーが発生します。これは次のように解決されます（コマンドの実行後、少し待つ必要があります）。

sudo -u postgres psql -c "select pg_wal_replay_resume()"

UPD：私が理解しているように、このエラーは、recovery_target =即時でのリカバリ後、pgbackrestがデータベースを一時停止するという事実が原因で発生します。これを回避するには、いくつかのフラグを追加で指定する必要があります（こことここでそれらの意味を読むことができます）：

sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate --target-action=promote --type=immediate restore

実際、特定のバックアップをその名前で復元することは可能です。ここでは、ドキュメントでこの機能の説明へのリンクのみを提供します。開発者は、このパラメーターを慎重に使用することをお勧めし、その理由を説明します。私自身から、私はそれを使用したことを追加することができます。主なことは、リカバリ後にデータベースがリカバリモードを終了し（pg_is_in_recovery（）を選択すると「f」が表示されるはずです）、リカバリ後に完全バックアップを作成する場合に備えて確認することです。



3.クラスターを開始します。

sudo pg_ctlcluster 11 main start

バックアップを復元した後、2番目のバックアップを実行します。

sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup

クリーンなクラスターへのバックアップの復元：

何かひどいことが起こったと想像してみましょう-サーバーが焼失しました（落ちた、浸水した、アクセスが失われた）。すべてを新しいクリーンなサーバーに復元する必要があります。新しいサーバーでは、すでにsudoユーザーを作成し、pgbackrestをインストールし、postgresqlをインストールしており、クリーンで新しいメインクラスターがあります。



前のサーバーと同じ方法でpostgresqlとpgBackRestの構成をセットアップし、postgresqlを再起動して、restore：



sudo userまたはrootと同様のコマンド順序を実行するだけです



。1。実行中のクラスターを停止します。

sudo pg_ctlcluster 11 main stop

2.バックアップからの回復：

sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --recovery-option=recovery_target=immediate  --target-action=promote --type=immediate restore

PS私はこのコマンドの微妙な違いと微妙さを上で説明しました。 



3.クラスターを開始します。

sudo pg_ctlcluster 11 main start

バックアップを復元した後、2番目のバックアップを実行する必要があります。

sudo -u postgres pgbackrest --log-level-console=info --stanza=main backup

実際、それがすべてです。火が消えた。

ポイントインタイムリカバリ（PITR）

16:00にバックアップが作成され、18：05に誤って重要なプレートを消去してしまい、2時間で失いたくない重要なデータが大量に侵入したと想像してみてください。PostgreSQLを犠牲にしてPgBackRestは、そのような機会を提供します。回復するのに十分な情報があれば、特定の時点にロールバックできます。



それはこのように動作します：

1. 18:04の時間にロールバックしたいと言います。
2. pgBackRestは、最後の最新のバックアップ（16:00）を検索します。
3. それを復元しますが、すべてがロールオーバーするわけではなく、18.04より前に何とか実行できたものだけです。

PSこのメカニズムはWALログに基づいて構築されています。ここで読むことができます。



次のコマンドを使用して、特定の時点（クラスターを停止した後）へのリカバリーを実行できます。

sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --type=time "--target=2020-09-06 18:27:24.561458+02" --target-action=promote restore

重要な注意-PostgreSQLはWALログを順方向にのみ再生でき、逆方向には再生できません。これは実際にはどういう意味ですか？



16:00にバックアップが作成されたとしましょう。 18:05に誤ってテーブルを削除し、18：10に、すでに削除されたテーブルを使用してバックアップが再度作成されました。 PITRを作成しようとすると、pgBackRestは16:00に作成されたバックアップを取得し、18：05より前のすべてをロールオーバーし、18：10に作成されたバックアップを取得せず、すべてをロールバックします。これを理解することが重要です。このメカニズムについては、ここで詳しく説明します。



テーブルの削除に関する情報がすでに含まれているバックアップを作成したとします。 --setフラグを使用して、ベース（テーブルがまだあるバックアップ）にどのバックアップを使用するかを考えてみましょう。 pgBackRestはこのバックアップを取り、テーブルが削除される前のすべてをロールオーバーします。

sudo -u postgres pgbackrest --stanza=main --log-level-console=info --delta --type=time --set=20200905-183838F_20200906-182612I "--target=2020-09-06 18:27:24.561458+02" --target-action=promote restore

PS上記のバックアップのリストを取得するためのコマンドを示しました。



クラスターを起動しましょう。起動後、ファイル/var/log/postgresql/postgresql-11-main.logを調べてみましょう。その中で、指定された時点への回復が成功したことを示す次の行に関心があります。

starting point-in-time recovery to 2020-09-07 11:26:52.493127+02
...
recovery stopping before commit of transaction 576, time 2020-09-07 11:27:14.584496+02
...
last completed transaction was at log time 2020-09-07 11:24:09.583761+02

それで全部です。戦闘で使用する前に、このツールを試してみることを強くお勧めします。