Thread: Data recovery
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. Thanks in advance for any assistance. Regards - Bob Kruger
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