Do we need more emphasis on backup?

[Scott Marlowe]

I'm wondering if there's some basic failing in how we're presenting
backing up the database on a regular basis.

Maybe even our reputation for reliability hurts a bit here. I'm sure if
PostgreSQL corrupted files all the time or had some other data
reliability problem people would backup religiously.

Now, the SQL documentation set has a tutorial that proceeds it that
really is a great walk through on the features of PostgreSQL, and I was
wondering if we needed an administrative walk through in a similar vein?

It could include load generation scripts written in Perl or PHP or
something like that to populate and exercise the database for
demonstration purposes.

It would include creating, populating, backing up, deleting, and
restoring a database to simulate a catastrophic failure, etc...

With things like tablespaces coming online, more and more administrative
functions are in danger of being road blocks for the beginner if.

I'd be willing to start it on the wiki site if anyone thinks it's a good
idea. Any ideas welcome. I plan on following the basic administrative
guide, just creating a tutorial analog for it.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Tom Lane]

"Scott Marlowe" <sm******@qwest.net> writes:

I'm wondering if there's some basic failing in how we're presenting
backing up the database on a regular basis. Maybe even our reputation for reliability hurts a bit here.
I have definitely noticed that a very large percentage of the data-loss
problems we've seen reported lately seem to trace to hardware problems.
Postgres is more reliable than consumer-grade PC hardware. (And is that
ever a change from when I started working with it ... but I digress.)

We do need to point out that you're only as reliable as your last
backup. I'm not sure exactly where to say this.
Now, the SQL documentation set has a tutorial that proceeds it that
really is a great walk through on the features of PostgreSQL, and I was
wondering if we needed an administrative walk through in a similar vein? It could include load generation scripts written in Perl or PHP or
something like that to populate and exercise the database for
demonstration purposes.

Hm, that seems a bit far afield from the problem...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Jim Seymour]

Tom Lane <tg*@sss.pgh.pa.us> wrote:

[snip]
We do need to point out that you're only as reliable as your last
backup. I'm not sure exactly where to say this. [snip]

Hmph. Backups are for mitigation against a catastrophic failure
destroying or corrupting main storage. And even then: Subtle errors
can induce data corruption that may go un-noticed until it's too late.
(I.e.: The last correct backups have been over-written, retired, so
old they've become unreadable, so old the data's no longer useful,
etc.)

My position is that your data is only as reliable as your hardware,
period. Use cheap (usually PC, sorry) hardware and, well... I wonder
how many people are aware of the fact that the cheaper PCs don't even
have parity memory anymore? Then there are the issues with IDE
drives. (Don't recall those, exactly - don't use 'em.)

One of the other mailing lists I'm on: The project developer, whenever
somebody comes on list and says "Your code is blowing up, losing stuff,
corrupting stuff," or whatever, first asks "What hardware are you
running?" IIRC, he gives short shrift to complainants running
inexpensive PC hardware. He won't spend any time on the complaint
until they prove it's *not* their hardware.

Jim

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Bruce Momjian]

Jim Seymour wrote:

Tom Lane <tg*@sss.pgh.pa.us> wrote:

[snip]

We do need to point out that you're only as reliable as your last
backup. I'm not sure exactly where to say this.

[snip]

Hmph. Backups are for mitigation against a catastrophic failure
destroying or corrupting main storage. And even then: Subtle errors
can induce data corruption that may go un-noticed until it's too late.
(I.e.: The last correct backups have been over-written, retired, so
old they've become unreadable, so old the data's no longer useful,
etc.)

My position is that your data is only as reliable as your hardware,
period. Use cheap (usually PC, sorry) hardware and, well... I wonder
how many people are aware of the fact that the cheaper PCs don't even
have parity memory anymore? Then there are the issues with IDE
drives. (Don't recall those, exactly - don't use 'em.)

There is a basic misconception that all PC hardware is created equal ---
that hard drives, mother boards, and RAM are all the same because they
are all PC-compatible. Compatible != Similar Quality.

Not sure where we would document this. :-(

Running BSD, I have always had to buy server-class hardware for my home
machines, and I never regretted it nor had a problem.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org