August 23rd, 2013 by depesz | Tags: , , , , , , | 1 comment »
Did it help? If yes - maybe you can help me? Donate BTC to 19zPa5diT2LZqGtTi8f8bfApLn8rw9zBHx

Title: OmniPITR v1.2.0 released

It's been a while since last release, but the new one finally arrived, and has some pretty cool goodies :)

For starters, you can now skip creation of xlog backups – which is nice, if you have ready walarchive, with all xlogs – there is no point in wasting time on creation of xlog tarball for backup.

There is also a way to use “-r %r" option to omnipitr-restore, which will make the “remove obsolete xlogs from walarchive" part of its work a bit simpler.

Nowadays, most of the people (I imagine), use streaming replication, so omnipitr-restore is less used, but it is still nice add on.

But the biggest change, and the one with most versatile uses is addition of “dst-pipe".

Before 1.2.0, you could have send xlogs or backups to local file, or to remote file, using various methods. Now, –dst-pipe, gives one more destination: pipe to program.

How does it work?

You provide –dst-pipe option to omnipitr-archive, omnipitr-backup-master or omnipitr-backup-slave, and give it value that is path to program or script (script usually).

You can even prefix it with compression specifier, like “gzip=".

What the script will do – is absolutely unlimited.

The pipe program, will be called with one argument – being name of currently provided file (just the filename, no paths). And the content of the file will be provided on stdin.

So, you could, for example, have such script:

#!/usr/bin/env bash
gpg -a -e -r depesz@depesz.com - > "/mnt/nfs/storage/backups/$1.asc"

Which would encrypt the file with gpg, and save it to local file in /mnt/nfs/storage/backups directory.

Alternative usage is sending backups to S3, or Hadoop, Dropbox, or whatever that can be done using a script or program.

Please note that encrypting every file (for example) every xlog might not be best idea, but you can easily have:

  • encrypted backups sent to offsite storage
  • unencrypted xlogs sent to slave server
  • encrypted, compressed, xlogs sent to offsite storage

One thing that I need to mention. When doing dst-pipe and compression, you have two choices:

  • specify compression as part of dst-pipe argument, like: –dst-pipe gzip=/usr/local/bin/some_script
  • add compression in the script itself, for example using: gzip -c – | gpg ….

First method should be used if you are already using some gzipped destinations, as omnipitr will be smart enough to compress it only once.

Second method should be used if there are no other destinations, or no other destinations compressed using given compressor.

In any way – I am very excited about the ability to automatically send encrypted backups to offsite storage using non-ssh and non-rsync protocols.

Hope you'll like it too.

As always you can download from github or pgxn.

  1. One comment

  2. # Vasilis
    Aug 23, 2013

    awesome , dst-pipe feature is awesome for so many reasons
    pasting a post i did about it:

    http://vv-dba.blogspot.co.uk/2013/08/backing-up-postgresql-to-hadoop.html

Leave a comment