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: