Heroku PGBackups

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2022年03月22日(火)

データのバックアップは、障害発生時の復旧だけでなく、テスト、ステージング環境の設定、データの移行時にも、あらゆるアプリケーションにとって重要です。 すべてのプロフェッショナルプランの Heroku Postgres データベースには、背後で実行される障害復旧のための継続的保護​の仕組みと、 直接操作できるオプションの「論理」バックアップがあります。

この記事では、手動バックアップやスケジュール設定されたバックアップの取り方、既存のバックアップの表示方法、バックアップの復元方法、2 つのデータベース間で直接データを転送する方法について説明します。

すべての本番用 Heroku Postgres プランでは、継続的保護​を使用してデータのバックアップと復元を行うことをお勧めします。

PGBackups は、負荷が中程度でサイズが 20 GB までのデータベースを対象としています。大規模な (または負荷が高い) データベース、または大量のスキーマや大きなオブジェクトが含まれたデータベースでは、バックアッププロセスがタイムアウトになるまでに論理バックアップを取れない可能性があります。詳細は、「論理バックアップのパフォーマンスへの影響​」を参照してください。

バックアップを作成する

デフォルトでは、pg:backups​ は、DATABASE_URL​ 環境設定で指定されたプライマリデータベースに対して動作します。

$ heroku pg:backups:capture --app sushi
Hit Ctrl-C at any time to stop watching progress; the backup will
continue running. Stop a running backup with heroku pg:backups:cancel.

HEROKU_POSTGRESQL_BLACK (DATABASE_URL)  ----backup--->  b251

Running... done

アプリケーションに複数のデータベースがある場合は、データベース名を指定して、どちらのバックアップを作成するかを選択できます。

$ heroku pg:backups:capture HEROKU_POSTGRESQL_PINK
Hit Ctrl-C at any time to stop watching progress; the backup will
continue running. Stop a running backup with heroku pg:backups:cancel.

HEROKU_POSTGRESQL_PINK  ----backup--->  b252

Running... done

--verbose​ フラグを使用すると、バックアップの進行中にログを表示できます。 何らかの理由でバックアップを停止する必要がある場合は、cancel​ コマンドを使用します。

$ heroku pg:backups:cancel

Canceled backup b252

手動バックアップの保持制限

保持できる手動バックアップの件数には制限があります。保持できる件数は、ご利用のデータベースプランに基づきます。

プラン 保持されるバックアップ件数
Hobby-Dev 2
Hobby-Basic 5
Standard-* 25
Premium-* 50
Enterprise​ 50

上記の制限に達し、さらにバックアップを作成する必要がある場合は、capture コマンドによってもっとも古い手動バックアップの期限が自動的に切れ、その後、新しい手動バックアップが作成されます。

バックアップを取ると、バックアップの進行中はデータベースにかかる負荷が増えます。アプリケーションに及ぶ影響は、データベースのサイズとアプリの性質によって変わります。マスターでバックアップを実行すると影響が大きい場合は、フォロワーのバックアップを取ることを検討してください。

バックアップのスケジュールを設定する

手動で起動するバックアップに加え、定期的な自動バックアップのスケジュールを設定することができます。スケジュール設定されたバックアップは、毎日、指定したデータベースに対して実行されます。

$ heroku pg:backups:schedule DATABASE_URL --at '02:00 America/Los_Angeles' --app sushi

--at​ オプションでは、24 時間形式を使用して、バックアップを取る時刻を指定します。 --at​ オプションには、完全な TZ 形式 (America/Los_Angeles) または省略形 (PST) のいずれかでタイムゾーンを指定できますが、完全な TZ 形式 を使用することをお勧めします。

バックアップのスケジュールを設定する場合、--at​ オプションは必須です。 Windows の場合は、--at​ の時刻とタイムゾーンを二重引用符 ("​) で囲んでください ("02:00 America/Los_Angeles"​ など)。

スケジュールバックアップが失敗しても、通知されません。スケジュール設定されたバックアップを手動で確認する必要があります。

バックアップスケジュールは、次の場合に失われることがあります。

  • データベースを Hobby 層から Production 層にアップグレードした。
  • バックアップが新しいデータベースに復元された。
  • フォロワーの切り替え​を使用して Heroku Postgres プランを更新した。元のデータベースのスケジュールは元のデータベースに関連付けられたままになるため、プロモートされたデータベースのスケジュールが存在しない場合は、新しいスケジュールを作成する必要があります。

定期バックアップを停止するには、unschedule​ を使用します。

$ heroku pg:backups:unschedule DATABASE_URL --app sushi

アプリの現在のスケジュールを表示するには、次のコマンドを使用します。

$ heroku pg:backups:schedules --app sushi
Current backup schedules:
RED: daily at 2:00 (America/Los_Angeles)

スケジュール設定されたバックアップの保持制限

スケジュール設定されたバックアップには、手動バックアップとは異なる保持ポリシーがあります。 このポリシーは、データベースプランにも基づきます。すべてのプランで、直近 7 日分の日次バックアップが保持されます。つまり、7 件 (直近 7 日間について 1 日 1 件) のバックアップが存在することになります。週次バックアップとは、7 日ごとに 1 件のバックアップのみ保存されることを意味します。月次バックアップとは、1 か月間に 1 件のバックアップのみ保存されることを意味します。現在の制限に基づき、たとえば Premium-0 では、12 件の月次バックアップ (直近 12 か月間で毎月 1 件) が保持されます。

プラン 保持される週次バックアップ件数 保持される月次バックアップ件数
Hobby-Dev 1 週間 0 か月
Hobby-Basic 1 週間 0 か月
Standard-* 4 週間 0 か月
Premium-* 8 週間 12 か月
Enterprise​ 8 週間 12 か月

プロビジョニング解除されたアドオンのすべてのバックアップは、プロビジョニング解除の 30 日後にすべて削除されます。プロビジョニング解除されたデータベースのバックアップを保持する必要がある場合は、バックアップをダウンロード​し、外部データストレージサービスに保存することをお勧めします。

バックアップをダウンロードする

pg:backups:url​ コマンドで、公開バックアップ URL を作成できます。バックアップ ID なしでこのコマンドを指定すると、最新の使用可能なバックアップ URL が返されます。この URL は、Heroku Postgres 外にデータを書き出す場合に便利です。

$ heroku pg:backups:url b001 --app sushi
The following URL will expire at 2015-04-07 18:35:50 +0000:
"http://s3.amazonaws.com/xkpgbackups/app1234567@heroku.com/b004.dump?AWSAccessKeyId=ABCD1234&Expires=1289261668&Signature=3mMBeKISewgEUDT%2FL5mRz4EYS4M%3D"

公開 URL ではありますが、推測は困難です。60 分後に期限が切れます。

pg:backups:url​ コマンドでは、URL が期限切れになる時間が URL と共に出力されます。 URL をほかのコマンドに渡す場合は、pg:backups:url​ で期限情報が出力に追加されないようにして、後続のコマンドに URL だけが渡されるようにします。 たとえば、追加情報なしで URL の一覧だけをターミナルに表示する場合は、次のようにします。

$ heroku pg:backups:url --app sushi | cat
http://s3.amazonaws.com/xkpgbackups/app1234567@heroku.com/b004.dump?AWSAccessKeyId=ABCD1234&Expires=1289261668&Signature=3mMBeKISewgEUDT%2FL5mRz4EYS4M%3D

コマンドライン経由でバックアップをダウンロードするには、download​ コマンドを使用します。

$ heroku pg:backups:download

PGBackups での Heroku Postgres データベースの読み込みと書き出しについての詳細は、Heroku のドキュメント​を参照してください。

バックアップの状態を確認する

バックアップの一覧を表示するには、次のコマンドを実行します。

$ heroku pg:backups --app sushi
=== Backups
ID    Backup Time                Status                              Size    Database
----  -------------------------  ----------------------------------  ------  --------
b013  2015-03-18 19:03:16 +0000  Running                                     IVORY
b011  2015-02-18 17:55:38 +0000  Finished 2015-02-18 17:55:39 +0000  1.9GB   IVORY
b010  2015-02-17 19:14:43 +0000  Finished 2015-02-17 19:14:48 +0000  1.9GB   IVORY
b004  2015-02-11 19:00:55 +0000  Finished 2015-02-17 19:14:48 +0000  1.9GB   IVORY

==== Restores
ID    Restore Time               Status                              Size    Database
----  -------------------------  ----------------------------------  ------  --------
r002  2015-03-16 17:33:19 +0000  Finished 2015-03-16 17:33:19 +0000  1.9GB   IVORY
r001  2015-03-15 12:13:44 +0000  Failed 2015-03-15 12:13:47 +0000    1.7GB   IVORY

特定のバックアップに関する詳細情報を表示するには、info コマンドを使用します。

$ heroku pg:backups:info b017 --app sushi
=== Backup info: b017
Database: HEROKU_POSTGRESQL_IVORY
Started:  2013-06-24 17:11.28 UTC
Status:   Running
Type:     Manual
Size:     1.2GB
Schema:   0bff3ac

オプションの --verbose​ フラグを使用して、問題となっているバックアップのログを表示することもできます。バックアップがまだ実行中の場合は、バックアップが終了するまで、または CTRL+C​ を入力してコマンドをキャンセルするまで、進行中のログが出力されます。

PGBackups では、圧縮バイナリ形式​でバックアップが保存され、インデックス自体ではなく、インデックスを再作成するためのコマンドがバックアップに格納されます。その結果、バックアップのサイズは、pg:info​ で返されるディスク上の現在のデータベースのサイズより小さくなります。

バックアップを削除する

古くなったバックアップを削除したり、新しいバックアップ用の空き領域を確保したりするために、手動でバックアップを削除できます。バックアップ ID を使用して、削除するバックアップを指定します。

$ heroku pg:backups:delete b101 --app foo
Deleting b101... done

バックアップを復元する

バックアップを復元するには、restore コマンドを使用します。

$ heroku pg:backups:restore b101 DATABASE_URL --app sushi

このコマンドにより、バックアップ ID b101​ が、アプリ sushi​ で、指定されたデータベース URL に復元されます。注意: バックアップ ID とターゲットデータベースを省略して、最新のバックアップを DATABASE_URL​ に復元することができます。そうでない場合、バックアップ ID とターゲットデータベースの両方を指定する必要があります。

別のアプリのバックアップから復元することもできます (sushi アプリから sushi-staging アプリへ)。

$ heroku pg:backups:restore sushi::b101 DATABASE_URL --app sushi-staging

公開 URL から復元することもできます。

$ heroku pg:backups:restore 'https://s3.amazonaws.com/me/items/mydb.dump' DATABASE_URL -a sushi

転送中のデータを確実に暗号化するために、必ず HTTPS URL を使用してください。HTTP 経由の復元はサポートされていません。

時間の経過とともに、テーブルの肥大化​や未使用のインデックスデータによって、ディスク上でデータベースが大きくなります。その結果、バックアップを新しいデータベースに復元すると、ほとんどの場合、pg:info​ で報告される全体ディスクサイズが減少します。

前回の pgbackups​ コマンドとは異なり、既存のデータベースに部分的なバックアップを復元することはできません。pg:backups:restore​ を実行すると、バックアップの復元前に、復元先のデータベースからすべてのデータが削除されます​。

データベース間の直接コピー

pg:backups では、バックアップと復元に加え、データベース間で直接データを転送することもできます。

このような転送を実行するには、次のコマンドを実行します。

$ heroku pg:copy COBALT GREEN --app sushi

このコマンドにより、sushi​ アプリ内の COBALT​ データベースから GREEN​ データベースにすべてのデータがコピーされます。

別のアプリのデータベースから直接転送することもできます。

$ heroku pg:copy sushi::ORANGE GREEN --app sushi-staging

このコマンドにより、sushi​ アプリの ORANGE​ データベースから sushi-staging​ の GREEN​ データベースにデータがコピーされます。この方法を使用して、本番データをテストのためにステージングアプリにコピーすることができます。

これらのコマンドではデータベースを識別するために短縮名が使用されています。たとえば、COBALT​ は heroku addons --app sushi​ で出力される HEROKU_POSTGRESQL_COBALT​ という名前のデータベースを指しています。作成する最初のデータベースは、デフォルトで DATABASE​ という名前になります。追加のデータベースには、HEROKU_POSTGRESQL_COBALT​ などの色の名前が付きます。DATABASE​ や COBALT​ などを使用して、Heroku Postgres CLI コマンドでデータベースを選択することができます。

視認性

Heroku Postgres では、バックアップを取るために、ご使用の資格情報を使ってデータベースに接続する必要があります。この接続は、ご利用のプランの接続制限の件数に含まれます。ターミナルから次のコマンドを実行すると、Heroku Postgres によって行われた接続を識別できます。

$ heroku pg:psql -c "select * from pg_stat_activity where application_name = 'Heroku Postgres Backups'"

データの所在

pg:backups​ を使用して作成されるすべてのバックアップは、データベースのある場所にかかわらず米国内で保管されます​。