Difference between revisions of "Backup and Restore"

Latest revision as of 15:49, 29 May 2017

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 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 IMSMA^NG Database

By far, the most critical component to backup is the IMSMA^NG database itself because it contains all of the actual data in IMSMA^NG and published templates, etc. 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. The resulting dump.sql file, which is stored in a time-stamped directory for easy identification.

	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 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 configuration, 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 total file size of the 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 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 IMSMA^NG stores all coordinate data in the PGSQL database that is backed up with the IMSMA^NG database, IMSMA^NG also uses a geodatabase file (IMSMA.gdb), also known as the sandbox, to display the data in the Map Pane inside IMSMA^NG. These files should be included with each IMSMA^NG backup to shorten the time it takes to launch IMSMA^NG after a restore. IMSMA^NG automatically rebuilds the sandbox during launch of the IMSMA^NG 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

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. In Map Data is also the sub-theme assignments included.

Data Entry Form Templates and iReport Templates

IMSMA^NG 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 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 standard configuration of IMSMA^NG, 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 IMSMA^NG and information managers should ensure that these external tools are backed up manually.

IMSMA Restore

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

Backups created using IMSMA^NG Backup should be restored using IMSMA^NG Restore. 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.

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

@@ Line 1: / Line 1: @@
-<div class="boilerplate metadata vfd" style="background-color: #F3F9FF; margin: 0 auto; padding: 0 1px 0 0; border: 1px solid #AAAAAA; font-size:10px">
-{| width = "100%"
-|-
-! width="33%" align="left"  | <font color="gray">&lt;</font> [[Managing Current Views]]
-! width="33%" align="center" | <font color="gray">^</font> [[Administrating IMSMA]]
-! width="33%" align="right" | [[Managing External Reporting Connections]]  <font  color="gray">&gt;</font>
-|}</div>
-{{Reference guide header|The ''Managing Searches' process is a series of steps to...
-}}
 __FORCETOC__
 {{TOC right}}
+==Backing Up And Restoring Data==__NOEDITSECTION__
+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}}.
-{{HowTo's
-|[[Standalone]]
-|[[Network Environment]]
-|[[Externally Connected Tools]]
-|[[Attachments]]
-}}
-==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>.
 *disk mirroring
 *operating system backups
 *hard disk backup
 *offsite data storage
-*IMSMANG-specific backups
+*{{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.
-Finally, any data backup strategy should include occasioanl tests to ensure that all of the backups are functioning properly.
+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 IMSMA<sup>NG</sup> Database===
+===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.
-The IMSMA<sup>NG</sup> Datebase holds all of the actie data in IMSMA<sup>NG</sup> ranging from published reports to general mine action information.  IMSMA<sup>NG</sup> Backup is responsible for storing all of this data under the MySQL database.  The MySQL database dump command impliments a complete backup of all the data in the database.  The resulting dump.sql file includes the necessary commands to recreate the database with all the existing data.  The existing file is stored in a time-stamped directory for easy access.
+{{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]]
+}}
-[[File:BackingUp Tip1CORRECT.png|border|caption]]
+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| 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.}}
-Information Managers can create automatic dailiy or weekly backups using MySQL Administration tools.  These backups also work simultaneously with IMSMA <sup>NG</sup> Backup; however any backup made outside of IMSMA <sup>NG</sup> needs to be manually restored.
+===Attachments===__NOEDITSECTION__
+{{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.
-[[File:BackingUp Tip2.png|border|caption]]
+===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}} 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.
-Attachmes are stored seprately from the IMSMA<sup>NG</sup> database on the server file.  However because of their size, it may not be necessary to back up the attachments each time.  For this reason, IMSMA<sup>NG</sup> Backup provides the option of excluding attachments when performing a backup.
+===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.
+===Translations===__NOEDITSECTION__
+{{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.
-Including attachments is still reccomended for complete backups.  However, if the file size is too large attachments can be deleted manually.  Avoid excluding attachemtns from backups since attachmets cannot be added to the backup file.
+==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.
-===Backing Up Other IMSMA<sup>NG</sup> Information===
+* client and server '''settings''' including memory settings
-Apart from the IMSMA<sup>NG</sup> database and attachment stored on the server, IMSMA<sup>NG</sup> Backup allows members to backup specific elements from the client including:
+* C:\IMSMAng\server\gis\maps\imsma.mxd (if customized)
+* the background map(s) source files ('''not''' only the .mxd file)
-*GIS database (.mdb file)
+* local projection files (.prj)
-*map files (.mxd, etc)
+* C:\IMSMAng\migration\conf\migration.properties and any import scripts
-*field report template files
+* [[Language and Translations#Data language|fallback fonts]] (C:\IMSMAng\java\lib\fonts\fallback)
-*iReport template files
+* ODBC configurations
-*translation .properties files
+* 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.
-====GIS Dataabase====
-IMSMA<sup>NG</sup> also stores corrdinate data on each client computer in a geodatabase file (IMSMA.mdb) to allow data to be displayed on a map.  Even if the file is missing, IMSMA<sup>NG</sup> automatically builds this file aftre the system launch.  However, it can take several hours.  To avoid this, each IMSMA<sup>NG</sup> backup should include this file to reduce the time it takes to launch IMSMA<sup>NG</sup> after a restore.
-Likewise, since the geodatabase is structured on a per-client basis, the best way to fully update the geodatabase is to launch the client prior to backing it up.  Once it is backed up, users can shorten the time required to build the geodatabase by manually transferring it to newly installed clinets.
-====Maps====
-IMSMA<sup>NG</sup> map fiiles 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.
-[[File:Map Tip1CORRECT.png|border|caption]]
+==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__
+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.
-IMSMA<sup>NG</sup>users can store copies or drafts of field reports templates and iReports templates to the file system. Select the option on the IMSMA<sup>NG</sup> Backup window to store these files in the backup.
+{{note| In a client/server environment, it is recommended to stop the server prior to restoring the database to ensure all clients are disconnected.}}
+{{NavBox IMSMA NG Administration}}
-====Translations====
+[[Category:NAA]]
-Translations and localizations of data elements are stored in the IMSMA<sup>NG</sup> database and secured with the database backup.  Although the properties files used to translate the IMSMA<sup>NG</sup> interface are stored externally to the database, they can be added to the IMSMA<sup>NG</sup> Backup.  Be sure to backup all properties files each time a change or a full backup is made.