"Andrew Dunstan" <andrew@dunslane.net> writes:
> Greg Stark said:
> > Well fwiw what pg_dump does isn't even considered a "backup" at all in
> > other systems. It's a "logical export" or something of that sort.
> >
> > It's not considered a "backup" because it's saving something different
> > than the actual physical database. When you restore you get something
> > (hopefully) logically equivalent but still physically different.
>
> This seems fairly arbitrary. On that basis anything on a higher level than
> dd is not a backup method, ISTM.
Well most of other options *aren't* any higher level than dd.
Even with PITR you're just storing the transaction logs byte for byte. When
you replay it works at slightly higher level but it's still far from
reinterpreting your data and you'll get (almost) exactly the same bytes back.
I'm not saying pg_dump is a bad thing, but now that Postgres has real backups
there isn't much of a use case for using pg_dump as a stand-in for backups. If
your system crashes and you need to bring up a new system quickly you want to
bring it up in exactly the state the one that crashed was in. You don't want
to pass all the data through a program that interprets the ascii
representation again and hope it comes up with the same data.
There are other reasons to need pg_dump of course. Just not for backups.
--
greg