Data recovery

Bob Kruger <bkruger@mindspring.com> writes:

I am recovering a system from a complete HD crash.
I have a backup of the Postgres data directory, e.g.
/usr/local/pgsql/data/base.
Is there a way or method to have Postgres pick these databases up again?
The version of Postgres run in this machine was/is 6.4.2.

If you have a backup of the whole pgsql/data directory, just reinstall
the same Postgres release, restore the data directory (instead of doing
an initdb), and you should be in fat city.

If you only have the data/base subdirectory, you will need to work
harder; you'll have to regenerate the top-level files. I think if you
get pg_shadow and pg_database right you will be OK. First, install and
initdb to get a basic set of files. You will need to recall the old set
of users (including their userIDs) in order to reconstruct pg_shadow.
After you've done the createusers, issue a createdb for each old
database (subdirectory of base/) so that they have entries in
pg_database. Then, shut down the postmaster, blow away the contents of
the base/ subdirectory and restore it from tape, and restart. I think
it'll work...

In any case it's critical to install the same Postgres version you
were using.

regards, tom lane

Tom Lane wrote:

Bob Kruger <bkruger@mindspring.com> writes:

I am recovering a system from a complete HD crash.
I have a backup of the Postgres data directory, e.g.
/usr/local/pgsql/data/base.
Is there a way or method to have Postgres pick these databases up again?
The version of Postgres run in this machine was/is 6.4.2.

If you have a backup of the whole pgsql/data directory, just reinstall
the same Postgres release, restore the data directory (instead of doing
an initdb), and you should be in fat city.

If you only have the data/base subdirectory, you will need to work
harder; you'll have to regenerate the top-level files. I think if you
get pg_shadow and pg_database right you will be OK. First, install and
initdb to get a basic set of files. You will need to recall the old set
of users (including their userIDs) in order to reconstruct pg_shadow.
After you've done the createusers, issue a createdb for each old
database (subdirectory of base/) so that they have entries in
pg_database. Then, shut down the postmaster, blow away the contents of
the base/ subdirectory and restore it from tape, and restart. I think
it'll work...

In any case it's critical to install the same Postgres version you
were using.

NO - this cannot work. He surely needs the entire data
directory because the information in the heap's relies on the
bits in data/pg_log. And that info (which XID's are
committed and which not) cannot be reconstructed from the
files - no chance.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

If you only have the data/base subdirectory, you will need to work
harder; you'll have to regenerate the top-level files. I think if you
get pg_shadow and pg_database right you will be OK. First, install and
initdb to get a basic set of files. You will need to recall the old set
of users (including their userIDs) in order to reconstruct pg_shadow.
After you've done the createusers, issue a createdb for each old
database (subdirectory of base/) so that they have entries in
pg_database. Then, shut down the postmaster, blow away the contents of
the base/ subdirectory and restore it from tape, and restart. I think
it'll work...

In any case it's critical to install the same Postgres version you
were using.

NO - this cannot work. He surely needs the entire data
directory because the information in the heap's relies on the
bits in data/pg_log. And that info (which XID's are
committed and which not) cannot be reconstructed from the
files - no chance.

Very, very hard, but not impossible. If you update a row, and do a
select on that row, the select updates the transaction status so the
next select doesn't need to look at the pg_log table. What this means
is that pg_log could probably be reconstructed from existing data, with
just 'unselected' changes not appearing properly.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

If you only have the data/base subdirectory, you will need to work
harder; you'll have to regenerate the top-level files. I think if you
get pg_shadow and pg_database right you will be OK. First, install and
initdb to get a basic set of files. You will need to recall the old set
of users (including their userIDs) in order to reconstruct pg_shadow.
After you've done the createusers, issue a createdb for each old
database (subdirectory of base/) so that they have entries in
pg_database. Then, shut down the postmaster, blow away the contents of
the base/ subdirectory and restore it from tape, and restart. I think
it'll work...

In any case it's critical to install the same Postgres version you
were using.

NO - this cannot work. He surely needs the entire data
directory because the information in the heap's relies on the
bits in data/pg_log. And that info (which XID's are
committed and which not) cannot be reconstructed from the
files - no chance.

Very, very hard, but not impossible. If you update a row, and do a
select on that row, the select updates the transaction status so the
next select doesn't need to look at the pg_log table. What this means
is that pg_log could probably be reconstructed from existing data, with
just 'unselected' changes not appearing properly.

So at the end you have some data that you cannot trust. I
don't think that's worth the efford.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Very, very hard, but not impossible. If you update a row, and do a
select on that row, the select updates the transaction status so the
next select doesn't need to look at the pg_log table. What this means
is that pg_log could probably be reconstructed from existing data, with
just 'unselected' changes not appearing properly.

So at the end you have some data that you cannot trust. I
don't think that's worth the efford.

Yes. True. It is just a point that came up recently when Tom found the
first select on a table slow.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026