Glom: Backups and coping with PostgreSQL upgrades

Over the last few days, I added a Backup feature to Glom. It’s in Glom 1.14.4 that I released today. I don’t usually add features to stable releases, but this time it might help some people.

The Export Backup menu item saves everything in a .tar.gz tarball, using PostgresSQL’s pg_dump command and tar. (I hate calling command-line utilities from code, instead of calling functions in libraries.) The Restore Backup command uses that .tar.gz tarball and recreates a Glom system, either locally or on a central server if you choose.

The backup feature is obviously useful in general, but it’s particularly important since we noticed that use of pg_dump and pg_restore is necessary for migration when upgrading PostgreSQL, for instance from version 8.3 to 8.4.That’s not so awful when you just have one central database server, and Debian/Ubuntu even have a script that does the pg_dump/pg_restore dance on your central data when you upgrade. But Glom’s self-hosting feature (the default) has a separate set of database files for each .glom file, starting the PostgreSQL instance on demand. Ubuntu’s upgrade system obviously can’t know about all those files, which might even be on a USB stick.

The Backup feature can be used to work around this problem, if you remember to use it before upgrading your distro, but it’s not a nice solution.

Before anybody tells me to use SQLite instead, please remember that it still doesn’t have the features Glom needs, such as access-control and multi-user network sharing.

2 thoughts on “Glom: Backups and coping with PostgreSQL upgrades

  1. There are also pg_migrator (to 8.4) and pg_upgrade (to 9.0+) which do in-place upgrades of the data. I agree that a library to perform these functions would be terrific.

  2. Patrick, yes, I might use pg_upgrade
    http://developer.postgresql.org/pgdocs/postgres/pgupgrade.html
    to attempt automatic upgrading when opening .glom files, when the older version of Postgres is available on the system, though it’s not much nicer than using pg_dump and pg_restore.

    At least that would make it easier to preserve user passwords. At the moment they are lost because I don’t want to store them in a text file.

Comments are closed.