Changes

==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 IMSMA^NG {{IMSMANG}} data is regularly backed up, but more importantly a multitired multitiered backup strategy should be used to eliminate data loss. Consider the following options below when developing a backup strategy for IMSMA^NG{{IMSMANG}}.

*{{IMSMANG}}-specific backups

Moreover, a backup is only as good as the ability 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 {{IMSMANG}} Database===__NOEDITSECTION__IMSMANG contains several stores of information that can be backed up. By far, the most critical store component to backup is the {{IMSMANG }} database itself because it contains all of the active actual data in {{IMSMANG including }} and published reportstemplates, form templates and geographic data in addition to the typical mine action informationetc. IMSMANG’s {{IMSMANG}}’s Backup capability backs up the {{IMSMANG }} database by executing a MySQL 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.

{{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|[[File:BackingUp Tip1CORRECT.pngBackup IMSMA Data|Backup IMSMA Data]]|border[[Scheduling Backup|captionScheduling Backup of IMSMA database]]}} 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.}} ===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. ===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.

Information managers ===Maps===__NOEDITSECTION__{{IMSMANG}} map files can augment the IMSMANG Backup capability with other scheduled backups using MySQL Administration tools, for example, be loaded on a per-client basis and build daily or weekly routines that back up the database automatically. These backups work similarly to stored in {{IMSMANG }} Backup; however, any backup made outside of IMSMANG will have providing an easy way to be restored manuallyshare maps between clients. Even so, regularly scheduled backups are an excellent component of a backup strategyIn Map Data is also the [[Customise Sub-Themes | sub-theme]] assignments included.

[[File:BackingUp Tip2===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.png|border|caption]]

===AttachmentsTranslations===__NOEDITSECTION__{{IMSMANG }} stores attachments on translations of the server file system separate from application in several places. Translations and localisations of data elements are stored in the {{IMSMANG }} databaseand are backed up with the database backup. The . Because of properties files used to translate the {{IMSMANG}} interface are stored externally to the size of some attachmentsdatabase, it may not but they can be beneficial or necessary added to back up the attachments each time. {{IMSMANG }} Backup provides as an option. If changes are made to the option .properties files, it is recommended to exclude attachments when performing back them up after each change as well as each time a full backupis made.

For regular, complete backups, it is recommended to include attachments. But, if ==Other Backup Considerations==__NOEDITSECTION__While {{IMSMANG}} Backup backs up all of the files used in the size standard configuration of a backup file is a concern{{IMSMANG}}, 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 there are other files that should also be used with cautionbacked up and/or carefully documented.

===Backing Up Other IMSMA^NG Information===In addition to the IMSMANG database * client and attachments stored on the server, IMSMANG Backup allows users to back up certain '''settings''' including memory settings from the IMSMANG client. These include: * GIS database C:\IMSMAng\server\gis\maps\imsma.mxd (.mdb fileif customized)* the background map (s) source files ('''not''' only the .mxd, etcfile)* field report template local projection files(.prj)* iReport template filesC:\IMSMAng\migration\conf\migration.properties and any import scripts* translation .properties files[[Language and Translations#Data language|fallback fonts]] (C:\IMSMAng\java\lib\fonts\fallback) * ODBC configurations====GIS Dataabase====* External toolsWhile : External reporting tools and other add-ons are not backed up by {{IMSMANG stores all coordinate data in the MySQL database }} and information managers should ensure that is these external tools are 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 somanually.

Because ==IMSMA Restore==__NOEDITSECTION__{{Warning| {{IMSMANG}} Restore replaces all data in the geodatabase is built on a per-client basis, it is also recommended {{IMSMANG}} database and copy over existing files. Prior to launch restoring the client to fully update the geodatabase prior to backing it {{IMSMANG}} database, information managers should ensure that all necessary data has been backed up. After it is backed up, the geodatabase can {{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 transferred manually restored using {{IMSMANG}} Restore. {{IMSMANG}} Restore allows users to other freshly installed clients determine which components of an {{IMSMANG}} Backup to shorten restore. The components available depend on the time required to build options that were selected during backup. Each option behaves slightly differently depending on whether the geodatabase during system launchrestore is occurring on a server or a client.

====Maps=Restore on the Server===__NOEDITSECTION__IMSMA<sup>NG<In a client/sup> map files server environment, the {{IMSMANG}} database can be loaded 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 perstand-client basis alone machine) restores the {{IMSMANG}} database and stored the available attachments to the server, replacing any existing data in IMSMA^NG Backupthe {{IMSMANG}} database. When a restore is complete, providing an easy way to share maps between clients{{IMSMANG}} closes and must be restarted.

[[File:Map Tip1CORRECT{{note| In a client/server environment, it is recommended to stop the server prior to restoring the database to ensure all clients are disconnected.png|border|caption]]}}