Difference between revisions of "Backup and Restore"

From IMSMA Wiki
Jump to: navigation, search
 
(38 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 
__FORCETOC__
 
__FORCETOC__
 
{{TOC right}}
 
{{TOC right}}
==Backing Up And Restoring Data==
+
==Backing Up And Restoring Data==__NOEDITSECTION__
The most important aspect of maintaining a properly functioning IMSMANG system is backing up and restoring data.
+
The most important aspect of maintaining a properly functioning {{IMSMANG}} 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<sup>NG</sup> data is regularly backed up, but more importantly a multitired backup strategy should be used to eliminate data loss.  Consider the following options below when developing a backup strategy for IMSMA<sup>NG</sup>.   
+
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 {{IMSMANG}} 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 {{IMSMANG}}.   
  
 
*disk mirroring
 
*disk mirroring
Line 9: Line 9:
 
*hard disk backup
 
*hard disk backup
 
*offsite data storage
 
*offsite data storage
*IMSMANG-specific backups
+
*{{IMSMANG}}-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.
+
Moreover, a backup is only as if you are able 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.
  
{{note| Backup Recommendations
+
Note that an event-based change to the components necessitates a backup '''before''' and '''after''' the change. Event-based changes include events such as:
 +
* upgrading any software on the server
 +
* importing data and/or Data Entry Forms
 +
* changing SQL views in the database.
  
The table below outlines the recommended schedule for backing up the IMSMANG database and other files. Note that an event-based change to the components necessitates a backup. Event-based changes include events such as:
+
===Backing Up the {{IMSMANG}} Database===__NOEDITSECTION__
 +
By far, the most critical component to backup is the {{IMSMANG}} database itself because it contains all of the actual data in {{IMSMANG}} and published templates, etc. {{IMSMANG}}’s Backup capability backs up the {{IMSMANG}} database by executing a PGSQL database dump command that creates a complete backup of all of the data in the database. The resulting dump.sql file, which is stored in a time-stamped directory for easy identification.
 +
 
 +
{{note| The dump.sql file is stored in text format and can be made smaller for storage using compression tools such as WinZIP. }}
 +
{{HowTo's
 +
|[[Backup IMSMA Data|Backup IMSMA Data]]
 +
|[[Scheduling Backup|Scheduling Backup of IMSMA database]]
 +
}}
  
* Before upgrading software
+
Information managers can schedule backups using PGSQL Administration tools and build daily or weekly routines that back up the database automatically. These backups work similarly to {{IMSMANG}} Backup; however, any backup made outside of {{IMSMANG}} will have to be restored manually. Even so, regularly scheduled backups are an excellent component of a backup strategy.
* Before importing data
 
* After importing field reports
 
* After making SQL changes to the database
 
  
Server Client Server and Client
+
{{note| In a client/server configuration, backups should be made from the server rather than the clients. Similarly, backups can only be restored on the {{IMSMANG}} server.}}
Component Daily Weekly Weekly Event-based change
 
IMSMANG database ● ● ●
 
Attachments ● ● ●
 
GIS database ● ● ●
 
Maps ● ● ●
 
Templates ● ● ●
 
Translation ● ●
 
}}
 
  
===Backing Up the IMSMA<sup>NG</sup> Database===
+
===Attachments===__NOEDITSECTION__
IMSMANG contains several stores of information that can be backed up. By far, the most critical store is the IMSMANG database itself because it contains all of the active data in IMSMANG including published reports, form templates and geographic data in addition to the typical mine action information. IMSMANG’s Backup capability backs up the IMSMANG database by executing a MySQL 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.  
+
{{IMSMANG}} stores attachments on the server file system separate from the {{IMSMANG}} database. Because of the total file size of the attachments, it may not be beneficial or necessary to back up the attachments each time. {{IMSMANG}} Backup provides the option to exclude attachments when performing a backup which is '''not''' recommended.
 
 
{{note| 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 IMSMANG Backup capability with other scheduled backups using MySQL Administration tools, for example, and build daily or weekly routines that back up the database automatically. These backups work similarly to IMSMANG Backup; however, any backup made outside of IMSMANG will have to be restored manually. Even so, regularly scheduled backups are an excellent component of a backup strategy.
+
For regular, complete backups, it is highly recommended to include attachments. It is also possible to take an IMSMA backup of the database and a file backup of the attachments.
  
{{note| In a client-server environment, backups should be made from the server rather than the clients. Similarly, backups can only be restored on the IMSMANG server
+
===GIS Database===__NOEDITSECTION__
}}
+
While {{IMSMANG}} stores all coordinate data in the PGSQL database that is backed up with the {{IMSMANG}} database, {{IMSMANG}} also uses a geodatabase file (IMSMA.gdb), also known as the sandbox, to display the data in the Map Pane inside {{IMSMANG}}. These files should be included with each {{IMSMANG}} backup to shorten the time it takes to launch {{IMSMANG}} after a restore. {{IMSMANG}} automatically rebuilds the sandbox during launch of the {{IMSMANG}} if the sandbox is missing, but it can take several hours to do so. After it is backed up, the sandbox can be transferred manually to other freshly installed clients to shorten the time required to build the geodatabase during system launch.
  
===Attachments===
+
===Maps===__NOEDITSECTION__
IMSMANG stores attachments on the server file system separate from the IMSMANG database. Because of the size of some attachments, it may not be beneficial or necessary to back up the attachments each time. IMSMANG Backup provides the option to exclude attachments when performing a backup.
+
{{IMSMANG}} map files can be loaded on a per-client basis and stored in {{IMSMANG}} Backup, providing an easy way to share maps between clients. In Map Data is also the [[Customise Sub-Themes | sub-theme]] assignments included.
  
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.
+
===Data Entry Form Templates and iReport Templates===__NOEDITSECTION__
 +
{{IMSMANG}} provides the capability to store copies of 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 {{IMSMANG}} database backup, the files are only included if the option is selected on the {{IMSMANG}} Backup window. Storing these files in the backup is recommended as it makes it easier to resume drafting templates and reports.
  
===Backing Up Other IMSMA<sup>NG</sup> Information===
+
===Translations===__NOEDITSECTION__
In addition to the IMSMANG database and attachments stored on the server, IMSMANG Backup allows users to back up certain settings from the IMSMANG client. These include:
+
{{IMSMANG}} stores translations of the application in several places. Translations and localisations of data elements are stored in the {{IMSMANG}} database and are backed up with the database backup. The .properties files used to translate the {{IMSMANG}} interface are stored externally to the database, but they can be added to the {{IMSMANG}} 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.
 
* GIS database (.mdb file)
 
* map files (.mxd, etc)
 
* field report template files
 
* iReport template files
 
* translation .properties files
 
 
====GIS Dataabase====
 
While IMSMANG stores all coordinate data in the MySQL database that is backed up with the IMSMANG database, IMSMANG 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 IMSMANG backup to shorten the time it takes to launch IMSMANG after a restore. IMSMANG 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.
+
==Other Backup Considerations==__NOEDITSECTION__
 +
While {{IMSMANG}} Backup backs up all of the files used in the standard configuration of {{IMSMANG}}, there are other files that should also be backed up and/or carefully documented.  
  
====Maps====
+
* client and server '''settings''' including memory settings
IMSMA<sup>NG</sup> map files can be loaded on a per-client basis and stored in IMSMA<sup>NG</sup> Backup, providing an easy way to share maps between clients.
+
* C:\IMSMAng\server\gis\maps\imsma.mxd (if customized)
 +
* the background map(s) source files ('''not''' only the .mxd file)
 +
* local projection files (.prj)
 +
* C:\IMSMAng\migration\conf\migration.properties and any import scripts
 +
* [[Language and Translations#Data language|fallback fonts]] (C:\IMSMAng\java\lib\fonts\fallback)
 +
* ODBC configurations
 +
* External tools
 +
: External reporting tools and other add-ons are not backed up by {{IMSMANG}} and information managers should ensure that these external tools are backed up manually.  
  
{{note| IMSMANG Backup backs up only the active map on each client. Other maps previously loaded on a client will need to be copied manually
+
==IMSMA Restore==__NOEDITSECTION__
 +
{{Warning| {{IMSMANG}} Restore replaces all data in the {{IMSMANG}} database and copy over existing files. Prior to restoring the {{IMSMANG}} database, information managers should ensure that all necessary data has been backed up. {{IMSMANG}} Restore operations cannot be undone.}}
 +
{{HowTo's
 +
| [[Restore IMSMA Backup on Server]]
 +
|[[Restore IMSMA Backup on Client]]
 
}}
 
}}
 +
Backups created using {{IMSMANG}} Backup should be restored using {{IMSMANG}} Restore. {{IMSMANG}} Restore allows users to determine which components of an {{IMSMANG}} 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.
  
====Field Report Templates and iReport Templates====
+
===Restore on the Server===__NOEDITSECTION__
IMSMANG provides the capability to store copies or drafts of field report 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 IMSMANG database backup, the files are only included if the option is selected on the IMSMANG Backup window. Storing these files in the backup is recommended as it makes it easier to resume drafting templates and reports.
+
In a client/server environment, the {{IMSMANG}} database can be restored only on the server machine so as to prevent accidental deletion of data by client users. Conducting an {{IMSMANG}} Restore on the server machine (or a stand-alone machine) restores the {{IMSMANG}} database and the available attachments to the server, replacing any existing data in the {{IMSMANG}} database. When a restore is complete, {{IMSMANG}} closes and must be restarted.  
  
====Translations====
+
{{note| In a client/server environment, it is recommended to stop the server prior to restoring the database to ensure all clients are disconnected.}}
IMSMANG stores translations of the application in several places. Translations and localisations of data elements are stored in the IMSMANG database and are backed up with the database backup. The .properties files used to translate the IMSMANG interface are stored externally to the database, but they can be added to the IMSMANG 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===
+
{{NavBox IMSMA NG Administration}}
While IMSMANG Backup backs up all of the files used in the typical operation of IMSMANG, there are other customisable files that should also be backed up. These include:
 
  
* map customisations
+
[[Category:NAA]]
IMSMANG does not automatically back up customisations made to maps used in IMSMANG. 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 IMSMANG 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 IMSMANG for use on client computers. While IMSMANG Backup backs up the maps when they have been imported, these base map files are not managed within IMSMANG 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 IMSMANG and should be backed up manually. These include any tools using ODBC connections to IMSMANG 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.
 

Latest revision as of 15:49, 29 May 2017

Backing Up And Restoring Data

The most important aspect of maintaining a properly functioning IMSMANG 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 IMSMANG 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 IMSMANG.

  • disk mirroring
  • operating system backups
  • hard disk backup
  • offsite data storage
  • IMSMANG-specific backups

Moreover, a backup is only as if you are able 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.

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

  • upgrading any software on the server
  • importing data and/or Data Entry Forms
  • changing SQL views in the database.

Backing Up the IMSMANG Database

By far, the most critical component to backup is the IMSMANG database itself because it contains all of the actual data in IMSMANG and published templates, etc. IMSMANG’s Backup capability backs up the IMSMANG database by executing a PGSQL database dump command that creates a complete backup of all of the data in the database. The resulting dump.sql file, which is stored in a time-stamped directory for easy identification.

Note.jpg The dump.sql file is stored in text format and can be made smaller for storage using compression tools such as WinZIP.

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

Note.jpg In a client/server configuration, backups should be made from the server rather than the clients. Similarly, backups can only be restored on the IMSMANG server.

Attachments

IMSMANG stores attachments on the server file system separate from the IMSMANG database. Because of the total file size of the attachments, it may not be beneficial or necessary to back up the attachments each time. IMSMANG Backup provides the option to exclude attachments when performing a backup which is not recommended.

For regular, complete backups, it is highly recommended to include attachments. It is also possible to take an IMSMA backup of the database and a file backup of the attachments.

GIS Database

While IMSMANG stores all coordinate data in the PGSQL database that is backed up with the IMSMANG database, IMSMANG also uses a geodatabase file (IMSMA.gdb), also known as the sandbox, to display the data in the Map Pane inside IMSMANG. These files should be included with each IMSMANG backup to shorten the time it takes to launch IMSMANG after a restore. IMSMANG automatically rebuilds the sandbox during launch of the IMSMANG if the sandbox is missing, but it can take several hours to do so. After it is backed up, the sandbox can be transferred manually to other freshly installed clients to shorten the time required to build the geodatabase during system launch.

Maps

IMSMANG map files can be loaded on a per-client basis and stored in IMSMANG Backup, providing an easy way to share maps between clients. In Map Data is also the sub-theme assignments included.

Data Entry Form Templates and iReport Templates

IMSMANG provides the capability to store copies of 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 IMSMANG database backup, the files are only included if the option is selected on the IMSMANG Backup window. Storing these files in the backup is recommended as it makes it easier to resume drafting templates and reports.

Translations

IMSMANG stores translations of the application in several places. Translations and localisations of data elements are stored in the IMSMANG database and are backed up with the database backup. The .properties files used to translate the IMSMANG interface are stored externally to the database, but they can be added to the IMSMANG 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 IMSMANG Backup backs up all of the files used in the standard configuration of IMSMANG, there are other files that should also be backed up and/or carefully documented.

  • client and server settings including memory settings
  • C:\IMSMAng\server\gis\maps\imsma.mxd (if customized)
  • the background map(s) source files (not only the .mxd file)
  • local projection files (.prj)
  • C:\IMSMAng\migration\conf\migration.properties and any import scripts
  • fallback fonts (C:\IMSMAng\java\lib\fonts\fallback)
  • ODBC configurations
  • External tools
External reporting tools and other add-ons are not backed up by IMSMANG and information managers should ensure that these external tools are backed up manually.

IMSMA Restore

Warning.jpg IMSMANG Restore replaces all data in the IMSMANG database and copy over existing files. Prior to restoring the IMSMANG database, information managers should ensure that all necessary data has been backed up. IMSMANG Restore operations cannot be undone.

Backups created using IMSMANG Backup should be restored using IMSMANG Restore. IMSMANG Restore allows users to determine which components of an IMSMANG 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 IMSMANG database can be restored only on the server machine so as to prevent accidental deletion of data by client users. Conducting an IMSMANG Restore on the server machine (or a stand-alone machine) restores the IMSMANG database and the available attachments to the server, replacing any existing data in the IMSMANG database. When a restore is complete, IMSMANG closes and must be restarted.

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