Due to cost restrictions, throughout the course of the development of Bareos we have to set certain priorities. Often though, users offer to provide the funding of new features, so that we can implement them earlier as planned.
These users cannot or do not always want to fund the development costs in full. The features though are often of interest to many customers. That's why through co-funding we offer the opportunity for multiple users to raise the necessary funds together.
In the course of our co-funding-process you have the opportunity to co-finance features that are already planned, as well as advance your own proposals for a new feature. In the latter case we then examine the financial requirements for its development, and as soon as the funding meets the needs, we will implement the feature.
At the moment the following features are open to co-funding:
If you would like to contribute to one of those features or propose a new feature yourself, please do not hesitate to contact us.
List of companies (in alphabetical order) that helped to improve the Bareos project by funding parts of the development.
- Secure Erase feature:
Allow to define an external program (like wipe or shred.exe) for deleting data in a secure manner. This can be necessary to comply to strict industry standards and government regulations that force organizations to mitigate the risk of unauthorized exposure of confidential corporate and government data.
- Database optimization:
Especially professional users with large environments will benefit from the new database optimization (de-normalization of the file table), which leads to significant speed-increase when backing up millions or more files.
- LAN address feature:
User with distributed networks, such as hosters backing up systems from customer networks, will benefit from the LanAddress feature. These customers can now perform central and / or decentral backups of clients. If both client and storage daemon have an optional LanAddress configured, the client will write the data directly to the local storage.
dass IT GmbH
- dass IT GmbH has participated over years with active development and by providing infrastructure such as servers and the Bareos build system.
- Improved NDMP support for Bareos
- NDMP on Solaris SPARC
- NDMP Single File Restore on NetApp
- Improved NDMP restores on Isilon
- Client Initiated Connection
- Allow File Daemons to connect to the Director, instead of the the Director connecting to the clients.
- MS SQL Plugin
- Supports restore to file and restore to different database server.
Thomas Magnete GmbH
- Allow multiple simultaneous Windows VSS backups.
Below you can find some details on the projects named above:
Extended ACL Filtering (implemented)
This feature expands the ACL support of Bareos, making it possible to restrict user's access to the resources that have been assigned to him. Although the user access is already limited to selecting / executing resources assigned to him, currently the user can still see all resources. The implementation of this feature is a further step towards a self-service system and multi-tenancy capability.
Extended ACL Filtering has been implemented in the master branch and will be available in Bareos 16.2.
Performance Enhancements for large number of clients / jobs
With a large number of jobs and many clients (> 1000) the database may get slow after a while. Thanks to a customer, who pointed us to the file / filename table, we've identified a way to significantly speed up the database behavior in large environments. This includes denormalization of the file / filename table.
This is a rather large project, as it includes analysis and rewriting of sql-queries and arbitrary testing.
Estimated amount: 30,000.00 €
Bareos supports multiple users (through so called console connections), all with individual ACLs. Currently the passwords for the users must be endorsed into the Bareos director config. By using PAM, a linkage to other authentication methods, e.g. LDAP, will be possible.
Postgres Backup Python Plugin
OK, there is bpipe, pg_dump command and some other stuff but Postgres has an own backup mechanism, that offers hot-backups and point-in-time (PIT) recovery, compare http://www.postgresql.org/docs/9.4/static/continuous-archiving.html.
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
Red Hat Enterprise Virtualization (RHEV) provides a Backup and Restore API. The goal is to develop a Bareos plugin that allows backup and restore of RHEV virtual machines.
There is a prototype for a Bareos - Graphite / Grafana connector. This connector imports metrics from Bareos (such as jobs running, bytes transferred, job sizes and many more) into the Graphite backend. Some sample Grafana charts and dashboards are created to show the capabilities. See https://github.com/bareos/bareos-contrib/tree/master/misc/performance/graphite for more information about the existing prototype.
The following enhancements are planned to get this prototype into production:
- Improve configuration
- Create installation packages
- Support more performance data backends (e.g. opentsdb)
- add more preconfigured and customizable Grafana dashboards
- Include graphs into Bareos webui
Estimated amount: 8,000 € (can be split into chunks for subtasks)
MySQL / MariaDB Percona plugin
The existing MySQL plugin uses a simple mysqldump to write a database into the backup. With the open source tool xtrabackup from Percona, incremental backups can be created and point in time (PIT) recovery is possible. We've got a prototype plugin in place, that already makes use of xtrabackup and can create full and incremental backups of Innodb type databases. The plugin is already production ready, yet the following steps are planned to improve it further:
- Configuration of databases / table to backup
- Credential handling
- Configuration validation
- MyISAM backup only possible with full backups, handling of mixed InnoDB / MyISAM environments
- Cleanup temporary disk space
- Restore to filespace and prepare job done by plugin, optionally perform complete restore process by plugin
- Optionally run preparation of backup data, before writing to backup. This makes sense for large critical databases, where fast disaster recovery is a must-have.
- Create continuous integration tests for automated quality assurance
- Create installation packages
Estimated amount: 9,000 €