Backup and Restore Types

Backup works by copying files (installed applications, Secure ID and data) from a Symbian device to a PC. Restore works by copying previously backed up files from the PC to the Symbian device. This section describes the different types of backup and restore.

Note: In each of the following sections, the backup process is explained. The restore process works in the same way, but it is a process from a PC to a device.

Base and incremental backup and restore

For an easy and quick backup and restore, the Symbian platform implements base and incremental backups. A base backup (sometimes described as a full backup) is a backup of all or part of a drive that includes all the selected files. An incremental backup is a backup of all or part of a drive that only includes files that are new or changed since a previous backup. An incremental backup is smaller than a base backup and takes less time.

There are (at least) two possible patterns of use for incremental backups:

  • The first pattern involves taking one base backup and then a series of incremental backups with each increment including only the files that are new or changed since the last increment. This pattern minimizes the time taken for each increment but has some drawbacks for restoring private files (because all the increments are required for restores).

  • The second pattern involves taking one base backup and then a series of incremental backups with each increment including only the files that are new or changed since the base backup. In this pattern, the time taken for an incremental backup is not minimized and may approach the time taken for a base backup but a restore operation only requires the base and a single increment.

The choice of which pattern to use is made by the PC software - not by the phone software.

Note: An incremental backup cannot be created purely based on a date and time stamp. If a new file is added with an old time-stamp, a time-based increment would omit it. Therefore, any incremental backup requires a list of the files included in the preceding backup.

Full and partial backup and restore

By default, a backup (whether base or incremental) aims to include all files on a specified drive. In practice, the application developer may only care about data belonging to one or more specific applications. By omitting other data files the time taken for the backup (or restore) is reduced.

An additional benefit of partial backup and restore is that a data owner may be able to participate in backup or restore without requiring all file locks to be freed. For example, if a data owner only deals with its own private files, it is possible to back up its data in isolation. This allows backups to have less impact on the application developer.

Active and passive backup and restore

Based on the types of the data owner, backup and restore can be passive, active or active proxy:

  • Active backup: The data owner application or server must implement Active Backup Client and registers with the Backup Engine using a registration file (see Backup Registration Files). The Backup Engine starts the registered process for active backup if not already started. The data owning process then responds to a central signal when a backup or restore operation takes place and actively provides its private data to or receives it from the Backup Engine. This requires that the data-owning process include specific code to take part in backup and restore, and that it must be running when a backup or restore takes place. In this model the data-owning process registers with the Backup Engine but exercises complete control of which data is backed up and restored.

  • Passive backup: The data owner application or server registers with the Backup Engine using a backup registration file which lists the files and directories to be backed up. The data-owning process then releases file locks. The files are backed up by the Backup Engine. The Backup Engine has the required capability to access private data files belonging to other processes.

    Passive backup is very simple for application developers to implement – all that is required is a backup registration file. Active backup requires more effort to implement but provides the data-owning process with more control over the data backed up and restored.

  • Active Proxy: Some processes manage data on behalf of other data owners and they are referred to as active proxy data owners. For example, the Central Repository manages data in repositories for other data owners.

    Active proxy data owners must have a backup registration file that registers them as active data owners. They must implement Active Backup Client methods that allow the Backup Engine to request backup data or supply restore data associated with the secure ID of the actual data owner. The APIs to request or supply data are similar to the Active Backup Client APIs but include an additional argument for the secure ID of the actual data owner.