I'm running a PostgreSQL 8.2.0 system on RHEL WS (update 5). The
machine is administered by someone else.
To make a long story short, I thought that the site administrator was
making regular backups, and that I was running pg_dump every night.
Unfortunately, neither assumption was quite right. The administrator
was using rsync to back things up, and accidentally reversed the
parameters a few nights ago, thus wiping out the contents of our PGDATA
directory. Well, not *all* of PGDATA. Among the things that were
partly or completely saved are PGDATA/base. But PGDATA/global, as well
as pg_clog, pg_xlog, and so forth are completely gone.
Now, I can rebuild this thing starting with a pg_dump backup that I made
a month or so ago. (And yes, you can be sure that I'll be making even
more regular backups of this sort in the future. Every other database I
run has a daily cron job to do pg_dump, and this one of all things
slipped through the cracks. Argh.) I'll then have to apply a bunch of
programs that I've written since then to update things. It'll take
time, but it's doable.
I assume that it would be smartest to work from the month-old backup,
rather than take my chances with sketchy data and a lack of any WAL
files. But I just wanted to get a sanity check from the PostgreSQL
community, saying that it would be foolish to try to do surgery on a
potentially flawed database, when a good version will simply take time
to restore.
Thanks for any advice you might have to offer!
Reuven
---------------------------(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
