Barmanリリースノート

© Copyright EnterpriseDB UK Limited 2025 - 無断複写・転載を禁じます。

3.19.02026-05-20

重要な変更

• クラウドストレージからのバックアップ復元のサポートを追加します

  Barmanは、クラウドオブジェクトストレージに保存されている場合、 backup_method = local-to-cloud または backup_method = postgres で取得されたバックアップを復元できるようになりました。

  標準の barman restore コマンドを使用して、このようなバックアップをリストアできます。

  WALリストアの場合、リカバリ中にクラウドストレージからWALファイルを直接取得するための新しい barman cloud-wal-restore コマンドが導入されました。このコマンドは、PostgreSQLの restore_command として使用でき、パフォーマンスの向上のための並列取得をサポートしています。

  また、サーバーがクラウドストレージを使用するように wals_directory が構成されている場合、リストア操作に常に get-wal が必要になるようになりました。 --no-get-wal が指定されている場合、または get-wal が recovery_options にない場合、 Barmanは自動的に get-wal を有効にし、警告を発行して、リストアを中断せずに続行できるようにします。

  これにより、クラウドバックアップのライフサイクルが完了し、完全にクラウドでのシームレスなバックアップとリカバリーのワークフローが可能になります。

  参考文献 BAR-929。

• バックアップをtarballにエクスポートするための新しいbarman allow-backupコマンドを追加

  バックアップをtarball形式にエクスポートする新しい barman export-backup コマンドを導入しました。このコマンドは、サーバー名、バックアップID、および宛先ディレクトリを引数として受け取り、バックアップデータを含むtarボールを作成します。これにより、バックアップを共有またはアーカイブする簡単な方法を提供します。

  参考文献 BAR-1180。

• tarballからバックアップをインポートするための barman import-backup コマンドを追加します

  tarball形式からバックアップをインポートする新しい barman import-backup コマンドを導入しました。このコマンドは、サーバー名とtarballパスを引数として取り、以前にエクスポートしたバックアップをBarmanカタログに登録し戻す方法を提供します。

  参考文献 BAR-1223。

マイナー変更

• GOOGLE_CLOUD_UNIVERSE_DOMAIN環境変数を介して代替GCPユニバースをサポート

  Barmanは、 GOOGLE_CLOUD_UNIVERSE_DOMAIN 環境変数を読み取ることにより、代替GCPユニバースS3NS / T-Systemsなどをサポートするようになりました。設定すると、値は client_options としてGCSストレージクライアントに渡され、 barman-cloud-* コマンドが非標準のGCPエンドポイントに対して動作できます。この機能は、コミュニティメンバー@mgarsteckiによって寄稿されました。

  参考文献 BAR-1017。

• barman-cloud-wal-restore での並列WALリストアのサポートを追加

  並列処理のサポートが barman-cloud-wal-restore コマンドに追加され、ユーザーはWALのリカバリー中に並列してダウンロードするWALの数を指定できます。この機能強化により、複数のWALファイルを同時にプリフェッチすることにより、WAL復元の全体的なパフォーマンスが向上します。詳細については、 barman-cloud-wal-restore のドキュメントを確認してください。

  参考文献 BAR-1253。

• 削除前にS3オブジェクトロックをチェックするためのaws_check_object_lock構成オプションを追加

  新しい aws_check_object_lock 構成オプションを導入しました。有効にすると、 BarmanはS3ストレージからベースバックアップファイルを削除する前にS3オブジェクトロックをチェックします。オブジェクトがロックされている場合、削除は中止されます。これにより、ロックされたオブジェクトのBarmanの動作が barman-cloud-delete に調整されます。 S3ストレージにのみ適用されます。非S3クラウドプロバイダーでこのオプションが有効になっている場合、警告がログに記録されます。

  参考文献 BAR-1113。

• 進行中のクラウドバックアップをバックアップカタログで可視化する

  進行中のクラウドバックアップが barman-cloud-backup-list にすぐに表示され、アーカイブステータス列に STARTED が表示され、空の終了時間が表示されます。以前は、バックアップは正常に完了した場合にのみ表示されます。 barman-cloud-backup-delete 、 barman-cloud-restore 、および last / latest / first / oldest ショートカットはすべて、それぞれ冗長数、自動復元選択、およびショートカットの解決から除外することにより、進行中のバックアップを安全に扱います。

  参考文献 BAR-1235。

• 実行時依存関係としてのsetuptoolsを削除

  Barmanのランタイム依存関係としてSetuptoolsは必要ありません。 Setuptoolsは、以前にPython 3.12+互換性の非推奨のdistutilsモジュールを提供するために含まれていましたが、別の実装に置き換えられました。 Setuptoolsは、パッケージ化の目的でビルド時に利用可能なままです。

  参考文献 BAR-1170。

• オプトイン.partial WALファイルコピーのためのバーマンリストアに-partial-walフラグを追加します

  新しい --partial-wal フラグが barman restore --no-get-wal に追加されました。設定すると、 Barmanは .partial WALファイルをリカバリーに含め、 .partial サフィックスを削除して、PostgreSQLが再生中にそれらを見つけられるようにします。 2つのソースがサポートされています。

  • ストリーミングWALディレクトリ 復元時に pg_receivewal によって書き込まれている進行中のセグメント。これを含めると、最後に完了したWALセグメント以降に書き込まれたトランザクションがリカバリ中に利用可能になるため、RPOが削減されます。

  • WALアーカイブ wals/ .partial サフィックスでアーカイブされたセグメント。 スタンバイが昇格し、PostgreSQLが進行中のセグメントで archive_command を呼び出したとき。圧縮および暗号化されたファイルは透過的に処理されます。

  --get-wal を使用する場合、 .partial ファイルは既に透過的に処理されているため、このフラグは効果がありません。

  参考文献 BAR-695。

• 並列WALアーカイブサポートを barman cloud-wal-archive に追加します

  barman cloud-wal-archive は、 --parallel フラグと、対応する cloud_wal_archive_parallel 構成オプションをサポートするようになりました。これにより、アーカイブ中に追加のWALファイルの日和見的プリフェッチが有効になります。 --parallel N が設定されている場合N > 1、プライマリWALが正常にアーカイブされた後、 pg_wal/archive_status で準備ができている最大N-1個の追加WALファイルが識別され、バックグラウンドワーカープロセスで同時にアップロードされます。これにより、WAL生成が多い期間にWALアーカイブのバックログを大幅に削減できます。 WALファイルが以前の呼び出しによって既にアップロードされている場合、そのWALの後続の archive_command 呼び出しはそれを検出し、0ですぐに終了し、冗長なアップロードを回避します。

  参考文献 BAR-1101。

バグ修正

• クラウドストレージで更新されないバックアップメタデータを修正する

  注この修正は、 Barmanサーバー、つまりバックアップ先としてクラウドストレージを使用する backup_method = local-to-cloud または backup_method = postgres で構成されたサーバーのクラウド統合を対象としています。これは、 barman-cloud-* スクリプトbarman-cloud-backupなどの問題ではありません。

  バックアップメタデータbackup.infoファイルはクラウドストレージで更新されておらず、これにより、たとえば、クラウドのバックアップのステータスがローカルのものと比較して古くなりました。これは、クラウドからのメタデータが主な情報ソースである可能性がある復元フェーズで問題になる可能性があります。この問題は修正されました。

  参考文献 BAR-1227。

• 使用できない.partial WALファイルをコピーする barman restore --no-get-wal を修正

  barman restore --no-get-wal 、 .partial を実行すると、WALアーカイブに存在するWALファイルがリカバリ先にコピーされました。ただし、 Barmanによって生成された restore_command は、 .partial サフィックスを考慮していない barman_wal ディレクトリの cp を使用します。したがって、これらのファイルは、リカバリ中にPostgreSQLによって使用されることはありません。 Barmanは、デフォルトで .partial ファイルをスキップするようになりました。それらを明示的に含めるには、新しい --partial-wal フラグを使用します。

  参考文献 BAR-1265。

• PostgreSQL 12+の新しいタイムラインからWALをコピーしない --no-get-wal リストアを修正

  PostgreSQL 12以降、 recovery_target_timeline のデフォルトが current から latest に変更されました。 --no-get-wal モードでPITRオプションたとえば --target-time を使用して復元する場合、 Barmanはバックアップの元のタイムラインからWALファイルをコピーしているだけでした。これにより、復旧ターゲットが新しいタイムラインにある場合、リストアが失敗する可能性があります。

  Barmanは、デフォルトのPostgresリカバリ動作と一致する、PostgreSQL 12+でPITRを実行するときに、利用可能な最新までのすべてのタイムラインからWALファイルを正しくコピーするようになりました。

  参考文献 BAR-1054。

• 中間ファイルが削除されないに関する複数の警告を修正する

  WAL圧縮を使用する場合、 Barmanは、圧縮プロセス中にアーカイブディレクトリに中間ファイルを作成します。中間ファイルパスはリストに保存され、ファイルアーカイブの最後に削除されます。

  ただし、複数のファイルをバッチでアーカイブする場合、各ファイルが処理された後に中間ファイルのリストがクリアされなかったため、後のアーカイブで存在しないファイルを削除しようとし、以下のような警告が発生しました。

  WARNING: Could not remove intermediary file /home/gustavo/pg/streaming/0000000100000013000000FD: [Errno 2] No such file or directory: '/home/gustavo/pg/streaming/0000000100000013000000FD'
  

  このバグは、バージョン3.18、コミット5db8ca9bで導入されました。現在は修正され、このような警告は発生しないはずです。

  参考文献 BAR-1228、CP-59700。

3.18.02026-03-12

重要な変更

• クラウドストレージでのインクリメンタル バックアップのサポートを追加します

  クラウドストレージでのブロックレベルのインクリメンタルバックアップのサポートが追加され、ユーザーは変更されたデータをアップロードするだけでバックアップストレージを効率的に管理し、コストを削減できます。

  この新機能は、ネイティブのPostgresバックアップ pg_basebackup で取得したBarmanへの、およびBarmanからクラウドストレージへの動的ストリーミングに依存しています。Barmanホストに完全なバックアップを保存することなく、小さなステージング領域のみを使用します。ステージング領域の場所とサイズは、それぞれ新しい cloud_staging_directory および cloud_staging_max_size 構成オプションを介して構成できます。

  この機能を構成するには、 backup_method = postgres と basebackups_directory と wals_directory をクラウドストレージURL s3://my-bucket/barman などに設定します。

  構成例

  [myserver]
  backup_method = postgres
  basebackups_directory = s3://my-bucket/barman
  wals_directory = s3://my-bucket/barman
  cloud_staging_directory = /tmp/barman/cloud-staging
  cloud_staging_max_size = 30Gi
  

  クラウドストレージのバックアップ構造は、現在のbarman-cloud-/*スクリプトと同じパターンに従います。つまり、バックアップファイルは tar でアーカイブされ、サーバー名とバックアップID、たとえば my-bucket/barman/<server_name>/base/<backup_id>/... に基づいて名前付けられたディレクトリの下にあります。一方、WALファイルはサーバーディレクトリの下の wals サブディレクトリ、つまり my-bucket/barman/<server_name>/wals/... に保存されます。この意味で、 basebackups_directory および wals_directory は、クラウドストレージのバックアップパスとWALパスのプレフィックスとして機能します。これにより、既存のバックアップ管理実践との互換性が保証されます。

  重要な注意事項

  • これは実験的な機能であり、注意すべき制限がいくつかあります。詳細については、ドキュメントを参照してください。

  • この方法で作成されたバックアップの復元は、現在Barmanでは直接サポートされておらず、これを手動でまたはカスタムスクリプト/プロセスを介して実行するのはユーザーの責任です。このようなバックアップの復元は、将来のリリースで提供される予定です。

  • これは、バーマンクラウドエクスペリエンスを統合し、クラウドバックアップ操作を簡素化するための最初のステップであり、将来のリリースではより多くの機能と改善が追加されます。

  参考文献 BAR-928。

• local-to-cloud バックアップ方法を barman CLIに追加

  新しい local-to-cloud バックアップ方法を追加することにより、メインの barman CLIを介した直接クラウドバックアップのサポートを導入しました。以前は、クラウドバックアップは、スタンドアロンの barman-cloud-* スクリプトを介してのみ利用できました。

  この機能強化により、 backup_method = local-to-cloud と basebackups_directory s3://bucket/path などのクラウドストレージURLを使用して、バーマン構成ファイルにクラウドバックアップを直接構成できるようになりました。これは、すべてのバックアップ方法に統一インターフェイスを提供し、スタンドアロンの barman-cloud-* スクリプトを非推奨にするための最初のステップです。

  新しい CloudBackupExecutor は、既存のバーマンバックアップインフラストラクチャとシームレスに統合し、低レベルバックアップAPIを使用してPostgreSQLと連携し、バックアップをクラウドオブジェクトストレージに直接アップロードします。

  構成例

  [myserver]
  backup_method = local-to-cloud
  basebackups_directory = s3://my-bucket/barman/backups
  conninfo = host=postgres-host dbname=postgres
  

  これは、バーマンクラウドエクスペリエンスを統合し、クラウドバックアップ操作を簡素化するための最初のステップです。

  次の構成オプションは再利用またはBarman構成に追加されて、 barman-cloud スクリプトと機能パリティを提供します。

  • cloud_upload_min_chunk_size

  • aws_region

  • aws_read_timeout

  • aws_encryption

  • aws_sse_kms_key_id

  • bandwidth_limit

  • cloud_delete_batch_size

  • cloud_upload_max_archive_size

  参照BAR-1095、BAR-1116、BAR-1122、BAR-1109、BAR-1120、BAR-1121、BAR-1117、BAR-1112、BAR-1115。

• ローカルからクラウドへのWALアーカイブ用に`barmancloud-wal-archive'コマンドを追加

  'local-to-cloud'バックアップ方法を使用する場合に、PostgreSQL pg_wal ディレクトリからクラウドオブジェクトストレージへの直接WALファイルアーカイブを有効にする新しい barman cloud-wal-archive コマンドを導入しました。このコマンドは、 BarmanサーバーがPostgreSQLインスタンスと同じホストで実行されている場合、PostgreSQL archive_command として使用するように設計されています。

  クラウドオブジェクトストレージに送信されるWALファイルは、既存の compression および compression_level 構成オプションを使用して、アップロードする前に圧縮することもできます。圧縮されたWALファイルは、 barman-cloud-wal-archive で既に使用されている規則に従って、適切なファイル拡張子たとえば .gz 、 .lz4 で保存されます。

  次のインメモリ圧縮アルゴリズムがサポートされています。 gzip 、 bzip2 、 xz 、 snappy 、 zstd 、および lz4 。 pigz および custom は、外部プロセスに依存するため、クラウドWALストレージではサポートされていません。

  構成例

  [myserver]
  backup_method = local-to-cloud
  archiver = on
  wals_directory = s3://my-bucket/barman/wals
  compression = gzip
  compression_level = 6
  

  参照元 BAR-1098、BAR-1124

マイナー変更

• S3互換ストレージプロバイダーの --addressing-style オプションを追加

  AWS S3またはS3互換ストレージプロバイダーを使用する場合、barman-cloudコマンドで新しい --addressing-style オプションが利用できるようになりました。このオプションを使用すると、ユーザーはS3アドレススタイルを明示的に auto 、 virtual 、または path に設定できます。 boto3 は非S3エンドポイントのパススタイルのアドレス指定を自動的にデフォルトにするため、仮想ホストスタイルのアドレス指定を必要とするS3互換ストレージシステムを使用する場合に役立ちます。

  PR #1134でこの機能を報告および寄稿していただいた@ChandonPierreに感謝します。

  参考文献 BAR-1011

• クラウド操作のPython 3.14互換性サポートを追加

  クラウドバックアップ操作に影響を与える functools.partial の重大な変更を修正することにより、Python 3.14のサポートを追加しました。このバージョンでは、 functools.partial は、クラス属性として使用されたときに動作を変更するメソッド記述子になりました。この更新により、Python 3.14にアップグレードしてもBarmanクラウド操作がシームレスに動作し続けます。

  このパッチは、@pvbiesenによるオリジナルのアイデアに基づいています。彼は機能を提案し、PR #1143に貢献しました。同様の修正は、PR #1109で@mjlshenによって提案されました。

  参考文献 BAR-1012

• 圧縮を使用したバックアップのフックとしてbarman-cloud-backupを使用しないようにする

  圧縮して取得されたバックアップのフックとしての barman-cloud-backup の使用は、適切なメッセージでエラーアウトすることにより防止されるようになりました。

  この変更により、圧縮を含むバックアップが誤ってクラウドバックアップフックで使用されることがなくなります、そのような使用はこれまでサポートされていなかった。

  この動作は、警告ノートとともに文書化されています。

  参考文献 BAR-1015。

• BarmanクラウドのLZ4圧縮サポートを追加

  barman-cloud-backup コマンドでのLZ4圧縮のサポートを追加しました。 –lz4オプションを指定して、クラウドストレージにアップロードする前にLZ4圧縮を使用してバックアップファイルを圧縮できるようになりました。このオプションは他の圧縮オプション-gzip、-bzip2、-snappyと相互排他的であり、 lz4 Pythonライブラリをインストールする必要があります。

  この機能は、PR #1144で@vietcgiによって提案および実装されました。

  参考文献 BAR-1013。

• WarehousePGデータベースID構成の実験的なサポート

  WarehousePGの実験的なサポートの追加。これには、ユーザーがPostgreSQLバックアップ方法を使用するときにWarehousePGセグメントのデータベースIDを指定できる新しい構成オプション warehousepg_dbid が含まれます。この構成は、バックアップおよびリストア操作のためにWarehousePGとのより適切な統合を有効にすることを目的としています。

  archive_timeout がWarehousePGセグメントの pg_settings で公開されていないため、Postgresパラメーターの収集も向上しています。

  参考文献 BAR-1092。

• バーマンリカバリー操作のカスタム復元コマンドのサポートを追加します

  barman recover コマンドに新しい --restore-command オプションを追加しました。これにより、ユーザーはBarmanのデフォルトのrestoreコマンドをカスタムコマンドでオーバーライドできます。 Barmanがビルドしたデフォルトのrestoreコマンドは、ほとんどの場合に適していますが、このオプションを使用すると、セットアップで必要な場合に代替コマンドを指定できます。

  以前は、ユーザーは復旧後にPostgreSQLリカバリ構成ファイルを手動で編集してrestoreコマンドを変更する必要がありましたが、これはエラーが発生しやすく、追加の手動介入が必要でした。この新しいオプションを使用すると、ユーザーはコマンドラインを介してカスタム復元コマンドを直接指定できるようになりました。

  この機能強化は、@PaganMuffinによって#881で報告された問題のために適用されました。

  参考文献 BAR-201。

バグ修正

• 長時間実行されているWALアーカイブサービスのファイルハンドルリークを修正

  WALファイルをクラウドストレージにアップロードした後、ファイルハンドルが適切に閉じられない、クラウドWALアーカイブ機能のリソースリークを修正しました。この問題は、主に、複数のWALファイルを順番に処理する長期実行WALアーカイブサービスに影響を与える可能性があります。開いているファイルハンドルが蓄積すると、最終的に「Too many open files」エラーが発生し、それ以上のWALアーカイブ操作が妨げられる可能性があります。

  この修正により、圧縮が使用されるかどうかに関係なく、およびアップロード失敗が発生した場合でも、各アップロード操作が完了した直後にファイルハンドルが適切に閉じられるようになりました。これにより、クラウドプロバイダーへの継続的または高頻度のWALアーカイブを実行するサービスでのハンドルの枯渇を防ぎます。

  PR #1129でこの機能に貢献した@ethiebautgeorge-nasuniに感謝します。

  参考文献 BAR-973。

3.17.02026-01-07

重要な変更

• 非アクティブ/無効なサーバーでのクエリー、取得、および選択的な操作を有効にする

  複数のBarmanコマンドは、安全プロファイルに基づいて、非アクティブで無効になったサーバーで動作するようになりました。

  Query commands

  • list-backups 非アクティブ/無効なサーバーからバックアップを表示する

  • status 非アクティブ/無効になったサーバーのステータスを確認します

  • show-backup 非アクティブ/無効なサーバーからのバックアップの詳細を表示します

  • list-files 非アクティブ/無効なサーバー上のバックアップからファイルをリストする

  • verify-backup 非アクティブ/無効なサーバーでのバックアップを検証します

  Fetch commands

  • restore 非アクティブなサーバーからバックアップを復元する

  • get-wal 非アクティブなサーバーからWALファイルを取得します

  Modification commands

  • delete 非アクティブなサーバーからバックアップを削除します

  • config-switch 非アクティブ/無効なサーバーのスイッチ構成モデル

  この変更により、サーバーが手動で無効になっている非アクティブな場合、または構成に問題がある無効な場合でも、ユーザーはバックアップ情報を照会し、復元操作を実行できるため、運用の柔軟性が向上します。無効になったサーバーの異なる動作により、潜在的な構成の競合またはパスの問題があるサーバーでの操作に対する安全性が提供されます。

  参考文献 BAR-976。

• WALファイルのカスタム圧縮を非推奨にする

  custom 圧縮オプションとその関連構成オプション custom_compression_filter 、 custom_decompression_filter 、および custom_compression_magic は非推奨であり、将来のリリースでは削除されます。

  現在カスタム圧縮を使用しているユーザーは、 Barmanがサポートするビルトイン圧縮アルゴリズムのいずれかに移行することをお勧めします。

  カスタム圧縮機能は、特定の圧縮要件を持つユーザーに柔軟性を提供するように設計されましたが、任意の外部圧縮ツールとの互換性を維持することは、複雑でエラーが発生しやすいことがわかっています。ビルトイン圧縮オプションは、より良いパフォーマンス、信頼性、および保守性を提供します。

  カスタム圧縮を使用する既存の構成は、現在のリリースでも引き続き動作しますが、ユーザーは機能が削除される前に構成の移行を計画する必要があります。

  参考文献 BAR-993。

マイナー変更

• ファイル暗号化のチェック時に非UTF8出力を処理する

  barman-wal-restore または barman rebuild-xlogdb を実行してWALを復旧する場合、 Barmanは file コマンドを実行して、ファイルが暗号化されているかどうかを確認します。

  macOSシステム公式にサポートされていない場合、このコマンドは、その出力にUTF-8を使用してデコードできないバイトが含まれている場合、 UnicodeDecodeError 例外を発生させると報告されています。

  これを防ぐために、 Barmanはデコード不能なバイトを適切に処理し、プロセスを中断せずに続行できるようになりました。

  Github issue #1117

  参考文献 BAR-926。

• --recovery-option-port を barman restore コマンドに追加

  get-wal モードでリモート復元を実行する場合、 Barmanは barman-wal-restore を呼び出してWALを取得する restore_command を書き込みます。ただし、現在、作成された barman-wal-restore コマンドにカスタムポートを指定する方法はありません。

  この変更では、 --recovery-option-port フラグが barman restore コマンドに導入され、ユーザーはリモートリストア中に barman-wal-restore コマンドの --port オプションの値を指定できます。

  参考文献 BAR-943。

• barman-cloudでのバックアップの削除のためのS3オブジェクトロックのサポートを追加します

  barman-cloud-backup-delete は、AWS S3でバックアップを削除する前にオブジェクトロックのチェックをサポートするようになりました。この機能は、コンプライアンスまたはガバナンス保持ポリシーによって保護されたオブジェクトの削除を防止するのに役立ちます。

  新しい --check-object-lock オプションが追加され、削除前にオブジェクトロックの検証が有効になります。有効にすると、ベースバックアップのすべてのオブジェクトの削除操作は、これらのオブジェクトのいずれかがロックされている場合に中止されます。パフォーマンス上の理由から、ロックチェックはベースバックアップファイルに対してのみ実行されます。ベースバックアップが削除されると、対応するWALファイルは使用できなくなるためです。

  この機能は、削除するオブジェクトごとに追加のAPI呼び出しを必要とするため、削除操作にオーバーヘッドが追加されることに注意してください。この機能はAWS S3互換オブジェクトストアでのみ利用でき、正しく機能するには適切な権限が必要です。

  参考文献 BAR-946。

バグ修正

• バックアップ削除のための非準拠S3オブジェクトストアのカバレッジを拡大する

  この修正では、バックアップ削除の非準拠S3オブジェクトストアのカバレッジを拡大します。

  「content-MD5」を含むメッセージを返すエラーコードをキャッチできなかった場合に、返されるメッセージと一致していた式を削減しました。

  これにより、バックアップ削除の非準拠のS3オブジェクトストアのほぼすべてがカバーされると考えています

  参考文献 BAR-974。

• 同期していないパッシブノードを修正する

  Barman 3.16では、 barman diagnose コマンドの“config”キーから“name”フィールドが削除されました。パッシブノードを同期するときにも同じ「config」データが使用され、「name」フィールドの欠如が同期に失敗することがわかりました。

  この変更により、“name”フィールドが“config”キーに追加され、パッシブノードの同期が修正されます。

  GitHub issue #1125で報告されました。

  参考文献 BAR-971。

• デルタリストアが機能しないを修正

  デルタリストア機能は、 Barmanが復元を実行する前に宛先ディレクトリを削除している見落としにより、正しく機能していませんでした。この問題は、特定の操作で宛先ディレクトリの削除を回避することにより修正されました。 GitHub issue #1139で報告されました。

  参考文献 BAR-1002。

• リストア中の「rmexecution failed」エラーを修正する

  バージョン3.15のリリース中に実装されたリファクタリングの結果、 Barmanは、バックアップファイルをコピーする前に復元操作の宛先ディレクトリの削除を開始しました。これは、ファイルが常にクリーンなディレクトリにコピーされるようにするためです。

  ただし、宛先ディレクトリがマウントポイント、またはユーザーが親に対する十分な権限を持っていないサブディレクトリである場合、ディレクトリの削除は失敗し、「rm実行に失敗しました」のようなエラーが発生します。

  この問題は、リストアの最終的な宛先でのPGDATAの宛先ディレクトリとテーブルスペースの削除を回避することにより修正されました。

  参考文献 BAR-975。

3.16.22025-11-04

バグ修正

• barman-cloudの削除回避策を改善して、エラーメッセージのコンテンツを検査する

  一部のS3互換ストレージは、削除操作中に「MissingContentMD5」の代わりに「InvalidRequest」エラーを結果ます。エラーコードのみに依存することはできないため、これにより、エラーメッセージテキストも検査してMissingContentMD5のような問題を検出し、適切なフォールバックを適用するようにロジックが更新されます。

  参考文献 BAR-947。

3.16.12025-10-14

重要な変更

• 自動バケット作成がbarman-cloud-check-wal-archiveに追加されました

  barman-cloud-check-wal-archive コマンドは、ターゲットバケットが構成済みのクラウドストレージAWS S3に存在するかどうかを確認し、存在しない場合は自動的に作成します。

  以前は、自動バケットの作成は barman-cloud-backup によって処理されていました。この変更により、この動作に依存するCloudNativePG CNPGオートメーションとの互換性が復元され、 Barman 3.16.0のリリース後に影響を受けました。

  CloudNativePGチームと協力して、私たちはこの機能を barman-cloud-check-wal-archive に再導入して、CNPGワークフローと内部テストのシームレスなオペレーションを保証しながら、通常のBarmanユーザーが意図した動作と簡単さを維持します。

  参考文献 BAR-931。

3.16.02025-10-02

重要な変更

• ローカルリストアの restore_command には、 sudo が含まれなくなりました

  ローカル復元に barman restore --get-wal を使用する場合つまり --remote-ssh-command なしで、生成された restore_command には sudo -u $USER プレフィックスが含まれません。これにより、ローカルに復元されたPostgresクラスターが barman restore 操作の終了までに既にファイルを所有している barman ユーザーによって実行される一般的な場合のプロセスが簡素化されます。

  Action Required: 復元されたクラスターを別のユーザーたとえば postgres として実行する予定がある場合は、適切な sudo -u postgres プレフィックスをリカバリ構成の restore_command に手動で追加し、ファイルの所有権が正しいことを確認する必要があります。

  参考文献 BAR-675。

• pygzip および pybzip2 圧縮オプションを非推奨にします

  pygzip および pybzip2 圧縮オプションは非推奨であり、将来のリリースでは削除される予定です。ユーザーは gzip および bzip2 オプションに移行する必要があります。これらはPythonの内部ライブラリを使用するようになりました。

  この変更は、パフォーマンスとコードの一貫性を向上させるために行われました。以前は、 gzip および bzip2 オプションは外部サブプロセスに依存していましたが、対応する py はネイティブPythonライブラリを使用していました。 gzip および bzip2 のコア圧縮ロジックは、Pythonのビルトインライブラリを使用するように更新され、 pygzip および pybzip2 オプションが冗長になっています。

  参考文献 BAR-878。

• delta-restoreフラグとリカバリオプションをバーマンリストアに追加

  barmanリストアの-delta-restoreフラグを導入し、デルタリストアモードを有効にします。このモードでは、宛先ディレクトリに既に存在する同一のデータを再利用してバックアップを復元します。これにより、復元時間とネットワークトラフィックが大幅に削減されます。

  この機能は、サーバー構成ファイルのdelta-restoreと呼ばれる新しいフィールドとしての`recovery_options'を介してサーバーごとに構成することもできます。

  参考文献 BAR-788。

• boto3 >=1.36に準拠していないオブジェクトストアのS3オブジェクト削除フォールバック

  一部の非準拠のS3互換オブジェクトストアで delete_objects() を使用する場合、ユーザーは MissingContentMD5 ClientError が発生する可能性があります。boto3 1.36の破壊的変更により、Botocoreが Content-MD5 ヘッダーを自動的に計算および設定しなくなりました。

  これに対処するために、 Barmanはフォールバックメカニズムを実装するようになりました。

  • delete_objects() を介した一括削除は、引き続き最初に試行されます。

  • delete_objects() が MissingContentMD5 で失敗した場合、 Barmanは自動的にフォールバックし、 Content-MD5 ヘッダーを必要としない delete_object() を使用してオブジェクトを個別に削除します。

  • 他のエラーは、以前と同様に例外を発生させます。

  この変更により、 Barmanは、ユーザー側で変更を必要とせずに非準拠オブジェクトストアとの互換性を維持できます。

  古いS3互換ストレージを使用するユーザーは、障害なしでバックアップクリーンアップの実行を継続できますが、新しいオブジェクトストアは影響を受けません。

  参考文献 BAR-909。

• クラウド接続チェックは、 -t / --test フラグを使用してのみ実行されます。

  以前は、 Barmanはほとんどのコマンドでクラウド接続とバケットの存在を常にテストし、接続に失敗した場合、またはバケットが存在しない場合にエラーを生成しました。 -t / --test フラグが指定された場合にのみ、両方のチェックが実行されるようになりました。唯一の例外は barman-cloud-check-wal-archive でしたが、これは引き続き接続とバケットの存在をチェックします。

  さらに、バケットは自動的に作成されなくなりました。Barmanは、ターゲットバケットが既に存在することを想定しているため、ユーザーの責任で事前にバケットをプロビジョニングします。

  リファレンス BAR-895、BAR-908、BAR-918。

マイナー変更

• barman restore コマンドに combine-mode オプションを追加

  --combine-mode オプションを barman restore コマンドに追加しました。これは、リストア中にインクリメンタルバックアップを組み合わせるときに pg_combinebackup のコピーモードを指定するために使用できます。使用可能なモードは copy 、 link 、 clone 、および copy-file-range であり、それぞれ pg_combinebackup オプション --copy 、 --link 、 --clone 、および --copy-file-range と同等です。同等の combine_mode 構成オプションは、構成ファイルで指定できます。

  この機能により、基になるファイルシステム機能に基づいて、復元プロセスのより大きな最適化が可能になります。

  参考文献 BAR-870。

• バーマン診断JSONのフィールドを再編成する

  バーマン診断JSONでは、実際の構成フィールドではない場合でも、サーバーの「config」セクションの下にいくつかのフィールドが表示されます。

  フィールド“barman_lock_directory”、“lock_directory_cleanup”、および“config_changes_queue”は、グローバル構成を表すため、“global”キーの下に再配置されました。サーバー名が既にキーとして使用されているため、“name”フィールドが削除されました。さらに、“msg_list”がサーバーの名前キーの下に保存されるようになりました。

  参考文献 BAR-134。

• --get-wal が True の場合、barman-wal-restoreコマンドに`-p JOBS'を追加します

  --get-wal または get_wal 構成オプションが True であり、 JOBS が -p フラグまたは parallel_jobs 構成オプションを介してユーザーが選択したジョブの数である場合、barman-wal-restoreコマンドに`-p JOBS'を追加します。

  参考文献 BAR-857。

• /barman show-backup/`コマンドは、バックアップの圧縮方法を表示するようになりました

  barman show-backup コマンドの出力が強化され、新しい Backup Compression フィールドが含まれます。圧縮を有効にしてバックアップが取得された場合、このフィールドには、使用された圧縮アルゴリズム zstd などが表示されます。これにより、バックアップの圧縮ステータスをすばやく確認することが簡単になります。

  参考文献 BAR-901。

バグ修正

• barman-wal-restoreの並列処理を修正します –Parallelオプション

  Barman 3.12.0で --keep-compression オプションを導入したときに barman-wal-restore にリグレッションがあり、 --parallel オプションが予想通りにプロセスを呼び出しません。この問題は修正されました。

  参考文献 BAR-865。

• staging_location が remote の場合、 PATH で pg_combinebackup が見つからない問題を修正

  staging_location が remote に設定されているリモートサーバーにインクリメンタルバックアップをリカバリーする場合、 Barmanはリモート PATH で pg_combinebackup が利用できるかどうかを確認します。ただし、以前の問題により、ローカルの PATH も誤ってチェックされ、 pg_combinebackup がローカルにインストールされていない場合にエラーが発生しました。この問題は、 pg_combinebackup が実際に実行されるサーバーでのみチェックが実行されるようにすることにより修正されました。

  参考文献 BAR-903。

3.15.02025-08-05

重要な変更

• 圧縮と暗号化を使用してインクリメンタル バックアップを取得できます

  以前は、 Barmanは、圧縮が有効になっている場合、または親バックアップが既に圧縮されている場合、インクリメンタルバックアップが実行されないようにしていました。 Barmanでの暗号化には圧縮が必要であるため、これは、暗号化では増分バックアップを取得できないことを意味しました。

  この制限は、このようなバックアップの復元の複雑さのために存在し、復号化、解凍、およびバックアップの組み合わせのための複数のステージングフェーズが関係します。

  重要なリファクタリングの努力の後、 Barmanは、圧縮および/または暗号化の両方を使用したインクリメンタルバックアップの取得を完全にサポートするようになりました。これにより、より柔軟なバックアップ戦略が可能になり、ユーザーは使用可能なすべての機能を制限なく利用できます。

  リファレンス BAR-764、BAR-801、BAR-841。

• local_staging_path および recovery_staging_path 構成オプションの非推奨

  local_staging_path および recovery_staging_path 構成オプションは非推奨であり、新しい staging_path および staging_location オプションを優先します。古いオプションは下位互換性のために引き続き機能しますが、ユーザーはより良い明確さと柔軟性を得るために新しい構成オプションに移行することをお勧めします。

  リファレンス BAR-571、BAR-801。

• ステージング領域構成の柔軟性と一貫性の向上

  圧縮、暗号化、またはインクリメンタルバックアップを復元するときは、 Barmanは、解凍または復号化されたファイルなどの中間ファイル、または結合されたインクリメンタルバックアップデータを処理するためのステージング領域が必要です。

  以前は、 Barmanには、シナリオごとに異なる構成オプションがありました。

  • インクリメンタル バックアップの場合、ステージング領域はBarman構成の local_staging_path を介して指定されました。これは、 Barmanホスト内のパスのみです。

  • 圧縮バックアップの場合、ステージング領域は recovery_staging_path を介して指定されました。これは、 Barmanホスト内のパスローカルリカバリの場合またはターゲットサーバー内のパス別のサーバーへのリモートリカバリの場合。

  • 暗号化されたバックアップの場合、ステージング領域はBarman構成の local_staging_path を介して指定されました。これは、 Barmanホスト内のパスのみです。暗号化には圧縮を有効にする必要があるため、暗号化されたバックアップを復元するとき、ユーザーは recovery_staging_path と local_staging_path の両方を指定する必要があることに注意してください。

  Barmanは、単一の統合されたより柔軟なステージングエリア構成を提供するようになりました。

  • 新しい staging_path 構成オプションを使用して、中間ファイルが保存されるステージング領域の絶対パスを指定できます。デフォルト値は /tmp です。

  • 新しい staging_location 構成オプションを使用して、ステージング領域がBarmanホスト local 上にあるか、リモートサーバー remote 上にあるかを指定できます。デフォルト値は local です。

  これは、ステージングパスの統合された構成を持つことに加えて、ユーザーがBarmanホストまたはリモートPostgresサーバーのいずれかにステージング領域を配置する場所をより柔軟に指定できることを意味します。

  ストレージの使用量も最適化されて、可能な限りリソースの消費量が削減されます。これには以下が含まれます

  • 中間ファイルが必要でなくなったらすぐに削除します。

  • 必要以外の場合、ステージング領域の使用を避けてください。 圧縮されたバックアップをローカルに復元する場合、ステージングは必要なく、バックアップは最終的な宛先に直接解凍されます。

  この変更により、構成が簡素化され、一貫性とリソースの使用率が向上し、エンドユーザーにとって復旧管理がより透明で予測可能になります。

  リファレンス BAR-764、BAR-765、BAR-801、BAR-841。

マイナー変更

• --staging-path および --staging-location を barman restore に追加

  --staging-path および --staging-location オプションを barman restore コマンドに追加して、ユーザーがリストアプロセス中にステージング領域のカスタムパスを指定できるようにします。 --staging-path は、 --staging-location がその場所、つまり local または remote を定義するときに使用される絶対パスです。 barman.conf には、それぞれ staging_path および staging_location として同等の構成オプションがあります。

  参考文献 BAR-570。

• オプション --if-not-exists を barman receive-wal --create-slot に追加

  新しい --if-not-exists フラグが barman receive-wal --create-slot コマンドに追加されました。これにより、既に作成されたレプリケーションスロットを作成しようとしたときにコマンドが失敗するのが防止され、スクリプトでの使用の信頼性が向上します。

  PRを作成し、 Barmanに貢献してくださった@crazybolillo antonio@zoftko.com別名@antonag32に感謝します。

  参考文献 BAR-527。

• バックアップメタデータで予期しないフィールドが見つかった場合、正常に失敗します。

  この更新では、 Barmanが現在のバージョンで不明なフィールドを含むバックアップメタデータを処理する方法を改善します。この状況は、 Barmanの新しいバージョンで作成されたバックアップを古いバージョンを使用して復元しようとしているときに発生する可能性があります。たとえば、新しいバージョンが暗号化に関するメタデータを追加し、古いバージョンがそのフィールドを認識しない場合。これは、この変更が関連する場合です。

  以前は、これにより役に立たない例外が発生していました。ここで、 Barmanは、バックアップが新しいバージョンで作成され、現在のバージョンと互換性がない可能性を説明する明確なメッセージを表示します。

  参考文献 BAR-763。

• 適切なクリーンアップのための孤立したバックアップの警告を改善しました

  孤立したバックアップの警告メッセージが改善され、ユーザーが不完全または手動で削除されたバックアップを完全にクリーンアップしやすくなりました。以前は、メッセージに backup.info ファイルの場所が記載されておらず、混乱を招いていました。更新されたメッセージは、 backup.info ファイルの場所を明確に示し、ユーザーが適切に削除できるようになりました。

  参考文献 BAR-793。

• クラウドコマンドのタグ処理を改善して解析エラーを修正

  barman-cloud-backup および barman-cloud-wal-archive の --tags コマンドラインオプションは、解析の信頼性を向上させ、標準のCLI実践と調整するために置き換えられました。以前のスペース区切り形式では、特に位置引数の前に配置された場合、解析エラーが発生する可能性がありました。

  コマンドは、複数の --tag フラグを、キーと値のペアごとに1つずつ受け入れるようになりました。

  Before: barman-cloud-backup ... --tags key1,val1 key2,val2

  After: barman-cloud-backup ... --tag key1,val1 --tag key2,val2

  --tags オプションは非推奨になりました。古い --tags 形式を使用する既存のスクリプトは引き続き動作しますが、ユーザーはスクリプトを新しい形式に更新することをお勧めします。この変更には下位互換性があり、重大な変更は導入されません。

  参考文献 BAR-441。

• barman show-backup出力の WAL Number ラベルを明確に

  barman show-backup 出力の誤解を招く WAL Number ラベルの名前を Number of WALs に変更します。

  参考文献 BAR-791。

• show-backupコマンドの「No of files」を「Number of files」に変更します

  show-backupコマンドのWal Informationセクションでは、“No of files”の出力が“Number of files”に変更されました。

  参考文献 BAR-798。

• config-update を介してサーバーとモデルに渡されたオプションを検証する

  barman config-update コマンドは、変更をエンキューする前に、提供された各セクションで追加の検証を実行するようになりました。とりわけ、すべての必須フィールドが存在すること、提供された値が予想される型に準拠していること、および各値がそれぞれのパーサーも渡すことを検証します。さらに、チェックが失敗した場合にコマンドはエラーになるようになりました。これにより、部分的または不正な形式の更新が適用されるのを防ぎます。

  参考文献 BAR-142。

• barman check および barman backup コマンドに --check-timeout 引数を追加

  barman check および barman backup コマンドに新しいCLIオプションが導入され、チェックオペレーションの時間が設定された check_timeout を超え、バックアップがスケジュールされない状況に対処します。このオプションを使用すると、ユーザーはタイムアウトを無効にするか、デフォルトまたは構成済みの check_timeout 値をオーバーライドできます。

  参考文献 BAR-219。

• --list-empty-directories を barman list-files コマンドに追加

  新しい --list-empty-directories 引数を list-files コマンドに追加して、空のディレクトリをリストに追加します。

  参考文献 BAR-220。

• 自動WALスイッチとアーカイブによるアーカイブチェックの向上

  ユーザーエクスペリエンス、特にサーバーの初期構成中のユーザーエクスペリエンスを向上させるために、 barman check コマンドがより堅牢になりました。

  以前は、WALアーカイブが空の場合、チェックは失敗し、手動介入が必要でした。

  Barmanは、最初にBarmanサーバーに存在する既存のWALをアーカイブしようとすることにより、これをインテリジェントに処理するようになりました。存在しない場合、PostgresサーバーのWALスイッチを自動的にトリガーし、結果のファイルをアーカイブしようとします。この機能強化により、一般的な手動手順が自動化され、すぐに使える初期ヘルスチェックの信頼性が向上します。

  参考文献 BAR-718。

• BarmanクラウドスクリプトでバックアップIDとしてショートカットをサポート

  Barmanクラウドコマンドでバックアップを参照するときに、ショートカット first / oldest 、 last / latest および last-failed を指定できるようになりました。 Barmanは、これらのショートカットを自動的に解析し、関連するバックアップIDを返すようになりました。

  参考文献 BAR-717。

バグ修正

• バックアップ中に一時テーブルのデータファイルを無視する

  一時関係ファイルのパターンと一致するファイルは、 pg_basebackup によって暗黙的に実行される除外と同様に、 rsync バックアップ中に無視されるようになりました。これは、rsyncが既に削除された一時ファイルをコピーしようとする場合があり、手動でブロックが解除されるまでBarmanをハングアップする可能性があるため、多くの一時テーブルを作成およびドロップするPostgresインスタンスに対してrsyncコンカレントモードでBarmanを実行する際のエラーを回避するために必要です。

  参考文献 BAR-266。

• pg_combinebackup が見つからない場合のエラーメッセージを改善

  以前は、インクリメンタルバックアップを復元し、PATHで pg_combinebackup が利用できない場合、 Barmanは例外を適切に処理せず、エラーを理解して修正することが困難でした。現在、適切な例外が発生し、ターゲットサーバーで pg_combinebackup が見つからなかったことを示す明確なメッセージが表示されます。

  参考文献 BAR-840。

• ターゲットデータまたはテーブルスペースディレクトリが空でない場合、リストアは失敗します。

  以前、 Barmanは、復元する前にテーブルスペースの宛先ディレクトリが空かどうかを検証しなかったため、コンテンツがサイレントに上書きされ、データの損失または破損が発生する可能性がありました。ここで、復元プロセスは、続行する前に、データとテーブルスペースを含むすべての宛先ディレクトリが空であることを確認します。そうでないものがある場合、 Barmanはオペレーションを停止し、適切なエラーメッセージを表示し、ローカルとリモートの両方の復元の安全性とデータの完全性を大幅に向上させます。

  参考文献 BAR-787。

• 孤立した古いバックアップを削除する際のエラーを修正する

  バックアップが孤立していて古い場合、保持ポリシーの適用が失敗する場合がある問題を解決しました。 Barmanは、ベースバックアップディレクトリを削除しようとする前に、ベースバックアップディレクトリが存在することを確認し、ディレクトリが既に削除されている場合のエラーを防止するようになりました。

  参考文献 BAR-794。

• PG17境界LSNの正しいWALセグメントの名前付けを確認します

  barmanバックアップ <server> を使用する場合にPostgreSQL 17以降のバージョンで発生したバックアップのハング問題を修正し、低アクティビティのインスタンスで待機し、 pg_walfile_name()およびpg_walfile_name_offset()と対話するメソッドとプロパティ内のロジックを変更します。

  barman#1041で説明しているように、PostgreSQL 17では、バックアップの終了WALが、最後に完了したWALファイルではなく、現在書き込まれているWALファイルになりました。アクティビティが最小限のサーバーでは、この現在のWALファイルはすぐに完了またはアーカイブされない場合があり、 pg_switch_wal()が発生するまでバックアッププロセスが無期限に停止する場合があります。

  PostgreSQLの変更の詳細については、 https://www.postgresql.org/docs/release/17.0/ を参照してください。

  参考文献 BAR-519。

• スナップショットバックアップがAWSのNitroインスタンスの非ルートEBSボリュームをサポートするようになりました

  スナップショットバックアップがAWSのNVMeNitroデバイスの非ルートEBSボリュームを検出できなかった問題を解決しました。スナップショットバックアップは、インスタンスに接続されているすべての非ルートEBSボリュームで確実に動作するようになりました。

  リファレンス BAR-500

3.14.12025-06-18

バグ修正

• WALアーカイブのパフォーマンス問題を修正する

  Barman WALアーカイブプロセスは、現在の実行でアーカイブされないWALファイルの処理が原因でパフォーマンスの低下が発生していました。また、3.14で導入された暗号化ロジックにも誤りがあり、 BarmanはサーバーにストリーミングされるWALファイルの暗号化をチェックしました。ストリーミングされたWALはGPG暗号化も圧縮もされないため、これは不要です。両方の問題が修正されると、アーカイブプロセスが大幅に高速化され、リソース効率が向上します。

  問題1087の詳細な分析をしていただいた@thealex55に感謝します。

  参考文献 BAR-775。

3.14.02025-05-15

重要な変更

• tarバックアップとWALファイルのGPG暗号化の実装

  tarバックアップのGPG暗号化を実装します。暗号化はバックアップの最後に開始され、PGDATAのバックアップとバックアップディレクトリに存在するテーブルスペースが暗号化されます。暗号化されたバックアップファイルには、 .gpg 拡張子が追加されます。

  Barmanは、新しい encryption_passphrase_command 構成オプションで取得したパスフレーズを使用して、GPG暗号化されたバックアップの復号化と復元をサポートしています。復元プロセス中に、復号化されたファイルはBarmanホストの local_staging_path 設定でステージングされ、信頼性の高い安全な復元プロセスが保証されます。

  バックアップとWALファイルの暗号化と復号化に必要な新しい構成オプションを追加する必要があります。新しいオプションは encryption 、 encryption_key_id 、および encryption_passphrase_command です。

  encryption = gpg の場合、WALファイルはすべてGPGで暗号化されます。これには、xlogdbレコードの読み取りおよび書き込み方法の変更下位互換性の維持、およびファイルが暗号化されるタイミングと暗号化プロセス自分自身を検出する新しいロジックが含まれます。

  barman listコマンドのget-walおよびno-get-walフラグを使用する場合、復元プロセス中のGPG暗号化WALファイルの復号化。これにより、 encryption_passphrase_command 構成オプションを介してバックアップを復号するために追加された機能が拡張されます。

  show-backup には、バックアップが暗号化されたかどうかを公開する新しいフィールドがあり、使用された暗号化方法がある場合は指定します。

  barman check コマンドは、ユーザーの暗号化設定がBarmanサーバーで正しく構成され、予想通りに機能しているかどうかを確認します。

  参照BAR-683、BAR-687、BAR-693、BAR-669、BAR-671、BAR-692、BAR-685、BAR-680、BAR-670、BAR-681、BAR-702。

• Pythonバージョン3.6および3.7の非推奨

  Barmanのバージョン3.14の時点で、Python 3.6および3.7のサポートを非推奨にします。これらはPythonコミュニティでサポートされていません。 Barmanは、必要なすべてのモジュールが含まれているRHEL 8システムで利用可能な最新バージョンであるPython 3.8を引き続きサポートしています。

  参考文献 BAR-737。

マイナー変更

• BarmanサーバーでWAL圧縮の圧縮レベルを指定できるようにします

  新しい compression_level パラメーターをBarman構成に追加します。このオプションは、有効な整数値または事前定義されたオプションのいずれか low 、 medium 、および high を受け入れます。各オプションは、選択した圧縮アルゴリズムに応じて異なるレベルに対応します。

  参考文献 BAR-540。

• クライアントサイドの圧縮を barman-wal-archive に追加する

  クライアントサイドの圧縮オプションが barman-wal-archive に追加され、 Barmanサーバーで使用可能なものと同じアルゴリズムをサポートしています。有効にすると、圧縮はWALをBarmanサーバーに送信する前にクライアント側で適用されます。 --compression-level パラメーターを使用すると、選択したアルゴリズムに目的の圧縮レベルを指定できます。

  参考文献 BAR-262。

• –compression-levelパラメーターをbarman-cloud-wal-archiveに追加します

  compression-level と呼ばれるパラメーターが barman-cloud-wal-archive に追加されました。これにより、使用中の圧縮アルゴリズムのレベルを指定できます。

  参考文献 BAR-557。

• Snappy圧縮アルゴリズムをBarmanサーバーに追加する

  Snappy圧縮は、以前は barman-cloud-wal-archive でのみ使用できましたが、標準のBarmanサーバーでも使用できるようになりました。他のすべてのアルゴリズムと同様に、 compression 構成パラメーターで snappy を設定することにより構成できます。

  参考文献 BAR-557。

• サーバープロセスをリストするための新しい list-processes サブコマンドの紹介

  Barmanサーバーのすべてのアクティブなサブプロセスを出力する新しい list-processes コマンドを追加します。このコマンドは、各プロセスのPIDとタスクを表示します。

  参考文献 BAR-664。

• Barmanサブプロセスを終了するための新しい terminate-process サブコマンドの紹介

  新しい terminate-process コマンドを追加して、ユーザーはタスク名を指定して、特定のサーバーのアクティブなBarmanサブプロセスを終了できます。 Barmanは、指定されたサーバーに属し、現在アクティブである限り、サブプロセスを終了します。

  参考文献 BAR-665。

• クラウドスクリプトで使用されるboto3バージョンからピンを削除します

  boto3 > = 1.36の問題を徹底的に調査した後、バージョン1.35で依存関係を維持したピンを削除することにしました。

  AWSとMinIOオブジェクトストアは両方とも最新バージョンで正常に動作し、boto3のバージョン> = 1.36を使用すると、 BarmanクラウドスクリプトがFIPS準拠の環境で動作します。

  参考文献 BAR-637。

バグ修正

• 最小限の冗長性チェックでは「非インクリメンタル バックアップ」のみを考慮するようにしてください

  冗長数にインクリメンタル バックアップが含まれるため、 minimum_redundancy ルールに違反する可能性がある問題が報告されました。例として、カタログに1つの完全バックアップと2つの依存増分バックアップが含まれ、ユーザーが minimum_redundancy = 2 であったシナリオでは、ルールは誤って満たされたと考えられました。その結果、完全なバックアップを削除すると、そのインクリメンタルな依存関係のカスケード削除がトリガーされ、カタログにはバックアップがありません。

  この問題は、非インクリメンタルバックアップのみつまりフル、rsync、スナップショットのみを考慮するように minimum_redundancy ロジックを更新することにより修正されました。これにより、構成された最小の冗長レベルに違反する場合、完全なバックアップを削除できません。

  参考文献 BAR-707。

• gzip 、 bzip2 、および pigz 圧縮アルゴリズムを使用して、 --keep-compression での barman-wal-restore の使用を修正します

  --keep-compression を指定しているときに gzip 、 bzip2 または pigz で圧縮されたWALを復元しようとすると、予期しないエラーが発生する barman-wal-restore の問題を修正します。

  参考文献 BAR-722。

3.13.32025-04-24

バグ修正

• ブロックレベルのインクリメンタルバックアップのローカルリストアを修正する

  ブロックレベルのインクリメンタルバックアップのローカル復元を実行すると、 Barmanは次のようなエラーに直面していました。

  ERROR: Destination directory '/home/vagrant/restore/internal_no_get_wal' must be empty
  

  そのエラーは、オプション --staging-wals-directory がバージョン3.13.0で導入されたときの回帰によって発生しました。それとともに、続行する前にWAL宛先ディレクトリが空であることを確認する新しいチェックが付属しました。ただし、ブロックレベルのインクリメンタルバックアップをローカルに復元する場合、 Barmanはこのチェックを実行する前にWAL宛先ディレクトリを設定していたため、上記のエラーがトリガーされました。

  参考文献 BAR-655。

• barman-cloud-backup をフックとして実行する場合の回帰を修正

  Barman 3.13.2は、WORM環境の問題を修正するために提供された作業の一部として、 backup.info メタデータファイルの場所を変更しました。

  ただし、これらの変更は、 Barmanサーバーでバックアップフックとして barman-cloud-backup を使用する場合に回帰を導入しました。フックは、メタデータファイルの新しい場所を認識しませんでした。

  この更新ではその問題が修正されるため、 barman-cloud-backup は新しいフォルダー構造を認識し、 backup.info ファイルを適切に見つけて、実行時障害を回避します。

  参考文献 BAR-696。

• カスタム圧縮が構成されている場合、部分的なWALファイルの解凍を回避する

  カスタム圧縮が構成されているときにBarmanが部分的なWALファイルを解凍しようとした問題を修正しました。部分的なWALファイルは圧縮されないため、 barman-wal-restore または barman get-wal で --partial フラグを使用すると、それらを解凍しようとするとエラーが発生します。

  参考文献 BAR-697。

• barman-cloud-backup が一時パーツファイルをリサイクルしないを修正した

  これにより、一時パーツファイルがクラウドにアップロードされた後に削除されず、ディスク領域の枯渇につながる barman-cloud-backup 問題が修正されます。この問題は、Python > = 3.12を使用している場合にのみ発生し、名前付け一時ファイルオブジェクトの delete 属性を削除するPythonの変更によるものでした。内部チェックを実行するときにBarmanが依存していました。

  参考文献 BAR-674。

• WORM環境でのバックアップアノテーションの使用を修正

  Barmanは、以前に barman keep や barman delete のような操作を追跡するために使用されるバックアップアノテーションファイルをバックアップディレクトリ自分自身内に保存していました。これらの注釈は、バックアップを保持するか、削除用にマークを付けるかを決定するのに役立ちます。ただし、WORM環境では、バックアップディレクトリ内のファイルは、特定の期間が経過すると変更または削除できないため、バックアップ状態の管理に問題が発生しました。この修正では、アノテーションファイルを専用のメタデータディレクトリに再配置して、このような操作がWORM環境で正しく機能することを保証します。

  参考文献 BAR-663。

3.13.22025-03-27

マイナー変更

• 不変ストレージを使用する際のエラーを修正する

  新しい worm_mode 構成を追加して、 BarmanでのWrite Once ReadManyの処理を有効にし、不変ストレージへのバックアップをサポートできるようにします。

  この修正では、backup.infoファイルの自動再配置も提供します backup_directory 内の新しいディレクトリ meta 。これにより、 Barmanは将来必要に応じて更新できます。

  Barmanは、最初のバックアップを実行するときに必要とされないWALファイルのwalsディレクトリをパージしません。これにより、この最初のバックアップが時代遅れで削除されたときに再利用される追加の領域が追加されますその時までに、バックアップとWALは保持ポリシーウィンドウの範囲外になります。

  バックアップ用の不変ストレージで実行する場合の制限を説明する追加ノートをドキュメントに追加しました。特に、ファイルの不変性における猶予期間の必要性と、 barman keep がこれらの環境ではサポートされていないという事実。

  参照BAR-649、BAR-645、BAR-650、BAR-651、BAR-652。

3.13.12025-03-20

マイナー変更

• バックアップショートカットの動作を改善します last-full / latest-full

  ショートカット last-full / latest-full は、サーバーの最後の完全なバックアップではなく、インクリメンタルバックアップの親としての資格のあるサーバーの最後の完全なバックアップを取得していました。

  これは予想された動作ですが、コミュニティからのフィードバックでは、ユーザーが混乱していることが示されています。

  今後、ショートカット last-full / latest-full は、そのバックアップがインクリメンタルバックアップの親として適格であるかどうかにかかわらず、 Barmanサーバーの最後の完全なバックアップを取得します。

  インクリメンタルバックアップの親としてのフルバックアップの適格性は、後の手順でBarmanによって検証され、親として適合しない場合には、適切なメッセージが表示されます。

  参考文献 BAR-555。

バグ修正

• barman restore の無効な --target-time を解析する際のエラーメッセージを修正

  barman restore コマンドを使用する場合、無効な --target-time 文字列を解析したときのエラーメッセージは次のとおりです。

  EXCEPTION: local variable 'parsed_target' referenced before assignment
  

  その例外は、理解可能なエラーメッセージに置き換えられました。

  参考文献 BAR-627。

• クラウド復元コマンドの相互排他的な引数を修正する

  barman-cloud-restore コマンドでは、 target_tli および target_lsn が相互排他的な引数であることを確認していました。ここで、チェックする正しいペアは target_time および target_lsn になります。

  参考文献 BAR-624。

• custom_decompression_filter を尊重しないBarmanを修正

  指定された圧縮アルゴリズムがBarmanによってネイティブにサポートされている場合、 Barmanが設定された custom_decompression_filter を尊重しない問題を修正しました。 WALファイルを解凍するときに、カスタムフィルタがネイティブハンドラーより優先されるようになりました。

  参考文献 BAR-584。

• –no-get-walおよび-standbyを使用してバーマンの復元を修正する

  --no-get-wal と --standby-mode が一緒に指定されている場合、リカバリー中にBarmanが pg_wal ディレクトリを削除していた問題を修正しました。この問題は、 Barmanが recovery_end_command を含む pg_wal を参照するリカバリパラメーターを誤って入力したために発生し、この問題が発生しました。 Barmanは、この特定のケースに必要ないため、このようなパラメーターの入力を無視します。

  リファレンス BAR-630。

• barman restore および barman-cloud-restore の引数解析の問題を修正

  Barman 3.13.0では、回帰が導入され、 barman restore および barman-cloud-restore コマンドを使用するとエラーが発生しました。具体的には、そのバージョンでオプショナルになった backup_id 位置引数は他の引数と競合し、認識されない引数とエラーを発生させました。

  例、次のように barman-cloud-restore を実行します。

  barman-cloud-restore source_url server_name backup_id --cloud-provider aws-s3 recovery_dir
  

  次のようなエラーがトリガーされます。

  barman-cloud-restore: error: unrecognized arguments: recovery_dir
  

  この修正では、 backup_id を再度必須引数にすることにより問題を解決します。さらに、新しい“auto”値が backup_id として受け入れられるようになったため、 Barmanは特定の backup_id を必要とせずに、復元に最適なバックアップを自動的に選択できます。この更新では、引数処理を修正しましたが、ユーザーはスムーズで柔軟な復元プロセスを可能にします。

  参考文献 BAR-596。

3.13.02025-02-20

重要な変更

• 新しいxlogdb_directory構成を追加します

  新しい xlogdb_directory 構成オプションを導入します。このパラメーターは、グローバルまたはサーバーごとに設定でき、 xlog.db ファイルのカスタムディレクトリを指定できます。このファイルには、アーカイブされたWALファイルのメタデータが保存され、さまざまなシナリオでBarmanによって内部的に使用されます。設定されていない場合、デフォルトの wals_directory の値が使用されます。さらに、ファイルの名前も変更されて、サーバー名が接頭辞として含まれます。

  参考文献 BAR-483。

• バックアップを復元するときに“backup_id”をオプショナルにする

  歴史的に、 Barmanはバックアップを復元するには常に「backup_id」を必要とし、そのバックアップを復元のソースとして使用していました。

  この機能により、リストアのソースとして使用するバックアップを指定する必要がなくなり、オプショナルになります。

  この変更は、 Barmanとbarman-cloudスクリプトの両方に適用されます。

  これで、ユーザーは次の方法でバックアップを復元できるようになりました。

  1. “backup_id”を提供します

  2. “backup_id”は指定しないでください。最新のバックアップを取得します

  3. “backup_id”は提供しませんが、次のようなリカバリターゲットを提供します。- “target_time” target_lsnと相互排他的 “target_time”の前に最も近いバックアップを取得します。 “target_lsn”-“target_tli”“target_time”または“target_lsn”と組み合わせて使用する前に、最も近いバックアップを取得します。タイムラインと一致する最新のバックアップを取得します。他の復旧ターゲットと組み合わせる場合、タイムラインと一致するtarget_timeまたはtarget_lsnの前に最新のバックアップを取得します

  リカバリターゲット --target-xid 、 --target-name および --target-immediate はサポートされておらず、使用するとメッセージでエラーアウトします。

  この機能は、postgresクラスターを復元する際の柔軟性と簡単さを提供します。

  リファレンス BAR-541、BAR-473。

マイナー変更

• 現在アクティブなモデルを barman show-server および barman status に追加します

  以前は、構成モデルを適用した後、サーバーで現在アクティブなモデルを確認する唯一の方法は、 barman diagnose コマンドを使用することでした。この更新により、 barman status および barman show-server コマンドは、サーバーの現在アクティブな構成モデルがある場合はそれも表示するようになりました。

  リファレンス BAR-524、BAR-400。

• --staging-wal-directory オプションを barman restore コマンドに追加して、PITRの代替WALディレクトリを許可します

  新しいコマンドラインオプション --staging-wal-directory が restore / recover コマンドに追加され、PITRの実行時にWALファイルの代替の宛先ディレクトリを使用できます。以前は、WALファイルは復元先ディレクトリ内の barman_wal ディレクトリにコピーされていました。この機能強化により、リカバリ中にWALを別のパーティションに保存するなど、柔軟性が向上します。

  参考文献 BAR-224。

• boto3バージョンを任意のバージョン<= 1.35.99に固定します

  Boto3バージョン1.36は、S3の完全性をチェックする方法を変更したため、このバージョンは現在のBarmanコードと互換性がなく、次のエラーが生成されます。

  PutObjectオペレーションを呼び出すときにエラーMissingContentLengthが発生しました

  一時的な回避策として、 boto3のバージョンは、 Barmanで1.36のサポートが実装されるまで、バージョン<= 1.35.99に固定されます。

  参考文献 BAR-535。

• 重複したWALファイルを処理する際にbarman-wal-archiveをよりスマートに

  一部の特殊なケースでは、Postgresは同じWALを2回アーカイブしようとする場合があります。例えば barman-wal-archive はWALファイルをBarmanホストにコピーしますが、スクリプトはPostgresに成功を報告する前に中断された場合。 WALは既にPostgresからBarmanにコピーされていますが、非同期Barman WALアーカイバーによってまだ処理されていないため、同じファイルを再度アーカイブしようとすると、 barman-wal-archive の新しい実行が失敗する場合があります。

  このマイナーな変更は、既存のファイルと着信ファイルのチェックサムを確認することにより、この状況に対処します。チェックサムが一致する場合、着信ファイルは無視され、そうでない場合、出力情報メッセージが送信され、着信ファイルはerrorsディレクトリに移動されます。コードは、どちらの状況も0で終了し、 archive_command の障害が原因でPostgresホストにWALが蓄積するのを回避します。

  参考文献 BAR-225。

• WALアーカイブ障害チェックをクリアするための文書手順

  Barmanドキュメントの再デザイン中に、サーバーがアイドル状態で barman check が「WALアーカイブ」で失敗を返した場合、 switch-wal コマンドを実行するようにユーザーにアドバイスするノートの追加を忘れていました。

  これにより、以前のドキュメントから残ったギャップが解消されます。

  参考文献 BAR-521。

• 可能であれば、ディレクトリ全体を一度に削除してWALを削除します

  以前は、WALファイルを削除する必要がある場合、バックアップの削除など、 BarmanはすべてのWALファイルを反復し、個別に削除していました。これにより、主にZFSファイルシステムを使用するシステムでパフォーマンスの問題が発生する可能性があります。この変更により、ディレクトリ内のすべてのファイルがBarmanによって必要とされなくなったことに気づくたびに、ディレクトリ全体が削除されます。

  参考文献 BAR-511。

• Azure認証での DefaultAzureCredential オプションのサポートを追加します

  ユーザーは、サーバー構成の azure_credential の default オプションまたは barman-cloud-* の場合は --azure-credential default オプションを使用することにより、認証にAzureの DefaultAzureCredential を明示的に使用できるようになりました。以前は、資格情報が提供されず、環境変数が設定されていない場合に、フォールバックとしてのみ設定できました。

  参考文献 BAR-539。

• リテンションポリシー情報の診断出力を改善します

  barman promoteコマンドの出力を改善して、より使いやすい文字列表現を表示します。具体的には、`retention_policy'属性の「redundancy 2 b」の代わりに「REDUNDANCY 2」が表示され、`wal_retention_policy'属性は「simple-wal 2 b」の代わりに「MAIN」が表示されます。

  参考文献 BAR-100

バグ修正

• barman restore を --target-tli とともに使用する場合のPITRを修正

  Barmanは、次の場合に recovery.signal を作成せず、 postgresql.auto.conf に recovery_target_timeline を埋めていません。

  • barman restore に渡された唯一のリカバリターゲットは --target-tli でした。または

  • --target-tli は他の --target-* オプションで指定されましたが、指定されたターゲットタイムラインは、選択したバックアップのタイムラインと同じでした。

  --target-* オプションが barman restore に渡される場合、それはPITRとして正しく扱われるようになりました。

  参考文献 BAR-543。

• 割り当て前にAWS `profile`変数が参照される場合のバグを修正

  問題は、 Barman 3.12.0リリースの一部としてBAR-242によって導入されました。この問題により、 --aws-profile 引数または aws_profile 構成が設定されていない場合、 barman-cloud-backup-delete および場合によっては他のコマンドが次のようなエラーで失敗します。

  ERROR: Barman cloud backup delete exception: local
  variable 'profile' referenced before assignment`
  

  参考文献 BAR-518。

• barman-cloud-wal-archiveの-zstdフラグを修正する

  barman-cloud-wal-archive の --zstd フラグのバグを修正しました。基本的に無視され、アップロード前にWALファイルを実際に圧縮していません。

  参考文献 BAR-567。

3.12.12024-12-09

バグ修正

• json出力にバックアップの開始時間と終了時間のisoformatフィールドを追加します

  このパッチは、 infofileオブジェクトのjson出力を変更し、2つの新しいフィールド begin_time_iso および end_time_iso を追加します。新しいフィールドにより、より標準のタイムゾーンを認識する時間形式を使用でき、以前のバージョンとの互換性を維持できます。将来的には、日付のiso形式がバーマンが日付を保存するために使用する標準になり、人間が判読できない出力が要求される場所はどこでも使用されることに注意してください。

  作業の一部として、このパッチは、 Barman 3.12.0で導入されたBAR-316を元に戻します。

  参考文献 BAR-494。

3.12.02024-11-21

マイナー変更

• BarmanにFIPSサポートを追加する

  md5 ハッシュアルゴリズムはFIPSに準拠していないため、 sha256 に置き換えられます。 sha256 はFIPSに準拠しており、広く使用されており、ほとんどの実用的な目的において安全であると考えられています。このリリースまでは、BarmanのWALアーカイブクライアントは hashlib.md5 を使用して、 Barmanサーバーに送信される前にtarファイルのチェックサムを生成していました。ここで、 tarファイルは、複数のファイルをバンドルするために使用されるファイル形式であり、チェックサムとそれに対応するパスをリストする MD5SUMS ファイルです。このリリースでは、 md5 ハッシュアルゴリズムは、デフォルトとして sha256 に置き換えられました。その結果、 tarファイルのチェックサムは sha256 を使用して計算され、 MD5SUMS ファイルの名前は SHA256SUMS になります。 Barmanは、ユースケースがある場合、クライアントからデフォルト以外の md5 アルゴリズムと MD5SUMS ファイルを使用する機能があります。ユーザーは、 --md5 フラグを barman-wal-archive archive_command に追加するだけです。

  参考文献 BAR-155、CP-34954、CP-34391

• el7、debian10、およびubuntu1804サポートを削除しました。 DebianとSLESを更新しました。

  el7、debian10、およびubuntu1804のサポートが削除されました。さらに、バージョン12とバージョン名「bookworm」がDebianに追加され、以前に欠落していたエントリに対処しました。 SLESイメージバージョンもsp4からsp5に更新されました。

  参考文献 BAR-389。

• Postgres Extended 17PGEおよびPostgres Advanced Server 17EPASのサポートを追加します

  テストはPostgres Extended 17PGEおよびPostgres Advanced Server 17EPASで実施され、 Barmanの最新機能との完全な互換性が確認されました。この検証により、PGEおよびEPASの最新バージョンのユーザーは、 Barmanのすべての新機能を自信を持って活用できます。

  参考文献 BAR-331。

• zstd 、 lz4 、および xz アルゴリズムでWAL圧縮を向上させる

  WALファイルのxz圧縮のサポートを導入しました。 compression サーバーパラメーターで xz を指定することにより、有効にできます。 WALは、BarmanのWALアーカイブに入るときに圧縮されます。クラウドの場合、 barman-cloud-wal-archive の実行時に --xz を指定することにより有効にできます。

  WALファイルでのzstandard圧縮のサポートを導入しました。 compression サーバーパラメーターで zstd を指定することにより、有効にできます。 WALは、BarmanのWALアーカイブに入るときに圧縮されます。クラウドの場合、 barman-cloud-wal-archive の実行時に --zstd を指定することにより有効にできます。

  WALファイルのlz4圧縮のサポートを導入しました。 compression サーバーパラメーターで lz4 を指定することにより、有効にできます。 WALは、BarmanのWALアーカイブに入るときに圧縮されます。クラウドの場合、 barman-cloud-wal-archive の実行時に --lz4 を指定することにより有効にできます。

  リファレンス BAR-265、BAR-423、BAR-264。

• マルチパートアップロードを回避することにより、S3バケットでのWALアップロードパフォーマンスを向上させます

  以前は、WALファイルは、 upload_fileobj メソッドを介してboto3ライブラリが提供するマルチパートアップロードを使用してS3バケットにアップロードされていました。マルチパートアップロードは、WALセグメントなどの小さなファイルに使用すると、単一のPUT要求でアップロードする場合と比較して、時間がかかることに注意しました。これは、100MB未満のファイルのマルチパートアップロードを回避することにより改善されました。この変更により、各WALファイルの平均アップロード時間は約15%削減される予定です。

  参考文献 BAR-374。

• KEEP:STANDALONE フルバックアップのリテンションポリシーを適用する際の動作を変更します

  backup_method = postgres で作成されたフルバックアップにリテンションポリシーを適用する場合、 Barmanは以前に、使用されるKEEPターゲットに関係なく、すべての依存子インクリメンタルバックアップを VALID としてマーキングしていました。ただし、このアプローチは間違っています。

  • KEEP:STANDALONE というラベルのバックアップの場合、 Barmanは、サーバーをそのバックアップの正確な状態に復元するために必要なWALファイルのみを保持します。これらのバックアップは自己完結型であるため、ルートバックアップが保持ポリシーの範囲外になると、依存子のバックアップは必要ありません。

  • 対照的に、 KEEP:FULL とマークされたバックアップは、ポイントインタイムリカバリーを目的としています。これをサポートするために、 BarmanはすべてのWALと子バックアップを保持して、バックアップの一貫性を保証し、可能な最新のポイントへのリカバリーを可能にします。

  この違いにより、 KEEP:STANDALONE バックアップは特定の瞬間のスナップショットとして機能しますが、 KEEP:FULL バックアップは完全なポイントインタイムリカバリーに必要なすべてを保持します。

  参考文献 BAR-366。

• Barmanの復旧プロセスのドキュメントとユーザー向け機能を更新します。

  Barmanドキュメントとツール自分自身は、両方とも以下を参照するために「recover」/「recovery」という用語を使用していました。

  • Postgresの復旧プロセス。

  • バックアップを復元し、リカバリーの準備をするプロセス。

  コードとドキュメントの両方が変更され、「restore」および「recover」/「recovery」という用語の使用を正確に反映しています。

  また、 barman recover コマンドは barman restore に名前が変更されました。古い名前は、下位互換性のためのエイリアスとして残されています。

  参考文献 BAR-337。

• –keep-compressionフラグをbarman-wal-restoreおよびget-walに追加します

  新しい --keep-compression オプションが barman-wal-restore と get-wal の両方に追加されました。このオプションは、圧縮されたWALファイルを取得する前にBarmanサーバーで解凍するかどうかを制御します。 get-wal で指定される場合、デフォルトの解凍はスキップされ、出力は元の状態のWALファイルコンテンツです。 barman-wal-restore で指定すると、WALファイルはそのまま取得され、圧縮されている場合はクライアントサイドで解凍されます。

  参考文献 BAR-435。

• ランサムウェア保護-AWSスナップショットロックのサポートを追加

  Barmanは、Amazon EBSスナップショットの誤ってまたは悪意のある削除を防ぐための新しい統合機能であるAWS EBS Snapshot Lockをサポートするようになりました。スナップショットがロックされている場合、ユーザーは削除できませんが、完全にアクセスして使用できます。この機能を使用すると、スナップショットを指定した期間Write-Once-Read-Many形式で保存できます。ロックの有効期限が切れるまでデータを安全に改ざん防止に保つことにより、規制要件を満たすのに役立ちます。

  この機能を開始したコミュニティ貢献者Rui Marinhoに心より感謝いたします。

  参考文献 BAR-242。

• バックアップの削除中のクラッシュから孤立したファイルが残されないようにします

  このコミットは、バックアップの削除中にシステムがクラッシュした場合、バックアップにファイルが残る問題を修正します。

  バックアップが削除されると、最初に「削除マーカー」を取得します。バックアップの削除中にクラッシュが発生した場合、マーカーは、サーバー再起動時に不完全なバックアップ削除を認識するのに役立ちます。

  Barman cronジョブは、これらの削除されたマーカーを検索するように更新されました。 「削除マーカー」を含むバックアップが見つかった場合、プロセスを完了します。

  参考文献 BAR-244。

• スナップショットでタグを使用するサポートを追加します

  Barmanは、 barman-cloud-backup scriptコマンドを使用してバックアップを作成するときに、スナップショットのタグ付けをサポートするようになりました。 –tagsと呼ばれる新しい引数が追加されました。

  この機能を開始したコミュニティ貢献者Rui Marinhoに心より感謝いたします。

  参考文献 BAR-417。

• BarmanクラウドコマンドのJSON出力を生成するときは、ctimeの代わりにISO形式を使用します

  ctime形式には、タイムスタンプに関連付けられたタイムゾーンに関する情報がありません。それに加えて、そのフォーマットは人間が使用するのにより適しています。マシンでの使用には、ISO形式の方が適しています。

  参考文献 BAR-316。

バグ修正

• レプリケーションスロットに対して誤った結果を返すバーマンチェックを修正

  以前は、スタンバイノードからバックアップし、プライマリからWALをストリーミングするアーキテクチャを使用している場合、 Barmanはレプリケーションチェックに conninfo スタンバイサーバーをポイントして誤って使用し、次のようなエラーを引き起こしていました。

  replication slot (WAL streaming): FAILED (replication slot 'barman' doesn't exist. Please execute 'barman receive-wal --create-slot pg17')

  これにより、 wal_conninfo が設定されている場合はWALレプリケーションチェックに使用されるようにすることにより、次の問題 #1024 _が修正されます。

  両方が設定されている場合、 wal_conninfo は wal_streaming_conninfo より優先されます。この変更により、 wal_conninfo のみが設定されている場合、それが使用され、 conninfo にフォールバックしません。

  また、ドキュメントでは、 conninfo がスタンバイサーバーをポイントする場合、正確なレプリケーションステータスチェックには wal_conninfo を設定および使用する必要があることを明示的に変更しました。

  参考文献 BAR-409。

• barman keep の欠落しているオプションを修正

  オプションなしで barman keep を実行したときにBarman CLIが出力したエラーメッセージは、statusとreleaseのショートカットエイリアスが存在することを示唆していました。これらのエイリアス-sおよび-rは存在しないため、エラーメッセージは誤解を招くものでした。これは、これらの短いオプションをBarman CLIに含め、これらのショートカットが既に存在する barman-cloud-backup-keep のような他のツールと調整することにより、問題を修正します。

  参考文献 BAR-356。

• conninfoおよびprimary_conninfoに関連するスタンバイチェックを軽減する

  スタンバイサーバーをバックアップするときに、 Barmanはいくつかのチェックを実行して、 conninfo が実際にスタンバイリカバリモードを指していること、および primary_conninfo がプライマリ非リカバリーを指していることをアサートします。

  問題#704および#744で報告されたように、フェールオーバーが発生すると、 conninfo が代わりにプライマリを指すようになり、チェックが失敗し始めるため、ユーザーはフェールオーバーが発生するたびにBarman構成を手動で変更する必要があることです。

  この修正では、このようなチェックを非クリティカルにすることにより問題を解決しました。つまり、チェックはまだ失敗しますが、 Barmanは関係なく動作し続けます。基本的に、 Barmanは conninfo がスタンバイをポイントしていない場合、 primary_conninfo を無視します。この構成の誤りに関する警告は、 Barmanコマンドを実行するたびに出力されるため、ユーザーが気づくことができます。

  参考文献 BAR-348。

• Barmanでpg_has_roleを呼び出すときにMEMBERではなくUSAGEを確認する

  正しく動作するには、 Barmanデータベースユーザーを一部のロールに含める必要があります。 Barmanは、Postgresで pg_has_role を呼び出すことにより、条件が満たされることを確認していました。ただし、 USAGE ではなく MEMBER 特権のチェックでした。この見落としは修正されました。

  この変更は、@RealGreenDragonからの貢献です。

  参考文献 BAR-489。

3.11.12024-08-22

バグ修正

• barman-cloud-backup-delete の障害を修正します。このコマンドは、以前のリリースで導入されたバグのため、保持ポリシーを適用するときに失敗していました。

3.11.02024-08-22

重要な変更

• Postgres 17+のインクリメンタルバックアップのサポートを追加します。この主要機能は、いくつかの小さな変更で構成されています。

  • --incremental コマンドラインオプションを barman backup コマンドに追加します。これは、インクリメンタルバックアップを作成するときに親バックアップを指定するために使用されます。親は、完全バックアップまたは別のインクリメンタルバックアップのいずれかです。

  • latest-full ショートカットバックアップIDを追加します。 latest と同様に、これは、インクリメンタルバックアップの親バックアップを選択するショートカットとして使用できます。 latest は、フルまたはインクリメンタルの場合を独立して取得しますが、 latest-full は最新のフルバックアップを取得します。

  • barman keep コマンドは、 backup_method = postgres の場合のフルバックアップにのみ適用できます。

  • 保持ポリシーでは、インクリメンタル バックアップは考慮されません。インクリメンタル バックアップは、完全なバックアップまでで使用可能なバックアップの完全なチェーンがないと復旧できないため、完全なバックアップのみが保持ポリシーを考慮します。フルバックアップに依存するインクリメンタルバックアップがあり、リテンションポリシーが適用される場合、フルバックアップはそのステータスを、関連するインクリメンタルバックアップに伝播します。フルバックアップに KEEP ターゲットでフラグが設定されている場合、 Barmanは関連するすべてのインクリメンタルバックアップのステータスを VALID に設定します。

  • バックアップを削除すると、それに依存するすべての増分バックアップがある場合は、それも削除されます。

  • barman recover は、リカバリ時に完全バックアップとインクリメンタルバックアップのチェーンを組み合わせる必要があります。新しいCLIオプション --local-staging-path 、および対応する local_staging_path 構成オプションは、インクリメンタルバックアップをリカバリーするときにバックアップが結合されるBarmanホスト内のパスを指定するために使用されます。

• barman show-backup 出力の変更

  • 「推定クラスターサイズ」フィールドを追加します。バックアップを復元するときに、クラスターのデータディレクトリのサイズを推定すると役立ちます。これは、圧縮バックアップまたはインクリメンタルバックアップを復旧する場合、バックアップのサイズがPostgresのデータディレクトリのサイズを反映していない場合に特に役立ちます。 JSON形式では、これは cluster_size として保存されます。

  • 「WAL resumer」フィールドを追加します。このフィールドは、バックアップが作成されたときにPostgresで summarize_wal が有効になっていたかどうかを示します。 JSON形式では、これは server_information.summarize_wal として保存されます。このフィールドは、Postgres 16以前では省略されます。

  • 「Data checksums」フィールドを追加します。これは、バックアップが取得されたときにPostgresで data_checkums が有効になっていたかどうかを示します。 JSON形式では、これは server_information.data_checksums として保存されます。

  • 「バックアップ方法」フィールドを追加します。これは、このバックアップに使用されたバックアップ方法を示します。 JSON形式では、これは base_backup_information.backup_method として保存されます。

  • フィールド「Disk Capacity」の名前を「Backup Size」に変更します。後者は、 Barmanホストのバックアップのサイズを表すより包括的な名前を提供します。 base_backup_information の下のJSONフィールドの名前も disk_usage から backup_size に変更されました。

  • 「WALサイズ」フィールドを追加します。これは、バックアップに必要なWALのサイズを示します。 JSON形式では、これは base_backup_information.wal_size として保存されます。

  • フィールド「インクリメンタルサイズ」をリファクタリングします。これは名前が“Resources Saving”になり、 rsync または pg_basebackup でインクリメンタルバックアップを取得したときに節約されるリソースの推定値を表示するようになりました。バックアップサイズと推定クラスターサイズを比較して、インクリメンタルバックアップを行うことにより保存されたディスクリソースとネットワークリソースの量を推定します。 JSON形式では、フィールドの名前が incremental_size から base_backup_information の下の resource_savings に変更されました。

  • system_id フィールドをJSONドキュメントに追加します。このフィールドには、Postgresのシステム識別子が含まれています。コンソール形式では存在しましたが、JSON形式ではありませんでした。

  • Postgresのインクリメンタル バックアップに関連するフィールドを追加します。

    • “Backup type” Postgresバックアップがフルかインクリメンタルかを示します。 JSON形式では、これは base_backup_information の下の backup_type として保存されます。

    • 「ルートバックアップ」 1つ以上のインクリメンタルバックアップのチェーンのルートである完全バックアップのID。 JSON形式では、これは catalog_information.root_backup_id として保存されます。

    • 「親バックアップ」 この増分バックアップが取得された完全または増分バックアップのID。 JSON形式では、これは catalog_information.parent_backup_id として保存されます。

    • “Children Backup(s)” このバックアップを親として取得したインクリメンタルバックアップのID。 JSON形式では、これは catalog_information.children_backup_ids として保存されます。

    • 「バックアップチェーンサイズ」 このインクリメンタルバックアップからルートバックアップまでのチェーン内のバックアップの数。 JSON形式では、これは catalog_information.chain_size として保存されます。

• barman list-backup 出力の変更

  • JSON出力にバックアップタイプが含まれるようになりました。これは、 rsyncで取得したバックアップの場合は rsync 、 pg_basebackup で取得したバックアップの場合は full または incremental 、またはクラウドスナップショットの場合は snapshot です。コンソールに出力する場合、バックアップタイプは、対応するラベル R 、 F 、 I または S で表されます。

  • 出力からテーブルスペース情報を削除します。それは出力が肥大化していました。表領域情報は、 barman show-backup の出力で引き続き見つかります。

• recovery_target_time 〜 barman recover を構成するときは、常にタイムゾーンを使用してタイムスタンプを設定します。以前は、 --target-time を介してタイムゾーンが明示的に設定されていない場合、 BarmanはPostgresでタイムゾーンなしで recovery_target_time を構成していました。タイムゾーンがないと、PostgresはPostgresの timezone GUCを介して構成されているものを想定しています。今後、 Barmanは --target-time オプションを介してユーザーがタイムゾーンを設定していない場合、 Barmanホストのタイムゾーンで recovery_target_time を構成します。

• --target-lsn が設定されている場合、「no get wal」アプローチでバックアップをリカバリーする場合、構成したターゲットに到達するために必要なWALファイルのみをコピーします。以前は、 BarmanがアーカイブからPostgresにすべてのWALファイルをコピーしていました。

• --target-immediate が設定されている場合、「no get wal」アプローチでバックアップをリカバリーする場合、一貫性のあるポイントに到達するために必要なWALファイルのみをコピーします。以前は、 BarmanがアーカイブからPostgresにすべてのWALファイルをコピーしていました。

• barman-wal-restore は、WALをコピーする代わりに、スプールディレクトリから pg_wal に移動するようになりました。これにより、spoolディレクトリと pg_wal ディレクトリが同じパーティションにある場合、パフォーマンスが向上します。

• barman check-backup は、バックアップが出力とログで FAILED としてマークされた理由を表示するようになりました。以前は、バックアップが FAILED としてマークされた理由を知るには、 barman show-backup コマンドを実行する必要がありました。

• 構成オプション aws_await_snapshots_timeout と、対応する --aws-await-snapshots-timeout コマンドラインオプションを barman-cloud-backup に追加します。これは、スナップショットバックアップが完了状態に到達するまで待機するタイムアウトを秒単位で指定します。

• rsyncベースのバックアップにキープアライブメカニズムを追加します。以前は、 pg_backup_start() および pg_backup_stop() を実行するためにBarmanによって作成されたPostgresセッションは、ベースバックアップコピーがかかる間アイドル状態のままでした。これにより、ファイアウォールまたはルーターが長時間アイドル状態であったために接続がドロップされる可能性があります。キープアライブメカニズムは、その接続を介してハートビートクエリをPostgresに送信するため、接続がドロップされる可能性が減少します。ハートビート間の間隔は、新しい構成オプション keepalive_interval と、 barman backup コマンドの対応するCLIオプション --keepalive-interval を介して制御できます。

バグ修正

• 「no get wal」アプローチと --target-time 設定を使用してバックアップをリカバリーする場合、すべてのWALファイルをコピーします。以前は、 Barmanは、Postgresが構成したターゲット時間に到達するために必要なWALファイルを「推測」しようとしました。ただし、このメカニズムは、 BarmanホストのWALファイルの統計、具体的には作成時間に基づいていたため、十分に堅牢ではありませんでした。例えば PostgresとBarmanの間でアーカイブまたはストリーミングの遅延があった場合、ファイル統計に基づいたチェックが弱いためにBarmanは必要なすべてのWALファイルのコピーを逃すため、リカバリーが失敗するのに十分である可能性があります。

• Python 3.6以前でBarmanを実行する場合、 python-snappy を 0.6.1 に固定します。 python-snappy の新しいバージョンには、 cramjam バージョン 2.7.0 以降が必要です。これらはPython 3.7以降でのみ使用できます。

• barman receive-wal は、次の場合に 0 ではなくコード 1 で終了するようになりました。

  • pg_receivewal が実行されているため、 --reset フラグを使用して実行できません。

  • pg_receivewal プロセスは既に実行されているため、開始できません。

• barman diagnose 出力のPythonに関する情報を修正および改善します。

  • このコマンドは、 python_ver JSONキーを介してPythonバージョンを出力するときに、 Barmanがインストールされているのと同じPythonインタープリターを使用するようになりました。以前は、環境に複数のPythonインストールおよび/または仮想環境が含まれる場合、別のPythonインタープリターから取得される可能性があるため、最終的に出力が誤解を招く可能性がありました。

  • python_executable キーをJSON出力に追加しました。これには、 Barmanが使用する正確なPythonインタープリターへのパスが含まれています。

3.10.12024-06-12

バグ修正

• 一部のプラットフォームでのインストールの問題を回避するには、 argcomplete をオプショナルにします。

• ファイルが存在する場合にのみ barman.auto.conf をロードします。

• cfg_changes.queue ファイルの形式が不正な場合に警告を発します。

• pg_checkpoint が利用可能なpostgresqlバージョンのドキュメントを修正します。

• --no-partial オプションを barman-cloud-wal-restore に追加します。

3.10.02024-01-24

重要な変更

• 新しいCLIオプション --max-bandwidth で設定された値に従って、AWS S3またはAzure Blob Storageにバックアップするときに barman-cloud-backup が使用する平均帯域幅を制限します。

• 新しい構成オプション lock_directory_cleanup を追加します。これにより、cronは、未使用のロックファイルからbarman_lock_directoryを自動的にクリーンアップします。

• model と呼ばれる新しいタイプの構成のサポートを追加します。モデルは、特定のBarmanサーバーの構成オプションのオーバーライドのセットとして機能します。

• JSONを使用して構成の作成と更新を可能にする新しいbarmanコマンド barman config-update を追加します

バグ修正

• Barmanのフックスクリプトとしてbarman-cloud-backupを使用する場合、 --min-chunk-size が無視される原因になったバグを修正します。

3.9.02023-10-03

重要な変更

• ユーザーが pg_checkpoint ロールを持っている場合、PG>=14に対して barman switch-wal --force を実行できます。このパッチはtoydarianに感謝します。

• チェックタイムアウトが発生すると、現在のチェックを info レベルでログに記録します。

• S3またはAzure Blob Storageで barman-cloud-backup を使用する場合のアップロードチャンクの最小サイズを、 --min-chunk-size オプションを使用して指定できるようになりました。

• backup_compression = none は、 pg_basebackup を使用する場合にサポートされます。

• PostgreSQL 15以降の場合 zstd および lz4 の許可される backup_compression_level 値が、 pg_basebackup で許可される値と一致するように更新されました。

• 15より前のPostgreSQLバージョンの場合 backup_compression_level = 0 を backup_compression = gzip とともに使用できるようになりました。

バグ修正

• 新しいプロセスを開始するときにマルチプロセッシングがデフォルトでスポーンを使用するプラットフォームで barman recover を修正します。

3.8.02023-08-31

重要な変更

• パッケージのインストールを明確にする。 barmanは、各オペレーティングシステムのデフォルトのPythonバージョンがパッケージされています。

• minimum-redundancy オプションが barman-cloud-backup-delete に追加されます。常に使用可能なバックアップの最小数を設定できます。

• 新しい primary_checkpoint_timeout 構成オプションを追加します。新しいWALファイルが生成されない場合、プライマリサーバーにチェックポイントを強制する前に、バックアップの最後にBarmanが待機する秒数を定義できます。

バグ修正

• バーマンリテンションポリシーアプリケーションの競合状態を修正します。要求されたバックアップで別の削除が進行中の場合、バックアップの削除で警告が発生するようになりました。

• barman-cloud-backup-show のマニュアルページのインストールを修正します。

3.7.02023-07-25

重要な変更

• EBSボリュームを使用したAWSでのスナップショットバックアップのサポートが追加されました。

• barman-cloud-* スクリプトの --profile オプションの名前が --aws-profile に変更されます。古い名前は非推奨であり、将来のリリースでは削除される予定です。

• backup_method = rsync で作成されたバックアップの完了時に、バックアップマニフェストを自動的に生成できるようになりました。これは、 autogenerate_manifest 構成変数を設定することにより有効になり、 --manifest および --no-manifest CLIオプションを使用してオーバーライドできます。

バグ修正

• barman-cloud-* スクリプトは、継続トークンを正しく使用して、AWS S3互換オブジェクトストアのオブジェクトをページングするようになりました。これにより、 barman-cloud-backup-delete がバックアップの削除後に最も古い1000の対象WALのみを削除するバグが修正されます。

• マイナーなドキュメントの修正。

3.6.02023-06-15

重要な変更

• PostgreSQLバージョン10はサポートされなくなりました。

• 管理対象ディスクを使用したMicrosoft Azureでのスナップショットバックアップのサポートが追加されました。

• --snapshot-recovery-zone オプションは、他のプロバイダー固有のオプションとの一貫性を保つために --gcp-zone に名前変更されました。古い名前は非推奨であり、将来のリリースでは削除される予定です。

• snapshot_zone オプションと --snapshot-zone 引数の名前は、それぞれ gcp_zone と --gcp-zone に変更されます。古い名前は非推奨であり、将来のリリースでは削除される予定です。

• snapshot_gcp_project オプションと --snapshot-gcp-project 引数の名前が gcp_project および --gcp-project に変更されます。古い名前は非推奨であり、将来のリリースでは削除される予定です。

バグ修正

• Barmanは、パッシブノードに対して replication-status コマンドを実行しようとしなくなりました。

• backup_label は、 barman-cloud-backup-delete でスナップショットバックアップが削除されるときに、クラウドストレージから削除されます。

• generate-manifest および verify-backup コマンドのマニュアルページが追加されました。

• マイナーなドキュメントの修正。

3.5.02023-03-29

重要な変更

• Python 2.7はサポートされなくなりました。サポートされている最も古いPythonバージョンは3.6になりました。

• EL7の barman 、 barman-cli および barman-cli-cloud パッケージでは、python 2.7ではなくpython 3.6が必要になりました。サポートされている他のプラットフォームの場合、 Barmanパッケージには既にPythonバージョン3.6以降が必要であるため、パッケージ化は影響を受けません。

• PostgreSQL 10のサポートは、将来のBarmanリリースで廃止されます。 3.5.xは、PostgreSQL 10をサポートするBarmanの最後のバージョンです。

• barman-cloud-backup または barman-cloud-wal-archive で --kms-key-name オプションを使用することにより、Google Cloud StorageにアップロードされたバックアップとWALを特定のKMSキーを使用して暗号化できるようになりました。

• AWS S3にアップロードされたバックアップとWALは、 barman-cloud-backup または barman-cloud-wal-archive とともに --sse-kms-key-id オプションを使用することにより、特定のKMSキーを使用して暗号化できるようになりました --encryption=aws:kms 。

• 2つの新しい構成オプションが提供され、 backup_method = rsync を使用したバックアップおよびリカバリー中にパラレルワーカーが起動されるレートを制限できます。 parallel_jobs_start_batch_size は、単一のバッチで起動されるパラレルワーカーの量を制限するように設定でき、 parallel_jobs_start_batch_period は、ワーカーの単一バッチが開始される秒単位の時間を定義できます。これらは、 barman backup および barman recover コマンドで引数 --jobs-start-batch-size および --jobs-start-batch-period を使用してオーバーライドできます。

• 新しいオプション --recovery-conf-filename が barman recover に追加されます。これは、 BarmanがPostgreSQLリカバリオプションを書き込むファイルをデフォルトの postgresql.auto.conf から別の場所に変更するために使用できます。

バグ修正

• barman-cloud-backup-show が、 barman backup で作成され、 barman-cloud-backup によってバックアップ後フックスクリプトとしてアップロードされたバックアップのバックアップメタデータを表示できないバグを修正しました。

• バックアップ圧縮設定の検証に使用されるPostgreSQL接続が、 Barmanコマンドが終了するまで開いたままになるバグを修正しました。

• idle_session_timeout を超える期間実行すると、rsync-concurrentバックアップが失敗する原因となった問題を修正します。

• --wait フラグが barman backup で使用された場合、バックアップ名がバックアップメタデータに保存されないバグを修正しました。

• mojtabash78、mhkarimi1383、epolkerman、barthisrael、およびhzettersの貢献に感謝します。

3.4.02023-01-26

重要な変更

• これは、Python 2をサポートするBarmanの最後のリリースであり、新機能にはPython 3.6以降が必要です。

• snapshot という名前の新しい backup_method が追加されます。これにより、クラウドストレージボリュームのスナップショットを取得することにより、バックアップが作成されます。現在、Google Cloud Platformのみがサポートされていますが、将来のBarmanリリースでは、AWSおよびAzureのサポートが続く予定です。この機能には、Python最小バージョン3.7が必要であることに注意してください。詳細については、 Barmanのマニュアルを参照してください。

• スナップショットバックアップのサポートも barman-cloud-backup に追加され、スナップショットバックアップのリストアの最小限のサポートが barman-cloud-restore に追加されます。

• 新しいコマンド barman-cloud-backup-show が追加されました。これは、クラウドオブジェクトストレージに保存されているバックアップメタデータを表示し、 barman show-backup に似ています。これは、復元時にスナップショットのメタデータを簡単に取得できるように提供されていますが、 barman-cloud-backup で作成されたバックアップのメタデータを検査する便利な方法でもあります。

• ドキュメントのRPMからBarmanをインストールする手順が更新されました。

• ドキュメントのNFS要件のフォーマットが修正されました。

• サポートされているPostgreSQLバージョンは、ドキュメントで更新されています。これはドキュメントの修正のみです。サポートされている最小メジャーバージョンはまだ10です。

3.3.02022-12-14

重要な変更

• barman backup および barman-cloud-backup コマンドでサポートされた新しい --name オプションを使用して、バックアップ時にバックアップに名前を付けることができるようになりました。バックアップと対話するコマンドを実行するときに、バックアップIDの代わりにバックアップ名を使用できます。さらに、バックアップをリストおよび表示するコマンドが更新され、プレーンテキストおよびJSON出力形式でバックアップ名が含まれるようになりました。

• PostgreSQLバージョンの厳密なチェックにより、 BarmanがサポートされているPostgreSQLバージョンに対して実行されていることを確認します。

バグ修正

• barman Cloudコマンドドキュメントとこれらのコマンドのヘルプ出力間の不一致を修正します。

• スタンバイのバックアップ中にプライマリでWALを切り替えるときは、新しいPostgreSQL接続を使用して、 SSL error メッセージや接続の失敗などの未定義の動作を回避します。

• 子プロセスで実行されるコマンドのstdoutのデフォルトログレベルを DEBUG に変更することにより、ログボリュームを削減します。ただし、 pg_basebackup は除きます。これは、出力を確認することが頻繁に役立つ長時間実行プロセスであるため、 INFO レベルで意図的にログに記録されますコマンドの実行中)。

3.2.02022-10-20

重要な変更

• barman-cloud-backup-delete は、単一の要求で削除されるオブジェクトの最大数を決定する --batch-size オプションを受け入れるようになりました。

• すべての barman-cloud-* コマンドが --read-timeout オプションを受け入れるようになりました。これは aws-s3 クラウドプロバイダーで使用される場合、S3への要求を行うときにboto3ライブラリが使用する読み取りタイムアウトを決定します。

バグ修正

• Barman構成で backup_compression が設定されているが、PostgreSQLサーバーが利用できない場合の barman recover の障害を修正します。

3.1.02022-09-14

重要な変更

• backup_method = postgres で取得したバックアップを、それぞれ backup_compression = lz4 または backup_compression = zstd を設定することにより、lz4およびzstd圧縮を使用して圧縮できるようになりました。これらのオプションは、PostgreSQL 15ベータ以降でのみサポートされています。

• 並列圧縮に使用されるスレッドの数を設定する新しいオプション backup_compression_workers が利用できます。これは、現在 backup_method = postgres および backup_compression = zstd でのみ使用できます。

• 新しいオプション primary_conninfo を設定して、バックアップのファイナライズ時にプライマリでWALスイッチが発生するのをスタンバイのバックアップが待機する必要を回避できます。 Barmanは、 primary_conninfo の接続文字列を使用して、バックアップを停止するときにプライマリでWALスイッチを実行します。

• --files-from 引数の末尾の改行を必要とするCVE-2022-29154にパッチされた特定のRsyncバージョンのサポート。

• barman receive-wal メンテナンスオプション --stop 、 --reset 、 --drop-slot および --create-slot を非アクティブなサーバーに対して実行できます。

• --port オプションを barman-wal-archive および barman-wal-restore コマンドに追加して、SSH構成を必要とせずにカスタムSSHポートを使用できるようにします。

• さまざまなドキュメントの改善。

• Python 3.5はサポートされなくなりました。

バグ修正

• barman cron の実行中にPostgreSQL接続が正常に閉じられることを確認します。

• barman generate-manifest は、既存のbackup_manifestファイルをエラー条件として扱うようになりました。

• backup_manifestファイルは、リカバリ操作中にバックアップIDを追加して名前が変更され、古いbackup_manifestファイルを含む今後のバックアップが防止されます。

• タイムゾーンを認識しないjson出力のエポックタイムスタンプを修正しました。

• pg_basebackup の出力は、バックアップの進行中にBarmanログファイルに書き込まれるようになりました。

• このリリースに貢献して頂いたbarthisrael、elhananjir、kraynopp、lucianobotti、およびmxeyに感謝します。

3.0.12022-06-27

バグ修正

• PyPIのパッケージ署名問題を修正しました3.0.0と同じソース

3.0.02022-06-23

重大な変更

• PostgreSQLバージョン9.6以前はサポートされなくなりました。これらのバージョンのいずれかを使用している場合、 Barmanの以前のバージョンを使用する必要があります。

• Rsyncバックアップのデフォルトのバックアップモードは、排他的ではなくコンカレントになりました。排他的バックアップはPostgreSQL 9.6以降非推奨であり、PostgreSQLでは削除されました

  15. 15より前のPostgreSQLバージョンに対してBarmanを実行しており、排他的バックアップを使用したい場合は、 backup_options で exclusive_backup を設定する必要があります。

• 各バックアップの backup.info ファイルに保存されるバックアップメタデータには、追加のフィールドがあります。これは、 Barmanの以前のバージョンが3.0.0で取得されたバックアップが存在すると動作しないことを意味します。さらに、 pg-backup-apiのユーザーはバージョン0.2.0にアップグレードして、pg-backup-apiが更新されたメタデータで動作できるようにする必要があります。

重要な変更

• backup_compression 構成オプションを設定することにより、 backup_method = postgres で取得したバックアップをpg_basebackupで圧縮できるようになりました。圧縮レベル、バックアップ形式、およびpg_basebackupクライアントまたはPostgreSQLサーバーが圧縮を適用するかどうかを制御するための追加オプションが提供されています。注これらのバックアップのリカバリーには、 Barmanが recovery_staging_path オプションで指定された場所のリカバリサーバー上の圧縮ファイルをステージングする必要があります。

• PostgreSQL 15のサポートを追加します。排他的バックアップはPostgreSQL 15ではサポートされていないため、 PostgreSQL 15サーバーのBarman構成は backup_options で exclusive_backup を指定することはできません。

• 圧縮されたWALファイルを識別するときは、custom_compression_magicが設定されている場合、使用します。これにより、 Barmanは非圧縮のWAL streaming ディレクトリの *.partial ファイルなどを正しく識別し、解凍しようとする代わりにそれらを返すことができます。

マイナー変更

• さまざまなドキュメントの改善。

バグ修正

• Barmanがメッセージ「バックアップは開始バックアップコマンドの発行に失敗しました。」ログに記録する原因となった順序バグを修正します。 stopbackupコマンドの障害を処理している間。

• WALセグメント名の16進値が10進数の整数として解析されるため、9より大きいタイムラインが存在する場合に --target-tli を使用したリカバリーを妨げたバグを修正します。

• enum34依存関係の問題により、特定のpython2インストールでbarmanクラウドを使用するときに発生するインポートエラーを修正します。

• マジックバイトを識別しようとしたときに、 Barmanが圧縮WALから3バイトを超えて読み取らないバグを修正します。これは、3バイトを超えるマジックを使用したカスタム圧縮WALが正しく解凍されることを意味します。

• backup_method = rsync を使用したバックアップ中に --immediate-checkpoint フラグが無視される原因となったバグを修正します。

2.192022-03-09

重要な変更

• barman diagnose 出力日付形式をISO8601に変更します。

• Barman CloudにGoogle Cloud StorageGCSサポートを追加します。

• barman recover の --target-tli オプションの current および latest リカバリターゲットをサポートします。

• SLESへのインストールに関するドキュメントを追加します。

バグ修正

• barman-wal-archive --test は、エラーが発生したときにゼロ以外の終了コードを返すようになりました。

• -t オプションが使用される場合の barman-cloud-check-wal-archive の動作を修正して、接続テスト後に終了するようにしました。

• --no-get-wal が使用され、 recovery_options で /"get-wal/" が設定されていない場合、 barman recover は継続されるようになりました。

• 非アクティブなサーバーの barman show-servers --format=json ${server} 出力を修正しました。

• 構成ファイルに barman_home の存在を確認します。

• パッシブbarmanサーバーは、 backup_method = postgres で取得したバックアップを同期するときに、テーブルスペースデータの2つのコピーを保存しなくなりました。

• このリリースへのrichyenの貢献に感謝します。

2.182022-01-21

重要な変更

• barmanクラウドにスナッピー圧縮アルゴリズムのサポートを追加しますオプションのpython-snappy依存関係が必要です。

• barman-cloud-wal-archiveでWALをアップロードするときに、Azureクライアントの同時実行パラメーターを設定できるようにします。

• barmanクラウドに --tags オプションを追加して、バックアップファイルとアーカイブされたWALをクラウドストレージawsおよびazureでタグ付けできるようにします。

• 接続エラーの専用コード2が存在するように、バーマンクラウド終了ステータスコードを更新します。

• コマンド barman verify-backup および barman generate-manifest を追加して、バックアップが有効かどうかを確認します。

• barmanクラウドでのAzureマネージドID認証のサポートを追加します。これは、 --credential オプションで有効にできます。

バグ修正

• バケットが存在しない場合の barman-cloud-check-wal-archive の動作を変更します。

• list-files 出力が、基になるファイルシステムに関係なく、常にソートされることを確認します。

• barman-cloud-backup-keep、barman-cloud-backup-delete、およびbarman-cloud-check-wal-archiveのマニュアルページがPythonパッケージに追加されました。

• このリリースに貢献して頂いたrichyenとstrakisに感謝いたします。

2.172021-12-01

重要な変更

• バージョン2.14で導入されたパフォーマンスの低下は、 --jobs フラグを使用するときに barman backup または barman recover コマンドのコピー時間を増加させました。

• sender プロセスのrsync部分転送エラーを無視して、このようなエラーがバックアップの失敗を引き起こさないようにします。barthisraelに感謝します。

2.162021-11-17

重要な変更

• コマンド barman-check-wal-archive および barman-cloud-check-wal-archive を追加して、提案されたアーカイブの場所が新しいPostgreSQLサーバーに安全に使用できるかどうかを検証します。

• Barmanがカスタム圧縮スキームを使用して既に圧縮されたWALを識別して、再圧縮を回避できるようにします。

• last_backup_minimum_size および last_wal_maximum_age オプションを barman check に追加します。

バグ修正

• コマンドライン解析には、メンテナンスされていないarghモジュールの代わりにargparseを使用します。

• begin_time および end_time のタイムゾーンを一貫させます。

• このリリースへの貢献に感謝します。

2.152021-10-12

重要な変更

• list-backup 、 list-server および show-server コマンドの複数形を追加しました。これらは list-backups 、 list-servers および show-servers になりました。単数形は、下位互換性のために保持されています。

• カタログ内の最新の失敗したバックアップを参照する last-failed バックアップショートカットを追加して、次のことを行うことができます。

  • barman delete <SERVER> last-failed

バグ修正

• EPASの古いバージョンで正しいバージョン文字列を検出する問題のため、EPASバージョン9.6および10のバックアップからテーブルスペースは省略されません。

2.142021-09-22

重要な変更

• barman-cloud-backup-delete コマンドを追加します。これは、バックアップIDまたはリテンションポリシーを指定して、クラウドストレージのバックアップを削除できます。

• barman keep および barman-cloud-backup-keep を使用して既存のバックアップをアーカイブバックアップとしてタグ付けする機能を導入することにより、有効な保持ポリシーを超えてバックアップを保持できるようにします。

• Azure BLOBストレージのより広いストレージアカウントレベルではなく、制限されたBLOBコンテナレベルで作成されたSAS認証トークンの使用を許可します

• 数十万のファイルを含むバックアップの空のディレクトリへの barman restore を大幅に高速化します。

バグ修正

• ユーザーに「userepl」権限がない場合でもバックアップ権限チェックは失敗しなくなり、必要な権限が欠落している場合には、より良いエラーメッセージを結果ことができます#318および#319。

2.132021-07-26

重要な変更

• Azure Blob Storageのサポートをbarman-cloudに追加します

• --tablespace name:location を介してbarman-cloud-restoreでのテーブルスペースのリマッピングをサポート

• barman-cloud-backupおよびbarman-cloud-wal-archiveをBarmanフックスクリプトとして実行できるようにして、 Barmanサーバーからクラウドストレージにデータを中継できるようにします

バグ修正

• idle_in_transaction_session_timeoutが原因でStopバックアップが失敗する EnterpriseDB/barman#333

• xlog.dbエントリの更新におけるbackupとarchive-wal間の競合状態を修正します #328

• barman-cloud-backupのシンボリックリンクであるPGDATAを処理すると、リストア時に「seeking attempts is not allowed」エラーが発生しました #351

• 元がシンボリックリンクの場合、リストア時にpg_walを再作成します #327

• リストア時にテーブルスペースのpg_tblspcシンボリックリンクを再作成します #343

• barman-cloud-backup-listで、たとえば、Glacierストレージにあるため、読み取ることができないバックアップをスキップさせます #332

• -d database オプションをbarman-cloud-backupに追加して、最初に接続するデータベースを指定します #307

• boto3クライアントをピクルしようとすると発生する、Python 3.8以降のbarman-cloud-backupからの“Backup failed upgradeing data”エラーを修正します #361

• デフォルトで暗号化が有効になっていないバケットのS3でサーバーサイドの暗号化を正しく有効にします。

  Barman 2.12では、barman-cloud-backupの --encryption オプションは、暗号化が有効になっていないS3バケットにバックアップが保存されている場合、バックアップのコンテンツの暗号化を正しく有効にしませんでした。これに該当する場合は、古いバックアップを削除し、 Barman 2.13で新しいバックアップを取ることを検討してください。

  S3バケットの暗号化がデフォルトで有効になっている場合これをお勧めしますが、これは影響しません。

2.12.12021-06-30

バグ修正

• 他の target-* リカバリオプションでtarget-tliを指定できるようにします。

• barman-cloud-backup-listのマンページの誤ったNAMEを修正します。

• SIGALRMが無視される場合でもエラーを発生させません。

• Postgres 13からwal_keep_segmentsではなく、wal_keep_sizeを取得します。

2.122020-11-05

重要な変更

• local-rsyncと呼ばれる新しいbackup_methodオプションを導入します。これは、PostgreSQLと同じサーバーにBarmanがインストールされ、rsyncを直接使用してベースバックアップを取得し、SSHレイヤーをバイパスする場合を対象としています。

バグ修正

• ワーカープロセスでのboto接続の破損を回避します。

• テスト中にPostgreSQLへの接続試行を回避します。

2.112020-07-09

重要な変更

• クラウド関連のすべてのユーティリティを含むbarman-cli-cloudパッケージの紹介。

• barman-cloud-wal-restoreを追加して、オブジェクトストアからbarman-cloud-wal-archiveで以前にアーカイブされたWALファイルを復元します。

• barman-cloud-restoreを追加して、以前にbarman-cloud-backupで取得したバックアップをオブジェクトストアから復元します。

• barman-cloud-backup-listに、オブジェクトストアでbarman-cloud-backupを使用して取得されたバックアップをリストします。

• barman-cloud-backupの任意のアーカイブサイズのサポートを追加します。

• –endpoint-urlオプションのサポートをクラウドユーティリティに追加します。

• PG 10+の厳密なスーパーユーザー要件を削除しますKaarel Moppelによる。

• barmanの-log-levelランタイムオプションを追加して、特定のコマンドのデフォルトのログレベルをオーバーライドします。

• PostgreSQL 13のサポート

バグ修正

• barman-cli GH-257のSSH接続でのメッセージと警告を抑制します。

• barman-cloud-backup GH-259でアップロードされたパーツを取得する際の競合状態を修正します。

• バックアップ後にPostgreSQL接続を閉じます GH-258

• accept-wal –reset GH-260で初期化されていないレプリケーションスロットがないかを確認します。

• begin_walに基づいて行動する前に、begin_walが有効になっていることを確認します GH-262

• カスタムセグメントサイズGH-287を使用したXLOG / WAL演算のバグを修正します。

• 最近のrsyncとのrsync互換性エラーを修正しました。

• PostgreSQLClientバージョンの解析を修正しました。

• 非ASCIIメッセージを使用したPostgreSQL例外処理を修正します。

• 各postgres接続に空のsearch_pathがあることを確認します。

• backup.infoファイルの読み取り中はPostgreSQLへの接続を避けてください。

RPM / Aptパッケージを介してインストールされた既に barman-cloud-wal-archive または barman-cloud-backup を使用しており、システムをアップグレードする場合、barman-cli-cloudパッケージをインストールする必要があります。すべてのクラウド関連ツールは、以前に barman-cli に同梱されていた barman-cloud-wal-archive および barman-cloud-backup を含むbarman-cli-cloudパッケージの一部になりました。その理由は、クラウドユーティリティの要件であるboto3ライブラリの複雑な依存関係管理です。

2.102019-12-05

重要な変更

• get-walおよびbarman-wal-restoreを使用して.partial WALファイルをプルし、リカバリシナリオのrestore_commandでBarmanサーバーから部分的なWALファイルのコンテンツを取得できます。この機能は、RPO=0リカバリ操作を簡素化および強化します。

• PostgreSQLシステム識別子をサーバーディレクトリとバックアップ情報ファイル内に保存します。 checkコマンドを改善して、システム識別子とアクティブな接続標準およびレプリケーションおよびディスク上のデータとの一貫性を検証します。

• barman-cloud-wal-archiveと呼ばれる新しいスクリプトがbarman-cliパッケージに追加され、PostgreSQL archive_commandを使用してAWS S3と互換性のあるクラウドオブジェクトストレージサービスにWALファイルを直接シッピングします。暗号化と圧縮をサポートしています。

• barman-cloud-backupと呼ばれる新しいスクリプトがbarman-cliパッケージに追加され、ローカルのPostgreSQLサーバーからAWS S3と互換性のあるクラウドオブジェクトストレージサービスにベースバックアップを直接出荷します。暗号化、並列アップロード、圧縮をサポートしています。

• server/globalオプションcreate_slotを介したレプリケーションスロットの自動作成。 autoに設定されている場合、streaming_archiveが有効であり、slot_nameが定義されている場合、 Barmanはレプリケーションスロットを作成します。下位互換性のため、デフォルト値はmanualです。

• '-w/–wait'オプションをbackupコマンドに追加し、バックアップが完了したと判断する前に、必要なすべてのWALファイルがアーカイブされるまでBarmanを待機させます。 –wait-timeoutオプションデフォルト0、タイムアウトなしも追加します。

• Barman出力、特にbarman promote InfoSecからのパスワードを秘匿化する

• 最後の部分ファイルが現在の場所または存在する場合はレプリケーションスロットとアラインメントされていることを確認することにより、receive-wal –resetコマンドの堅牢性を向上させます。

• ドキュメントの改善

バグ修正

• PGDATA GH-245内のテーブルスペースを除外する場合の間違った文字列マッチング操作。

• WAL削除フックスクリプトGH-240のマイナー修正。

• PostgreSQL接続生存性チェックGH-239を修正します。

2.92019-08-01

重要な変更

• GUCオプションとシグナルファイルrecovery.signalおよびstandby.signalを介してリカバリとスタンバイ設定を管理する新しい方法をサポートすることにより、PostgreSQL 12を透過的にサポートします

• –bwlimitコマンドラインオプションを追加して、バックアップおよびリカバリーコマンドの帯域幅制限を設定します

• 最新のバックアップがWAITING_FOR_WALSの場合、checkコマンドのWALアーカイブ障害を無視する

• PostgreSQL 10以降でrecoverコマンドのリカバリターゲットログシーケンス番号を設定するために-target-lsnオプションを追加

• –spool-dirオプションをbarman-wal-restoreに追加して、ユーザーがスプールディレクトリの場所をデフォルトから変更できるように、同じサーバー上に複数のPostgreSQLインスタンスがある場合の競合を回避できます Drazen Kacarに感謝します。

• barman_xlog ディレクトリの名前をbarman_walに変更します

• コマンド出力をJSONオブジェクトとしてエクスポートし、外部ツールやシステムとの統合を促進するためのJSON出力ライタMarcin Onufry Hlybinに感謝します。このリリースでは実験的。

バグ修正

• replication-status は、スロットのないストリーマーを表示しない GH-222

• 接続が生きていることを確認するとき「SELECT 1」クエリー、PostgreSQL接続GH-149のステータスを保存します。これにより、トランザクション内アイドルタイムアウトにより接続が終了し、同時バックアップが失敗する場合が修正されます。

2.82019-05-17

重要な変更

• パッシブノードのインクリメンタルバックアップコピーのgeo冗長性でのreuse_backupのサポートを追加します

• より汎用的なdateutil.parserの代わりにstrptimeを使用することにより、rsyncベースのコピーのパフォーマンスを向上させます #210

• '-test'オプションをbarman-wal-archiveおよびbarman-wal-restoreに追加して、 Barmanサーバーとの接続を確認します

• PostgreSQL 9.5がPGDGによってEOL宣言されると、将来のデフォルト値がclusive_backupからconcurrent_backupに変更されるため、backup_optionsが明示的に設定されていない場合に文句を言う

• show-serverおよび診断コマンドの追加設定を表示しますarchive_timeout、data_checksums、hot_standby、max_wal_senders、max_replication_slots、およびwal_compression。

• Barmanにbarman-cliプロジェクトをマージします

マイナー変更

• 非アクティブなサーバーのcheck –nagiosのメッセージングを改善します。

• recoveryコマンドを使用してリモートSSHコマンドをログに記録します。

• replication-statusコマンドでの論理デコード接続を非表示にします。

このリリースは、Python 3を公式にサポートし、Python 2将来のリリースで廃止される可能性があります非推奨にします。

PostgreSQL 9.3以前は、 Barmanのこのリリースから非推奨になりました。スタンバイからのバックアップのサポートは、PostgreSQL 9.4以降、およびスタンバイからのWAL出荷に制限されています。詳細については、ドキュメントを参照してください。

バグ修正

• Python 3のget-walのエンコードエラーを修正しました。Jeff Janes、#221

• exclude_and_protect_filterを修正しましたJeff Janes、#217

• WALをリセットするときに偽のメッセージを削除します Jeff Janes、#215

• プライマリに最初のバックアップより古いWALがある場合のsync-walsエラーを修正します。

• synchronous_standby_names設定での二重引用符のサポート。

2.72019-03-12

重要な変更

• パラレルバックアップ中のエラー処理を修正しました。以前は、コピー中の回復不能なエラーがbarmanの内部状態を破損する可能性があり、SIGTERMでのbarmanプロセスの手動killとPostgreSQLで実行中のバックアップの手動クリーンアップが必要でした。 GH#199

• 入力および出力GH#194およびGH#196でのUTF-8文字のサポートを修正しました。

• 地理的冗長性の最初の同期で履歴/バックアップ/部分ファイルを無視する GH#198 。

• cronがブレークする原因となった地理的冗長性によるネットワーク障害を修正します GH#202 。

• 9.2より前のPostgreSQLのバックアップ検証を修正しました。

• さまざまなドキュメントの修正。

2.62019-02-04

重要な変更

• 地理的冗長性のサポートを追加し、3つの新しいコマンドsync-info、sync-backup、sync-walsを導入します。地理的冗長性により、 BarmanサーバーはPostgreSQLサーバーの代わりに別のBarmanサーバーをデータソースとして使用できます。

• barman-cliに含まれるbarman-wal-archiveスクリプトを使用して、 BarmanがPostgreSQLのarchive_commandを介してWALファイルを安全に受信できるput-walコマンドを追加します。

• checkコマンドにANSIカラーサポートを追加します。

バグ修正

• 空のWALディレクトリを使用してスタンバイでswitch-walを修正します。

• wait_for_walメソッドでのアーカイバーロックを尊重します。

• WAL圧縮検出アルゴリズムを修正します。

• コンカレント停止バックアップエラーのcurrent_actionを修正します。

• バックアップを検証するときに、ロックファイルビジーをエラーとして扱わないでください。

2.52018-10-23

重要な変更

• PostgreSQL 11のサポートを追加

• check-backupコマンドを追加して、ベースバックアップの一貫性に必要なWALファイルがアーカイブに存在することを確認します。 Barmanは、ベースバックアップの完了後に新しい状態WAITING_FOR_WALSを追加し、バックアップの先頭から最後までのすべてのWALファイルが存在することを確認するとDONEに設定します。このコマンドは、通常のcronメンテナンスジョブに含まれます。 Barmanは、 WAITING_FOR_WALS状態にあるバックアップを復旧しようとしているユーザーに通知するようになりました。

• switch-xlog –archiveがスタンバイで動作できるようにしますアーカイブ部分のみ

バグ修正

• 外部コマンド出力の読み取りデコードエラーを修正しました 問題174

• WALストリーミングとスタンバイからのバックアップに関するドキュメントを修正します。

2.42018-05-25

重要な変更

• バックアップ削除前/後のための標準および再試行フックスクリプトを追加します。

• リカバリー前/後用の標準および再試行フックスクリプトを追加します。

• WAL削除前/後のための標準のフックスクリプトと再試行フックスクリプトを追加します。

• –standby-modeオプションをbarman recoveryに追加して、事前に生成されたrecovery.confにstandby_mode = onを追加します。

• –target-actionオプションをbarman recoveryに追加し、ユーザーが事前に生成されたrecovery.confファイルにシャットダウン、一時停止、またはプロモートを追加できるようにします。

• 一貫性チェックによりポイントインタイムリカバリーの使いやすさを向上させますたとえば、復旧時間はバックアップの終了時間後です。

• マイナーなドキュメントの改善。

• Python 3.3のサポートを終了します。

バグ修正

• リモートのget_file_contentメソッドGitHub #151を修正し、インクリメンタルリカバリーが発生しないようにします。

• コマンドのUnicodeの問題GitHub #143および#150。

• pg_basebackup >= 10の場合、 –wal-method=noneを追加します GitHub #133 。

• プロセスマネージャーモジュールがロックファイルのコンテンツを上書きするのを停止する

• rsync出力の解析ルールを緩和する

• ストリーミングディレクトリ内の消えたファイルを無視する

• 大文字と小文字を区別しないスロット名GitHub #170

• DataTransferFailure.from_command_error()の復元力を高める GitHub #86

• command()の名前をbarman_command()に変更しますGitHub #118

• 同期スタンバイ名リストが設定されていない場合は初期化する GitHub #111

• 正しいプレースホルダーの順序GitHub #138

• レプリケーション接続の日付スタイルをisoに強制する

• deleteコマンドでバックアップが削除されない場合、エラーを返します

• is_power_of_two(None)を呼び出す際の例外を修正

• ダウングレードした同期スタンバイの名前付けデバッグするメッセージGitHub #89

2.32017-09-05

重要な変更

• PostgreSQL 10にサポートを追加します

• PostgreSQL 10の名前の変更に従ってください。

  • switch-xlogコマンドの名前がswitch-walに変更されました。

  • コマンド出力では、xlogワードがWALに変更され、ロケーションがLSNに変更されました。

• –network-compression / –no-network-compressionオプションをbarman recoveryに追加して、実行時のネットワーク圧縮を有効または無効にします

• 一貫した状態に到達したときにリカバリを終了するように、recoverコマンドに-target-immediateオプションを追加しますバックアップの終了、PostgreSQL 9.4から利用できます

• barman statusコマンドを使用してクラスター状態マスターまたはスタンバイを表示します

• ドキュメントの改善

バグ修正

• Parallel_jobs > 1での高いメモリ使用量を修正する #116

• パラレルコピーを使用したエラーの処理の向上#114

• システム例外を使用してバーマン診断をより堅牢にする

• archive-walに.tmp拡張子を持つファイルを無視させます

2.22017-07-17

重要な変更

• repair_jobsグローバル/サーバーオプションを使用してバックアップ/リカバリーのパラレルコピーを実装しますが、backupおよびrecoverコマンドの-jobsまたは-jランタイムオプションでオーバーライドされます。パラレルバックアップは、rsyncコピー方法でのみ使用できます。デフォルトでは、1に設定されています以前のバージョンとの動作の互換性のため。

• PostgreSQL 8.4以降のカスタムWALサイズをサポートします。バックアップ時に、 BarmanはPostgreSQLからwal_segment_sizeおよびwal_block_size値を取得し、必要な計算を計算します。

• checkコマンドを改善して、アーカイバー=オフの場合に受信ディレクトリが空であり、ストリーミング_アーカイバー=オフの場合にストリーミングディレクトリが空であることを確認します#80

• external_configurationをbackup_optionsに追加して、ユーザーがPGDATADebian/Ubuntuインストールのデフォルト内にない場合、構成ファイルのバックアップを無視するようにBarmanに指示できるようにします。この場合、 Barmanは警告を表示しません。

• バーマンリカバリーに-get-walおよび-no-get-walオプションを追加します

• checkコマンドのmax_incoming_wals_queueグローバル/サーバーオプションを追加して、アーカイバーとストリーミング_アーカイバーの両方の着信WALディレクトリに指定された値より多くのファイルが含まれている場合に、ノンブロッキングエラーが返されるようにします。

• ドキュメントの改善

• ファイル形式の変更

  • backup.infoファイルの形式が変更されました。このため、 Barman 2.2で取得したバックアップは、以前のバージョンのBarmanで読み取ることができません。ただし、以前のバージョンで取得したバックアップは、 Barman 2.2で読み取ることができます。

バグ修正

• レプリケーションステータスがスタンバイに対して機能することを許可します

• pg_basebackupを開始する前にPostgreSQL接続を閉じます #104、#108

• 特殊文字を含むパスを安全に処理する

• ストリーミングソースのプロモーション後に.partialファイルをアーカイブする

• リカバリー中にディレクトリを再帰的に作成する SF#44

• xlog.dbロックの改善 #99

• リカバリー中にtablespace_mapファイルを削除する #95

• 接続がドロップした場合はPostgreSQLに再接続します SF#82

2.12017-01-05

重要な変更

• –archiveおよび-archive-timeoutオプションをswitch-xlogコマンドに追加します。

• PostgreSQL 10#73の暫定サポート。

• マイナーな追加

  • 最後にアーカイブされたWAL情報を診断出力に追加します。

  • 開始時間と実行時間をdeleteコマンドの出力に追加します。

バグ修正

• 非アクティブなサーバーでのget-walコマンドの結果失敗

• stable_archive_namesおよびstreaming_backup_nameオプションをグローバルにする #57

• 転送中に切り詰められたファイルによるrsync障害を修正する #64

• 圧縮履歴ファイルを正しく処理する #66

• リカバリーの準備時にpg_tblspcのシンボリックリンクの逆参照を回避する #55

• 最後のアーカイブ失敗の比較を修正しました #40、#58

• postgresql.confが書き込み可能でない場合のリカバリの失敗を回避する #68

• replication-statusコマンドの出力を修正しました #56

• pg_basebackupのようなバックアップからファイルを除外する #65、#72

• テーブルスペースのコピー中に他のPostgresバージョンからディレクトリを除外する #74

• 再試行フックスクリプトオプションをグローバルにする

2.02016-09-27

重要な変更

• backup_method=postgresを使用したPostgreSQLストリーミングレプリケーションプロトコルを介したpg_basebackupおよびbaseバックアップのサポート PostgreSQL 9.1以降が必要

• slot_name構成オプションと、receive-walコマンドの-create-slotおよび-drop-slotオプションを介した物理レプリケーションスロットのサポートPostgreSQL 9.4以降が必要。 slot_nameが指定され、streaming_archiverが有効になっている場合、receive-walはpg_receivexlogと透過的に統合し、スロットが存在し、アクティブに使用されていることを確認します

• PostgreSQL 9.6で導入された新しいバックアップAPIのサポート。これは、同時バックアップと、標準のrsyncバックアップ方法を使用してスタンバイサーバーからのバックアップを透過的に有効にします。同時バックアップは、pgespresso拡張機能を介してPostgreSQL 9.2〜9.5バージョンでのみ可能でした。新しいバックアップAPIは、将来的にpgespressoを冗長化します

• 適切に構成されている場合、 Barmanは、WALストリーミングの観点から同期スタンバイとして機能できます。マスター上のsynchronous_standby_names優先リストのstreaming_archiver_nameを適切に設定し、レプリケーションスロットのサポートを有効にすることにより、receive-walコマンドをPostgreSQL同期レプリケーションクラスターの一部にすることができ、RPO=0 PostgreSQL 9.5.5以降が必要です。

• barman-wal-restoreは、Pythonで書かれた標準の堅牢なスクリプトで、クラスターのスタンバイサーバーのrecovery.confファイルでrestore_commandとして使用できます。 SSHを介してget-walを効率的に呼び出すことにより、WALファイルのリモート並列取得をサポートします。現在、barman-cliと呼ばれる別のプロジェクトとして利用できます。 get-walがrecovery_optionsにリストされている場合、リモートリカバリにはbarman-cliパッケージが必要です

• check_timeoutグローバル/サーバー構成オプションを使用してcheckコマンドの最大実行時間を制御しますデフォルトで30秒

• archive-wal実行によって処理されるWALセグメントの数を、それぞれ標準のアーカイバーとreceive-walからのWALセグメントのアーカイブを制御するarchiver_batch_sizeおよびstreaming_archiver_batch_sizeグローバル/サーバーオプションを介して制限します

• チェック操作中のXLOGデータベースのロックを削除しました

• show-backupコマンドはタイムラインを認識するようになり、特定のベースバックアップのリカバリターゲットとして使用できるタイムラインを適切に表示します。内部的に、 Barmanは.historyファイルを解析できるようになりました

• コピー操作で問題が発生した場合の再試行メカニズムの背後にあるロジックを改善しました。これには、バックアップ rsyncおよびpostgresおよびリモートリカバリrsyncが含まれます

• リモートコマンドおよび物理コピーインターフェイスを含むコードのリファクタリング

バグ修正

• ストリーミングからの.historyファイルを正しく処理する

• PostgreSQL 9.1のレプリケーションステータスを修正する

• 送信および書き込み場所が利用できない場合のレプリケーションステータスを修正する

• pg_receivexlog終了時の誤解を招くメッセージを修正

1.6.12016-05-23

マイナー変更

• get-walコマンドに-peekオプションを追加して、Barmanのアーカイブから既存のWALファイルを検出します

• PostgreSQLサーバーに接続しているストリーミングレプリケーションクライアントのステータスを監視するためのreplication-statusコマンドを追加します。 –targetオプションを使用すると、ユーザーは要求をホットスタンバイサーバーまたはWALストリーミングクライアントのみに制限できます

• switch-xlogコマンドを追加して、WALファイルのPostgreSQLサーバーへのスイッチを要求します。 `-force」を介して、事前にチェックポイントを発行します

• repairing_archiverが有効になっているときに適切なapplication_nameをpg_receivexlogに設定するstreaming_archiver_nameオプションを追加します PostgreSQL 9.3以降のみ

• PostgreSQLの標準接続を使用して スーパーユーザー 特権を確認する #30

• WALアーカイブが空でないことを確認します

• サーバーがダウンしているときにマスターの`backup_label`を確認する

• barman-wal-restore contribスクリプトを改善

バグ修正

• “failed tasks”チェックを致命的でないものとして扱う

• get-walの`-x`オプションの名前を`-z`に変更します

• archive_mode=alwaysのPostgreSQL 9.5のサポートを追加#32

• 必要に応じてPostgreSQL接続を適切に閉じる

• pg_receive_xlogバージョン9.2のreceive-walを修正

1.6.02016-02-29

重要な変更

• streaming_conninfoサーバーオプションを介したストリーミングレプリケーション接続のサポート

• BarmanがPostgreSQLのネイティブストリーミングプロトコルを介してWALファイルを受信できるようにするstreaming_archiverオプションのサポート。 'on'に設定すると、pg_receivexlogに依存してWALデータを受信し、目標リカバリポイントを削減します。現在、WALストリーミングは追加機能です標準のログアーカイブが引き続き必要です。

• streaming_archiverがオンのときに、WALストリーミングのpg_receivexlogをラップするreceive-walコマンドを実装します。ストリーミングプロトコルを介してWALファイルの受信を停止するには、 –stopオプションを追加します。 –resetオプションを追加して、ストリーミングステータスをリセットし、Postgresの現在のxlogからリスタートします。

• cronコマンドを介したreceive-walコマンドの自動管理スタートアップと停止

• path_prefix構成オプションのサポート

• PostgreSQLのarchive_commandを介したログ配布を介して、特定のサーバーの継続的なWALアーカイブを有効にするアーカイバーオプション現在オンに固定されています

• streaming_wals_directoryおよびerrors_directoryオプションのサポート

• archive-walコマンドでのWAL重複の管理とcheckコマンドとの統合

• Streaming_archiveが有効になっているときにpg_receivexlogがcheckコマンドで実行されているかどうかを確認する

• 失敗したバックアップがcheckコマンドに存在するかどうかを確認する

• 受信ディレクトリで圧縮されたWALファイルを受け入れます

• pigzコンプレッサーのサポートを追加します Stefano Zacchiroli zack@upsilon.ccに感謝します

• pygzipおよびpybzip2コンプレッサーを実装しますChristoph Moench-Tegeder christoph@2ndquadrant.deの初期アイデアに基づいています

• バックアップの最後に暗黙的な復元ポイントを作成する

• バーマンステータスのPostgreSQLデータファイルの現在のサイズ

• PostgreSQL 9.5サーバーのarchive_mode=alwaysを許可しますChristoph Moench-Tegeder christoph@2ndquadrant.deに感謝します

• PostgreSQLへの接続を担当するコードの完全なリファクタリング

• サブプロセスに関するcronコマンドのメッセージを改善します

• Python > = 3.3のネイティブサポート

• 行動の変化

  • archive-wal中にWALファイルのトラッシュを停止する commit:e3a1d16

バグ修正

• アトミックWALファイルのアーカイブ#9および#12

• “-c”オプションをBarmanサブプロセスに伝播する#19

• バックアップ削除中のバックアップIDの管理を修正する #22

• archive-walの堅牢性とログメッセージを向上させる #24

• パラメーターが欠落している場合のエラー処理を改善する

1.5.12015-11-16

マイナー変更

• 特定のサーバーでWALメンテナンス操作を実行する`archive-wal'コマンドのサポートを追加します

• `cron`コマンドの「サーバーごとの」同時実行性のサポートを追加します

• xlog.dbエラーの管理の向上

• WALファイルの混合圧縮タイプのサポートを追加します SF.net#61

バグ修正

• リカバリ中のリテンションポリシーチェックを回避する

• PostgreSQLバージョン<9.0での`wal_level`チェックを回避する #3

• バックアップサイズの計算を修正する #5

1.5.02015-09-28

重要な変更

• ユーザーが特定のサーバーのアーカイブからWALファイルを取得できるget-walコマンドのサポートを追加します

• 再試行フックスクリプト、 Barmanが成功するまで実行しようとする特別な種類のフックスクリプトのサポートを追加します

• サーバーのアクティブな構成オプションを追加して、Falseに設定してサーバーを一時的に無効にします

• ロックファイルの場所を変更するためのbarman_lock_directoryグローバルオプションを追加しますデフォルトでは`barman_home`

• バックアップを開始する前にチェックの完全なスイートを実行し、1つ以上のチェックが失敗した場合にスキップします

• 実行中のバックアップの削除を禁止する

• バックアップおよびリカバリー操作中にPostgreSQLサーバーのinclude指示子を分析する

• Barmanの構成に競合するパスのチェックを追加します。サーバー内を一時的に無効にすることによると、サーバー間で任意のサーバーへのコマンドを拒否することにより。

• wal_levelのチェックを追加

• barman get-walと組み合わせて、スタンバイサーバーでrestore_commandとして使用するbarman-wal-restoreスクリプトを追加します

• エラー管理のための標準の一貫したポリシーを実装する

• バックアップのキャッシュ管理の向上

• 単体テストでの構成の管理の向上

• チュートリアルとマニュアルページのソースがMarkdown形式に変換されました

• Sphinxを介してコードドキュメントを追加

• バックアップおよびrecoverコマンドの管理を担当するコードの完全なリファクタリング

• バックアップの内部ディレクトリ構造の変更

• copy_methodオプションを導入します現在rsyncに修正されています

バグ修正

• PostgreSQL構成ファイルで`=`を使用せずにオプションを管理する

• タイムライン履歴ファイルの保存修正#70

• SUSE Linuxでのrsyncの回避策クローズ#13および#26

• postgresql.auto.confの危険な設定を無効にするクローズ#68

1.4.12015-05-05

マイナー変更

• xlogdbファイルの管理が改善され、更新時に正しくfsyncされるようになりました。また、rebuild-xlogdbコマンドは一時的な新しいファイルを操作するようになり、完了するとメインファイルを上書きします。

• dateutilモジュールの互換性のための単体テストを追加

• PEP 440ルールに従ってBarmanバージョンを変更し、Python 3.4でのテストのサポートを追加しました

バグ修正

• 最初のバックアップが空の場合にWALアーカイブが動作を停止する問題を修正したクローズ#64

• Barmanリカバリーのエラー処理中の例外を修正するクローズ#65

• バックアップ後、cronアクティビティをWALアーカイブのみに制限しますクローズ#62

• backup deleteコマンドの堅牢性とエラー報告の向上クローズ#63

• show-backupコマンドで報告されるWAL生産率の計算を修正します

1.4.02015-01-26

重要な変更

• resume_backupグローバル/サーバーオプションを介したインクリメンタル ベースバックアップの実装。使用可能な値はoff 無効、デフォルト、copy 未変更のファイルが転送されないようにする、およびlink ハードリンクを介した重複排除を許可します。

• 再利用_backup=リンクを使用する場合、重複排除効果を保存および表示します。

• check、show-server、およびstatusコマンドにpg_stat_archiver PostgreSQL 9.4の透過的なサポートを追加しました。

• 成功したバックアップの最後にWALメンテナンスを呼び出すことにより、管理が向上しました。

• 同時バックアップケースと排他的バックアップケースを区別することにより、未使用のWALファイルをゴミ箱に入れる方法を変更しました。

• WAL統計計算のパフォーマンスの向上。

• 欠落しているpg_ident.confは、エラーではなく警告として扱います。

• 残りのyield呼び出しを削除することにより、出力レイヤーをリファクタリングしました。

• rsyncがシステムパスにあることを確認します。

• 履歴ファイルをWAL管理に含めます。

• より多くの単体テストを介したロバスト性の向上。

バグ修正

• バグ#55を修正しました ディレクトリでのfsync EINVALエラーを無視します。

• 修正されたバグ#58保持ポリシーの削除。

1.3.32014-08-21

重要な変更

• 管理者がカタログ内の最後のバックアップの最大保存期間を設定できる新しいグローバル/サーバーオプションであるlast_backup_max_ageを追加しました。定期的なバックアップ実行に関する問題を検出しやすくなります

• 2つのグローバル/サーバーオプション“basebackup_retry_times”と“basebackup_retry_sleep”を導入することにより、“barmanbackup”の堅牢性が向上しました。これらのオプションを使用すると、管理者は、失敗後のコピー操作の試行回数と、再試行までの待機秒数をそれぞれ指定できます。

• 以前のrsync呼び出しをいくつかのことに分割することにより、既存のディレクトリのrsyncを介したリカバリプロセスインクリメンタルリカバリーを改善しました-必要な場合にのみチェックサム制御を呼び出す

• PostgreSQL 8.3のサポートを追加しました

マイナー変更

• コンマ区切りリスト値構成オプションのサポート

• 「barmanbackup」および「barman cron」中にバックアップファイルとWALファイルでfsync()を呼び出すことにより、バックアップの耐久性が向上しました

• “barman check –nagios”のNagios出力の向上

• 「barman show-backup」でのWALの表示圧縮率

• バーマンバックアップの実行中にキーボードの中断CTRL-Cが正しく処理される

• バックアップの停止に関する障害のエラーメッセージの改善

• 単体テストの幅広いカバレッジ

バグ修正

• “barman recovery”中にリモートサーバーに“recovery.conf”をコピーします#45

• プレ/ポストアーカイブフックスクリプトを正しく検出する #41

1.3.22014-04-15

バグ修正

• PostgreSQL 8.4との非互換性を修正しましたクローズ#40、バージョン1.3.1で導入されたバグ

1.3.12014-04-14

マイナー変更

• “pgespresso”拡張機能を使用するPostgreSQL 9.2および9.3サーバーの同時バックアップのサポートを追加しました。この機能は、“backup_options”構成オプションglobal/serverによって制御され、“concurrent_backup”に設定されている場合にアクティブになります。コンカレントバックアップにより、DBAはストリーミングレプリケートスタンバイから完全なバックアップ操作を実行できます。

• Barmanシステムに関する重要な情報を出力する「barman promote」コマンドを追加しましたサポートと問題解決に非常に役立ちます

• エラーメッセージと例外処理インターフェイスの改善

バグ修正

• PGDATAディレクトリ内で作成されたテーブルスペースのリカバリーのバグを修正しましたバージョン1.3.0で導入されたバグ

• cronジョブで使用されるコマンドのクワイエットモード用、未処理の-qオプションのマイナーバグを修正しましたバージョン1.3.0で導入されたバグ

• 軽微なバグ修正とコードのリファクタリング

1.3.02014-02-03

重要な変更

• 新しいFieldListFileクラスinfofileモジュールを使用するようにバックアップメタデータのBackupInfoクラスをリファクタリングしました

• Nagios NagiosOutputWriterクラスとの統合を促進するために、専用モジュールを使用するように出力レイヤーをリファクタリングしました

• stdin / stderr / stdoutチャネルを分離するためにリファクタリングされたサブプロセス処理command_wrappersモジュール

• リファクタリングされたフックスクリプト管理

• 構成クラスからロギング構成とユーザーIDの適用を抽出しました。

• `pre_archive_script`および`post_archive_script`構成オプションを介して、WALファイルがアーカイブされる前後に実行されるフックスクリプトのサポート。

• –immediate-checkpointコマンドオプションと`immediate_checkpoint`構成オプションを使用して即時チェックポイント機能を実装

• `network_compression`構成オプションを介してリモートバックアップとリカバリーのネットワーク圧縮を実装しました#19

• `rebuild-xlogdb`コマンドを実装しましたクローズ#27および#28

• PGDATAディレクトリ内にあるテーブルスペースの重複排除を追加しました

• リモートディレクトリの準備を実行することにより、ローカルリカバリと同じように動作するようにリモートリカバリコードをリファクタリングしましたリモートユーザーがリモートサーバーに対する適切な権限を持っていることを前提としています。

• `barmanbackup'は、完全なバックアップを実行する前にサーバーディレクトリの作成を試行するようになりました#14

バグ修正

• バグ22の修正 テーブルスペースの再配置に関するドキュメントの改善

• 修正したバグ31'barman cron'は、ロックファイルのディレクトリのアクセス許可をチェックします

• 修正したバグ32 cronアクティビティ中のxlog.db読み取りアクセス

1.2.32013-09-05

マイナー変更

• PostgreSQL 9.3のサポートを追加しました

• “-target-name”復旧オプションのサポートを追加しました。これにより、以前にpg_create_restore_pointで指定した名前付けポイントに復元できますPostgreSQL 9.1以降のユーザーのみ

• Python 3互換性の導入

バグ修正

• barman.lockfileでのflock()の使用に関するバグ27を修正しました Damon Snyder damonsnyder@users.sf.netに感謝します。

1.2.22013-06-24

バグ修正

• Python 2.6の互換性を修正

1.2.12013-06-17

マイナー変更

• バックアップおよびリカバリー操作のI/O帯域幅KBPS単位を制限できる「bandwidth_limit」グローバル/サーバーオプションを追加しました

• テーブルスペースごとにバックアップおよびリカバリー操作のI/O帯域幅KBPS単位を制限できる「tablespace_bandwidth_limit」グローバル/サーバーオプションを追加しました

• デフォルトの場所として/etc/barman/barman.confを追加しました

バグ修正

• FAILEDバックアップでのminimum_redundancyチェックのトリガーを回避します Jérôme Vanandruelに感謝します

1.2.02013-01-31

重要な変更

• 保持ポリシーを適用する方法を定義する「retention_policy_mode」グローバル/サーバーオプションを追加しました現在は「auto」のみ

• サーバーに保持するバックアップの最小数を定義する“minimum_redundancy”グローバル/サーバーオプションを追加しました

• 冗長性たとえば リダンダンシー4またはリカバリウィンドウ例 3か月のリカバリウィンドウに基づいてリテンションポリシー管理を定義する「retention_policy」グローバル/サーバーオプションを追加しました。

• ロギングインフラストラクチャ、“check”および“status”コマンドにリテンションポリシーのサポートを追加しました

• “check”コマンドに最小冗長制御が統合されました

• 保持ポリシーの状態有効、廃止、および廃止の可能性を「show-backup」および「list-backup」コマンドに追加しました

• `all`キーワードはサーバー名として禁止されました

• –nagiosオプションを介して'check'コマンドにNagiosプラグイン出力の基本サポートを追加しました

• Barmanには、argh => 0.21.2およびargcomplete-が必要になりました

• マイナーなバグ修正

1.1.22012-11-29

マイナー変更

• ディレクトリから複数のサーバー構成ファイルを含めることができる「configuration_files_directory」オプションを追加しました

• 特別なバックアップIDのサポート最新、最後、古い、最初

• `list-backup`コマンドへの複数のサーバーの管理。 `barman list-backup all'は、構成されているすべてのサーバーのバックアップをリストするようになりました。

• PostgreSQL > = 9.0の“application_name”管理を追加

バグ修正

• 修正したバグ18.削除中に見つからない場合は、不足しているWALファイルを無視します

1.1.12012-10-16

バグ修正

• recoveryコマンドの回帰を修正します。

1.1.02012-10-12

重要な変更

• `pre_backup_script`および`post_backup_script`構成オプションを介して`backup`コマンドの前後に実行されるフックスクリプトのサポート。

• `backup`コマンドへの複数のサーバーの管理。 `barmanbackup all'は、構成されているすべてのサーバーを反復的にバックアップするようになりました。

• postgresql.confファイルでファイルの場所オプションが定義されている場合、リカバリーに警告を追加します 問題10

• 宛先ディレクトリに`:`文字が含まれる場合クローズ#4または無効なテーブルスペース再配置ルールが渡された場合、recoverコマンドでフェイルファースト

• 排他的バックアップが既に実行されているためにpg_start_backup()呼び出しが失敗した場合、情報メッセージをレポートしますクローズ#8

バグ修正

• バグ9.2問題を修正しました pg_tablespace_location()

1.0.02012-07-06

重要な変更

• 異なるバージョンの複数のPostgreSQLサーバーのバックアップ。 PostgreSQL 8.4以降のバージョンがサポートされています。

• 安全なリモートバックアップのサポートSSHを介して

• すべてのサーバーのバックアップのカタログの管理。ユーザーは新しいバックアップを簡単に作成、古いバックアップを削除、または復元できます。

• 事前定義されたgzipおよびbzip2またはカスタムの両方の圧縮/解凍フィルタを使用して、サーバーごとに構成できるWALファイルの圧縮

• グローバルおよびサーバーごとの指示子を使用したINI構成ファイルのサポート。構成ファイルのデフォルトの場所は/etc/barman.confまたは~/.barman.confです。 `-c`オプションを使用すると、ユーザーは別のオプションを指定できます

• ローカルデータベースを必要としない、ベースバックアップとWALセグメントの単純なインデックス作成

• メンテナンスモード`cron`コマンドから呼び出されます。WALのアーカイブと圧縮、カタログの更新などの通常の操作を実行します。

• Barmanで構成された特定のPostgreSQLサーバーの完全な物理ベースバックアップを取得する'backup'コマンドを追加しました

• 特定のバックアップのローカルリカバリを実行する`recover'コマンドを追加し、DBAがポイント・インタイムを指定できるようにします。 `recover`コマンドは、PGDATAディレクトリと、該当する場合はテーブルスペースの両方の再配置をサポートしています

• バックアップのリモートリカバリーのための`-remote-ssh-command'オプションを`recover'コマンドに追加しました。リモートリカバリーは現在テーブルスペースの再配置をサポートしていません

• barmanで構成されたすべてのアクティブサーバーをリストする`list-server'コマンドを追加しました

• 特定のサーバーの関連情報を表示する`show-server`コマンドを追加しました すべての構成オプションを含む

• Postgresバージョン、現在のトランザクションID、archiveコマンドなどを含むサーバーの現在の状態に関する情報を表示する`status'コマンドを追加しました。

• Barmanが必要とするすべてが正常に機能している場合に0を返す 'check'コマンドを追加しました

• ベースバックアップのサイズ、関連するWALセグメントの合計サイズを含む、特定のサーバーで使用可能なすべてのバックアップをリストする`list-backup'コマンドを追加しました

• 開始時刻、サイズ、関連するWALセグメントの数とそのサイズなど、特定のバックアップの関連情報を表示する`show-backup'コマンドを追加しました。

• カタログからバックアップを削除する`delete`コマンドを追加しました

• 単一のバックアップのすべてのファイルをリストする`list-files'コマンドを追加しました

• RHEL 5/6のRPMパッケージ