Even while developing first version of the OmniPITR, we know there are things that could be improved. But first things first - we have to finish development of base functionality before starting work on new stuff.
Here are the already known about missing features:
Ability to use %r in omnipitr-restore instead of relying on pg_controldata
While definitely good thing, we will still keep code to use pg_controldata as %r is not available in 8.2.
Add a way to specify "primary" destination for wal segments.
This would be useful if you have WAL-slave in the same network, and additional slave, on a network link that can be down. Problems with non-primary destinations wouldn't stop replication to primary destinations.
Make it possible to provide remote source in omnipitr-restore and omnipitr-backup-slave (remote, via http/ftp)
Make it possible to provide multiple sources for omnipitr-restore
This is for migration purposes - for example, when you're switching your walarchive from compressed to not-compressed.
Add option to skip archiving of xlogs to omnipitr-backup-*
This is assuming the user is keeping their own xlog archive and will limit the ability to restore a standalone database.
Support sending to cloud storage such as Amazon S3
Add support for xz compression (similar to lzma)
Add support for using ZFS/LVM snapshops.
This has the benefit of keeping required xlogs to a minimum for backups.
report missing statedir on start, and to logs, and not to stderr (or to both, but add to logs)
make omnipitr-restore don't care about walarchive writability if -r option is not given
[1.1.0] Provide support for --help option
Well, it can be helpful to avoid having to type another command to get to docs
[1.1.0] Add support for config file
This has the benefit over command line options that it lets you change the options without Pg restart (in omnipitr-restore case at least).
[1.1.0] Add --version option to all programs.
[1.1.0] Make temp directories inside given temp-dir, based on pid and/or random values - to allow easy running (for example) 2 slaves on the same machine.
[0.7.0] Have omnipitr-backup-* look at .backup file to determine exactly what xlogs it needs to keep for backup integrity.
[0.6.0] Deliver to multiple destinations in parallel
When delivering wal segments to slave server, and to backup destination - we can reduce the time it takes, by delivering it in parallel.
[0.4.0] Add specialized program to serve as archive_cleanup_command - with support for compressed walarchive, and pausing removal
The OmniPITR project is Copyright (c) 2009-2012 OmniTI. All rights reserved.