In an abstract sense, a running <productname>PostgreSQL</productname> system produces an indefinitely long sequence of WAL records. The system physically divides this sequence into WAL <firstterm>segment files</firstterm>, which are normally 16MB apiece (although the segment size can be altered during <application>initdb</application>). The segment files are given numeric names that reflect their position in the abstract WAL sequence. When not using WAL archiving, the system normally creates just a few segment files and then <quote>recycles</quote> them by renaming no-longer-needed segment files to higher segment numbers. It's assumed that segment files whose contents precede the last checkpoint are no longer of interest and can be recycled. 抽象的な意味では、実行中のPostgreSQLシステムは無限に長い一連のWALレコードを生成します。 システムは物理的にこの並びを、通常1つ16メガバイト（このセグメントサイズはinitdbの実行時に変更可能です）の、WALセグメントファイルに分割します。 このセグメントファイルには、概念的なWALの並び内の位置を反映した、数字の名前が付与されます。 WALアーカイブを行わない場合、システムは通常数個のセグメントファイルを生成し、不要となったセグメントファイルの名前をより大きなセグメント番号に変更することでそれを「リサイクル」します。 最後のチェックポイントより前の内容を持つセグメントファイルはもはや重要でなく、リサイクルできると見なされます。

When archiving WAL data, we need to capture the contents of each segment file once it is filled, and save that data somewhere before the segment file is recycled for reuse. Depending on the application and the available hardware, there could be many different ways of <quote>saving the data somewhere</quote>: we could copy the segment files to an NFS-mounted directory on another machine, write them onto a tape drive (ensuring that you have a way of identifying the original name of each file), or batch them together and burn them onto CDs, or something else entirely. To provide the database administrator with flexibility, <productname>PostgreSQL</productname> tries not to make any assumptions about how the archiving will be done. Instead, <productname>PostgreSQL</productname> lets the administrator specify a shell command or an archive library to be executed to copy a completed segment file to wherever it needs to go. This could be as simple as a shell command that uses <literal>cp</literal>, or it could invoke a complex C function &mdash; it's all up to you. WALデータをアーカイブする場合、完成したセグメントファイルのそれぞれの内容を取り出し、再利用のために回収される前にそのデータをどこかに保存することが必要です。 アプリケーションと利用できるハードウェアに依存しますが、数多くの「データをどこかに保存する」方法があります。 例えば、NFSでマウントした他のマシンのディレクトリにセグメントファイルをコピーすること、あるいは、テープ装置に書き出すこと（元々のファイル名を識別する手段があることを確認してください）、それらを一度にまとめてCDに焼くこと、そのほか全く異なったなんらかの方法などです。 柔軟性をデータベース管理者に提供するために、PostgreSQLは、どのようにアーカイブがなされたかについて一切想定しないようになっています。 その代わりにPostgreSQLは、管理者に完全なセグメントファイルをどこか必要な場所にコピーするシェルコマンドあるいはアーカイブライブラリを指定させます。 このコマンドは単純なcpを使ったシェルコマンドでも構いませんし、また、複雑なC関数を呼び出しても構いません。 全て管理者に任されています。

To enable WAL archiving, set the <xref linkend="guc-wal-level"/> configuration parameter to <literal>replica</literal> or higher, <xref linkend="guc-archive-mode"/> to <literal>on</literal>, specify the shell command to use in the <xref linkend="guc-archive-command"/> configuration parameter or specify the library to use in the <xref linkend="guc-archive-library"/> configuration parameter. In practice these settings will always be placed in the <filename>postgresql.conf</filename> file. WALアーカイブを有効にするには、wal_level設定パラメータをreplica以上に、archive_modeをonに設定し、archive_command設定パラメータで使用するシェルコマンドを指定するか、archive_library設定パラメータで使用するライブラリを指定します。 実際には、これらの設定は常にpostgresql.confファイルに置かれます。

In <varname>archive_command</varname>, <literal>%p</literal> is replaced by the path name of the file to archive, while <literal>%f</literal> is replaced by only the file name. (The path name is relative to the current working directory, i.e., the cluster's data directory.) Use <literal>%%</literal> if you need to embed an actual <literal>%</literal> character in the command. The simplest useful command is something like: archive_commandでは、%pはアーカイブするファイルのパス名に置き換えられますが、%fはファイル名のみに置き換えられます。 （パス名は現在の作業ディレクトリ、つまりクラスタのデータディレクトリからの相対パスです。） 実際の%文字をコマンドに埋め込む必要がある場合は%%を使用してください。 最も簡単で便利なコマンドは以下のようなものです。

archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows

which will copy archivable WAL segments to the directory <filename>/mnt/server/archivedir</filename>. (This is an example, not a recommendation, and might not work on all platforms.) After the <literal>%p</literal> and <literal>%f</literal> parameters have been replaced, the actual command executed might look like this: これは、アーカイブ可能なWALセグメントを/mnt/server/archivedirディレクトリにコピーします （これは一例です。 推奨するものではなく、また、全てのプラットフォームで動作しない可能性があります）。 %pおよび%fパラメータが置き換えられたあと、実行された実コマンドは以下のようになります。

test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

A similar command will be generated for each new file to be archived. 類似したコマンドがアーカイブされるそれぞれの新規ファイルに生成されます。

The archive command will be executed under the ownership of the same user that the <productname>PostgreSQL</productname> server is running as. Since the series of WAL files being archived contains effectively everything in your database, you will want to be sure that the archived data is protected from prying eyes; for example, archive into a directory that does not have group or world read access. このアーカイブ用コマンドはPostgreSQLサーバを稼働させるユーザと同じ所有権で実行されます。 アーカイブされる一連のWALファイルには、実質、データベース内の全てが含まれていますので、アーカイブしたデータをのぞき見から確実に保護しなければならないでしょう。 例えば、グループや全員に読み込み権限を付与していないディレクトリにデータをアーカイブしてください。

It is important that the archive command return zero exit status if and only if it succeeds. Upon getting a zero result, <productname>PostgreSQL</productname> will assume that the file has been successfully archived, and will remove or recycle it. However, a nonzero status tells <productname>PostgreSQL</productname> that the file was not archived; it will try again periodically until it succeeds. アーカイブ用コマンドが成功した場合のみにゼロという終了ステータスを返すことが重要です。 PostgreSQLは、ゼロという結果に基づいて、そのファイルのアーカイブが成功したことを想定し、そのファイルを削除したり回収するかもしれません。 しかし、非ゼロのステータスは、PostgreSQLに対してファイルがアーカイブされなかったことを通知し、成功するまで定期的に再試行させます。

Another way to archive is to use a custom archive module as the <varname>archive_library</varname>. Since such modules are written in <literal>C</literal>, creating your own may require considerably more effort than writing a shell command. However, archive modules can be more performant than archiving via shell, and they will have access to many useful server resources. For more information about archive modules, see <xref linkend="archive-modules"/>. アーカイブするための別の方法は、archive_libraryとしてカスタムアーカイブモジュールを使用することです。 このようなモジュールはCで記述されているため、独自のモジュールを作成するには、シェル・コマンドを記述するよりもかなり多くの労力が必要になる場合があります。 しかし、アーカイブモジュールはシェルを介したアーカイブよりもパフォーマンスが高く、多くの有用なサーバ・リソースにアクセスできます。 アーカイブモジュールの詳細は第49章を参照してください。

When the archive command is terminated by a signal (other than <systemitem>SIGTERM</systemitem> that is used as part of a server shutdown) or an error by the shell with an exit status greater than 125 (such as command not found), or if the archive function emits an <literal>ERROR</literal> or <literal>FATAL</literal>, the archiver process aborts and gets restarted by the postmaster. In such cases, the failure is not reported in <xref linkend="pg-stat-archiver-view"/>. アーカイブコマンドがシグナル（サーバのシャットダウンの一部として使用されるSIGTERM以外）やシェルによる125より大きい終了ステータスを持つエラー（command not foundなど）、あるいはアーカイブ関数がERRORまたはFATALを出力したことによって終了すると、アーカイバプロセスは中止され、postmasterによって再起動されます。 このような場合、失敗はpg_stat_archiverでは報告されません。

Archive commands and libraries should generally be designed to refuse to overwrite any pre-existing archive file. This is an important safety feature to preserve the integrity of your archive in case of administrator error (such as sending the output of two different servers to the same archive directory). It is advisable to test your proposed archive library to ensure that it does not overwrite an existing file. 通常アーカイブ用コマンドあるいはライブラリは、既存のアーカイブ済みファイルの上書きを行わないように設計されなければなりません。 これは、管理者のミス（例えば2つの異なるサーバの出力を同一のアーカイブ用ディレクトリに送信してしまうなど）といった場合からアーカイブ状況の整合性を保護するための安全策として重要です。 確実に既存のファイルを上書きしないように、使用予定のアーカイブライブラリを試験することをお勧めします。

In rare cases, <productname>PostgreSQL</productname> may attempt to re-archive a WAL file that was previously archived. For example, if the system crashes before the server makes a durable record of archival success, the server will attempt to archive the file again after restarting (provided archiving is still enabled). When an archive command or library encounters a pre-existing file, it should return a zero status or <literal>true</literal>, respectively, if the WAL file has identical contents to the pre-existing archive and the pre-existing archive is fully persisted to storage. If a pre-existing file contains different contents than the WAL file being archived, the archive command or library <emphasis>must</emphasis> return a nonzero status or <literal>false</literal>, respectively. まれに、PostgreSQLは以前にアーカイブされたWALファイルを再アーカイブしようとすることがあります。 たとえば、サーバがアーカイブの成功を永続的に記録する前にシステムがクラッシュした場合、サーバは再起動後にファイルを再びアーカイブしようとします（アーカイブがまだ有効になっている場合）。 アーカイブコマンドやライブラリが既に存在するファイルに遭遇した場合、WALファイルの内容が既に存在するアーカイブと同じであり、既に存在するアーカイブがストレージに完全に永続化されている場合、それぞれ0のステータス、trueを返すことが必要です。 既に存在するファイルがアーカイブされるWALファイルと異なる内容を含む場合、アーカイブコマンドやライブラリは、それぞれ0のステータス、falseを返さなければなりません。

The example command above for Unix avoids overwriting a pre-existing archive by including a separate <command>test</command> step. On some Unix platforms, <command>cp</command> has switches such as <option>-i</option> that can be used to do the same thing less verbosely, but you should not rely on these without verifying that the right exit status is returned. (In particular, GNU <command>cp</command> will return status zero when <option>-i</option> is used and the target file already exists, which is <emphasis>not</emphasis> the desired behavior.) 上のUnix用のコマンド例では、別途testという段階を含めることで、既に存在するアーカイブへの上書きを防いでいます。 いくつかのUnixプラットフォームではcpコマンドには-i 引数を使うことで煩雑な出力を少なくし使うことができますが、正しい終了コードが返ることを確認せずに使用するべきではありません。 （具体的にはGNUのcpコマンドは-i オプションを使い、ターゲットファイルがすでに存在している場合、ゼロのステータスを返します。これは期待していない動作です。）

While designing your archiving setup, consider what will happen if the archive command or library fails repeatedly because some aspect requires operator intervention or the archive runs out of space. For example, this could occur if you write to tape without an autochanger; when the tape fills, nothing further can be archived until the tape is swapped. You should ensure that any error condition or request to a human operator is reported appropriately so that the situation can be resolved reasonably quickly. The <filename>pg_wal/</filename> directory will continue to fill with WAL segment files until the situation is resolved. (If the file system containing <filename>pg_wal/</filename> fills up, <productname>PostgreSQL</productname> will do a PANIC shutdown. No committed transactions will be lost, but the database will remain offline until you free some space.) アーカイブ設定を設計する時には、操作者の介入が必要であったり、アーカイブ場所の容量不足の理由でアーカイブ用コマンドあるいはライブラリが繰り返し失敗した時にどうなるかを考慮してください。 例えば、これはオートチェンジャ機能のないテープに書き出している場合に発生する可能性があります。 テープが一杯になった場合、テープを交換するまでアーカイブを行うことができなくなります。 こうした状況を相応の早さで解消できるよう、適切に操作者に対しエラーや要求を確実に連絡できるようにしなければなりません。 この状況が解消するまで、WALセグメントファイルはpg_wal/ディレクトリ内に格納され続けます。 （pg_wal/を含むファイルシステムがいっぱいになると、PostgreSQLはパニック停止します。コミットされたトランザクションは失われませんが、データベースはいくらかの容量を解放するまでオフラインのままです。）

The speed of the archive command or library is unimportant as long as it can keep up with the average rate at which your server generates WAL data. Normal operation continues even if the archiving process falls a little behind. If archiving falls significantly behind, this will increase the amount of data that would be lost in the event of a disaster. It will also mean that the <filename>pg_wal/</filename> directory will contain large numbers of not-yet-archived segment files, which could eventually exceed available disk space. You are advised to monitor the archiving process to ensure that it is working as you intend. サーバのWALデータの生成に要する平均速度に追いついている限り、アーカイブ用コマンドあるいはライブラリの処理速度は重要ではありません。 アーカイブプロセスが多少遅れたとしても通常の操作は続けられます。 アーカイブ処理がかなり遅れると、災害時に損失するデータの量が増加することになります。 また、これはpg_wal/ディレクトリ内に多くのアーカイブ処理待ちのセグメントファイルが格納され、ディスク容量が不足する状況になる可能性があることを意味します。 アーカイブ処理が確実に意図通りに動作しているかを監視することを推奨します。

In writing your archive command or library, you should assume that the file names to be archived can be up to 64 characters long and can contain any combination of ASCII letters, digits, and dots. It is not necessary to preserve the original relative path (<literal>%p</literal>) but it is necessary to preserve the file name (<literal>%f</literal>). アーカイブ用コマンドあるいはライブラリを作成する時、アーカイブされるファイル名は最長64文字までで、ASCII文字と数字とドットのどんな組合せを使用しても構いません。 元の相対パス（%p）を保存する必要はありませんが、ファイル名（%f）を保存する必要はあります。

Note that although WAL archiving will allow you to restore any modifications made to the data in your <productname>PostgreSQL</productname> database, it will not restore changes made to configuration files (that is, <filename>postgresql.conf</filename>, <filename>pg_hba.conf</filename> and <filename>pg_ident.conf</filename>), since those are edited manually rather than through SQL operations. You might wish to keep the configuration files in a location that will be backed up by your regular file system backup procedures. See <xref linkend="runtime-config-file-locations"/> for how to relocate the configuration files. WALアーカイブによってPostgreSQLデータベースでなされた変更は全てリストアすることができますが、設定ファイルはSQL操作ではなく手作業で変更されますので、設定ファイル（postgresql.conf、pg_hba.conf、およびpg_ident.conf）になされた変更までリストアしないことに注意してください。 通常のファイルシステムバックアップ手続きでバックアップされる場所に設定ファイルを保持したい場合があります。 設定ファイルの設置場所を変更するには19.2を参照してください。

The archive command or function is only invoked on completed WAL segments. Hence, if your server generates only little WAL traffic (or has slack periods where it does so), there could be a long delay between the completion of a transaction and its safe recording in archive storage. To put a limit on how old unarchived data can be, you can set <xref linkend="guc-archive-timeout"/> to force the server to switch to a new WAL segment file at least that often. Note that archived files that are archived early due to a forced switch are still the same length as completely full files. It is therefore unwise to set a very short <varname>archive_timeout</varname> &mdash; it will bloat your archive storage. <varname>archive_timeout</varname> settings of a minute or so are usually reasonable. アーカイブコマンドあるいは関数は完全なWALセグメントに対してのみ呼び出されます。 このため、サーバが少ししかWAL流量がない（処理を行わないなぎの期間がある）場合、トランザクションの完了とアーカイブ格納領域への安全な記録との間に長期にわたる遅延があることになります。 古い未アーカイブのデータをどうするかについて制限を付けるために、archive_timeoutを設定して、強制的にサーバを新しいWALセグメントにある程度の間隔で切り替えるようにすることができます。 強制切り替えにより早期にアーカイブされたアーカイブ済みファイルは完全に完了したファイルと同じ大きさを持つことに注意してください。 そのため、非常に小さなarchive_timeoutを使用することはお勧めしません。 格納領域を膨張させてしまいます。 通常ならば分単位のarchive_timeout設定が合理的です。

Also, you can force a segment switch manually with <function>pg_switch_wal</function> if you want to ensure that a just-finished transaction is archived as soon as possible. Other utility functions related to WAL management are listed in <xref linkend="functions-admin-backup-table"/>. 終わったばかりのトランザクションをできるだけ早くアーカイブさせたい場合、pg_switch_walを使用して手作業でセグメント切り替えを強制することができます。 この他のWAL管理に関連した関数を表 9.95に列挙します。

When <varname>wal_level</varname> is <literal>minimal</literal> some SQL commands are optimized to avoid WAL logging, as described in <xref linkend="populate-pitr"/>. If archiving or streaming replication were turned on during execution of one of these statements, WAL would not contain enough information for archive recovery. (Crash recovery is unaffected.) For this reason, <varname>wal_level</varname> can only be changed at server start. However, <varname>archive_command</varname> and <varname>archive_library</varname> can be changed with a configuration file reload. If you are archiving via shell and wish to temporarily stop archiving, one way to do it is to set <varname>archive_command</varname> to the empty string (<literal>''</literal>). This will cause WAL files to accumulate in <filename>pg_wal/</filename> until a working <varname>archive_command</varname> is re-established. wal_levelがminimalの場合、14.4.7に書かれているように、いくつかのSQLコマンドはWALロギングを回避するため最適化されます。 アーカイビングもしくはストリーミングレプリケーションがこれら構文の１つを実行中に作動させられると、アーカイブ復旧のための十分な情報をWALが含まなくなります。（クラッシュ復旧は影響を受けません。） このことにより、wal_levelはサーバの起動時のみ変更可能です。 とは言っても、archive_commandとarchive_libraryは構成ファイルを再読み込みすることで変更できます。 シェルでアーカイブしており、一時的にアーカイビングを停止したい場合、１つの方法はarchive_commandを空文字列（''）に設定することです。 このようにすると、動作するarchive_commandが再構築されるまでWALファイルはpg_wal/に蓄積します。

The easiest way to perform a base backup is to use the <xref linkend="app-pgbasebackup"/> tool. It can create a base backup either as regular files or as a tar archive. If more flexibility than <xref linkend="app-pgbasebackup"/> can provide is required, you can also make a base backup using the low level API (see <xref linkend="backup-lowlevel-base-backup"/>). ベースバックアップを取得する最も簡単な方法はpg_basebackup を実行する方法です。 通常のファイルやTAR形式のファイルとしてベースバックアップを取得することができます。 もし、pg_basebackupより柔軟性が求められる場合は、低レベルなAPIを使ってバックアップを作成することもできます（詳細は 25.3.4を参照）。

It is not necessary to be concerned about the amount of time it takes to make a base backup. However, if you normally run the server with <varname>full_page_writes</varname> disabled, you might notice a drop in performance while the backup runs since <varname>full_page_writes</varname> is effectively forced on during backup mode. ベースバックアップを取得するための時間を考慮する必要はありません。 しかし、普段、full_page_writesを無効にして運用している場合、バックアップ取得中は強制的にfull_page_writesが有効になるため、パフォーマンスが落ちていると感じる可能性があります。

To make use of the backup, you will need to keep all the WAL segment files generated during and after the file system backup. To aid you in doing this, the base backup process creates a <firstterm>backup history file</firstterm> that is immediately stored into the WAL archive area. This file is named after the first WAL segment file that you need for the file system backup. For example, if the starting WAL file is <literal>0000000100001234000055CD</literal> the backup history file will be named something like <literal>0000000100001234000055CD.007C9330.backup</literal>. (The second part of the file name stands for an exact position within the WAL file, and can ordinarily be ignored.) Once you have safely archived the file system backup and the WAL segment files used during the backup (as specified in the backup history file), all archived WAL segments with names numerically less are no longer needed to recover the file system backup and can be deleted. However, you should consider keeping several backup sets to be absolutely certain that you can recover your data. バックアップを使用するためには、ファイルシステムのバックアップ取得中、および、その後に生成されるWALセグメントファイル全てが保存されている必要があります。 この目的のために、ベースバックアップの過程で即座にWALアーカイブ領域にバックアップ履歴ファイルが作成されます。 このファイルにはファイルシステムのバックアップに最初に必要とされるWALセグメントの名前が付けられます。 例えば、最初のWALファイルが 0000000100001234000055CDである場合、バックアップ履歴ファイルは0000000100001234000055CD.007C9330.backupというように名付けられます。 （ファイル名の2番目のパートはWALファイルの厳密な位置が記載されます。通常は無視することができます。） 一旦、安全にファイルシステムのバックアップとそのバックアップ中に使用されたWALセグメントファイル（バックアップ履歴ファイルから特定できます）を取得すると、それより数値の小さな全てのWALアーカイブセグメントはファイルシステムの復旧には必要が無く、削除することができます。 しかし、データを確実に復旧させるためには数世代のバックアップセットを保持することを考慮すべきです。

The backup history file is just a small text file. It contains the label string you gave to <xref linkend="app-pgbasebackup"/>, as well as the starting and ending times and WAL segments of the backup. If you used the label to identify the associated dump file, then the archived history file is enough to tell you which dump file to restore. バックアップ履歴ファイルは、ほんの小さなテキストファイルです。 これにはpg_basebackupで与えたラベル文字列の他、バックアップの開始、終了時間およびバックアップのWALセグメントが含まれます。 このラベルをバックアップを構成するために使うことで、アーカイブ履歴ファイルはどのバックアップをリストアするべきか間違いなく判断することができます。

Since you have to keep around all the archived WAL files back to your last base backup, the interval between base backups should usually be chosen based on how much storage you want to expend on archived WAL files. You should also consider how long you are prepared to spend recovering, if recovery should be necessary &mdash; the system will have to replay all those WAL segments, and that could take awhile if it has been a long time since the last base backup. 最後のベースバックアップ以降のWALアーカイブを保持し続ける必要があるため、通常、ベースバックアップを取得すべき期間は、WALアーカイブを保持するためにどのくらいのストレージを拡張できるかによって決定されます。 また、復旧が必要になった場合に、どのくらいの時間を復旧に使うと覚悟するのかも考慮すべきです。— システムは全てのWALセグメントを適用する必要があるため、もし、最後のベースバックアップを取得してから長い時間が経過している場合、適用に時間を要する可能性があります。

You can use <xref linkend="app-pgbasebackup"/> to take an incremental backup by specifying the <literal>&#45;-incremental</literal> option. You must supply, as an argument to <literal>&#45;-incremental</literal>, the backup manifest to an earlier backup from the same server. In the resulting backup, non-relation files will be included in their entirety, but some relation files may be replaced by smaller incremental files which contain only the blocks which have been changed since the earlier backup and enough metadata to reconstruct the current version of the file. 《機械翻訳》pg_basebackupを使用してインクリメンタルバックアップを作成するには、--incrementalオプションを指定します。 同じ引数から前のバックアップへのバックアップマニフェストを、サーバ先--incrementalとして指定する必要があります。 作成されたバックアップには、リレーション以外のファイルもすべて含まれますが、一部のリレーションファイルは、以前のバックアップから変更されたブロックと、ファイルの現在のバージョンを再構築するのに十分なメタデータのみを含む、より小さな増分ファイルに置き換えられる場合があります。

To figure out which blocks need to be backed up, the server uses WAL summaries, which are stored in the data directory, inside the directory <literal>pg_wal/summaries</literal>. If the required summary files are not present, an attempt to take an incremental backup will fail. The summaries present in this directory must cover all LSNs from the start LSN of the prior backup to the start LSN of the current backup. Since the server looks for WAL summaries just after establishing the start LSN of the current backup, the necessary summary files probably won't be instantly present on disk, but the server will wait for any missing files to show up. This also helps if the WAL summarization process has fallen behind. However, if the necessary files have already been removed, or if the WAL summarizer doesn't catch up quickly enough, the incremental backup will fail. 《機械翻訳》どのブロックをバックアップする必要があるかを判断するために、サーバは、データディレクトリ内のディレクトリpg_wal/summariesに格納されているWALサマリを使用します。 必要な要約ファイルが存在しない場合、インクリメンタルバックアップの実行は失敗します。 このディレクトリに存在する要約は、前のバックアップのスタートLSNから現在バックアップのスタートLSNまでのすべてのLSNをカバーしなければならない。 サーバは現在バックアップのスタートLSNを確立した直後にWAL要約を探しますので、必要な要約ファイルはおそらくディスクにすぐには存在しませんが、サーバは不足しているファイルが現れるのを待ちます。 これは、プロセスのWAL集約が遅れている場合にも役立ちます。 しかし、必要なファイルがすでに削除されている場合や、WALサマライザが十分な速さでキャッチアップしない場合、インクリメンタル・バックアップは失敗します。

When restoring an incremental backup, it will be necessary to have not only the incremental backup itself but also all earlier backups that are required to supply the blocks omitted from the incremental backup. See <xref linkend="app-pgcombinebackup"/> for further information about this requirement. Note that there are restrictions on the use of <literal>pg_combinebackup</literal> when the checksum status of the cluster has been changed; see <link linkend="app-pgcombinebackup-limitations">pg_combinebackup limitations</link>. 《機械翻訳》インクリメンタル・バックアップをリストアする場合は、インクリメンタル・バックアップ・自分自身だけでなく、インクリメンタル・バックアップから除外されたブロックを提供するために必要な以前のすべてのバックアップも必要になります。 この要件の詳細については、pg_combinebackupを参照してください。 ノートクラスタのチェックサムステータスが変更された場合、pg_combinebackupの使用に制限があります。 pg_combinebackup limitationsを参照してください。

Note that all of the requirements for making use of a full backup also apply to an incremental backup. For instance, you still need all of the WAL segment files generated during and after the file system backup, and any relevant WAL history files. And you still need to create a <literal>recovery.signal</literal> (or <literal>standby.signal</literal>) and perform recovery, as described in <xref linkend="backup-pitr-recovery" />. The requirement to have earlier backups available at restore time and to use <literal>pg_combinebackup</literal> is an additional requirement on top of everything else. Keep in mind that <application>PostgreSQL</application> has no built-in mechanism to figure out which backups are still needed as a basis for restoring later incremental backups. You must keep track of the relationships between your full and incremental backups on your own, and be certain not to remove earlier backups if they might be needed when restoring later incremental backups. 《機械翻訳》ノートフルバックアップを使用するためのすべての要件は、インクリメンタル・バックアップにも適用されます。 インスタンスに関しては、セグメント中およびファイルシステムバックアップ後に生成された全てのWAL歴史ファイルと、関連する全てのWAL地域ファイルが必要です。 また、25.3.5で説明されているように、リカバリ.シグナル（またはスタンバイ.シグナル）を作成し、リカバリを実行する必要があります。 以前のバックアップをリストア時間に利用可能にし、pg_combinebackupを使用するという要件は、他のすべてのものの中でトップの追加要件です。 PostgreSQLには、後で増分バックアップを復元するための基礎として、どのバックアップがまだ必要かを判断するためのメカニズムが組み込まれていないことに注意してください。 完全バックアップと増分バックアップの関係は自分で追跡する必要があります。 また、後で増分バックアップをリストアするときに必要になる場合は、前のバックアップを削除しないようにしてください。

Incremental backups typically only make sense for relatively large databases where a significant portion of the data does not change, or only changes slowly. For a small database, it's simpler to ignore the existence of incremental backups and simply take full backups, which are simpler to manage. For a large database all of which is heavily modified, incremental backups won't be much smaller than full backups. 《機械翻訳》通常、増分バックアップは、makeのかなりの部分が変更されないか、またはゆっくりとしか変更されない比較的ラージのデータベースに対してのみデータを感知します。 小規模なデータベースの場合は、増分バックアップの存在を無視して、管理が簡単なフル・バックアップを実行する方が簡単です。 すべてが大幅に変更されるラージデータベースの場合、増分バックアップはフル・バックアップよりも大幅に小さくはなりません。

An incremental backup is only possible if replay would begin from a later checkpoint than for the previous backup upon which it depends. If you take the incremental backup on the primary, this condition is always satisfied, because each backup triggers a new checkpoint. On a standby, replay begins from the most recent restartpoint. Therefore, an incremental backup of a standby server can fail if there has been very little activity since the previous backup, since no new restartpoint might have been created. 《機械翻訳》インクリメンタル・バックアップは、リプレイが依存している前のチェックポイントよりも後のバックアップから開始する場合にのみ可能です。 プライマリでインクリメンタルバックアップを実行する場合、バックアップごとに新しいチェックポイントがトリガーされるため、この条件は常に満たされます。 スタンバイでは、リプレイは最新の再始動点から開始します。 そのため、前回のスタンバイサーバ以降のアクティビティが非常に少ない場合は、新しいリスタートポイントが作成されていない可能性があるため、バックアップのインクリメンタルバックアップが失敗する可能性があります。

Instead of taking a full or incremental base backup using <xref linkend="app-pgbasebackup"/>, you can take a base backup using the low-level API. This procedure contains a few more steps than the <application>pg_basebackup</application> method, but is relatively simple. It is very important that these steps are executed in sequence, and that the success of a step is verified before proceeding to the next step. 《マッチ度[62.469734]》低レベルのAPIを使ったベースバックアップを取得するにはpg_basebackup を使う方法に加えて数ステップが必要ですが、比較的簡単です。 これらのステップは順番に実行することが重要で、次のステップに進む前にこれらのステップが成功していることを確認する必要があります。 《機械翻訳》pg_basebackupを使用して全ベースバックアップまたは増分ベースバックアップを利用する代わりでは、低レベルAPIを使用してに乗ることができます。 このプロシージャ包含はpg_basebackupメソッドよりも数ステップ多くなりますが、比較的シンプルです。 これらのステップがシーケンスで実行され、ステップの成功が次のステップに進む前で検証されることが非常に重要です。

Multiple backups are able to be run concurrently (both those started using this backup API and those started using <xref linkend="app-pgbasebackup"/>). 複数のバックアップを同時に実行できます（このバックアップAPIを使用して開始されたバックアップとpg_basebackupを使用して開始されたバックアップの両方）。

Okay, the worst has happened and you need to recover from your backup. Here is the procedure: さて、最悪の事態が発生し、バックアップから復旧する必要が出てきたものとします。 以下にその手順を説明します。

The key part of all this is to set up a recovery configuration that describes how you want to recover and how far the recovery should run. The one thing that you absolutely must specify is the <varname>restore_command</varname>, which tells <productname>PostgreSQL</productname> how to retrieve archived WAL file segments. Like the <varname>archive_command</varname>, this is a shell command string. It can contain <literal>%f</literal>, which is replaced by the name of the desired WAL file, and <literal>%p</literal>, which is replaced by the path name to copy the WAL file to. (The path name is relative to the current working directory, i.e., the cluster's data directory.) Write <literal>%%</literal> if you need to embed an actual <literal>%</literal> character in the command. The simplest useful command is something like: ここで重要となるのは、どのように復旧させたいのかやどこまで復旧させたいかを記述する復旧設定を設定することです。 絶対に指定しなければならないことは、アーカイブ済みWALファイルセグメントをどのように戻すかをPostgreSQLに通知するrestore_commandです。 archive_command同様、これはシェルコマンド文字列です。 ここには、対象のWALファイルの名前で置換される%fやWALファイルのコピー先を示すパスで置換される%pを含めることができます。 （パス名は現在の作業用ディレクトリ、つまり、クラスタのデータディレクトリから見た相対パスです。） コマンド内に%文字自体を埋め込む必要があれば%%と記載してください。 最も簡単でよく使われるコマンドは以下のようなものです。

restore_command = 'cp /mnt/server/archivedir/%f %p'

which will copy previously archived WAL segments from the directory <filename>/mnt/server/archivedir</filename>. Of course, you can use something much more complicated, perhaps even a shell script that requests the operator to mount an appropriate tape. これは事前にアーカイブされたWALセグメントを/mnt/server/archivedirディレクトリからコピーします。 当然ながら、もっと複雑なものを使用することができます。 例えば、操作者に適切なテープをマウントさせることを要求するようなシェルスクリプトでさえ可能です。

It is important that the command return nonzero exit status on failure. The command <emphasis>will</emphasis> be called requesting files that are not present in the archive; it must return nonzero when so asked. This is not an error condition. An exception is that if the command was terminated by a signal (other than <systemitem>SIGTERM</systemitem>, which is used as part of a database server shutdown) or an error by the shell (such as command not found), then recovery will abort and the server will not start up. このコマンドが失敗した時に非ゼロの終了ステータスを返すことが重要です。 このコマンドは、アーカイブに存在しないファイルを要求するかもしれませんが、その場合でも非ゼロを返さなければなりません。 これはエラー状態ではありません。 例外は、コマンドがシグナルによって中断された場合(データベースの停止に使用されるSIGTERM以外)か、シェルによるエラー(コマンドが見つかりませんなど)で復旧が中断され、サーバが起動しない場合です。

Not all of the requested files will be WAL segment files; you should also expect requests for files with a suffix of <literal>.history</literal>. Also be aware that the base name of the <literal>%p</literal> path will be different from <literal>%f</literal>; do not expect them to be interchangeable. 要求されるファイルはWALセグメントファイルだけではありません。 .historyが付いているファイルが要求されることも想定しなければなりません。 同時に、%pパスのファイル名部分は%fと異なることに注意してください。 これらが相互に置き換え可能であるとは考えないでください。

WAL segments that cannot be found in the archive will be sought in <filename>pg_wal/</filename>; this allows use of recent un-archived segments. However, segments that are available from the archive will be used in preference to files in <filename>pg_wal/</filename>. アーカイブ場所で見つけられなかったWALセグメントはpg_wal/から検索されます。 これにより、最近の未アーカイブのセグメントを使用することができます。 しかし、アーカイブ場所から利用できるセグメントはpg_wal/内のファイルよりも優先的に使用されます。

Normally, recovery will proceed through all available WAL segments, thereby restoring the database to the current point in time (or as close as possible given the available WAL segments). Therefore, a normal recovery will end with a <quote>file not found</quote> message, the exact text of the error message depending upon your choice of <varname>restore_command</varname>. You may also see an error message at the start of recovery for a file named something like <filename>00000001.history</filename>. This is also normal and does not indicate a problem in simple recovery situations; see <xref linkend="backup-timelines"/> for discussion. 通常は利用可能な全てのWALセグメントを使用して復旧処理が行われます。 その結果、データベースを現時点まで（もしくは、利用可能なWALセグメントで得られる限り現在に近い時点まで）リストアします。 従って、通常の復旧は「file not found」メッセージで終了します。 エラーメッセージの正確な文言はrestore_commandの選択によります。 また、復旧の開始時点で00000001.historyのようなファイル名のエラーメッセージが出ることがあります。 これも単純な復旧作業では不具合を意味するものでなく正常です。 論議については25.3.6を参照してください。

If you want to recover to some previous point in time (say, right before the junior DBA dropped your main transaction table), just specify the required <link linkend="runtime-config-wal-recovery-target">stopping point</link>. You can specify the stop point, known as the <quote>recovery target</quote>, either by date/time, named restore point or by completion of a specific transaction ID. As of this writing only the date/time and named restore point options are very usable, since there are no tools to help you identify with any accuracy which transaction ID to use. もし以前のある時点まで復旧させたい場合（例えば、経験不足のデータベース管理者が主トランザクションテーブルを消去した直前）、要求する停止時点を指定するだけです。 停止時点は、「recovery target」として既知の停止時点で指定することも、日付と時刻で指定することも、リストアポイントか完了した特定のトランザクションIDで指定することもできます。 本ドキュメントの執筆時点では使用するトランザクションIDの識別を補助するツールがありませんので、ほとんどの場合は日付と時刻による指定のみを使用することになるでしょう。

If recovery finds corrupted WAL data, recovery will halt at that point and the server will not start. In such a case the recovery process could be re-run from the beginning, specifying a <quote>recovery target</quote> before the point of corruption so that recovery can complete normally. If recovery fails for an external reason, such as a system crash or if the WAL archive has become inaccessible, then the recovery can simply be restarted and it will restart almost from where it failed. Recovery restart works much like checkpointing in normal operation: the server periodically forces all its state to disk, and then updates the <filename>pg_control</filename> file to indicate that the already-processed WAL data need not be scanned again. 復旧時にWALデータの破損がわかると、復旧はその時点で止まり、サーバは起動しません。 こうした場合、「復旧対象」に破損時点より前の時点を指定することで、復旧処理が正常に完了できるよう、復旧プロセスを初めからやり直すことができます。 システムクラッシュなど外的理由により復旧処理が失敗した場合やWALアーカイブがアクセスできなくなった場合、復旧処理を単に再起動させることができます。 この場合は失敗した時点とほぼ同じところから再開します。 復旧処理の再起動は、次のような通常操作時のチェックポイント処理とほぼ同様に動作します。 サーバは定期的にすべての状態をディスクに強制し、再度スキャンする必要がない処理済みのWALデータを示すpg_controlファイルを更新します。

The ability to restore the database to a previous point in time creates some complexities that are akin to science-fiction stories about time travel and parallel universes. For example, in the original history of the database, suppose you dropped a critical table at 5:15PM on Tuesday evening, but didn't realize your mistake until Wednesday noon. Unfazed, you get out your backup, restore to the point-in-time 5:14PM Tuesday evening, and are up and running. In <emphasis>this</emphasis> history of the database universe, you never dropped the table. But suppose you later realize this wasn't such a great idea, and would like to return to sometime Wednesday morning in the original history. You won't be able to if, while your database was up-and-running, it overwrote some of the WAL segment files that led up to the time you now wish you could get back to. Thus, to avoid this, you need to distinguish the series of WAL records generated after you've done a point-in-time recovery from those that were generated in the original database history. 過去のある時点までデータベースを復旧できる機能は、タイムトラベルやパラレルユニバースといったSFの物語に類似した、多少の複雑性があります。 例えば、データベースの元の履歴で、火曜日の夕方5:15PMに重要なテーブルを削除し、水曜日のお昼まで手違いに気が付かなかったとします。 慌てずに、バックアップを取り出して、火曜日の夕方5:14PMの時点にリストアし、データベースを起動させます。 データベース世界のこの履歴では、そのテーブルを削除していません。 しかし、後になって、これは大した問題ではなかったことが分かり、元の履歴における水曜日に朝の何時かにまで戻したいと考えたと仮定しましょう。 データベースは既に起動していますので、元に戻したい時点に至るWALセグメントファイルの一部は上書きされていて、戻すことはできないかもしれません。 ですので、このことを避けるために、ポイントインタイムで復旧させた後に生成された一連のWALレコードと元のデータベースの履歴において生成されたWALレコードとを区別する必要があります。

To deal with this problem, <productname>PostgreSQL</productname> has a notion of <firstterm>timelines</firstterm>. Whenever an archive recovery completes, a new timeline is created to identify the series of WAL records generated after that recovery. The timeline ID number is part of WAL segment file names so a new timeline does not overwrite the WAL data generated by previous timelines. For example, in the WAL file name <filename>0000000100001234000055CD</filename>, the leading <literal>00000001</literal> is the timeline ID in hexadecimal. (Note that in other contexts, such as server log messages, timeline IDs are usually printed in decimal.) こうした問題を扱うためにPostgreSQLにはタイムラインという概念があります。 アーカイブ復旧が完了したときはいつでも、その復旧後に生成されたWALレコードを識別するための新しいタイムラインが生成されます。 タイムラインID番号はWALセグメントファイル名の一部です。ですので、新しいタイムラインはこれまでのタイムラインで生成されたWALデータを上書きしません。 たとえば、WALファイル名が0000000100001234000055CDの場合、先頭の00000001は16進数でのタイムラインIDです。 （たとえばサーバログメッセージのような他のコンテキストの場合、タイムラインIDは通常10進数で表示されることに注意してください。）

It is in fact possible to archive many different timelines. While that might seem like a useless feature, it's often a lifesaver. Consider the situation where you aren't quite sure what point-in-time to recover to, and so have to do several point-in-time recoveries by trial and error until you find the best place to branch off from the old history. Without timelines this process would soon generate an unmanageable mess. With timelines, you can recover to <emphasis>any</emphasis> prior state, including states in timeline branches that you abandoned earlier. 実際、多くの異なるタイムラインをアーカイブすることができます。 不要な機能と考えるかもしれませんが、命綱になることがしばしばあります。 どの時点まで復旧すればよいか確実でないといった状況を考えてみてください。 その時は、過去の履歴からの分岐点として最善の時点を見つけるために、試行錯誤して何度もポイントインタイムの復旧を行う必要があるでしょう。 タイムラインがないと、この手続きはすぐに管理不能な混乱を招いてしまいます。 タイムラインを使用して、以前捨てたタイムライン分岐における状態を含む、過去の任意の状態に復旧させることができます。

Every time a new timeline is created, <productname>PostgreSQL</productname> creates a <quote>timeline history</quote> file that shows which timeline it branched off from and when. These history files are necessary to allow the system to pick the right WAL segment files when recovering from an archive that contains multiple timelines. Therefore, they are archived into the WAL archive area just like WAL segment files. The history files are just small text files, so it's cheap and appropriate to keep them around indefinitely (unlike the segment files which are large). You can, if you like, add comments to a history file to record your own notes about how and why this particular timeline was created. Such comments will be especially valuable when you have a thicket of different timelines as a result of experimentation. 新しいタイムラインが生成される度に、PostgreSQLは、どのタイムラインがいつどこから分岐したかを示す「タイムライン履歴」ファイルを作成します。 この履歴ファイルは、複数のタイムラインを含むアーカイブ場所から復旧する時にシステムが正しいWALセグメントファイルを選択できるようにするために必要です。 したがって、履歴ファイルは、WALセグメントファイル同様にWALアーカイブ領域にアーカイブされます。 履歴ファイルは（巨大になるセグメントファイルとは異なり）単なる小さなテキストファイルですので、安価かつ適切に無期限で保管できます。 必要ならば、履歴ファイルにコメントを追加し、この特定のタイムラインがどのように、なぜ生成されたかについて独自の注釈を付与することができます。 特にこうしたコメントは、実験の結果いくつものタイムラインのもつれがある場合に有用です。

The default behavior of recovery is to recover to the latest timeline found in the archive. If you wish to recover to the timeline that was current when the base backup was taken or into a specific child timeline (that is, you want to return to some state that was itself generated after a recovery attempt), you need to specify <literal>current</literal> or the target timeline ID in <xref linkend="guc-recovery-target-timeline"/>. You cannot recover into timelines that branched off earlier than the base backup. 復旧処理のデフォルトは、アーカイブで見つかった最新のタイムラインへの復旧です。 ベースバックアップが取得された時点のタイムラインと同一のタイムラインや別の子タイムラインに沿って復旧させたい（つまり、復旧試行以降に生成されたある状態に戻りたい）場合は、currentかrecovery_target_timelineで対象のタイムラインIDを指定しなければなりません。 ベースバックアップより前に分岐したタイムラインに沿って復旧することはできません。

Some tips for configuring continuous archiving are given here. 継続的アーカイブを構成するいくつかのヒントを以下にあげます。

archive_command = 'gzip < %p > /mnt/server/archivedir/%f.gz'

restore_command = 'gunzip < /mnt/server/archivedir/%f.gz > %p'

archive_command = 'local_backup_script.sh "%p" "%f"'

At this writing, there are several limitations of the continuous archiving technique. These will probably be fixed in future releases: 本ドキュメント作成時点では、継続的アーカイブ技術にいくつかの制限があります。 将来のリリースでは修正されるはずです。

It should also be noted that the default <acronym>WAL</acronym> format is fairly bulky since it includes many disk page snapshots. These page snapshots are designed to support crash recovery, since we might need to fix partially-written disk pages. Depending on your system hardware and software, the risk of partial writes might be small enough to ignore, in which case you can significantly reduce the total volume of archived WAL files by turning off page snapshots using the <xref linkend="guc-full-page-writes"/> parameter. (Read the notes and warnings in <xref linkend="wal"/> before you do so.) Turning off page snapshots does not prevent use of the WAL for PITR operations. An area for future development is to compress archived WAL data by removing unnecessary page copies even when <varname>full_page_writes</varname> is on. In the meantime, administrators might wish to reduce the number of page snapshots included in WAL by increasing the checkpoint interval parameters as much as feasible. また、デフォルトのWALフォーマットは数多くのディスクページのスナップショットを含んでいるため、かなりかさばるものになってしまっていることに触れておくべきでしょう。 これらのページスナップショットは、クラッシュから回復のために設計されています。 それというのも、回復処理の際には不完全に書き込まれているディスクページを修復しなければならないことがあるからです。 システムのハードウェアやソフトウェアによっては、不完全なディスクページの書き込みが起きてしまう危険性は無視してもよい程微小です。 この場合full_page_writesパラメータを設定してページスナップショットを無効にすることで、アーカイブされたWALの総容量を大幅に縮小できます （実際に設定を行う前に、第28章の注意事項と警告を読んでください）。 ページスナップショットを無効にしても PITR処理の際にWALが使用できなくなることはありません。 将来の課題は、full_page_writesがたとえオンになっている場合であっても不要なページを取り除き、アーカイブ済みWALデータの圧縮を行うことでしょう。 差し当たり管理者は、可能な限りチェックポイント間隔パラメータを大きくすることによって、WALに含まれるページスナップショットの数を削減することができます。