<!-- $Header: /usr/prj/pg/cvsroot/doc/doc/src/sgml/backup.sgml,v 1.11 2001/09/10 07:18:21 t-ishii Exp $ -->
<chapter id="backup">
 <title><!--Backup and Restore-->バックアップとリストア</title>
<indexterm><primary sortas="ばっくあっぷ">バックアップ</primary></indexterm>
<indexterm><primary sortas="りすとあ">リストア</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="ばっくあっぷ">バックアップ</secondary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="りすとあ">リストア</secondary></indexterm>
 <para>
  <!--As everything that contains valuable data, <productname>Postgres</>
  databases should be backed up regularly. While the procedure is
  essentially simple, it is important to have a basic understanding of
  the underlying techniques and assumptions.-->

  <productname>Postgres</>データベースのすべての貴重なデータは、定期的にバックアップする必要があります。バックアップの手順は簡単ですが、その下にあるテクニックや概念などを理解する必要があります。
 </para>

 <para>
  <!--There are two fundamentally different approaches to backing up
  <productname>Postgres</> data:-->

  <productname>Postgres</>には、データのバックアップを行うために2つの方法があります。
</para>

  <itemizedlist>
   <listitem><para><acronym>SQL</><!-- dump-->ダンプ</para></listitem>
   <listitem><para><!--File system level backup-->
                   ファイルシステムレベルのバックアップ
             </para>
   </listitem>
  </itemizedlist>

 <sect1 id="backup-dump">
  <title><acronym>SQL</><!-- Dump-->ダンプ</title>
<indexterm><primary sortas="SQLだんぷ">SQLダンプ</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="SQLだんぷ">SQLダンプ</secondary></indexterm>
  <para>
   <!--The idea behind this method is to generate a text file with SQL
   commands that, when fed back to the server, will recreate the
   database in the same state as it was at the time of the dump.
   <productname>Postgres</> provides the utility program
   <application>pg_dump</> for this purpose. The basic usage of this
   command is:-->

   この方法の背後には、SQLコマンド群が書かれたテキストファイルを生成し、サーバーにそのファイルを読み込ませたら、ダンプされたときと同じ状態を再構築する、というものがあります。このため、<productname>Postgres</>にはユーティリティプログラムとして<application>pg_dump</>を提供しています。このコマンドの一般的な使用方法は以下のとおりです。<indexterm><primary>pg_dump</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>pg_dump</secondary></indexterm>
</para>

<synopsis>
pg_dump <replaceable class="parameter">dbname</replaceable> &gt; <replaceable class="parameter">outfile</replaceable>
</synopsis>

<para>
   <!--As you see, <application>pg_dump</> writes its results to the
   standard output. We will see below how this can be useful.-->

   見てわかるように、<application>pg_dump</>は結果を標準出力に書き出します。これがどのように活用できるかをこれから説明していきます。
  </para>

  <para>
   <!--<application>pg_dump</> is a regular <productname>Postgres</>
   client application (albeit a particularly clever one). This means
   that you can do this backup procedure from any remote host that has
   access to the database. But remember that <application>pg_dump</>
   does not operate with special permissions. In particular, you must
   have read access to all tables that you want to back up, so in
   practice you almost always have to be a database superuser.-->

   <application>pg_dump</>は、すぐれた機能を持っている<productname>Postgres</>の標準クライアントアプリケーションです。したがって、データベースに接続可能な、あらゆるリモートホストからバックアップの機能を実行することができます。しかし、<application>pg_dump</>は特別な権限で動作するわけではありません。具体的には、バックアップを行うすべてのテーブルに対して読むアクセス権が必要となります。実際には、ほとんどの場合、データベースのスーパーユーザーである必要があります。
  </para>

  <para>
   <!--To specify which database server <application>pg_dump</> should
   contact, use the command line options <option>-h
   <replaceable>host</></> and <option>-p <replaceable>port</></>. The
   default host is the local host or whatever your
   <envar>PGHOST</envar> environment variable specifies. Similarly,
   the default port is indicated by the <envar>PGPORT</envar>
   environment variable or, failing that, by the compiled-in default.
   (Conveniently, the server will normally have the same compiled-in
   default.)-->

   <application>pg_dump</>を行うデータベースサーバーを特定するには、コマンドラインオプション、<option>-h <replaceable>host</></>と<option>-p <replaceable>port</></>を使用します。デフォルトのホストはローカルホスト、または環境変数<envar>PGHOST</envar>が指定するものです。同様に、デフォルトのポートは環境変数<envar>PGPORT</envar>で指定されているか、コンパイル時に設定されたデフォルトとなります（普通サーバーは同じコンパイルデフォルトとなります）。
  </para>

  <para>
   <!--As any other <productname>Postgres</> client application,
   <application>pg_dump</> will by default connect with the database
   user name that is equal to the current Unix user name. To override
   this, either specify the <option>-u</option> option to force a prompt for
   the user name, or set the environment variable
   <envar>PGUSER</envar>. Remember that <application>pg_dump</>
   connections are subject to the normal client authentication
   mechanisms (which are described in <xref
   linkend="client-authentication">).-->

   他の<productname>Postgres</>のクライアントアプリケーションと同様に、<application>pg_dump</>はデフォルトで、現在のUnixユーザー名と同じデータベースユーザー名で接続します。これの対処方法の1つとしては、<option>-u</option>オプションを付けて、強制的にユーザー名を入力するためのプロンプトを表示させる方法があります。また、環境変数<envar>PGUSER</envar>を設定するのも1つの方法です。<application>pg_dump</>の接続は普通のクライアント認証方法によるものであることに注意してください。
  </para>

  <para>
   <!--Dumps created by <application>pg_dump</> are internally consistent,
   that is, updates to the database while <application>pg_dump</> is
   running will not be in the dump. <application>pg_dump</> does not
   block other operations on the database while it is working.
   (Exceptions are those operations that need to operate with an
   exclusive lock, such as <command>VACUUM</command>.)-->

   <application>pg_dump</>で作成されたダンプは、内部的に整合性があります。これはつまり、<application>pg_dump</>が行われている際の更新はダンプには反映されないということです。また、<application>pg_dump</>が作動しているときでも、データベースの他の作業は妨げられません（しかし、<command>VACUUM</command>などの、排他的なロックが必要な作業は例外となります）。
  </para>

  <important>
   <para>
    <!--When your database schema relies on OIDs (for instances as foreign
    keys) you must instruct <application>pg_dump</> to dump the OIDs
    as well. To do this, use the <option>-o</option> command line
    option.-->

    たとえば、OIDを外部キーとしている場合などのように、データベースのスキーマがOIDに依存しているならば、OIDも一緒にダンプするように<application>pg_dump</>に指定する必要があります。これを行うには、コマンドラインオプションとして<option>-o</option>を使用してください。
   </para>
  </important>

  <sect2 id="backup-dump-restore">
   <title><!--Restoring the dump-->ダンプのリストア</title>
<indexterm><primary sortas="りすとあ">リストア</primary><secondary sortas="だんぷ">ダンプ</secondary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="だんぷのりすとあ">ダンプのリストア</secondary></indexterm>
   <para>
    <!--The text files created by <application>pg_dump</> are intended to
    be read in by the <application>psql</application> program. The
    general command form to restore a dump is-->

    <application>pg_dump</>で作成されたテキストファイルは、<application>psql</application>プログラムで読み込まれることを意図しています。以下に、ダンプをリストアする一般的な方法を示します。
</para>

<synopsis>
psql <replaceable class="parameter">dbname</replaceable> &lt; <replaceable class="parameter">infile</replaceable>
</synopsis>


<para>
    <!--where <replaceable class="parameter">infile</replaceable> is what
    you used as <replaceable class="parameter">outfile</replaceable>
    for the pg_dump command. The database <replaceable
    class="parameter">dbname</replaceable> will not be created by this
    command, you must create it yourself from template0 before executing
    <application>psql</> (e.g., with <userinput>createdb -T template0
    <replaceable class="parameter">dbname</></userinput>).
    <application>psql</> supports similar options to <application>pg_dump</> 
    for controlling the database server location and the user names. See
    its reference page for more information.-->

    ここで、<replaceable class="parameter">infile</replaceable>とはpg_dumpコマンドを実行した際の<replaceable class="parameter">出力</replaceable>ファイル名です。このコマンドを実行しても<replaceable class="parameter">dbname</replaceable>（データベース）は作成されません。必ず<application>psql</>を使ってtemplate0から作成してください（例：<userinput>createdb -T template0 <replaceable class="parameter">dbname</></userinput>）。<application>psql</>には<application>pg_dump</>と似たような、データベースサーバーの場所とユーザー名を指定する機能があります。詳細については、該当するページを参照してください。
   </para>

   <para>
    <!--If the objects in the original database were owned by different
    users, then the dump will instruct <application>psql</> to connect
    as each affected user in turn and then create the relevant
    objects. This way the original ownership is preserved. This also
    means, however, that all these user must already exist, and
    furthermore that you must be allowed to connect as each of them.
    It might therefore be necessary to temporarily relax the client
    authentication settings.-->

    データベース内のオブジェクトの所有権が別のユーザーにあった場合、ダンプは<application>psql</>に該当するユーザーとして順番に接続させ、適切なオブジェクトを作成させます。この方法により、オリジナルの所有権が保たれます。しかしまた、それらのユーザーはあらかじめ存在しなければならず、それぞれのユーザーとして該当する各データベースに接続できる権限を持っていなければいけません。したがって、一時的にクライアント認証設定を緩める必要があるでしょう。

   </para>

   <para>
    <!--The ability of <application>pg_dump</> and <application>psql</> to
    write or read from pipes also make it possible to dump a database
    directory from one server to another, for example-->

    <application>pg_dump</>と<application>psql</>でパイプから読み書きが行えることは、1つのサーバーから別のサーバーへとデータベースのディレクトリをダンプすることが可能となりることを意味します。以下にその例を示します。</para>

    <informalexample>
<programlisting>
pg_dump -h <replaceable>host1</> <replaceable>dbname</> | psql -h <replaceable>host2</> <replaceable>dbname</>
</programlisting>
    </informalexample>


  <important>
   <para>
    <!--The dumps produced by pg_dump are relative to template0. This means 
    that any languages, procedures, etc. added to template1 will also be
    dumped by <application>pg_dump</>. As a result, when restoring, if 
    you are using a customized template1, you must create the empty
    database from template0, as in the example above.-->

    pg_dumpで作成されたダンプはtemplate0に相対しています。これはつまり、template1に追加されたあらゆる言語、手順なども<application>pg_dump</>でダンプされます。その結果、リストアする際に、カスタマイズされたtemplate1を使用している場合は上記のように、template0から空のデータベースを作成する必要があります。
   </para>
  </important>

  </sect2>

  <sect2 id="backup-dump-all">
   <title><!--Using--><command>pg_dumpall</>の利用</title>
<indexterm><primary>pg_dumpall</primary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary>pg_dumpall</secondary></indexterm>
   <para>
    <!--The above mechanism is cumbersome and inappropriate when backing
    up an entire database cluster. For this reason the
    <application>pg_dumpall</> program is provided.
    <application>pg_dumpall</> backs up each database in a given
    cluster and also makes sure that the state of global data such as
    users and groups is preserved. The call sequence for
    <application>pg_dumpall</> is simply-->

    上記に説明のあったものは、データベースクラスタすべてをバックアップする際にはとても厄介で、不適当なものです。これに対応するために、<application>pg_dumpall</>があります。<application>pg_dumpall</>は指定されたクラスタの各データベースのバックアップを行い、ユーザーやグループなどのグローバルデータの状態が確実に保存されるようにします。この方法の記述方法は以下のとおりです。
</para>

<synopsis>
pg_dumpall &gt; <replaceable>outfile</>
</synopsis>

<para>
    <!--The resulting dumps can be restored with <application>psql</> as
    described above. But in this case it is definitely necessary that
    you have database superuser access, as that is required to restore
    the user and group information.-->

    ダンプの結果は上記の説明のとおり、<application>psql</>でリストアすることが可能です。しかしこの場合、ユーザーとグループの情報を保存するので、データベースのスーパーユーザーの権限が必要です。
   </para>

   <para>
    <!--<application>pg_dumpall</application> has one little flaw: It is
    not prepared for interactively authenticating to each database it
    dumps. If you are using password authentication then you need to
    set it the environment variable <envar>PGPASSWORD</envar> to
    communicate the password the the underlying calls to
    <application>pg_dump</>. More severely, if you have different
    passwords set up for each database, then
    <application>pg_dumpall</> will fail. You can either choose a
    different authentication mechanism for the purposes of backup or
    adjust the <filename>pg_dumpall</filename> shell script to your
    needs.-->

    実は<application>pg_dumpall</application>には、1つの小さな欠点があります。それは、ダンプする各データベースの対話型ユーザー認証が実装されていないということです。パスワード認証を使用していた場合、環境変数<envar>PGPASSWORD</envar>に設定を行い、<application>pg_dump</>の関数が使えるようにする必要があります。また、各データベースで異なるパスワードを使用している場合には、すべての<application>pg_dumpall</>は失敗に終わってしまいます。バックアップを行うために認証方法を変えるか、<filename>pg_dumpall</filename>のシェルスクリプトをニーズに合うように書き換えてください。
   </para>
  </sect2>

  <sect2 id="backup-dump-large">
   <title><!--Large Databases-->大きいデータベース</title>
<indexterm><primary sortas="ばっくあっぷ">バックアップ</primary><secondary sortas="おおきいでーたべーす">大きいデータベース</secondary></indexterm>
   <note>
    <title><!--Acknowledgement-->謝辞</title>
    <para>
     <!--Originally written by-->原文はHannu Krosing（<email>hannu@trust.ee</email>）によって書かれました（<!-- on -->1999-06-19）。
    </para>
   </note>

   <para>
    <!--Since <productname>Postgres</productname> allows tables larger
    than the maximum file size on your system, it can be problematic
    to dump the table to a file, since the resulting file will likely
    be larger than the maximum size allowed by your system. As
    <application>pg_dump</> writes to the standard output, you can
    just use standard *nix tools to work around this possible problem.-->

    <productname>Postgres</productname>では、システムでの可能な最大ファイルサイズよりも大きなテーブルが可能ですので、ファイルにダンプする際に、可能ファイルサイズよりも大きくなってしまう、という問題に遭遇する可能性があります。<application>pg_dump</>は標準出力に書き出しますので、この問題を解決するために、Unixのツールを使用して回避することができます。
   </para>

   <formalpara>
    <title><!--Use compressed dumps.-->圧縮ダンプの使用</title>
<indexterm><primary sortas="あっしゅくだんぷ">圧縮ダンプ</primary></indexterm>
<indexterm><primary sortas="ばっくあっぷ">バックアップ</primary><secondary sortas="あっしゅくだんぷ">圧縮ダンプ</secondary></indexterm>
<indexterm><primary>PostgreSQL</primary><secondary sortas="あっしゅくだんぷ">圧縮ダンプ</secondary></indexterm>
    <para>
     <!--Use your favorite compression program, for example
     <application>gzip</application>.-->
     <application>gzip</application>のような、好みの圧縮ソフトを使用します。</para>
   </formalpara>

<programlisting>
pg_dump <replaceable class="parameter">dbname</replaceable> | gzip &gt; <replaceable class="parameter">filename</replaceable>.gz
</programlisting>

<para><!--Reload with-->伸張方法としては、以下のような方法があります。</para>

<programlisting>
createdb <replaceable class="parameter">dbname</replaceable>
gunzip -c <replaceable class="parameter">filename</replaceable>.gz | psql <replaceable class="parameter">dbname</replaceable>
</programlisting>

<para><!--or-->または、以下のようにもできます。</para>

<programlisting>
cat <replaceable class="parameter">filename</replaceable>.gz | gunzip | psql <replaceable class="parameter">dbname</replaceable>
</programlisting>


   <formalpara>
    <title><!--Use <application>split</>.--><application>split</>の使用</title>
<indexterm><primary>split</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary>split</secondary></indexterm><indexterm><primary sortas="ばっくあっぷ">バックアップ</primary><secondary>split</secondary></indexterm>
    <para>
     <!--This allows you to split the output into pieces that are
     acceptable in size to the underlying file system. For example, to
     make chunks of 1 megabyte:-->

     この方法は、結果を環境下にあるシステムで受け付けられる大きさに分割します。たとえば、1Mバイトのチャンクを分割するには、以下のコマンドを実行します。</para>

   </formalpara>

     <informalexample>
<programlisting>
pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 1m - <replaceable class="parameter">filename</replaceable>
</programlisting>
     </informalexample>

     <!--Reload with-->
<para>元に戻すには、以下のようにします。</para>

     <informalexample>
<programlisting>
createdb <replaceable class="parameter">dbname</replaceable>
cat <replaceable class="parameter">filename</replaceable>* | psql <replaceable class="parameter">dbname</replaceable>
</programlisting>
     </informalexample>



   <formalpara>
    <title><!--Use the custom dump format (V7.1).-->カスタムダンプ形式を使用（V7.1）</title><indexterm><primary sortas="かすたむだんぷ">カスタムダンプ</primary></indexterm><indexterm><primary>PostgreSQL</primary><secondary sortas="かすたむだんぷ">カスタムダンプ</secondary></indexterm><indexterm><primary sortas="ばっくあっぷ">バックアップ</primary><secondary sortas="かすたむだんぷ">カスタムダンプ</secondary></indexterm>
    <para>
     <!--If PostgreSQL was built on a system with the zlib compression library
     installed, the custom dump format will compress data as it writes it
     to the output file. For large databases, this will produce similar dump
     sizes to using gzip, but has the added advantage that the tables can be
     restored selectively. The following command dumps a database using the
     custom dump format:-->

     PostgreSQLが、zlibデータ圧縮ライブラリがインストールされているシステムにインストールされているならば、カスタムダンプ形式を使用すれば、結果ファイルに出力するときに、データを圧縮します。大きいデータベースでは、gzipを使用しているのと同様なダンプサイズとなります。しかし、テーブルの復元が部分的に行えるという点で、優れているといえます。下記のコマンドを実行するとカスタムダンプ形式でデータベースのダンプを行います。</para>
   </formalpara>

<para>
     <informalexample>
<programlisting>
pg_dump -Fc <replaceable class="parameter">dbname</replaceable> > <replaceable class="parameter">filename</replaceable>
</programlisting>
     </informalexample>
   </para>

     <!--See the <application>pg_dump</> and <application>pg_restore</> reference pages for details.-->

<para>詳細は<application>pg_dump</>と<application>pg_restore</>のリファレンスページを参照してください。

    </para>

  </sect2>

  <sect2 id="backup-dump-caveats">
   <title><!--Caveats-->警告</title>

   <para>
    <!--<application>pg_dump</> (and by implication
    <application>pg_dumpall</>) has a few limitations which stem from
    the difficulty to reconstruct certain information from the system
    catalogs.-->

    <application>pg_dump</>（実装面では<application>pg_dumpall</>も）にはシステムカタログからデータベースを復元する際、復元するのが困難な情報が中にはあるために生じる、いくつかの制約があります。
   </para>

   <para>
    <!--Specifically, the order in which <application>pg_dump</> writes
    the objects is not very sophisticated. This can lead to problems
    for example when functions are used as column default values. The
    only answer is to manually reorder the dump. If you created
    circular dependencies in your schema then you will have more work
    to do.-->

    特に、<application>pg_dump</>がオブジェクトを書き出す順序は洗練されていません。これは、たとえば列のデフォルト値として関数が使用されている場合などで問題となります。この問題を解決するには、手動でダンプ順序を変更する方法以外ありません。スキーマで巡回依存を作成していた場合は、これ以上の作業が必要となります。
   </para>

   <para>
    <!--For reasons of backward compatibility, <application>pg_dump</> does
    not dump large objects by default. To dump large objects you must use 
    either the custom or the TAR output format, and use the -B option in 
    <application>pg_dump</>. See the reference pages for details.
    The directory <filename>contrib/pg_dumplo</> of the
    <productname>Postgres</> source tree also contains a program that can
    dump large objects.-->

    逆互換性の理由から、<application>pg_dump</>のデフォルトではラージオブジェクトのダンプは行いません。ラージオブジェクトのダンプを行うには出力形式をカスタムする、もしくはTAR形式を使用する必要があり、<application>pg_dump</>に-bオプションを付ける必要があります。詳細はリファレンスページを参照してください。<productname>Postgres</>ソースツリーの<filename>contrib/pg_dumplo</>ディレクトリにもラージオブジェクトをダンプする方法の記載があります。
   </para>

   <para>
    <!--Please familiarize yourself with the
    <citerefentry><refentrytitle>pg_dump</></> reference page.-->

    <citerefentry><refentrytitle>pg_dump</></>のリファレンスページを読み親しんでください。

   </para>
  </sect2>
 </sect1>

 <sect1 id="backup-file">
  <title><!--File system level backup-->ファイルシステムレベルバックアップ</title>
<indexterm><primary sortas="ふぁいるしすてむれべるばっくあっぷ">ファイルシステムレベルバックアップ</primary></indexterm><indexterm><primary sortas="ばっくあっぷ">バックアップ</primary><secondary sortas="ふぁいるしすてむれべる">ファイルシステムレベル</secondary></indexterm><indexterm><primary>PostgreSQL</primary><secondary sortas="ふぁいるしすてむれべるばっくあっぷ">ファイルシステムレベルバックアップ</secondary></indexterm>
  <para>
   <!--An alternative backup strategy is to directly copy the files that
   <productname>Postgres</> uses to store the data in the database. In
   <xref linkend="creating-cluster"> it is explained where these files
   are located, but you have probably found them already if you are
   interested in this method. You can use whatever method you prefer
   for doing usual file system backups, for example-->

   バックアップの方法の代替案として、<productname>Postgres</>がデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。<xref linkend="creating-cluster">では、これらのファイルがどこにあるかが明記されていますが、この方法に興味があれば、もうすでに発見していることでしょう。下記のような、通常のファイルシステムのバックアップを行う方法と同じで問題ありません。</para>

   <informalexample>
<programlisting>
tar -cf backup.tar /usr/local/pgsql/data
</programlisting>
   </informalexample>

  <para>
   <!--There are two restrictions, however, which make this method
   impractical, or at least inferior to the <application>pg_dump</>
   method:-->

   しかし、この方法には2つの制約があり、そのためにあまり実用的ではなく、<application>pg_dump</>より劣るといわざるを得ません。
</para>

   <orderedlist>
    <listitem>
     <para>
      <!--The database server <emphasis>must</> be shut down in order to
      get a usable backup. Half-way measures such as disallowing all
      connections will not work as there is always some buffering
      going on. For this reason it is also not advisable to trust file
      systems that claim to support <quote>consistent
      snapshots</quote>. Information about stopping the server can be
      found in <xref linkend="postmaster-shutdown">.-->

有意義なバックアップを行うためには、データベースサーバーはシャットダウンされている必要があります。バッファリングなどが行われている可能性があるので、すべての接続を無効とするだけでは不十分です。また、この理由から、ファイルシステムの<quote>consistent snapshots</quote>の使用はあまりお勧めできません。サーバーの停止に関しては<xref linkend="postmaster-shutdown">を参照してください。
     </para>

     <para>
      <!--Needless to say that you also need to shut down the server
      before restoring the data.-->
言うまでもありませんが、データを復元する前にもサーバーを停止させる必要があります。
     </para>
    </listitem>

    <listitem>
     <para>
      <!--If you have dug into the details of the file system layout you
      may be tempted to try to back up or restore only certain
      individual tables or databases from their respective files or
      directories. This will <emphasis>not</> work because the
      information contained in these files contains only half the
      truth. The other half is in the file
      <filename>pg_log</filename>, which contains the commit status of
      all transactions. A table file is only usable with this
      information. Of course it is also impossible to restore only a
      table and the associated <filename>pg_log</filename> file
      because that will render all other tables in the database
      cluster useless.-->

ファイルシステムのレイアウトの詳細を知っている場合、ある個別のテーブルやデータベースのそれぞれのファイルやディレクトリのみをバックアップしたり、復元することを試みたことがあるかもしれません。しかし、それらのファイルの情報のみでは不十分なので、この方法では正常にバックアップは行えません。<filename>pg_log</filename>という、すべてのトランザクションのコミットのステータス書かれたファイルが必要となります。テーブルファイルはこの情報があって始めて意味を成します。また、テーブルと、それに関係する<filename>pg_log</filename>ファイルのみではデータベースクラスタにある他のテーブルを無効となってしまうので、リストアはできません。
     </para>
    </listitem>
   </orderedlist>

  <para>
   <!--Also note that the file system backup will not necessarily be
   smaller than an SQL dump. On the contrary, it will most likely be
   larger. (<application>pg_dump</application> does not need to dump
   the contents of indices for example, just the commands to recreate
   them.)-->

また、ファイルシステムのバックアップは必ずしもSQLのダンプより小さいものとはなりません。反対に、多くの場合は大きくなってしまいます（<application>pg_dump</application>では、たとえばインデックスなどはダンプする必要がなく、復元させるためのコマンドのみが必要だからです）。
  </para>

 </sect1>

 <sect1 id="migration">
  <title><!--Migration between releases-->リリース間の移行</title>
<indexterm><primary sortas="ばっくあっぷ">バックアップ</primary><secondary sortas="りりーすかんのいこう">リリース間の移行</secondary></indexterm><indexterm><primary>PostgreSQL</primary><secondary sortas="りりーすかんのいこう">リリース間の以降</secondary></indexterm>
  <para>
   <!--As a general rule, the internal data storage format is subject to
   change between releases of <productname>Postgres</>. This does not
   apply to different <quote>patch levels</quote>, these always have
   compatible storage formats. For example, releases 6.5.3, 7.0.1, and
   7.1 are not compatible, whereas 7.0.2 and 7.0.1 are. When you
   update between compatible versions, then you can simply reuse the
   data area in disk by the new executables. Otherwise you need to
   <quote>back up</> your data and <quote>restore</> it on the new
   server, using <application>pg_dump</>. (There are checks in place
   that prevent you from doing the wrong thing, so no harm can be done
   by confusing these things.) The precise installation procedure is
   not subject of this section, the <citetitle>Installation
   Instructions</citetitle> carry these details.-->

   一般的に、<productname>Postgres</>のリリース間では、内部のデータ保管形式は変更することが仮定されています。これは、異なったパッチレベルには該当しません。パッチレベル間では必ず互換性のある保管形式となっています。たとえば、6.5.3、7.0.1、7.1の間は互換性がありませんが、7.0.2と7.0.1は互換性があります。互換性があるバージョンでの移行を行う場合は、ただ単にディスク上のデータ領域を新しい実行プログラムで使用するだけで問題ありません。その他の場合は、<application>pg_dump</>を使って、データを<quote>バックアップ</>し、新しいサーバーに<quote>リストア</>する必要があります（間違ったことを行わないように、随時確認があります）。この章では、正確なインストール手順については触れませんので、詳細は<!--<citetitle>インストール手順</citetitle>--><xref linkend="installation">を参照してください。
  </para>

  <para>
   <!--The least downtime can be achieved by installing the new server in
   a different directory and running both the old and the new servers
   in parallel, on different ports. Then you can use something like-->

   サーバーを停止させる時間を最も短時間にするには、新しいサーバーを違ったディレクトリにインストールし、古いサーバーと新しいサーバーを異なったポートで並行に稼働させる方法があります。そして、データを転送させるために以下のようなコマンドを実行するか、中間ファイルを使用してください。</para>

<informalexample>
<programlisting>
pg_dumpall -p 5432 | psql -d template1 -p 6543
</programlisting>

</informalexample>

   <!--to transfer your data, or use an intermediate file if you want.
   Then you can shut down the old server and start the new server at
   the port the old one was running at. You should make sure that the
   database is not updated after you run <application>pg_dumpall</>,
   otherwise you will obviously lose that data. See <xref
   linkend="client-authentication"> for information on how to prohibit
   access. In practice you probably want to test your client
   applications on the new setup before switching over.-->

<para>その後、古いサーバーを停止させ、新しいサーバーを古いサーバーが稼働していたポートで立ち上げてください。このとき、<application>pg_dumpall</>を行った後にデータベースが更新されていないことを確認してください。さもないとそれらのデータは消えてしまいます。接続を拒否する方法は<xref linkend="client-authentication">を参照してください。実際には、サーバーを入れ換える前に、クライアントアプリケーションのテストを行うことをお勧めします。
  </para>

  <para>
   <!--If you cannot or do not want to run two servers in parallel you can
   do the back up step before installing the new version, bring down
   the server, move the old version out of the way, install the new
   version, start the new server, restore the data. For example:-->

   2つのサーバーを並行に稼働できない、または稼働したくない場合は、新しいバージョンのインストールを行う前に、下記のコマンドのようにまずバックアップを行い、古いバージョンを削除してから、新しいバージョンをインストールし、新しいサーバーを立ち上げて、データをリストアしてください。</para>

<informalexample>
<programlisting>
pg_dumpall > backup
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd /usr/src/postgresql-7.1
gmake install
initdb -D /usr/local/pgsql/data
postmaster -D /usr/local/pgsql/data
psql < backup
</programlisting>
</informalexample>

   <!--See <xref linkend="runtime"> about ways to start and stop the
   server and other details. The installation instructions will advise
   you of strategic places to perform these steps.-->

<para>サーバーを開始/停止させる方法や、その他の詳細は<xref linkend="runtime">を参照してください。インストール手順では、これらのステップを実行する場所についてのアドバイスが記載されています。

  </para>

  <note>
   <para>
    <!--When you <quote>move the old installation out of the way</quote>
    it is no longer perfectly usable. Some parts of the installation
    contain information about where the other parts are located. This
    is usually not a big problem but if you plan on using two
    installations in parallel for a while you should assign them
    different installation directories at build time.-->

    <quote>古いバージョンを削除</quote>した場合、それらは正常に使用できなくなってしまいます。インストールのある部分には、その他のものがどこにインストールされたかの情報が含まれています。これは多くの場合、たいした問題ではありませんが、2つのインストールをしばらく並行に使用する場合、ビルドの際に異なったインストールディレクトリを指定することをお勧めします。

   </para>
  </note>
 </sect1>
</chapter>
