backup.sgmlのPostgreSQL 17.0対応です。

doc/src/sgml/backup.sgml

@@ -1321,7 +1321,10 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
   </sect2>
 
   <sect2 id="backup-incremental-backup">
+<!--
    <title>Making an Incremental Backup</title>
+-->
+   <title>増分バックアップを作成する</title>
 
    <para>
 <!--
@@ -1334,9 +1337,9 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     only the blocks which have been changed since the earlier backup and enough
     metadata to reconstruct the current version of the file.
 -->
-《機械翻訳》<xref linkend="app-pgbasebackup"/>を使用してインクリメンタルバックアップを作成するには、<literal>--incremental</literal>オプションを指定します。
-同じ引数から前のバックアップへのバックアップマニフェストを、サーバ先<literal>--incremental</literal>として指定する必要があります。
-作成されたバックアップには、リレーション以外のファイルもすべて含まれますが、一部のリレーションファイルは、以前のバックアップから変更されたブロックと、ファイルの現在のバージョンを再構築するのに十分なメタデータのみを含む、より小さな増分ファイルに置き換えられる場合があります。
+<xref linkend="app-pgbasebackup"/>を使用して増分バックアップを作成するには、<literal>--incremental</literal>オプションを指定します。
+<literal>--incremental</literal>の引数として、同じサーバの以前のバックアップへのバックアップマニフェストを指定する必要があります。
+作成されたバックアップには、リレーション以外のファイルはそのまま含まれますが、一部のリレーションファイルは、以前のバックアップから変更されたブロックと、ファイルの現在のバージョンを再構築するのに十分なメタデータのみを含む、より小さな増分ファイルに置き換えられる場合があります。
    </para>
 
    <para>
@@ -1355,12 +1358,12 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     summarizer doesn't catch up quickly enough, the incremental backup will
     fail.
 -->
-《機械翻訳》どのブロックをバックアップする必要があるかを判断するために、サーバは、データディレクトリ内のディレクトリ<literal>pg_wal/summaries</literal>に格納されているWALサマリを使用します。
-必要な要約ファイルが存在しない場合、インクリメンタルバックアップの実行は失敗します。
-このディレクトリに存在する要約は、前のバックアップのスタートLSNから現在バックアップのスタートLSNまでのすべてのLSNをカバーしなければならない。
-サーバは現在バックアップのスタートLSNを確立した直後にWAL要約を探しますので、必要な要約ファイルはおそらくディスクにすぐには存在しませんが、サーバは不足しているファイルが現れるのを待ちます。
+どのブロックをバックアップする必要があるかを判断するために、サーバは、データディレクトリ内のディレクトリ<literal>pg_wal/summaries</literal>に格納されているWAL要約を使用します。
+必要な要約ファイルが存在しない場合、増分バックアップを作成する試みは失敗します。
+このディレクトリに存在する要約は、前のバックアップのスタートLSNから現在バックアップのスタートLSNまでのすべてのLSNを網羅しなければなりません。
+サーバは現在のバックアップの開始LSNを確立した直後のWAL要約を探すので、必要な要約ファイルはおそらくディスクにすぐには現れませんが、サーバは不足しているファイルが現れるのを待ちます。
 これは、プロセスのWAL集約が遅れている場合にも役立ちます。
-しかし、必要なファイルがすでに削除されている場合や、WALサマライザが十分な速さでキャッチアップしない場合、インクリメンタル・バックアップは失敗します。
+しかし、必要なファイルがすでに削除されている場合や、WAL要約が十分な速さで追いつかないときは、増分バックアップは失敗します。
    </para>
 
    <para>
@@ -1375,10 +1378,9 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     <link linkend="app-pgcombinebackup-limitations">pg_combinebackup
     limitations</link>.
 -->
-《機械翻訳》インクリメンタル・バックアップをリストアする場合は、インクリメンタル・バックアップ・自分自身だけでなく、インクリメンタル・バックアップから除外されたブロックを提供するために必要な以前のすべてのバックアップも必要になります。
+増分バックアップをリストアする場合は、増分バックアップ自体だけでなく、増分バックアップから除外されたブロックを提供するために必要な以前のすべてのバックアップも必要になります。
 この要件の詳細については、<xref linkend="app-pgcombinebackup"/>を参照してください。
-ノートクラスタのチェックサムステータスが変更された場合、<literal>pg_combinebackup</literal>の使用に制限があります。
-<link linkend="app-pgcombinebackup-limitations">pg_combinebackup limitations</link>を参照してください。
+クラスタのチェックサム状態が変更された場合、<literal>pg_combinebackup</literal>の使用に制限があることに注意してください。<link linkend="app-pgcombinebackup-limitations">pg_combinebackupの制限</link>を参照してください。
    </para>
 
    <para>
@@ -1399,13 +1401,12 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     and be certain not to remove earlier backups if they might be needed when
     restoring later incremental backups.
 -->
-《機械翻訳》ノートフルバックアップを使用するためのすべての要件は、インクリメンタル・バックアップにも適用されます。
-インスタンスに関しては、セグメント中およびファイルシステムバックアップ後に生成された全てのWAL歴史ファイルと、関連する全てのWAL地域ファイルが必要です。
-また、<xref linkend="backup-pitr-recovery" />で説明されているように、<literal>リカバリ.シグナル</literal>（または<literal>スタンバイ.シグナル</literal>）を作成し、リカバリを実行する必要があります。
-以前のバックアップをリストア時間に利用可能にし、<literal>pg_combinebackup</literal>を使用するという要件は、他のすべてのものの中でトップの追加要件です。
-<application>PostgreSQL</application>には、後で増分バックアップを復元するための基礎として、どのバックアップがまだ必要かを判断するためのメカニズムが組み込まれていないことに注意してください。
-完全バックアップと増分バックアップの関係は自分で追跡する必要があります。
-また、後で増分バックアップをリストアするときに必要になる場合は、前のバックアップを削除しないようにしてください。
+完全バックアップを使用するためのすべての要件は、増分バックアップにも適用されることに注意してください。
+たとえば、ファイルシステムバックアップ中と、その後に生成された全てのWALセグメントと、関連するWAL歴史ファイルが必要です。
+また、<xref linkend="backup-pitr-recovery" />で説明されているように、<literal>recovery.signal</literal>（または<literal>standby.signal</literal>）を作成し、リカバリを実行する必要があります。
+以前のバックアップをリストア時に利用可能にし、<literal>pg_combinebackup</literal>を使用するために要件は、それ以外の要件に対する追加の要件です。
+<application>PostgreSQL</application>には、後で増分バックアップからリストアするために、どのバックアップが前提として必要となるかを判断する機構は組み込まれていないことに注意してください。
+完全バックアップと増分バックアップの関係は自分で追跡する必要があり、後で増分バックアップをリストアするときに必要になる前のバックアップを削除しないようにしてください。
    </para>
 
    <para>
@@ -1417,9 +1418,9 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     to manage. For a large database all of which is heavily modified,
     incremental backups won't be much smaller than full backups.
 -->
-《機械翻訳》通常、増分バックアップは、makeのかなりの部分が変更されないか、またはゆっくりとしか変更されない比較的ラージのデータベースに対してのみデータを感知します。
-小規模なデータベースの場合は、増分バックアップの存在を無視して、管理が簡単なフル・バックアップを実行する方が簡単です。
-すべてが大幅に変更されるラージデータベースの場合、増分バックアップはフル・バックアップよりも大幅に小さくはなりません。
+通常、増分バックアップは、データのかなりの部分が変更されないか、または徐々にしか変更されない比較的大きなデータベースに対してのみ意味があります。
+小規模なデータベースの場合は、増分バックアップの存在を無視して、管理が簡単な完全バックアップを実行する方が簡単です。
+頻繁に変更される大きなデータベースの場合、増分バックアップは完全バックアップよりも大幅に小さくはなりません。
    </para>
 
    <para>
@@ -1433,10 +1434,10 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     little activity since the previous backup, since no new restartpoint might
     have been created.
 -->
-《機械翻訳》インクリメンタル・バックアップは、リプレイが依存している前のチェックポイントよりも後のバックアップから開始する場合にのみ可能です。
-プライマリでインクリメンタルバックアップを実行する場合、バックアップごとに新しいチェックポイントがトリガーされるため、この条件は常に満たされます。
-スタンバイでは、リプレイは最新の再始動点から開始します。
-そのため、前回のスタンバイサーバ以降のアクティビティが非常に少ない場合は、新しいリスタートポイントが作成されていない可能性があるため、バックアップのインクリメンタルバックアップが失敗する可能性があります。
+増分バックアップは、増分バックアップが依存しているバックアップよりも後のチェックポイントから再生を開始する場合にのみ可能です。
+プライマリで増分バックアップを実行する場合、バックアップごとに新しいチェックポイントが起こるため、この条件は常に満たされます。
+スタンバイでは、再生は最新のリスタートポイントから開始します。
+そのため、前回のバックアップ以降のアクティビティが非常に少ない場合は、新しいリスタートポイントが作成されていない可能性があるため、増分バックアップは失敗するかもしれません。
    </para>
   </sect2>
 
@@ -1455,11 +1456,9 @@ WALアーカイブによって<productname>PostgreSQL</productname>データベ
     sequence, and that the success of a step is verified before
     proceeding to the next step.
 -->
-《マッチ度[62.469734]》低レベルのAPIを使ったベースバックアップを取得するには<xref linkend="app-pgbasebackup"/> を使う方法に加えて数ステップが必要ですが、比較的簡単です。
-これらのステップは順番に実行することが重要で、次のステップに進む前にこれらのステップが成功していることを確認する必要があります。
-《機械翻訳》<xref linkend="app-pgbasebackup"/>を使用して全ベースバックアップまたは増分ベースバックアップを利用する代わりでは、低レベルAPIを使用してに乗ることができます。
-このプロシージャ包含は<application>pg_basebackup</application>メソッドよりも数ステップ多くなりますが、比較的シンプルです。
-これらのステップがシーケンスで実行され、ステップの成功が次のステップに進む前で検証されることが非常に重要です。
+<xref linkend="app-pgbasebackup"/>を使って完全、あるいは増分バックアップを取る代わりに、低レベルのAPIを使ってベースバックアップを取得できます。
+この手順は<application>pg_basebackup</application>を使う方法よりも少し余分の手順が必要ですが、比較的単純です。
+これらのステップを順番に実行すること、また次のステップに進む前にこれらのステップが成功していることを確認することが非常に重要です。
    </para>
     <para>
 <!--
@@ -1858,12 +1857,9 @@ GNUの <application>tar</application>で1.23以降のバージョンを使用し
      you should verify that the symbolic links in <filename>pg_tblspc/</filename>
      were correctly restored.
 -->
-《マッチ度[75.260417]》ファイルシステムバックアップからデータベースファイルをリストアします。
+完全バックアップをリストアする場合は、データベースファイルを直接ターゲットディレクトリにリストアすることができます。
 ファイルが正しい所有権（<literal>root</literal>ではなくデータベースシステムユーザです！）でリストアされていることを確認してください。
 テーブル空間を使用している場合は、<filename>pg_tblspc/</filename>内のシンボリックリンクが正しくリストアされていることを検証する必要があります。
-《機械翻訳》フルバックアップをリストアする場合は、データベースファイルを直接ターゲットディレクトリにリストアすることができます。
-これらのファイルが正しい所有者<literal>ルート</literal>ではなくデータベースシステムユーザと正しいパーミッションでリストアされていることを確認してください。
-テーブル空間を使用している場合は、<filename>pg_tblspc/</filename>内のシンボリックリンクが正しくリストアされていることを確認する必要があります。
     </para>
    </listitem>
    <listitem>
@@ -1879,9 +1875,9 @@ GNUの <application>tar</application>で1.23以降のバージョンを使用し
      and write out a synthetic full backup to the target directories. As above,
      verify that permissions and tablespace links are correct.
 -->
-《機械翻訳》インクリメンタル・バックアップをリストアする場合は、インクリメンタル・バックアップと、それが直接または間接的に依存している以前のすべてのバックアップを、リストアを実行しているマシンにリストアする必要があります。
-これらのバックアップは、実行中のターゲットを終了させたいサーバディレクトリではなく、別のディレクトリに配置する必要があります。
-これが完了したら、<xref linkend="app-pgcombinebackup"/>を使用してデータとその後のすべての増分バックアップからフルバックアップを取得し、合成フルバックアップをターゲットディレクトリに書き出します。
+増分バックアップをリストアする場合は、増分バックアップと、それが直接または間接的に依存している以前のすべてのバックアップを、リストアを実行しているマシンにリストアする必要があります。
+これらのバックアップは、実行中のサーバが最終的に目的とするターゲットディレクトリではなく、別のディレクトリに配置する必要があります。
+これが完了したら、<xref linkend="app-pgcombinebackup"/>を使用して完全バックアップとすべての増分バックアップからデータを抽出し、合成された完全バックアップをターゲットディレクトリに書き出します。
 上記のように、権限とテーブルスペースのリンクが正しいことを確認します。
     </para>
    </listitem>