Backup Registration Files

Introduction

Backup registration files are stored in the root of the private directory of the corresponding process. They have the standard name backup_registration.xml. These files are protected on the phone by placing them in the private data areas.

The backup registration file is searched on the specific drive that is being backed up. If the search does not fetch any backup registration file the corresponding private directory of the Z: is searched. If a backup registration file is found in the drive to be backed up, the Z: drive will not be searched. This allows the backup registration file on the Z: drive to be masked where necessary.

Backup registration file DTD

The DTD for the backup registration file is as follows:

<?xml version=”1.0” standalone=”yes”?> 
<!DOCTYPE backup_registration [ 
     <!ELEMENT backup_registration  
       (passive_backup?, system_backup?, public_backup?, active_backup?, 
       cenrep_backup*, proxy_data_manager*, dbms_backup*, restore?) > 
       <!ATTLIST backup_registration version CDATA #FIXED "1.0" > 
     <!-- Include file or directory name should include path relative to private directory 
          for private data. To include all private data use “\”. 
          Include file or directory name should include path relative to root of drive
       for public data. This may or may not include the drive letter. Inclusions with 
          drive letter will be excluded from backups of other drives. Inclusions without 
          drive letter will be assumed to apply to all drives. 
  --> 
     <!ELEMENT include_file EMPTY > 
       <!ATTLIST include_file name CDATA #REQUIRED > 
     <!-- Exclude file or directory name should be of the same form as the owning 
          <include_directory> and is not treated as relative to the <include_directory> 
     --> 
     <!ELEMENT exclude EMPTY > 
       <!ATTLIST exclude  name CDATA #REQUIRED > 
     <!ELEMENT include_directory (exclude*) > 
       <!ATTLIST include_directory  name CDATA #REQUIRED > 
     <!ELEMENT passive_backup (include_directory|include_file)* > 
       <!ATTLIST passive_backup  
         supports_selective (yes|no) "no" 
         delete_before_restore (yes|no) "no" 
         base_backup_only (yes|no) "no"   > 
     <!ELEMENT public_backup (include_directory|include_file)* > 
       <!ATTLIST public_backup  delete_before_restore (yes|no) "no" > 
     <!-- If the <system_backup> element is present then all executables 
          and resource files that were included in SIS files will be backed up. 
          The set of files does not need to be specified as it can be found from 
          package data. They can only be restored after checking against signed hashes. 
     --> 
     <!ELEMENT system_backup > 
     <!-- <proxy_data_manager> indicates that the data owner represented by this backup registration file has data that is accessed through a proxy which is itself an active data owner. 
     --> 
     <!ELEMENT proxy_data_manager EMPTY > 
       <!ATTLIST proxy_data_manager SID CDATA #REQUIRED > 
     <!ELEMENT dbms_backup EMPTY > 
       <!ATTLIST dbms_backup policy CDATA #REQUIRED > 
     <!ELEMENT active_backup EMPTY > 
       <!ATTLIST active_backup 
         process_name CDATA #REQUIRED 
         requires_delay_to_prepare_data (yes|no) "no" 
         supports_selective (yes|no) "no" 
         supports_incremental (yes|no) "yes" 
         active_type (activeonly|activeandproxy|proxyonly) “activeonly” > 
     <!ELEMENT restore EMPTY > 
       <!ATTLIST restore     requires_reboot (yes|no) "no" > 
]>

Note: The requires_reboot attribute for restore is currently reserved. It only supports "NO".

Content of the backup registration file

A backup registration file contains the following information:

• For a passive data backups, a list of private directories and files to be backed up.

  It is possible to list a directory for backup and then list sub-directories or files for exclusion. These directories and files are defined relative to the process private area, and it is not possible to refer to private files owned by another process.

  If files or directories do not exist, no error is raised. In such a scenario, base backups are usually specified rather than incremental backups. For example, if a data owner stores all of its data in one database file, any increment is the whole database file. It is more efficient to always do a base backup.

• A list of public files and directories to be backed up.

  The same syntax is used as for private files. System files or private files are ignored from this section. For files listed for passive backup, directories can be listed that do not yet exist.

• A tag for system files (executables and resource files) backup. It is not necessary to list all of the files. If any of the data owners specify that system files are to be backed up, all of the system files for the package are backed up and restored as a unit.

• For passive backup and partial backup of public files, an option to specify whether the target directories are cleared before a restore operation.

• An option to specify active backup or passive backup.

  For active backup, the tags to specify the data owner application or server. It is possible to invoke active backup and also request private and/or public files to be backed up. Active data is requested before passive for backup, and active is supplied before passive for restore. There is no guarantee which data owner’s data is backed up or restored first.

• To back up or restore a shared database passively, an attribute to specify the security policy ID of the database.

• For a proxy backup, an attribute in the proxy data manager tag to specify the secure ID of the proxy.

• An option to allow some time for data preparation before for backup or restore.

Example backup registration files

The following is an example of a backup registration file for a data owner that requires only passive backup of files in a sub-directory named ‘preserve’:

<?xml version="1.0" standalone="yes"?> 
<backup_registration> 
        <passive_backup> 
        <include_directory name = "preserve"/> 
        </passive_backup> 
        <restore requires_reboot = "no"/> 
</backup_registration>

The following is an example of a backup registration file for a data owner that requires passive backup of all its files and also wants its system files to be backed up:

<?xml version="1.0" standalone="yes"?> 
<backup_registration> 
        <passive_backup> 
        <include_directory name = "\" /> 
        </passive_backup> 
        <system_backup/> 
        <restore requires_reboot = "no"/> 
</backup_registration>

The following is an example of a backup registration file for a data owner that has only central repository data:

<?xml version="1.0" standalone="yes"?> 
<backup_registration> 
        <proxy_data_manager SID="0x10202BE9" /> 
</backup_registration>

The following is an example of backup registration file for an data owner that requires an active backup only:

<?xml version="1.0" encoding="UTF-16" standalone="yes" ?> 
<backup_registration version="1.0"> 
        <active_backup process_name="processname.exe"
         requires_delay_to_prepare_data="yes" 
         active_type="activeonly" /> 
</backup_registration>

The following is an example of backup registration file for data owner which implements a proxy:

<?xml version="1.0" encoding="UTF-16" standalone="yes" ?> 
<backup_registration version="1.0"> 
        <active_backup process_name="processname.exe" 
         active_type="proxyonly" /> 
</backup_registration>

The following is an example of backup registration file for a data owner who wishes to back up its DBMS databases:

<?xml version="1.0" standalone="yes" ?> 
<backup_registration> 
        <dbms_backup policy="AABBCCDD" /> 
</backup_registration>

Additional backup registration files

Application developers and device creators can provide additional plug-in executables after the ROM is built. To back up such files, additional backup registration files can be provided with the following requirements:

• The additional registration files must have a name of the form backup_registration*.xml and be located in the root of the relevant private directory. They are distinguished from the principal backup registration file by the file names. The principal backup registration file has the name backup_registration.xml.

• The additional registration files must only contain a subset of the principal backup registration file elements. They must not include an additional type of backup. For example, if the principal backup registration file uses active backup, additional must not specify passive backup.

All drives will be searched for additional backup registration files including the Z: drive. Additional backup registration files cannot be created or modified at runtime.