|
|
|
|
This instruction describes the MTELpage Backup operations. Backup of files is required for three reasons, the first is to keep the files to a reasonable size for searching and viewing records and the second is to compact read write files which grow forever. The third reason is larger files can get corrupted and therefore a greater loss of data may result. There are two files which are read write and therefore will grow in size indefinitely if they are not compacted. If the files grow too large typically in the tens of megabytes then the process of reading writing to the file becomes excessively slow. Log files are also created and backed up in the suite. The description of the logging files are handled on a separate web page.
The MTELPage Suite has one file which requires regular maintenance as it is a Microsoft Access database. The file is the message history list "mtelmess.mdb" which normally contains 7 days of history. It is unique from all the other Access files in the suite as it has read write requirements which is necessary to perform message archiving. All other files in the MTELPage suite are read only files. The file requires 2 types of maintenance, record backup and file compaction. In general, a backup of the file incorporates a compaction at the end of the backup. The compaction can be performed separately from the backup though it is a manual process and is rarely used or required. Compaction simply reduces the size of the file to the base record set. Backing up requires the deletion of records which are simply marked as inactive in the file. If the compaction process is not performed the file would grow in size as deletions of records are performed at every backup. The compaction process used by MTELpage Suite is to copy an empty file to a temporary file and simply add the records into the empty file. The temporary file then replaces the original file. Backup Operation: The history file is contains the last 7 days of messages as well logs from the servers and the off-air decoder messages. This file resides on the file server as "logs\mtelmess.mdb". There should never be any permanently open connections to this file. i.e. no lock file. The file is usually around 2 to 3 megabytes. Any larger may be due to excessive logging during a problem or the file may be corrupted. Backing up the file is quite involved and is therefore broken up into a series of function calls which are called every 10 seconds so that the application is unaffected and the speed of response of the workstation is unaffected. Since the file is on a file server the first step is to copy it to the local machine. Performing backup across the network is very tedious and performance demanding. The local copy is then modified and split into the backup file and a compacted copy of the last 7 days. Once the file is compacted it is copied back to the file server. A log of the process is shown below and can be viewed in the Client logs in MTELPage or in the System Log in MTELServe.
Backup Automation: Currently MTELpage and MTELServe are capable of backing up the message file. Both applications are automated to check the date of the last backup. However the applications can interfere with one another if two or more applications try to backup the file at the same time. More importantly if one application attempts a backup just after one of the other applications then dummy backup files are created which are empty. To avoid this problem all MTELpage clients have a last backup test date which is set when the application performs a backup. To stop the application from backing up, the last test date is set to the year 2099. Backup Delegation: It is best to assign just one application to do the backup process. The best application to perform the task is the one which is always running and is in operation in all comms centres. The S01 server has been designated to be the backup application and therefore the only application with a valid test date. In MTELServe 2013 the S01 is hard coded to be the only server application to perform a backup.
|
|
|
