よくある質問
はじめに
よくある質問では、ユーザーガイド、構成リファレンス、コマンドリファレンスで説明されている場合も、されていない場合もある個別の疑問について、詳しく説明します。ここで問題に関する情報が見つからない場合は、pgBackRestのGitHubのIssue一覧 も有用な情報源です。
「could not find WAL segment」エラーが発生した場合はどうすればよいですか。
このエラーはさまざまな問題によって発生する可能性があります。たとえば、次のような原因が考えられます。
archive_commandの設定ミス- pgBackRest構成ファイルの設定ミス
- ネットワークまたは権限の問題
- サードパーティー製品（S3、Swift、Minioなど）の設定の問題
- アーカイブ待ちのWALが大量にキューにたまっている
次の確認を推奨します。
- PostgreSQLの
archive_commandを確認する - 各ホストのpgBackRest構成設定を確認する（たとえば、リポジトリホストに
pg*の設定、pgホストにrepo*の設定が指定されているか） --archive-timeoutをpgBackRest構成ファイル内の値（またはデフォルト値）より大きくしてcheckコマンドを実行し、WALキューを処理し終えるまでにより長い時間が必要かどうかを確認する。システムで大量のWALを生成している場合は、非同期アーカイブ の構成を検討する
バックアップセットを手動で削除するにはどうすればよいですか。
コマンドリファレンス：Expire
で説明しているとおり、--setオプションを使用してフルバックアップセットを期限切れとして削除できます。
コマンドごとにオプションを個別に設定するにはどうすればよいですか。
pgBackRestでは、構成ファイル内でコマンドごとにオプションを個別に設定できます。クラスターのstanzaの構成 で、この機能とオプションの優先順位を詳しく説明しています。
たとえば、コマンドごとにprocess-maxオプションを最適化できます。
S3バケット名にドット（ピリオド）を使用できますか。
RFC-2818では、ワイルドカードをドット（.）に一致させることを認めていないため、S3バケット名にドットを含めてはなりません。S3バケット名にドットが含まれると、「unable to find hostname ‘my.backup.bucket.s3.amazonaws.com’ in certificate common name or subject alternative names」などのエラーが発生します。
例外はrepo-s3-uri-style=pathです。これは、バケットをホストではなくURIの先頭に付加します。バケットがホスト名の一部ではないため、証明書はエンドポイントのみと照合され、バケット名内のドットは問題になりません。ただし、すべてのS3互換オブジェクトストアがパス形式のURIをサポートしているわけではありません。
以前のバージョンのpgBackRestのパッケージはどこにありますか。
apt.postgresql.org リポジトリでは、以前のバージョンのアーカイブ を管理しています。Debianでも、すべてのテストビルドのスナップショット を管理しています。
backup-standby=yでスタンバイデータベースが停止していると、バックアップが失敗するのはなぜですか。
スタンバイからのバックアップを構成する主な目的は、プライマリーの負荷を減らすことです。そのため、スタンバイが停止したときにバックアップをプライマリーへ切り替えると、多くの場合、その目的を果たせなくなります。システムですでに障害が発生している状況で、プライマリーにさらに負荷をかけることは推奨しません。比較的新しいバックアップがあれば、バックアップ取得は緊急の作業ではありません。重要なのは、WALのアーカイブを遅れずに続けることです。システムが再び安定してからバックアップを取得する時間は十分にあります。
どうしてもバックアップが必要であれば、スタンバイを増やすか、backup-standbyを削除することが解決策になります。コマンドラインで--no-backup-standbyを指定すれば上書きできるため、一度だけのバックアップのために構成を変更する必要はありません。
リポジトリはスタンバイホストに配置すべきですか。
いいえ。プライマリーとスタンバイのデータベースを構成する場合、フェイルオーバーをシームレスに処理できるように、pgBackRestの構成ファイルは対称にすることを推奨します。そうでなければ、フェイルオーバー時に構成を変更する必要があり、さらに問題が生じる可能性もあります。
詳しくは、ユーザーガイドの専用リポジトリホスト のセクションを参照してください。
時刻を指定したポイントインタイムリカバリーが動作しないように見えるのはなぜですか。
時刻を指定したポイントインタイムリカバリーで最もよくある間違いは、目標時刻より前のバックアップセットを選び忘れることです。--setオプションを指定していない場合、pgBackRestは--target=で指定した時刻に向けて再生できるバックアップを見つけようとします。バックアップセットが見つからなければ、デフォルトで最新のバックアップをリストアします。ただし、最新のバックアップが目標時刻より後の場合、PostgreSQLは--target=を有効なものとみなさず無視するため、利用可能な最新時刻までWALリカバリーが進みます。
--setオプションを使用するには、infoコマンドを実行し、終了タイムスタンプが目標時刻より前のバックアップを見つけてバックアップセットを選択します。リストアを実行するときに、--set=BACKUP_LABELオプションを指定します。BACKUP_LABELは選択したバックアップセットです。
詳しくは、ユーザーガイドのポイントインタイムリカバリー のセクションを参照してください。
WALアーカイブの接尾辞は何を意味しますか。
接尾辞は、ファイルの整合性を検証するためのSHA1チェックサムです。省略する方法はありません。
バックアップの種類（フル、差分、増分）によってリストアにかかる時間は長くなりますか。
どの種類のバックアップも、リストアに必要な時間は同じです。リストアではバックアップマニフェストに基づいてファイルを取得します。増分バックアップや差分バックアップの場合、マニフェストが以前のバックアップ内のファイルを参照することがあります。バックアップの種類によって、バックアップの作成にかかる時間には差が生じることがありますが、ディスクI/O、ネットワークI/Oなどが同じであれば、リストア時間を決めるのはデータベースのサイズです。
ネットワークから隔離された環境で使用するために、バックアップをエクスポートするにはどうすればよいですか。
pgBackRestは、バックアップやWALアーカイブの保存だけでなく、圧縮、暗号化、ファイルのバンドル化といった機能に必要な重要なメタデータの維持にもリポジトリを使用します。このため、非常に限定的で厳しい条件を満たさない限り、バックアップとWALファイルの一部を単純にコピーするだけでは、通常は動作しません。
ただし、データベースを単独で利用できる形でエクスポートし、USBなどで転送することが目的であれば、回避策があります。--archive-copy
オプションを有効にしてバックアップを作成し、必要なWALセグメントがバックアップとともに保存されるようにします。その後、--type=none
--pg1-path=/your/target/pathを使用してリストアします。これにより、必要なWALファイルがすべてpg_walに配置された、リストア済みのPostgreSQLデータディレクトリが生成されます。これはpg_basebackupで作成されるものと似ています。
このディレクトリを別のシステムにコピーすれば、PostgreSQLはpgBackRestリポジトリにアクセスせずにリカバリーできるはずです。
このバックアップのリカバリーではタイムラインの切り替えが発生しないため、このクラスターはエクスポート元のリポジトリにWALを送信すべきではないことに注意してください。新しいクラスターがネットワークから隔離された環境にある場合、これは問題にならないはずです。