Backup/Restore
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
●Backup saves data values using the generic format name=value. For specific formats, see Backup.
●All identifiers, for example, names, are interpreted in a
●Spaces preceding, within, or following a name are treated as part of the name.
●<CR> and <LF>
●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.
Issue 5 April 2010 109