Here we gather some ideas that could be of interest for contributors. Interested in one of those or have other suggestions? Just join our mailinglists, discuss or propose and start contributing. It's Open Source!
You would like to see a certain feature coming, are not able to develop it yourself, but want to contribute financially instead? Just take a look at the co-funding-page over at bareos.com and pick a project you would like to support.
Reporting Templates
Want to have nice looking graphs of backup jobs, number of files backed up, time needed for jobs and all kind of statistics?
There is a lot of information inside the database and waiting for some dataminers to start working on reporting interfaces to make this information visible to the administrators and IT managers.
This could be a standalone reporting application, smartphone/tablet app or just templates or graph definitions for common used reporting tools like Crystal Reports or the open source standard reporting tool Jaspersoft.
We already have a whitepaper about reporting with Jasper.
To make use of this feature a Python-plugin would be a great idea. Here are some outlines for such a plugin:
Bareos FD and Python Postgres plugin must be installed on each Postgres Server that should go into backup
Generally perform basebackup and WAL file backups continuosly
Full Backup takes basebackup + wal files created during basebackup
Incremental backup fetches new and modified wal files since last incremental (full, if no incremental backup was taken after last full) backup
Each backup creates a recovery.conf file in the backup with basic information needed for recovery, among them
earliest and latest possible timestamp for recovery (default is latest possible)
other settings needed, to initiate immediate recovery
Restore Options
Files only
The files including the basebackup, wal files, postgres configuration files will be restored to the original place or any other place on a bareos client.
The restore locaction can be set as with any other Bareos restore job
The DBA may than process this files (i.e. edit the recovery.conf file and proceed with recovery)
Posgres recovery
Will be initiated by giving "recovery:" in the where-paramater of the backup job (or plugin option)
Files will be restored to the original locations as above
recovery.conf as created during backup will be written to the right place
Postgres will be started in recovery mode from the plugin, Posgres will then evaluate recovery.conf and start the recovery process
Options to the recovery process can be appended to the where string
recovery_target_name: timestamp-name for point-in-time (pit) recovery
recovery_target_time: timestamp for pit recovery
recovery_target_xid: transaction id for pit.
eventually others or generic way to specifiy any options for recovery
Alternative instead of restoring all wal files
only restore database files without wal files and recocery.conf
recovery.conf sets restore_command = to a commandline that is capable of restoring a named file from Bareos. To achieve this, additional scripting work is needed.
Advantage: Postgres triggers restore of only needed files from Bareos for the given recovery task.
Documentation inside doc.bareos.org
Working sample commands for use case
file only restore
postgres recovery to latest possible time
postgres recovery to a given timestamp
Working sample configuration
There is already an open source project called Barman, which implements these ideas and more but design is a little bit different. Any suggestions how to ingegrate Barman with Bareos are also appreciated.
Interested in starting work on this? Just get in contact on the mailinglist.
