Imagine that there is a third party developer who understands how to back up a certain kind of database repository. This third party might want to integrate his or her specialized backup into the Cedar Backup process, perhaps thinking of the database backup as a sort of “collect” step.
Prior to Cedar Backup 2.0, any such integration would have been completely independent of Cedar Backup itself. The “external” backup functionality would have had to maintain its own configuration and would not have had access to any Cedar Backup configuration.
Starting with version 2.0, Cedar Backup allows extensions to the backup process. An extension is an action that isn't part of the standard backup process, (i.e. not collect, stage, store or purge) but can be executed by Cedar Backup when properly configured.
Extension authors implement an “action process” function with a certain interface, and are allowed to add their own sections to the Cedar Backup configuration file, so that all backup configuration can be centralized. Then, the action process function is associated with an action name (i.e. “database”) which can be executed from the cback command line like any other action.
Although the initial 2.0 release will not include any extensions, it is our hope that as use of Cedar Backup 2.0 grows, users will contribute their own extensions back to the community. Well-written general-purpose extensions will be accepted into the official codebase, and we already have plans for a Subversion extension, a MySQL extension, and an extension for collecting important system information (fdisk information, etc.) to accompany a backup.
See Chapter 4, Configuration for more information on how extensions are configured. Also, developers may be interested in Appendix A, Extension Architecture Interface.