Criteria for Backup and Restore Types and Data

Criteria for backing up private data

As a developer responsible for creating or maintaining a process that owns private data, you must decide whether your application takes part in the backup of private data. In general, back up as much private data as possible. The following data is usually not backed up:

• If the private data must not be exposed to the user, it must not be backed up. Assume that all data backed up can be read and potentially altered by the user. This might change if a device creator implements encryption which does not rely on keys provided by the user but that is a device creator-specific decision and cannot be guaranteed.

• If the process cannot keep the private data stable during a backup or restore, they cannot safely back it up. This is a poor reason for not backing up data but may be a practical one. It depends on the sources of external events and whether they can be delayed or placed in a temporary location.

• If the private data can be easily recreated by other means, it may be excluded. This may not be a good criteria, but if a process would find it difficult to back up private data (perhaps for the reasons above) and the data could easily be created (for example by receiving configuration messages), choosing not to back it up may be more acceptable.

In addition, consider the implications on other processes of backing up the data or not. If your data must remain consistent with that in public files, the private data must be backed up. If your data must remain consistent with that owned by another process, either both or neither should back up data.

Active or passive backup

As described above, passive backup and restore is simpler than active backup. It also takes less system resources because processes taking part in active backup must be running during a backup or restore. However, active backup allows the data-owning process more control over the data and this can have both security and performance gains.

The choice between passive and active backup involves weighing up a number of factors. The following list includes a range of advantages and disadvantages and you need to consider all of these and make a decision.

• The registration for passive data backup only specifies whole files or directories. It is not possible to backup only part of a file using passive backup. If you need to backup only part of a file you need to either split the file into two or use active backup.

• The backup registration file that defines the files and directories to be subject to passive backup is created at system build time (for a system process) or at installation time (for an installed application). The backup registration files cannot be modified or created at runtime. If your process creates new directories after installation, the backup registration file cannot be extended for these. If you want these backed up, you need to put them under a common directory which all gets backed up or use active backup and make a run-time decision on what to backup. This aspect may be partially or wholly addressed by installing additional backup registration files.

• Backed up data is compressed to speed up data transfer which can be disabled. If your private data has a specific format and you can manage to backup only a fraction of it you may be able to make the backup of your data more efficient by implementing active backup.

• Backups can be base backups or incremental backups. With passive backup (as with the backing up of public files) incremental backups include all relevant files which have changed or are new since the last backup took place. If a file contains record-based data (such as a database), the addition or changing of one record will cause the whole file to require backup. If you implement active backup, you could only backup the changed or new records (plus recording deleted records in some way). This could increase the performance of backup and restore for your data.

• Active backup requires your process to be started during a backup or restore operation. Your process will be started automatically as required by the Backup Engine if not already running. If your process normally runs at all times, this imposes no additional burden on the phone. However, if your process is not normally running, it will require additional resources during a backup or restore and you should consider if the benefits of active backup justify the additional burden.

A hybrid approach may be useful. The Backup Engine allows a data owner to register as both an active backup client and a passive backup client. This was originally intended to allow a data owner to back up some data in each way but an alternative use is for the active backup client to prepare data for backup and then let the Backup Engine handle the actual transfer as a passive backup. The active backup client does not need to actually provide any data.

In order to support this, the Backup Engine must not retrieve data for passive backup until an active backup client has signaled that the data is ready. This set-up is configurable in the backup registration file. That is, if a data owner is registered to take part in both passive and active backup, the PC host or other client is expected to request active backup data before passive backup data.

When a restore operation is carried out, the data will be restored as passive data and the data owner is responsible for dealing with it when the restore operation is complete. In order to support this, the PC host or other client is expected to restore passively backed up data before actively backed up data if a data owner has registered for both active and passive backup and restore.

Private data to be actively backed up

Processes that own private data that needs to be actively backed up, must register with the backup engine as an owner of private data for active backup.

If an application is designed for separate installation compared to upgrade, it needs to copy a backup registration file into the private directory during installation. If an application is part of the platform, this involves creating a backup registration file as part of the build and ensuring that it is located in the relevant private directory.

In addition, the process must subscribe to the backup status flag described in Public and Subscribe Event for Active Backup in order to detect when a backup or restore takes place. Processes which own private data that needs to be actively backed up are started up if required by the Backup Engine in order to do the backup or restore. Therefore, they must check the backup flag on startup rather than making a normal startup. This may involve undesirable access to other servers and files.

Behavior required of a process that takes part in active backup of private data:

1. When the backup status flag gets set to ‘backup in progress’ any data that has not yet been saved may need to be saved.

2. The process has to release locks on all public data files that require to be backed up (files that are excluded from backup can be kept locked but assume that all public files will be backed up) so they can be copied off and stop modify private data files. This may require that the process ‘freezes’ all sessions to external processes to avoid external events that would cause files to be written to (whether requests are blocked or errors returned depends on the context).

3. The process tries to make a connection to the Backup Engine by name.

4. At the start of backing up private files, the process must ask the Backup Engine whether it is a base backup or an incremental backup using the active client APIs described in Active or passive backup and, if it is an incremental backup, the process must wait until the file snapshot to use for the increment is provided.

5. The process sends its private data as a stream using the active client APIs described in Active or passive backup. The owning process is responsible for taking its data files (all or whichever subset it wants to back up) and streaming them. Reference code will be provided to take all files in a private directory and stream them. Any other behavior will have to be implemented by the data owners.

   If the backup is a base backup, all the data in the relevant files must be provided.

   If it is an incremental backup, it should only stream data corresponding to the changes since the snapshot. The data-owning process has a choice of how sophisticated its behavior is in this regard. The simplest behavior is to always do a base backup (this will be an option, even when an incremental backup has been requested). An alternative is to provide backups of files that have changed since the last backup. The final option is to provide only that data that has changed since the last backup. Which choice is made will depend on the nature of the data to be backed up.

   Note that an application may have been installed after the base backup so a process must handle this (no snapshot will be provided).

   The data-owning process is responsible for providing a snapshot of files that can be used as a baseline for subsequent incremental backups.

6. The private data being sent may not be received all at once (multiple processes may be trying to supply data at the same time) and may not be received at all (if the backup is partial or has been broken off).

7. When the backup flag reverts to normal, files can be re-accessed and clients responded to. The process must handle the case where the backup data has only been partially received or has not been received at all.

Behavior required of a process that responds to an active restore of private data:

1. When the backup status flag gets set to ‘restore in progress’ the process has to release locks on all public data files that require to be restored (files that are excluded from restore can be kept locked) so they can be overwritten. This may require that the process ‘freezes’ all sessions to external processes to avoid external events that would cause files to be read or written to (whether requests are blocked or errors returned depends on the context).

2. The process tries to make a connection to the Backup Engine by name.

3. The process receives its private data as a stream using the active client APIs described in Active or passive backup. The owning process is responsible for receiving the data as previously provided and recreating the relevant files. Reference code will be provided to take a stream and create files in a private directory. Any other behavior will have to be implemented by the data owners.

The first chunk of data received will be a base backup of (potentially) multiple files.

If incremental backups have been carried out the base backup data will be followed by a sequence of increments. They will be supplied in the correct (i.e. chronological) order. The receiving process is responsible for amending the data accordingly. If the process can only provide full backups, it will not receive increments.

1. The private data being restored may not be received immediately (multiple processes may be trying to receive data at the same time) and may not be received at all (if the restore is partial or has been broken off).

2. When the backup flag reverts to normal, files can be re-accessed and clients responded to. The process must handle the case where the restore data has only been partially received or has not been received at all. Any cached data must be flushed after a restore.

Private data to be passively backed up

Processes that own private data that needs to be passively backed up must register the fact with the Backup Engine.

If an application is designed for separate installation (as opposed to upgrade) it will need to copy a backup registration file into the private directory during installation. If an application is part of the platform, this involves creating a backup registration file as part of the build and ensuring that it is located in the relevant private directory. See Backup Registration Files.

In addition, the process must subscribe to the backup status flag described in Public and Subscribe Event for Active Backup to be able to detect when a backup or restore takes place.

During the backup or restore, the process can exit or release locks on all public and private data files. If the process is a GUI app, the default behavior will be for it to be terminated politely so no extra code is required.

Private data not backed up

A process that accesses public data, but which does not wish to have private data backed up, does not have to register for backup and restore but it does have to respond to the backup status flag:

• If your process is a UI application which can exit during backup and restore, you need do nothing – you will be terminated politely as before. Note that this means that the default behavior is for private data of applications not to be backed up. The application needs to make a positive decision to get private data backed up. This ‘opt-in’ behavior is a deliberate choice for security reasons – applications cannot find their private data backed up without their knowledge.

• If your process is a non-UI application, or a UI application which will not terminate during backup and restore, and accesses public data, you will need to subscribe to the backup status flag. It must check it on start-up and, if it is set, enter the correct state (this should never happen because the process should not be started during a backup or restore. If it does, however, it should behave robustly just in case). If the process starts during a backup or restore, it should wait until it is complete before attempting to access any public data files.

  • When the backup status flag goes to ‘backup in progress’ your process must release all locks or at least make all public data files readable. This may require that the process ‘freeze’ all sessions to external processes to avoid external events that would cause files to be written to (whether requests are blocked or errors returned depends on the context). When the backup flag reverts to normal, sessions can be re-activated and files re-accessed.

  • When the backup status flag goes to ‘restore in progress’ your process must change to a state where public files can be overwritten. This will involve releasing all public data files accessed and ensuring that external events cannot cause an attempt to re-access any files. When the restore is complete your process must re-load data files and refresh any data stored in cache.

Data in a proxy to be backed up

Data owners can have data stored within another data owner’s data cage, such as with the central repository. In this scenario, data from each data cage must be backed up. The data owner holding data on behalf of another data owner is known as a proxy. From the PC’s point of view, this data belongs to the data owner, but internally the data is being requested from the proxy via the active client interface. A data owner requiring data from one of these proxies must specify the proxy in the element <proxy_data_manager /> using its secure ID. See the example in Backup Registration Files.

Note: During a backup or restore operation, the data owner will behave as an active data owner as far as the PC is concerned, although this requires no special action on behalf of the data owner itself.

Data stored in the central repository (CentRep) will be backed up if the proxy data manager tag is selected in the backup registration file specifying the central repository’s secure ID. Not all data may be backed up. Each value in CentRep has some metadata associated with it and one bit of the metadata is a backup flag. The value will be backed up only if the backup flag bit is set. It is the responsibility of the data owner to specify the correct settings within the repository initialization file.

CentRep backups are always base, as opposed to incremental, because the CentRep does not contain sufficient information to efficiently support incremental backups and because CentRep data is not expected to be sufficiently large to justify incremental backup.

DBMS files to be backed up

A data owner may be responsible for a number of databases that may need to be subject to back up and restore. Shared databases will be backed up if the policy number is specified in the data owners backup registration file using the <dbms_backup> tag. There is no need to specify database names as the DBMS will provide the list of the databases belonging to the data owner based on the policy identifier. See the example in Example backup registration files.

System (installed application) data to be backed up

On Symbian devices, installed applications are no longer backed up by default and now require the consent of the application developer. The backup and restore of an application’s binaries and its data is also done separately and requested differently. For an application's data see Active or passive backup. For binaries the <system_backup/> tag must be specified in the backup registration file. See Backup Registration Files for more details.

The <system_backup/> tag triggers the Backup Engine to query which package the application belongs to and retrieves a list of all the files referenced by the package. Only the following read-only files will be backed up as system data (any file or directory not listed below will need to be backed up separately using one of the other mechanisms described previously):

• \sys\bin\*

• \resource\*

• \private\123456\backup_registration*.xml

Writeable files will not be backed up as system data as they will fail to be restored as system data.

Note: It is essential to add the backup registration file(s) to the package. If forgotten, nothing will be backed up or restored.

An additional mechanism exists to specify backup registration files for data owners that do not have private directories - this is to be used for DLLs which are installed as part of a package. To use this method, the backup registration file must be placed in a special location under the Backup Engine’s private directory:

\private\10202D56\import\packages\<package-id>\backup_registration.xml

Note: 10202D56 is the SID of the Backup Engine, and replace <package-id> with the ID of the package containing the DLL. The data owner does not have a private directory, the only methods that are valid in this backup registration file are system and public file backup.