Backup/Restore
Issue 5 April 2010 109
Note:
Note: If you administered the APPSTAT parameter to suppress changes to one or more
applications, the telephone backs up and restores data as usual, but ignores data
for “suppressed” applications. This prevents a user from bypassing your
APPSTAT restrictions by editing the backup file. For information about APPSTAT,
see The Application Status Flag (APPSTAT)on page 114.
During backup file restoration, user activity is prohibited until a Restore successful or
Restore Failed message displays. When a restore attempt fails, if a retrieved file has no
valid data, or if a retrieved file cannot be successfully stored, a Retrieval Failed message
displays at the telephone until the user takes another action.
Data retrieval considerations are as follows:
When you create a backup file rather than edit an existing one, be sure to create the file
with UTF-16 LE (little endian) characters, with Byte Order Mark (BOM) for LE of 0xFFFE.
Backup saves data values using the generic format name=value. For specific formats,
see Backup.
All identifiers, for example, names, are interpreted in a case-insensitive manner, but the
case of parameter values, Contact names, and numbers is preserved.
Spaces preceding, within, or following a name are treated as part of the name.
<CR> and <LF> (UTF-16 characters 0x000D and 0x000A, respectively) are interpreted as
line termination characters.
Blank lines are ignored.
When an identifier is not recognized or is invalid, the entire line is ignored. Likewise, if an
identifier is valid but the data itself is invalid or incomplete, the line is ignored.
When an identifier is valid with valid and complete data, but the data is not applicable to
the current state of the telephone, the data is retained for possible use later, and is
considered data to be backed up at the appropriate time.
When more than one line contains a value for an option, parameter, or Contacts entry, the
last value read is retrieved, to allow new values to overwrite previous values as lines are
read from the backup file. In all other cases, the line order in the backup file has no bearing
on retrieval.
The existence of invalid data does not constitute a failed retrieval. The success of the
retrieval process requires the telephone to obtain the backup file and successfully restore
valid data.