Heroku PGBackups
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2021年08月10日(火)
Table of Contents
データのバックアップは、障害発生時の復旧だけでなく、テスト、ステージング環境の設定、データの移行時にも、あらゆるアプリケーションにとって重要です。 すべてのプロフェッショナルプランの 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 プランから本番プランにデータベースをアップグレードすると、スケジュールは消滅します。
新しいデータベースにバックアップを復元しても、元のデータベースのスケジュールは復元されないため、新しいスケジュールを作成する必要があります。
フォロワーの切り替えを使用して 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
を使用して作成されるすべてのバックアップは、データベースのある場所にかかわらず米国内で保管されます。