Skip site navigation (1) Skip section navigation (2)

Re: Suggestions needed about how to dump/restore a database

From: "Chris Hoover" <revoohc(at)gmail(dot)com>
To: arnaulist(at)andromeiberica(dot)com
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Suggestions needed about how to dump/restore a database
Date: 2006-12-19 21:44:06
Message-ID: 1d219a6f0612191344x2f772a7el8ef9117a057c9cd8@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
One other option is to shut the database down competely, and then do a copy
of the file system the new server.  I have done this when I need to move a
very large database to a new server.  I can copy 500GB's in a couple of
hours, where restoring my large databases backups would take 10+ hours.
Just make sure you are keeping postgres at the same version level.

HTH,

Chris

On 12/19/06, Arnau <arnaulist(at)andromeiberica(dot)com> wrote:
>
> Hi all,
>
>    I've got a DB in production that is bigger than 2GB that dumping it
> takes more than 12 hours. I have a new server to replace this old one
> where I have restore the DB's dump. The problem is I can't afford to
> have the server out of business for so long, so I need your advice about
> how you'd do this dump/restore. The big amount of data is placed in two
> tables (statistics data), so I was thinking in dump/restore all except
> this two tables and once the server is running again I'd dump/restore
> this data. The problem is I don't know how exactly do this.
>
>    Any suggestion?
>
> Thanks
> --
> Arnau
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>

In response to

Responses

pgsql-admin by date

Next:From: Joshua D. DrakeDate: 2006-12-19 21:45:59
Subject: Re: Upgrading from 7.4 to 8.2
Previous:From: Chris HooverDate: 2006-12-19 21:40:36
Subject: Re: Upgrading from 7.4 to 8.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group