System requirements
===================

-  Linux/Unix

-  Python > = 3.6

-  Pythonモジュール

   -  argcomplete
   -  psycopg2 >= 2.4.2
   -  python-dateutil
   -  setuptools

-  PostgreSQL > = 10次のバージョンはPostgreSQL > = 11が必要です。

-  rsync > = 3.1.0オプショナル

..  IMPORTANT::
   RedHat Enterprise Linux、CentOS、およびScientific Linuxのユーザーは、 `Extra Packages Enterprise Linux (EPEL) repository <https://fedoraproject.org/wiki/EPEL>`_ をインストールする必要があります。

..  NOTE::
   Python 2.6および3.5のサポートが終了しました。 Python 2.7のサポートはBarman 3.4.Xバージョンに制限されており、バグ修正のみを受け取ります。近い将来に販売終了となります。 Python 3.6のサポートは、将来のリリースで廃止されます。 PostgreSQL < 10のサポートは、 Barman 3.0.0以降で廃止されました。 PostgreSQL 10のサポートは、 Barman 3.5.0後に終了します。

バックアップの要件
------------------

Barmanサーバーの最も重要な要件は、利用可能なディスク領域の量です。クラスターのサイズ、1日あたり生成されるWALファイルの数、バックアップの頻度、および保持ポリシーに基づいて、必要なディスク領域を計画することをお勧めします。

Barman開発者は、XFSおよびext4を使用してBarmanを定期的にテストしています。
 `PostgreSQL <https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-FILESYSTEM>`_ と同様に、 BarmanはNFSに対して特別なことは何もしません。
NFSでBarmanを安全に使用するには、次の点が必要です。

-  ``barman_lock_directory``
   は、非ネットワークファイルシステム上にある必要があります。

-  NFSプロトコルのバージョン4を使用します。

-  ファイルシステムは、ハードおよび同期オプション\ ``hard,sync``
   を使用してマウントする必要があります。

リカバリの要件
--------------

Barmanを使用すると、PostgreSQLインスタンスをローカルにBarmanが存在する場所またはリモートで別のサーバーに復旧できます。

リモートリカバリーは、
BarmanでPostgreSQLサーバーを復元する最も一般的な方法であることは間違いありません。

いずれの場合も、同じ `requirements for PostgreSQL's Log shipping and Point-In-Time-Recovery apply <https://www.postgresql.org/docs/current/static/warm-standby.html#STANDBY-PLANNING>`_ 

-  同一のハードウェアアーキテクチャ

-  PostgreSQLの同一のメジャーバージョン

一般に、元のサーバーと同じではないにしても、できるだけ似たリカバリ環境を作成することを
**強くお勧めします**
。メンテナンスが簡単であるためです。たとえば、同じオペレーティングシステム、同じPostgreSQLバージョン、同じディスクレイアウトなどを使用することをお勧めします。

さらに、各PostgreSQLサーバーの専用のリカバリ環境は、オンデマンドでも、チームでディザスターリカバリー文化を育成できます。リカバリ操作を練習し、慣れておくことで、予期せぬことが発生した場合に備えることができます。

私たちの経験に基づいて、指定されたリカバリ環境は、実際の障害状況でのストレスの影響を軽減し、したがって、リカバリ操作の有効性を高めます。

最後に、NTPなどを使用して、サーバー間で時間が同期していることが重要です。
