Jim C. Nasby wrote:
> > > Has anyone tried moving a database from one location to another on the
> > > HD? I'd like to use slony to minimize downtime, but I'd also like my
> > > data to end up in the same place it is right now when I'm done.
> >
> > I used a straight copy of the filesystem with running database
> > (over the net in my case) and immediately after that,
> > stop the db and rsync for the last changes. This took only
> > 10 minutes (compared to 1.5h for the full filesystem copy)
> > and I could start up the db in new location.
> >
> > this could work for you too.
>
> I hadn't thought about using rsync; that's a great idea!
>
> Is there somewhere this could be documented? In an FAQ maybe?
Added to documentation, patch attached.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.56
diff -c -c -r2.56 backup.sgml
*** doc/src/sgml/backup.sgml 25 Feb 2005 04:56:01 -0000 2.56
--- doc/src/sgml/backup.sgml 17 Mar 2005 05:01:54 -0000
***************
*** 374,379 ****
--- 374,388 ----
</para>
<para>
+ Another option is to use <application>rsync</> to perform a file
+ system backup. First, while the database server is running,
+ run <application>rsync</>, then shut down the database
+ server and perform a second <application>rsync</>, then
+ restart the database server. This allows a file system backup to be
+ performed with minimal downtime.
+ </para>
+
+ <para>
Note that a 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
