Backup and Restore

Backing Up And Restoring Data

The most important aspect of maintaining a properly functioning IMSMA^NG system is backing up and restoring data. Regular data backups are essential for maintaining the integrity of the system in case of sytem failure, software errors or accidental data deletion. Not only should information managers mandate that all IMSMA^NG data is regularly backed up, but more importantly a multitiered backup strategy should be used to eliminate data loss. Consider the following options below when developing a backup strategy for IMSMA^NG.

disk mirroring
operating system backups
hard disk backup
offsite data storage
IMSMA^NG-specific backups

Moreover, a backup is only as good as the ability to restore it. As such, any data backup strategy should include plans to test existing backups to ensure that the backups are usable. If it becomes necessary to restore data, regular testing of backups helps ensure that it will be possible to do so.

Following is a list of components that should be backed up.

IMSMA^NG database
Attachments
GIS database
Maps
Templates
Translation

Note that an event-based change to the components necessitates a backup. Event-based changes include events such as:

Before upgrading software
Before importing data
After importing Data Entry Forms
After changing SQL views in the database

Backing Up the IMSMA^NG Database

IMSMA^NG contains several stores of information that can be backed up. By far, the most critical store is the IMSMA^NG database itself because it contains all of the actual data in IMSMA^NG including published reports, form templates and geographic data in addition to the typical mine action information. IMSMA^NG’s Backup capability backs up the IMSMA^NG database by executing a PGSQL database dump command that creates a complete backup of all of the data in the database including any additional tables, views and other customisations. The resulting dump.sql file, which is stored in a time-stamped directory for easy identification, includes the necessary commands to recreate the database with all of the existing data.

	The dump.sql file is stored in text format and can be made smaller for storage or transport using compression tools such as ZIP and RAR

Information managers can augment the IMSMA^NG Backup capability with other scheduled backups using PGSQL Administration tools, for example, and build daily or weekly routines that back up the database automatically. These backups work similarly to IMSMA^NG Backup; however, any backup made outside of IMSMA^NG will have to be restored manually. Even so, regularly scheduled backups are an excellent component of a backup strategy.

	In a client/server environment, backups should be made from the server rather than the clients. Similarly, backups can only be restored on the IMSMA^NG server

Attachments

IMSMA^NG stores attachments on the server file system separate from the IMSMA^NG database. Because of the size of some attachments, it may not be beneficial or necessary to back up the attachments each time. IMSMA^NG Backup provides the option to exclude attachments when performing a backup.

For regular, complete backups, it is recommended to include attachments. But, if the size of a backup file is a concern, the attachments can be manually deleted. This is a better alternative to creating a backup without attachments since attachments cannot be added back to the backup file. Excluding attachments from a backup is an option that should be used with caution.

Backing Up Other IMSMA^NG Information

In addition to the IMSMA^NG database and attachments stored on the server, IMSMA^NG Backup allows users to back up certain settings from the IMSMA^NG client. These include:

GIS database (.mdb file)
map files (.mxd, etc)
Data Entry Form template files
iReport template files
translation .properties files

GIS Database

While IMSMA^NG stores all coordinate data in the PGSQL database that is backed up with the IMSMA^NG database, IMSMA^NG also stores coordinate data in a geodatabase file (IMSMA.mdb) on each client computer to allow data to be displayed on the map. This file should be included with each IMSMA^NG backup to shorten the time it takes to launch IMSMA^NG after a restore. IMSMA^NG automatically builds this file during system launch if the file is missing, but it can take several hours to do so.

Because the geodatabase is built on a per-client basis, it is also recommended to launch the client to fully update the geodatabase prior to backing it up. After it is backed up, the geodatabase can be transferred manually to other freshly installed clients to shorten the time required to build the geodatabase during system launch.

Maps

IMSMA^NG map files can be loaded on a per-client basis and stored in IMSMA^NG Backup, providing an easy way to share maps between clients.

	IMSMA^NG Backup backs up only the active map on each client. Other maps previously loaded on a client will need to be copied manually.

Data Entry Form Templates and iReport Templates

IMSMA^NG provides the capability to store copies or drafts of Data Entry Form templates and iReport templates to the file system during report design. While the published versions of the templates are backed up as part of the IMSMA^NG database backup, the files are only included if the option is selected on the IMSMA^NG Backup window. Storing these files in the backup is recommended as it makes it easier to resume drafting templates and reports.

Translations

IMSMA^NG stores translations of the application in several places. Translations and localisations of data elements are stored in the IMSMA^NG database and are backed up with the database backup. The .properties files used to translate the IMSMA^NG interface are stored externally to the database, but they can be added to the IMSMA^NG Backup as an option. If changes are made to the .properties files, it is recommended to back them up after each change as well as each time a full backup is made.

Other Backup Considerations

While IMSMA^NG Backup backs up all of the files used in the typical operation of IMSMA^NG, there are other customisable files that should also be backed up. These include:

map customisations

IMSMA^NG does not automatically back up customisations made to maps used in IMSMA^NG. Users can make changes to the imsma.mxd file, create or modify ESRI style files, add symbology or make many other changes to maps, but these files are not included in the IMSMA^NG Backup and must be separately backed up and managed.

base maps

It is recommended that information managers make backups of maps that are imported into IMSMA^NG for use on client computers. While IMSMA^NG Backup backs up the maps when they have been imported, these base map files are not managed within IMSMA^NG and should be backed up manually to allow for customisation and later import.

external reporting tools

External reporting tools and other add-ons are not backed up by IMSMA^NG and should be backed up manually. These include any tools using ODBC connections to IMSMA^NG such as Microsoft Access databases, Microsoft Excel spreadsheets, OpenOffice connections and Crystal Reports. Information managers should ensure that these tools get backed up manually or automatically.

IMSMA Restore

Template:Important

Backups created using IMSMA^NG Backup can be restored using IMSMA^NG Restore as well as other PGSQL tools if necessary. The IMSMA^NG Restore function can be used on both clients and servers to restore key information in the event of data loss or other restore needs (for example, after an upgrade).

IMSMA^NG Restore allows users to determine which components of an IMSMA^NG Backup to restore. The components available depend on the options that were selected during backup. Each option behaves slightly differently depending on whether the restore is occurring on a server or a client.

Restore on the Server

In a client/server environment, the IMSMA^NG database can be restored only on the server machine so as to prevent accidental deletion of data by client users. Conducting an IMSMA^NG Restore on the server machine (or a stand-alone machine) restores the IMSMA^NG database and the available attachments to the server, replacing any existing data in the IMSMA^NG database. When a restore is complete, IMSMA^NG closes and must be restarted.

IMSMA^NG Restore can also restore the GIS database, Data Entry Form templates, iReport templates, map files and translation .properties files; however, these are only necessary when running the client on the server or when running in stand-alone mode.

	In a client/server environment, it is recommended to stop the server prior to restoring the database to ensure all clients are disconnected

Restore on the Client

Except for instances where the client and the server are on the same machine, the IMSMA^NG database cannot be restored to a client-only machine. However, IMSMA^NG Restore can be used to restore client settings including the GIS database, Data Entry Form templates, iReport templates, map files and translation .properties files. This functionality is particularly useful when connecting new clients to a server as this allows information managers to prebuild the GIS database and map configurations and simply restore them to the new clients.

On a client machine, IMSMA^NG Restore acts as a file copying function, copying files included in the backup to the correct location on the client. IMSMA^NG Restore also attempts to back up any files it is replacing. These backup directories have “_orig” appended to their file names to distinguish them from the new files.