/usr/share/doc/gnumed/user-manual/Gnumed/GmManualDatabaseBackupRestore.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en_US" lang="en_US">
<head>
	<title> GmManualDatabaseBackupRestore &lt; Gnumed &lt; Foswiki</title>
		  
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta name="robots" content="noindex" /> <link rel="alternate" type="application/rss+xml" title="RSS Feed" href="WebRss.html" />
	<link rel="icon" href="../rsrc/System/ProjectLogos/favicon.ico" type="image/x-icon" /> <link rel="shortcut icon" href="../rsrc/System/ProjectLogos/favicon.ico" type="image/x-icon" />
	<link rel="alternate" href="http://wiki.gnumed.de/bin/edit/Gnumed/GmManualDatabaseBackupRestore?t=1391005511" type="application/x-wiki" title="edit GmManualDatabaseBackupRestore" />
	<meta name="description" content="GmManualDatabaseBackupRestore" />
	 <!--[if IE]></base><![endif]-->
	
	<style type="text/css" media="all">
@import url('../rsrc/System/SkinTemplates/base.css');
</style>
<style type="text/css" media="all">
@import url('../rsrc/System/SkinTemplates/default.css');
</style>
<!--[if IE]><style type="text/css" media="screen">
pre {
	overflow-x:auto;
	padding-bottom:expression(this.scrollWidth > this.offsetWidth ? 16 : 0);
}
</style>
<![endif]-->

<meta name="foswiki.PUBURL" content="http://wiki.gnumed.de/pub" /> <!-- PUBURL -->
<meta name="foswiki.PUBURLPATH" content="/pub" /> <!-- PUBURLPATH -->
<meta name="foswiki.SCRIPTSUFFIX" content="" /> <!-- SCRIPTSUFFIX -->
<meta name="foswiki.SCRIPTURL" content="http://wiki.gnumed.de/bin" /> <!-- SCRIPTURL -->
<meta name="foswiki.SCRIPTURLPATH" content="/bin" /> <!-- SCRIPTURLPATH -->
<meta name="foswiki.SERVERTIME" content="29%20Jan%202014%20-%2015:25" /> <!-- SERVERTIME -->
<meta name="foswiki.SKIN" content="twikinet%2c%20pattern" /> <!-- SKIN -->
<meta name="foswiki.SYSTEMWEB" content="System" /> <!-- SYSTEMWEB -->
<meta name="foswiki.TOPIC" content="GmManualDatabaseBackupRestore" /> <!-- TOPIC -->
<meta name="foswiki.USERNAME" content="KarstenHilbert" /> <!-- USERNAME -->
<meta name="foswiki.USERSWEB" content="Main" /> <!-- USERSWEB -->
<meta name="foswiki.WEB" content="Gnumed" /> <!-- WEB -->
<meta name="foswiki.WIKINAME" content="KarstenHilbert" /> <!-- WIKINAME -->
<meta name="foswiki.WIKIUSERNAME" content="Main.KarstenHilbert" /> <!-- WIKIUSERNAME -->
<meta name="foswiki.NAMEFILTER" content="%5b%5cs%5c*%3f~%5e%5c%24%40%25%60%22'%26%3b%7c%3c%3e%5c%5b%5c%5d%23%5cx00-%5cx1f%5d" /> <!-- NAMEFILTER --><!--JQUERYPLUGIN::FOSWIKI::META-->
<script type='text/javascript' src='../rsrc/System/JQueryPlugin/jquery-1.4.3.js'></script><!--JQUERYPLUGIN-->
<script type='text/javascript' src='../rsrc/System/JQueryPlugin/plugins/livequery/jquery.livequery.js'></script><!--JQUERYPLUGIN::LIVEQUERY-->
<script type='text/javascript' src='../rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js'></script><!--JQUERYPLUGIN::FOSWIKI-->
<script type='text/javascript' src='../rsrc/System/JSTreeContrib/jquery.jstree.js'></script><!--JQUERYPLUGIN::JSTREE-->
</head>
<body class=""><div class="foswikiPage">
<a name="PageTop"></a> 
<p></p>
<p></p>
<h1><a name="Database_Backup_and_Restore_procedures"></a>  Database Backup and Restore procedures </h1>
<p></p>
GNUmed takes the utmost care to safeguard your medical data during upgrade and operation:
<p></p> <ul>
<li> upgrades are done non-destructively by cloning databases
</li> <li> a slew of foreign keys, triggers, rules and constraints ensures data integrity
</li> <li> most database access is read-only
</li> <li> full transaction semantics are used (serializable)
</li> <li> conflicting concurrent data modifications are detected
</li> <li> data modifications are audit logged
</li></ul> 
<p></p>
However, disaster strikes when it is least expected and there is a whole world of trouble GNUmed cannot do anything about. There are a few rules prudent to follow:
<p></p> <ul>
<li> use <a href="http://en.wikipedia.org/wiki/RAID" target="_top">RAID</a> for database drives
</li> <li> use <a href="http://en.wikipedia.org/wiki/S.M.A.R.T." target="_top">S.M.A.R.T.</a> monitoring on database drives
</li> <li> <a href="http://en.wikipedia.org/wiki/Replication_(computer_science)" target="_top">re</a><a href="http://rsync.samba.org/" target="_top">pli</a><a href="http://slony.info/" target="_top">cate</a> to a backup machine
</li> <li> consider <a href="http://en.wikipedia.org/wiki/Disk_cloning" target="_top">cloning</a> the physical machine into a virtual machine (e.g. with <a href="http://www.vmware.com/products/converter/get.html" target="_top">VMware Converter</a>)
</li> <li> take <a href="http://en.wikipedia.org/wiki/Backup" target="_top">backups</a>
</li> <li> <a href="http://en.wikipedia.org/wiki/Cron" target="_top">automate</a> taking backups
</li> <li> keep several generations of backups
</li> <li> keep duplicates of backups both on- and <a href="http://en.wikipedia.org/wiki/Rsync" target="_top">offsite</a>
</li> <li> <strong>Test</strong> the backups !
</li> <li> <strong>Test</strong> the restore procedures !
</li></ul> 
<p></p>
If you follow the above advice you have done quite a bit to be on the safe side. The <a href="http://www.postgresql.org/docs/8.3/static/admin.html" target="_top">PostgreSQL Manual</a> has excellent chapters on <a href="http://www.postgresql.org/docs/8.4/static/backup.html" target="_top">backup and restore</a> as well as <a href="http://www.postgresql.org/docs/8.4/static/high-availability.html" target="_top">replication and availability</a>. Be sure to read it.
<p></p>
GNUmed provides some scripts and configuration files which, under *nix, are ready for integration with cron/anacron. They can be found:
<p></p> <ul>
<li> in server releases, available <a href="http://www.gnumed.de/downloads/server/" target="_top">here</a>, where the scripts reside at the same level as the directory <code>bootstrap</code> and the .conf files reside in the subdirectory <code>/etc/gnumed</code> at the same level
</li> <li> in the GNUmed gitorious repository with the scripts at <a href="http://gitorious.org/gnumed/gnumed/trees/master/gnumed/gnumed/server" target="_top">this level</a> and the .conf files at <a href="http://gitorious.org/gnumed/gnumed/trees/master/gnumed/gnumed/client/etc/gnumed" target="_top">this level</a>.
</li></ul> 
<p></p>
The next sections provide an overview of the configuration and script files. For more information, consult the in-line comments within the respective files.
<p></p>
<h2><a name="Configuration_40.conf_41_files_setup"></a>  Configuration (.conf) files setup </h2>
<p></p>
The location and names of the .conf files need to be correctly-referenced in the dependent script files. By default, the scripts expect to find the .conf files in the directory <code>/etc/gnumed</code> with names <code>gnumed-backup.conf</code> and <code>gnumed-restore.conf</code>.
<p></p>
In addition, each .conf file contains a series of options which should nearly always be changed. These include <ul>
<li> some suitable name representing the praxis, which will be the <code>INSTANCE_OWNER</code>
</li> <li> where to eventually store the backup which, by default, is <code>BACKUP_DIR="${HOME}/.gnumed/backup/"</code> and which, if unchanged, will result in the backup being written into a directory owned by root. Under Mac OS 10.x this would be <code>/var/root/.gnumed/backup</code>
</li> <li> which database to backup e.g. <code>GM_DATABASE="gnumed_v15"</code>
</li> <li> the user/group the backup is eventually owned by <code>BACKUP_OWNER="$USER:$USER"</code>
</li> <li> more options, for example for offsiting and for using gnotary
</li></ul> 
<p></p>
<h2><a name="Script_40.sh_41_files_setup"></a>  Script (.sh) files setup </h2>
<p></p>
The scripts <code>gm-backup_database.sh</code> and <code>gm-restore_database.sh</code> can be run unchanged except for the appended Mac OS constraints.
<p></p>
Note also that when running the backup or restore manually &#8211; where you had not further configured pg_hba.conf to allow root to access the GNUmed database as "gm-dbo", and where you had not set up a .pgpass file &#8211; what works is to
<p></p> <ul>
<li> sudo -i to root
</li> <li> cd to the appropriate directory where the shell scripts are found
</li> <li> execute the script <code>sh gm-backup_database.sh</code>
</li> <li> provide the password for the postgres database user (twice) and the password for gm-dbo (twice)
</li> <li> take care whether any database newer than the database specified in your conf file should perhaps be the one that actually needs backing up. This will depend on whether you had since upgraded your production database or whether the newer versions represent purely tests of newer versions.
</li></ul> 
<p></p>
Mac OS constraints: <ul>
<li> on account of trouble in Mac OS to support the command line (or shell script) <code>su -c</code>, it is necessary under Mac OS to comment-out with <code>#</code> the backup script 'sanity check' which under linux can test for whether or not the database exists.
</li> <li> since Mac OS does not support -W (verify) Mac users should set VERIFY_TAR to an empty string "" in gnumed-backup.conf which will then do what is needed
</li></ul> 
<p></p>
Archival emails: <ul>
<li> an <a href="http://lists.gnu.org/archive/html/gnumed-devel/2008-10/msg00001.html" target="_top">here</a>
</li> <li> a <a href="http://lists.gnu.org/archive/html/gnumed-devel/2009-07/msg00371.html" target="_top">a more-recent (troubleshooting) email</a>.
</li></ul> 
<p></p>
<em>Additional arcane and rarely needed information can be found on</em> <a href="DatabaseBackupRestoreArchive.html"><em>this page</em></a>
<p></p>
<a name="TopicEnd"></a>
<p></p>
<p></p>
<p></p>
<p></p>
</div>
</body></html>
gnumed-doc 1.4.6+dfsg-1 / usr / share / doc / gnumed / user-manual / Gnumed / GmManualDatabaseBackupRestore.html
