Getting Started

BOBUP is a platform-independent, application-independent framework for backup and recovery. BOBUP focuses on backing up application objects, rather than files and databases.

See the Overview.

Installation

Download the distribution and extract the bobup-0.9ea.jar. Add this jar to the classpath.

Synopsis

Steps to backup are as follows:

  • Create an IBackup business object. It is the responsibility of the backup object to know how to assemble/disassemble itself into one or more IBackupPart backup parts.
  • Create an IBackupConfiguration configuration. Set the properties of the configuration.
  • Add IBackupProvider backup providers to a new Collater instance. Providers provision the IBackup backup object instances.
  • Start/stop backup by calling Collater.startBackup()/stopBackup() respectively.

Steps to restore are as follows:

  • Use the Browser to browse IBackupLocation locations and locate the backed up entity.
  • Use the Recoverer to restore the backed up entity.

A detailed explanation of the objects used follows.

Backup objects

Application objects indicate that they are to be backed up by implementing the IBackup interface. An IBackup instance does not strictly correspond to a particular business object. In fact, more than one itype/i of IBackup instance could correspond to a business object. However, every IBackup instance is uniquely identifiable through the getId() method and associated with the unique business object through the getBusinessObjectId() method.

For example, a physician practice application that deals with patient scheduling may choose to create a backup around a business object that includes both the Appointment and Doctor entities.

An application can have several different backups going on at the same time independent of each other. They be completely different business objects and different backup locations.

For example, the physician application mentioned above can be generating backups to a different location just for Patient objects.

Parts

Each IBackup object comprises one or more IBackupParts. It is the responsibility of the backup object to know its constituent parts.

Every IBackupPart instance can be individually identified using getId(), and also associated with its business object through the getBusinessObjectId() method.

Handlers

In addition, a backup part is identified with a type getType(). The type of the part associates it with an IBackupRecoveryHandler handler. While the backup part contains all the information about the part, the actual transfer for data to the backup (and reconstitution of the part from the backup) is delegated to the handler.

In the Memento design pattern, the handler functions as the Originator.

Configuration

The backup needs to be configured with some basic choices that go across all business objects of a particular type. Configurations implement IBackupConfiguration.

Most applications will implement IBackupConfiguration as a singleton and set the following properties of the configuration:

  • Sleep time. This is the time to pause between backup of the IBackup instances.
  • IBackupLocation Backup location. See more information below.
  • IBackupStrategy Backup strategy. See more information below.

Remember that many of the IBackupConfiguration backup configuration properties such as location apply to the IBackupRecovery recovery configuration as well. Thus these common elements are abstracted to the IGeneralConfiguration interface.

Location

A backup location IBackupLocation represents any variety of physical backup destinations. Types of backup locations could vary from local directories to remote geo-redundant locations and even email accounts.

In the early access release, only a LocalDirectoryBackupLocation is supported, but there are plans to add many of the locations listed above.

Strategy

A backup strategy is a methodology of allocating resources for a backup including the number and type of media and the choice of algorithms for rotating the media between periods (typically a period would be a 24-hour day, technically, it can be anything).

There are many types of backup strategies in use depending on the need such as Incremental, Grandfather-father-son, Tower of Hanoi etc..

In the early access release, TowerOfHanoiBackupStrategy is provided with rotation of 9 media. The Tower of Hanoi is one of more sophisticated backup strategies providing backups for upto 511 days.

Collater

The Collater persists the business object to the physical backup location in accordance with the properties of the configuration. In the Memento design pattern, half of the Caretaker's job is performed by the Collater. The other half (recovery) is performed by the Browser and Recoverer.

The Collater sources the business entities to backed up using providers (next section). The collater can also notify any listeners interested in knowing about the state of the backup (next section).

Providers and Listeners

An IBackupProvider provider sources a list of IBackup backup objects. One or more providers can be registered with the collater. Typically, you might have two kinds of providers: (a) real-time provider that will source business objects as soon as a relevant record of a business entity object is updated. (b) batch provider that will backup all business entities sometime when the load on the system load is low, usually at night time.

IBackupListeners can also be registered with the collater so that the listeners can be notified about backups of an object via a BackupEvent. Backup listeners are useful for administrative inspections.

Encryption

Encryption is not supported for the alpha release, but there are definite plans to include encryption in further releases.

Browser and Recoverer

The Browser and Recoverer provide the other half of the function of the Caretaker in the Memento design pattern i.e. restoration.

The browser allows the user to browse a IBackupLocation backup location and list its contents. The contents of a backup location can be other backup locations or the backed up business objects.

For performance reasons during the recovery purposes, information about the business object is first generated into an IBusinessObjectDescriptor. The Recoverer then uses the descriptor to determine the business object parts and thence the handlers that would handle the restoration of each part.