backup.sgml

PostgreSQL7.4.6 for Linux

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

   <formalpara>
    <title>Use the custom dump format.</title>
    <para>
     If <productname>PostgreSQL</productname> was built on a system with the <application>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 <command>gzip</command>, but has the added advantage that the tables can be
     restored selectively. The following command dumps a database using the
     custom dump format:

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

     See the <application>pg_dump</> and <application>pg_restore</> reference pages for details.
    </para>
   </formalpara>

  </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 of reconstructing certain information from the system
    catalogs.
   </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.
   </para>

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

   <para>
    Please familiarize yourself with the
    <citerefentry><refentrytitle>pg_dump</></> reference page.
   </para>
  </sect2>
 </sect1>

 <sect1 id="backup-file">
  <title>File system level backup</title>

  <para>
   An alternative backup strategy is to directly copy the files that
   <productname>PostgreSQL</> 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

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

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

   <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">.  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 of the data 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 commit log files
      <filename>pg_clog/*</filename>, which contain 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_clog</filename> data
      because that would render all other tables in the database
      cluster useless.
     </para>
    </listitem>
   </orderedlist>
  </para>

  <para>
   An alternative file-system backup approach is to make a
   <quote>consistent snapshot</quote> of the data directory, if the
   file system supports that functionality.  Such a snapshot will save
   the database files in a state where the database server was not
   properly shut down; therefore, when you start the database server
   on this backed up directory, it will think the server had crashed
   and replay the WAL log.  This is not a problem, just be aware of
   it.
  </para>

  <para>
   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 indexes for example, just the commands to recreate
   them.)
  </para>

 </sect1>

 <sect1 id="migration">
  <title>Migration Between Releases</title>

  <indexterm zone="migration">
   <primary>upgrading</primary>
  </indexterm>

  <indexterm zone="migration">
   <primary>version</primary>
   <secondary>compatibility</secondary>
  </indexterm>

  <para>
   As a general rule, the internal data storage format is subject to
   change between major releases of <productname>PostgreSQL</> (where
   the number after the first dot changes). This does not apply to
   different minor releases under the same major release (where the
   number of the second dot changes); these always have compatible
   storage formats. For example, releases 7.0.1, 7.1.2, and 7.2 are
   not compatible, whereas 7.1.1 and 7.1.2 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; these details are in <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

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

   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>

  <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:

<programlisting>
pg_dumpall > backup
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd ~/postgresql-&version;
gmake install
initdb -D /usr/local/pgsql/data
postmaster -D /usr/local/pgsql/data
psql template1 < backup
</programlisting>

   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>

  <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.
   </para>
  </note>
 </sect1>
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-tabs-mode:nil
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/share/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->