Обсуждение: backup including symbolic links?

Hello,

I have a 450gb production database, and was trying to create a development database using a bkp.
I was following the instructions on postgres documentation, and came across the paragraph that says...
" If you are using tablespaces that do not reside underneath this (data) directory, be careful to include them as well (and be sure that your backup dump archives symbolic links as links, otherwise the restore will mess up your tablespaces)."
I have a seperate pg_tablespaces folder under E:\ drive since there wasn't enough space in my C:\ drive to put them.

My db is 8.2 and is running on windows 2003.

Can anyone tell me how to backup my database (including the symbolic links as links).
Thank you
Nuwan

---

Looking for last minute shopping deals? Find them fast with Yahoo! Search.

On Jan 25, 2008 1:55 PM, NUWAN LIYANAGE <alnuwan@yahoo.com> wrote:
> Hello,
>
>  I have a 450gb production database, and was trying to create a development
> database using a bkp.
>  I was following the instructions on postgres documentation, and came across
> the paragraph that says...
>  " If you are using tablespaces that do not reside underneath this (data)
> directory, be careful to include them as well (and be sure that your backup
> dump archives symbolic links as links, otherwise the restore will mess up
> your tablespaces)."
>  I have a seperate pg_tablespaces folder under E:\ drive since there wasn't
> enough space in my C:\ drive to put them.
>
>  My db is 8.2 and is running on windows 2003.
>
>  Can anyone tell me how to backup my database (including the symbolic links
> as links).

A standard pg_dumpall --globals will dump the create tablespace
statement, which you can edit as needed for your new machine.  A plain
pg_dump of the database will dump out the tables with tablespace
statements.  A pg_dumpall of the whole database cluster can also be
used to do this.

On Jan 25, 2008 1:55 PM, NUWAN LIYANAGE wrote:
> Hello,
>
> I have a 450gb production database, and was trying to create a development
> database using a bkp.
> I was following the instructions on postgres documentation, and came across
> the paragraph that says...
> " If you are using tablespaces that do not reside underneath this (data)
> directory, be careful to include them as well (and be sure that your backup
> dump archives symbolic links as links, otherwise the restore will mess up
> your tablespaces)."
> I have a seperate pg_tablespaces folder under E:\ drive since there wasn't
> enough space in my C:\ drive to put them.
>
> My db is 8.2 and is running on windows 2003.
>
> Can anyone tell me how to backup my database (including the symbolic links
> as links).

A standard pg_dumpall --globals will dump the create tablespace
statement, which you can edit as needed for your new machine. A plain
pg_dump of the database will dump out the tables with tablespace
statements. A pg_dumpall of the whole database cluster can also be
used to do this.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

---

Never miss a thing. Make Yahoo your homepage.

On Jan 26, 2008 3:06 PM, NUWAN LIYANAGE <alnuwan@yahoo.com> wrote:
> Yes, I was thinking of doing a pg_dumpall, but my only worry was that the
> singl file is going to be pretty large. I guess I don't have to worry too
> much about that.
> But my question to you sir is, If I want to create the development db using
> this pg dump file, how do I actually edit create tablespace statements so
> they will be created in the directory I want them to be. Or should I even
> worry about this.. (I want my data directory to be in E: drive including all
> the tablespaces.)

Take a look through the docs on pg_dump and pg_dumpall.

A few of the options to look at are the ones to dump just data or just
schema.  Quite often you don't need the data, just the schema, for
development.  "pg_dump -s dbname" will dump just the schema, and
"pg_dumpall --globals" will dump just the global database info, i.e.
usernames, tablespaces, etc...

Then just edit in your favorite text editor and point the resulting
file(s) at your dev db with psql f mydump.sql where mydump.sql is the
file you got from one or more of the above operations.

After that, I highly recommend that any changes you wish to make, do
so with .sql scripts (stored in your favorite version control system),
so that you can then apply them to your production database later with
minimal fuss.

Note that any changes that should be "all or nothing" to the
production database can be applied in a transaction (i.e. wrapped in a
begin/commit pair) and then either all or none of the changes will be
made...

example
begin;
create table abc ....
alter table xyz ...
insert ...
commit;

if any of those commands fail (things like creating unique indexes
might fail on production where they didn't in development) then no
harm, no foul, just figure out what went wrong and update your script
so it takes care of those problems.

Thank you very much Scott..
I'll keep you updated on my progress.
Thanks again.
Nuwan.

Scott Marlowe <scott.marlowe@gmail.com> wrote:

On Jan 26, 2008 3:06 PM, NUWAN LIYANAGE wrote:
> Yes, I was thinking of doing a pg_dumpall, but my only worry was that the
> singl file is going to be pretty large. I guess I don't have to worry too
> much about that.
> But my question to you sir is, If I want to create the development db using
> this pg dump file, how do I actually edit create tablespace statements so
> they will be created in the directory I want them to be. Or should I even
> worry about this.. (I want my data directory to be in E: drive including all
> the tablespaces.)

Take a look through the docs on pg_dump and pg_dumpall.

A few of the options to look at are the ones to dump just data or just
schema. Quite often you don't need the data, just the schema, for
development. "pg_dump -s dbname" will dump just the schema, and
"pg_dumpall --globals" will dump just the global database info, i.e.
usernames, tablespaces, etc...

Then just edit in your favorite text editor and point the resulting
file(s) at your dev db with psql f mydump.sql where mydump.sql is the
file you got from one or more of the above operations.

After that, I highly recommend that any changes you wish to make, do
so with .sql scripts (stored in your favorite version control system),
so that you can then apply them to your production database later with
minimal fuss.

Note that any changes that should be "all or nothing" to the
production database can be applied in a transaction (i.e. wrapped in a
begin/commit pair) and then either all or none of the changes will be
made...

example
begin;
create table abc ....
alter table xyz ...
insert ...
commit;

if any of those commands fail (things like creating unique indexes
might fail on production where they didn't in development) then no
harm, no foul, just figure out what went wrong and update your script
so it takes care of those problems.

---

Looking for last minute shopping deals? Find them fast with Yahoo! Search.