3

I am trying to love PostGreSQL. I'm pushing it at my company. I want us to adopt it for more and more projects. But I am personally stumped by a backup/restore issue. I keep thinking, if this was MS-SQL, this would not be a problem...

We cannot restore backups of our database - not with pg_dump and pg_restore. It fails for numerous reasons. I've searched quite a bit - hours and hours - with no remedy. Much of the database does get restored, but key parts do not.

As many know, in MS-SQL, one can disconnect a database, and make a copy of the MDB and LDB files, and then re-connect it. I can then take those two copied files to any other computer and re-connect them, and barring perhaps missing user accounts, in our experience, we've had no problem.

But pg_dump and pg_dumpall (which mostly just ends up iteratively calling pg_dump) dump the SQL commands to re-create the database. Not the byte-for-byte copy of the state of the database. Given that restoring our database by running the commands pg_dump spits out to create it does not work, is there any alternative closer to the byte-level-copy solution from the MS-SQL world that I can use?

What is the goal? Aside from the obvious (being able to restore the database in case of failure), I'm trying to deploy a Vagrant development environment. So we have one master copy of the database that our database developer sets up in her virtual development environment. Then myself and others want to be able to get periodic snapshots of the database after major modifications, and load the snapshots into the Vagrants on our machines.

IF we could easily backup and restore the database, this would not be a problem. It would work just fine. I'd rather not have to copy an entire virtual machine to share database changes.

The only thing I tried different from futzing with pg_dump[all] and pg_restore was SymmetricDS, but it broke the database... perhaps through misconfiguration, or perhaps because it is trying to do the same kind of stuff pg_dump does. Not sure.

I suspect I'll get questions about why the pg_restore fails. So to clarify briefly, it has to do with custom data types, operators, and functions installed by 3rd party software, and us, into interdependent schemas (ArcSDE and PostGIS) not getting created in the right order as pg_dump thinks they should be created. I also believe (though cannot prove) that the search_path as set at the start of a pg_dump backup is wrong, which doesn't help the restore process already hampered by schema interdependencies.

NFlourish
  • 33
  • 4

1 Answers1

0

You can do a physical/file level backup on PostgreSQL, albeit it is not standard practice (I'll try very hard to make pg_dump work; have you asked on the mailing list?)

As another option, have you considered a replicated setup, with "live" point-in-time backup/recovery?

Anyway, to take a physical backup with minimal downtime you had to:

  1. stop PostgreSQL
  2. take a LVM snapshot inside your virtual machine
  3. restart PostgreSQL
  4. mount the LVM snapshot in a suitable directory inside your virtual machine
  5. make a copy the entire database cluster directory (eg: /var/lib/pgsql)
  6. unmount and delete the LVM snapshot

As taking a snapshot is very fast, this will minimize the downtime.

To restore the database on another PostgreSQL server, do the following:

  1. stop PostgreSQL
  2. delete/rename the database cluster directory (eg: mv /var/lib/pgsql /var/lib/pgsql_original)
  3. restore your copy of the database cluster directory (eg: mv mycopy /var/lib/pgsql)
  4. if SELINUX is enabled, relabel the new directory (eg: `restorecon -RF /var/lib/pgsql)
  5. restart PostgreSQL

Please note that this kind of backups can be used only between the same PostgreSQL version and the same arch (ie: you can not restore a i386/32 bit backup on a x86_64/64 bit machine).

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • Albeit not "as-easy-as MS-SQL" - this sounds worth trying out. I have read of others using the process and having questions... the first responses are always "why u no use pg_dump nar!?" which makes this process you described sound not just "unsupported" but really horrible. Given that we are not talking about a database in production, I can take it offline to make a file-level copy. Even when we go to production, we can still make a copy in the wee morning hours. We are on Windows... so using LVM is not an option. Otherwise, I'll see how this works out. Thanks! – NFlourish Jan 12 '16 at 15:45
  • I didn't think it had to be shut down if you had consistent file system snapshots and/or were careful about backup API and logs ? See also http://serverfault.com/questions/577998/postgresql-approach-for-live-hot-file-backup – John Mahowald Jan 12 '16 at 22:42
  • Shutting down the service (PostgreSQL, in this case) before taking the snapshot is a good means to avoid inconsistencies, as what is "consistent" from a filesystem standpoint can be different of the "consistency" as viewed from a database with mutiple updating tables. As you are under Windows, you had to use the VSS service to take snapshot. As you probably know, VSS has a module/plugin system exactly for this consistency issue - the VSS module will "freeze" the parent application and will enable the VSS service to take a consistent snapshot. – shodanshok Jan 12 '16 at 22:47