11<!--
2- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.51 2004/11/15 06:32:13 neilc Exp $
2+ $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.52 2004/11/17 18:29:02 tgl Exp $
33-->
44<chapter id="backup">
55 <title>Backup and Restore</title>
@@ -615,8 +615,10 @@ archive_command = 'test ! -f .../%f && cp %p .../%f'
615615 Note that although WAL archiving will allow you to restore any
616616 modifications made to the data in your <productname>PostgreSQL</> database
617617 it will not restore changes made to configuration files (that is,
618-
618+
619619 <filename>pg_ident.conf</>) after the initial base backup.
620+ You may wish to keep the configuration files in a location that will
621+ be backed up by your regular filesystem backup procedures.
620622 </para>
621623 </sect2>
622624
@@ -638,11 +640,11 @@ archive_command = 'test ! -f .../%f && cp %p .../%f'
638640SELECT pg_start_backup('label');
639641</programlisting>
640642 where <literal>label</> is any string you want to use to uniquely
641- identify this backup operation.<function>pg_start_backup</> creates
642- a <firstterm>backup label</> file, called <filename>backup_label</>,
643- in the cluster directory with information about your backup.
644- One good practice is to use thefull path where you intend to put the
645- backup dump file as .
643+ identify this backup operation. (One good practice is to use the
644+ full path where you intend to put the backup dump file.)
645+ <function>pg_start_backup</> creates a <firstterm> backup label</> file,
646+ called <filename>backup_label</>, in thecluster directory with
647+ information about your backup .
646648 </para>
647649
648650 <para>
@@ -762,19 +764,25 @@ SELECT pg_stop_backup();
762764 <orderedlist>
763765 <listitem>
764766 <para>
765- Stop the postmaster, if it's running. If you have the space to do so,
766- copy the cluster data directory and any tablespaces to a temporary
767- location so that you can reference them later. Note that this will
767+ Stop the postmaster, if it's running.
768+ </para>
769+ </listitem>
770+ <listitem>
771+ <para>
772+ If you have the space to do so,
773+ copy the whole cluster data directory and any tablespaces to a temporary
774+ location in case you need them later. Note that this precaution will
768775 require that you have enough free space on your system to hold two
769776 copies of your existing database. If you do not have enough space,
770- you need at the least tobackup the <filename>pg_xlog</> directory in
771- the cluster data directory as it may contain logs which were not archived
772- before the system went down.
777+ you need at the least tocopy thecontents of the <filename>pg_xlog</>
778+ subdirectory of the cluster data directory, as it may contain logs which
779+ were not archived before the system went down.
773780 </para>
774-
781+ </listitem>
782+ <listitem>
775783 <para>
776- Next, clean out all existing files under the cluster data directory and
777- under the root directories of any tablespaces you are using.
784+ Clean out all existing filesand subdirectories under the cluster data
785+ directory and under the root directories of any tablespaces you are using.
778786 </para>
779787 </listitem>
780788 <listitem>
@@ -797,7 +805,7 @@ SELECT pg_stop_backup();
797805 </listitem>
798806 <listitem>
799807 <para>
800- If you had unarchived WAL segment files that you saved in step1 ,
808+ If you had unarchived WAL segment files that you saved in step2 ,
801809 copy them into <filename>pg_xlog/</>. (It is best to copy them,
802810 not move them, so that you still have the unmodified files if a
803811 problem occurs and you have to start over.)