Re: File system snapshots for multiple file systems - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: File system snapshots for multiple file systems
Date
Msg-id 200804090312.m393CuL14101@momjian.us
Whole thread Raw
In response to File system snapshots for multiple file systems  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
I have applied the following patch to document the use of continuous
archiving backups to allow non-simultaneous snapshots.

I don't think we want to go any farther to stop WAL recycling during
back backups.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Right now it isn't possible to use file system snapshots a reliable
> backup if you are using multiple file systems for tablespaces because
> most systems don't allow the simultaneous snapshoting of multiple file
> system.  Our documentation mentions this:
>
>     If your database is spread across multiple file systems, there might not
>     be any way to obtain exactly-simultaneous frozen snapshots of all the
>     volumes. For example, if your data files and WAL log are on different
>     disks, or if tablespaces are on different file systems, it might not be
>     possible to use snapshot backup because the snapshots must be
>     simultaneous. Read your file system documentation very carefully before
>     trusting to the consistent-snapshot technique in such situations. The
>     safest approach is to shut down the database server for long enough to
>     establish all the frozen snapshots.
>
> However, it occurred to me that if someone turned on continuous arciving
> during the file system snapshots, then you could use PITR to recover
> from file system snapshots that were not simultaneous.
>
> Should this be documented?
>
> --
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
>
>   + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.117
diff -c -c -r2.117 backup.sgml
*** doc/src/sgml/backup.sgml    5 Apr 2008 01:34:05 -0000    2.117
--- doc/src/sgml/backup.sgml    9 Apr 2008 02:39:44 -0000
***************
*** 386,394 ****
     not be possible to use snapshot backup because the snapshots
     <emphasis>must</> be simultaneous.
     Read your file system documentation very carefully before trusting
!    to the consistent-snapshot technique in such situations.  The safest
!    approach is to shut down the database server for long enough to
!    establish all the frozen snapshots.
    </para>

    <para>
--- 386,402 ----
     not be possible to use snapshot backup because the snapshots
     <emphasis>must</> be simultaneous.
     Read your file system documentation very carefully before trusting
!    to the consistent-snapshot technique in such situations.
!   </para>
!
!   <para>
!    If simultaneous snapshots are not possible, one option is to shut down
!    the database server long enough to establish all the frozen snapshots.
!    Another option is perform a continuous archiving base backup (<xref
!    linkend="backup-base-backup">) because such backups are immune to file
!    system changes during the backup.  This requires enabling continuous
!    archiving just during the backup process; restore is done using
!    continuous archive recovery (<xref linkend="backup-pitr-recovery">).
    </para>

    <para>

pgsql-hackers by date:

Previous
From: "Jonah H. Harris"
Date:
Subject: Re: Setting a pre-existing index as a primary key
Next
From: Tom Lane
Date:
Subject: Re: Concurrent psql API