daydreamer
daydreamer

Reputation: 92119

pg_dump vs pg_dumpall? which one to use to database backups?

I tried pg_dump and then on a separate machine I tried to import the sql and populate the database, I see

CREATE TABLE
ERROR:  role "prod" does not exist
CREATE TABLE
ERROR:  role "prod" does not exist
CREATE TABLE
ERROR:  role "prod" does not exist
CREATE TABLE
ERROR:  role "prod" does not exist
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
WARNING:  no privileges could be revoked for "public"
REVOKE
ERROR:  role "postgres" does not exist
ERROR:  role "postgres" does not exist
WARNING:  no privileges were granted for "public"
GRANT

which means my user and roles and grant information is not in pg_dump

On the other hand we have pg_dumpall, I read conversation, and this does not lead me anywhere?

Question
- Which one should I be using for database backups? pg_dump or pg_dumpall?
- the requirement is that I can take the backup and should be able to import to any machine and it should work just fine.

Upvotes: 58

Views: 51824

Answers (2)

Eugen Konkov
Eugen Konkov

Reputation: 25207

Both commands pg_dump and pg_dumpall are pretty same. The difference is that (taken from man pg_dumpall):

  • pg_dumpall dumps all databases of a cluster into one script file. It does this by calling pg_dump for each database in the cluster.
  • pg_dumpall also dumps global objects that are common to all databases, namely database roles, tablespaces, and privilege grants for configuration parameters. pg_dump does not save these objects.

So the easiest way to backup/restore your database (even between major versions) is:

pg_dumpall -p 5432 | psql -d postgres -p 5433

You need to provide postgres as default database (-d flag), because on a new server, probably, you have only it.

Upvotes: 3

Craig Ringer
Craig Ringer

Reputation: 324751

The usual process is:

  • pg_dumpall --globals-only to get users/roles/etc
  • pg_dump -Fc for each database to get a nice compressed dump suitable for use with pg_restore.

Yes, this kind of sucks. I'd really like to teach pg_dump to embed pg_dumpall output into -Fc dumps, but right now unfortunately it doesn't know how so you have to do it yourself.

Up until PostgreSQL 11 there was also a nasty caveat with this approach: Neither pg_dump, nor pg_dumpall in --globals-only mode would dump user access GRANTs on DATABASEs. So you pretty much had to extract them from the catalogs or filter a pg_dumpall. This is fixed in PostgreSQL 11; see the release notes.

Make pg_dump dump the properties of a database, not just its contents (Haribabu Kommi)

Previously, attributes of the database itself, such as database-level GRANT/REVOKE permissions and ALTER DATABASE SET variable settings, were only dumped by pg_dumpall. Now pg_dump --create and pg_restore --create will restore these database properties in addition to the objects within the database. pg_dumpall -g now only dumps role- and tablespace-related attributes. pg_dumpall's complete output (without -g) is unchanged.


You should also know about physical backups - pg_basebackup, PgBarman and WAL archiving, PITR, etc. These offer much "finer grained" recovery, down to the minute or individual transaction. The downside is that they take up more space, are only restoreable to the same PostgreSQL version on the same platform, and back up all tables in all databases with no ability to exclude anything.

Upvotes: 93

Related Questions