データはおそらく会社で最も価値のある資産であるため、事故やハードウェア障害が発生した場合のデータ損失を防ぐために、ディザスタリカバリプラン（DRP）を用意する必要があります。バックアップはDRの最も単純な形式です。許容可能な目標復旧時点（RPO）を保証するには必ずしも十分ではないかもしれませんが、最初のアプローチとしては適切です。また、会社の要件に応じて目標復旧時間（RTO）を定義する必要があります。 RTO値に到達する方法はたくさんありますが、それは会社の目標によって異なります。
このブログでは、pgBackRestを使用してPostgreSQLとTimescaleDBをバックアップする方法と、このバックアップツールの最も重要な機能の1つである、完全バックアップ、増分バックアップ、および差分バックアップを組み合わせてダウンタイムを最小限に抑える方法について説明します。
>pgBackRestとは何ですか？
データベースにはさまざまな種類のバックアップがあります：
- 論理：バックアップはSQLなどの人間が読める形式で保存されます。
- 物理：バックアップにはバイナリデータが含まれています。
- 完全/増分/差分：これらの3種類のバックアップの定義は、名前に暗黙的に含まれています。完全バックアップは、すべてのデータの完全コピーです。増分バックアップは前回のバックアップ以降に変更されたデータのみをバックアップし、差分バックアップには最後に実行された完全バックアップ以降に変更されたデータのみが含まれます。増分バックアップと差分バックアップは、完全バックアップの実行にかかる時間とディスク容量の使用量を減らす方法として導入されました。
pgBackRestは、従来のpg_basebackupツールと比較していくつかの改善を加えた物理バックアップを作成するオープンソースバックアップツールです。 pgBackRestを使用して、既存のバックアップを使用してストリーミングレプリケーションの初期データベースコピーを実行するか、deltaオプションを使用して古いスタンバイサーバーを再構築できます。
最も重要なpgBackRest機能のいくつかは次のとおりです。
- 並列バックアップと復元
- ローカルまたはリモート操作
- 完全、増分、および差分バックアップ
- バックアップローテーションとアーカイブの有効期限
- バックアップの整合性チェック
- バックアップの履歴書
- デルタ復元
- 暗号化
それでは、pgBackRestを使用してPostgreSQLおよびTimescaleDBデータベースをバックアップする方法を見てみましょう。
pgBackRestの使用方法
このテストでは、OSとしてCentOS 7を使用し、データベースサーバーとしてPostgreSQL11を使用します。データベースがインストールされていることを前提としています。インストールされていない場合は、これらのリンクをたどって、ClusterControlを使用してPostgreSQLとTimescaleDBの両方を簡単にデプロイできます。
まず、pgbackrestパッケージをインストールする必要があります。
$ yum install pgbackrestpgBackRestは、コマンドラインから、またはデフォルトでCentOS7の/etc/pgbackrest.confにある構成ファイルから使用できます。このファイルには次の行が含まれています：
[global]
repo1-path=/var/lib/pgbackrest
#[main]
#pg1-path=/var/lib/pgsql/10/dataこのリンクをチェックして、この構成ファイルに追加できるパラメーターを確認できます。
次の行を追加します：
[testing]
pg1-path=/var/lib/pgsql/11/datapostgresql.confファイルに次の構成が追加されていることを確認してください（これらの変更にはサービスの再起動が必要です）。
archive_mode = on
archive_command = 'pgbackrest --stanza=testing archive-push %p'
max_wal_senders = 3
wal_level = logicalそれでは、基本的なバックアップを取りましょう。まず、特定のPostgreSQLまたはTimescaleDBデータベースクラスターのバックアップ構成を定義する「スタンザ」を作成する必要があります。スタンザセクションでは、データベースクラスターのパスと、データベースクラスターがリモートの場合はホスト/ユーザーを定義する必要があります。
$ pgbackrest --stanza=testing --log-level-console=info stanza-create
2019-04-29 21:46:36.922 P00 INFO: stanza-create command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:46:37.475 P00 INFO: stanza-create command end: completed successfully (554ms)次に、checkコマンドを実行して構成を検証できます。
$ pgbackrest --stanza=testing --log-level-console=info check
2019-04-29 21:51:09.893 P00 INFO: check command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:51:12.090 P00 INFO: WAL segment 000000010000000000000001 successfully stored in the archive at '/var/lib/pgbackrest/archive/testing/11-1/0000000100000000/000000010000000000000001-f29875cffe780f9e9d9debeb0b44d945a5165409.gz'
2019-04-29 21:51:12.090 P00 INFO: check command end: completed successfully (2197ms)バックアップを作成するには、次のコマンドを実行します。
$ pgbackrest --stanza=testing --type=full --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=full
WARN: option repo1-retention-full is not set, the repository may run out of space
HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 15:43:21": backup begins after the next regular checkpoint completes
INFO: backup start archive = 000000010000000000000006, lsn = 0/6000028
WARN: aborted backup 20190429-215508F of same type exists, will be cleaned to remove invalid files and resumed
INFO: backup file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: full backup size = 31.8MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 000000010000000000000006, lsn = 0/6000130
INFO: new backup label = 20190429-215508F
INFO: backup command end: completed successfully (12810ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (10ms)これで、「正常に完了しました」という出力でバックアップが完了したので、復元してみましょう。 postgresql-11サービスを停止します。
$ service postgresql-11 stop
Redirecting to /bin/systemctl stop postgresql-11.serviceそして、datadirを空のままにします。
$ rm -rf /var/lib/pgsql/11/data/*次に、次のコマンドを実行します。
$ pgbackrest --stanza=testing --log-level-stderr=info restore
INFO: restore command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
INFO: restore backup set 20190429-215508F
INFO: restore file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: write /var/lib/pgsql/11/data/recovery.conf
INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
INFO: restore command end: completed successfully (10819ms)次に、postgresql-11サービスを開始します。
$ service postgresql-11 stopこれで、データベースが稼働しました。
$ psql -U app_user world
world=> select * from city limit 5;
id | name | countrycode | district | population
----+----------------+-------------+---------------+------------
1 | Kabul | AFG | Kabol | 1780000
2 | Qandahar | AFG | Qandahar | 237500
3 | Herat | AFG | Herat | 186800
4 | Mazar-e-Sharif | AFG | Balkh | 127800
5 | Amsterdam | NLD | Noord-Holland | 731200
(5 rows)それでは、差分バックアップを作成する方法を見てみましょう。
$ pgbackrest --stanza=testing --type=diff --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=diff
WARN: option repo1-retention-full is not set, the repository may run out of space
HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: last backup label = 20190429-215508F, version = 2.13
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 21:22:58": backup begins after the next regular checkpoint completes
INFO: backup start archive = 00000002000000000000000B, lsn = 0/B000028
WARN: a timeline switch has occurred since the last backup, enabling delta checksum
INFO: backup file /var/lib/pgsql/11/data/base/16429/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/16429/2608 (448KB, 8%) checksum 53bd7995dc4d29226b1ad645995405e0a96a4a7b
. . .
INFO: diff backup size = 40.1MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 00000002000000000000000B, lsn = 0/B000130
INFO: new backup label = 20190429-215508F_20190430-212258D
INFO: backup command end: completed successfully (23982ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (14ms)より複雑なバックアップについては、pgBackRestユーザーガイドに従うことができます。
前述したように、コマンドラインまたは構成ファイルを使用してバックアップを管理できます。
ClusterControlでpgBackRestを使用する方法
1.7.2バージョン以降、ClusterControlはPostgreSQLおよびTimescaleDBデータベースをバックアップするためのpgBackRestのサポートを追加したので、ClusterControlからどのように使用できるかを見てみましょう。
バックアップの作成
このタスクでは、ClusterControl->[クラスター]->[バックアップ]->[バックアップの作成]を選択します。
新しいバックアップを作成するか、スケジュールされたバックアップを構成できます。この例では、単一のバックアップを即座に作成します。
バックアップを取得するサーバーとバックアップを保存する場所の1つの方法を選択する必要があります。対応するボタンを有効にすることで、バックアップをクラウド（AWS、Google、またはAzure）にアップロードすることもできます。
この場合、最初の完全バックアップを取るためにpgbackrestfullメソッドを選択します。このオプションを選択すると、次の赤いメモが表示されます：
「pgBackRestバックアップを最初に作成するときに、ClusterControlはノードを再構成し（pgBackRestをデプロイして構成します）、その後、dbノードを最初に再起動する必要があります。」
したがって、最初のバックアップの試行ではそれを考慮に入れてください。
次に、バックアップの圧縮の使用と圧縮レベルを指定します。
バックアップセクションでは、バックアップの進行状況と、方法、サイズ、場所などの情報を確認できます。
増分バックアップの差分を作成する手順は同じです。バックアップの作成時に必要な方法を選択するだけです。
バックアップの復元
バックアップが完了したら、ClusterControlを使用してバックアップを復元できます。このため、バックアップセクション（ClusterControl-> Select Cluster-> Backup）で、[Restore Backup]を選択するか、復元するバックアップを直接[Restore]することができます。
バックアップを復元するには、3つのオプションがあります。既存のデータベースノードでバックアップを復元したり、スタンドアロンホストでバックアップを復元して検証したり、バックアップから新しいクラスターを作成したりできます。
[ノードで復元]オプションを選択した場合は、マスターノードを指定する必要があります。これは、マスターノードがクラスター内で書き込み可能な唯一のノードであるためです。
ClusterControlの[アクティビティ]セクションから復元の進行状況を監視できます。
自動バックアップ検証
復元できない場合、バックアップはバックアップではありません。バックアップの検証は、通常、多くの人に無視されていることです。 ClusterControlがPostgreSQLおよびTimescaleDBバックアップの検証を自動化し、予期しない事態を回避するのにどのように役立つかを見てみましょう。
ClusterControlで、クラスターを選択して[バックアップ]セクションに移動し、[バックアップの作成]を選択します。
自動検証バックアップ機能は、スケジュールされたバックアップで使用できます。それでは、「バックアップのスケジュール」オプションを選択しましょう。
バックアップをスケジュールするときは、方法やストレージなどの一般的なオプションを選択するだけでなく、スケジュール/頻度も指定する必要があります。
次のステップでは、バックアップを圧縮して「バックアップの確認」機能を有効にします。
この機能を使用するには、クラスターの一部ではない専用のホスト（またはVM）が必要です。
ClusterControlはソフトウェアをインストールし、このホストにバックアップを復元します。復元後、ClusterControlバックアップセクションに確認アイコンが表示されます。
推奨事項
バックアップを作成するときに考慮に入れることができるいくつかのヒントもあります：
- バックアップをリモートの場所に保存する：データベースサーバーにバックアップを保存しないでください。サーバーに障害が発生した場合、データベースとバックアップが同時に失われる可能性があります。
- データベースサーバーに最新のバックアップのコピーを保持します。これは、リカバリを高速化するのに役立つ可能性があります。
- 増分/差分バックアップを使用する：バックアップのリカバリ時間とディスク容量の使用量を削減します。
- WALのバックアップ：最後のバックアップからデータベースを復元する必要がある場合、データベースを復元するだけでは、バックアップが作成されてから復元時までの変更は失われますが、WALがある場合は適用できます変更が加えられ、PITRを使用できるようになりました。
- 論理バックアップと物理バックアップの両方を使用する：さまざまな理由で両方が必要です。たとえば、データベース/テーブルを1つだけ復元する場合は、物理バックアップは必要ありません。論理バックアップのみが必要です。サーバー全体を復元するよりもさらに高速です。
- スタンバイノードからバックアップを作成する（可能な場合）：プライマリノードに余分な負荷がかからないようにするには、スタンバイサーバーからバックアップを作成することをお勧めします。
- バックアップのテスト：バックアップが実行されたことを確認するだけでは、バックアップが機能していることを確認できません。スタンドアロンサーバーに復元してテストし、障害が発生した場合の予期しない事態を回避する必要があります。
結論
ご覧のとおり、pgBackRestはバックアップ戦略を改善するための優れたオプションです。データを保護するのに役立ち、障害が発生した場合のダウンタイムを減らすことでRTOに到達するのに役立つ可能性があります。増分バックアップは、バックアッププロセスに使用される時間とストレージスペースの量を減らすのに役立ちます。 ClusterControlは、PostgreSQLおよびTimescaleDBデータベースのバックアッププロセスを自動化し、障害が発生した場合に数回クリックするだけで復元するのに役立ちます。