Version Differences for Backups of AnthillPro

* MySQL uses [http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html mysqldump], which there is additional examples on how to use it, [http://www.thegeekstuff.com/2008/09/backup-and-restore-mysql-database-using-mysqldump/ here].

* Oracle can use [http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php expdp], and we have some internal notes on how to use it, [http://wiki.urbancode.com/AnthillPro/Comments:Database_Permissions here].

+

== Filesystem ==

+

<font size=3>'''KEEP IN MIND THAT ALL THE STEPS LISTED ABOVE ARE ONLY FOR CHANGING THE DATABASE STATES'''</font>. In actuality, no other files are backed up, which leaves your previous build artifacts, codestation artifacts, job logs, test results, etc. at risk. To negate this, it is recommended to backup the entire anthillpro directory filesystem as well so that the filesystem can be restored to the same timeframe as the server.

+

Unfortunately, there are some cases that warrant a server not being able to have its entire filesystem backed up. The order of precedence on how to continue is thus:

+

# Attempt to make a backup of the entire server filesystem. If this is not an option, see #2.

+

# Attempt to backup any customized files (such as custom startup scripts in the '''bin''' directory, changed libraries in the '''lib''' directory, etc.) in addition to the '''var''' directory. If this is not an option, see #3.

+

# Attempt to back up the entire '''var''' directory. If this is not an option, see #4.

+

# Attempt to back up the most important parts of the '''var''' directory. This includes the following:

+

## '''artifacts''' - Where your build artifacts live for each buildlife.

+

## '''codestation''' - Where your codestation project artifacts live for each codestation buildlife.

+

## '''published''' - Where your published reports are stored.

+

## '''logs''' - Where your server logs, in addition to job logs, lie.

+

Make sure that whichever method you choose, you have an archive of it, and be sure to '''TEST THE ARCHIVE''' after creation to verify its integrity. For example, if backing up the entire server filesystem using 7-zip, one's command might look like thus:

+

<pre>7z a -t7z -m0=LZMA2 -mx9 -md256m -ms=on -mmt2 %ARCHIVE_DIRECTORY%\backup.7z %SERVER_HOME%</pre>

+

=== Filesystem Restoration ===

+

It would be best to rename the old server installation (as to not lose the current file structure/contents if the unarchive should go awry) first before unarchiving a backup, but all you need to do is '''unarchive the backup into the %SERVER_HOME% directory'''. Then, your server's filesystem should be back in the state the archive was.

+

=== Database Restoration ===

+

'''Please consult your database vendor's documentation for restoring databases'''.

 * MySQL uses [http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html mysqldump], which there is additional examples on how to use it, [http://www.thegeekstuff.com/2008/09/backup-and-restore-mysql-database-using-mysqldump/ here].
 * Oracle can use [http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php expdp], and we have some internal notes on how to use it, [http://wiki.urbancode.com/AnthillPro/Comments:Database_Permissions here].
                 == Filesystem ==
                 <font size=3>'''KEEP IN MIND THAT ALL THE STEPS LISTED ABOVE ARE ONLY FOR CHANGING THE DATABASE STATES'''</font>.  In actuality, no other files are backed up, which leaves your previous build artifacts, codestation artifacts, job logs, test results, etc. at risk.  To negate this, it is recommended to backup the entire anthillpro directory filesystem as well so that the filesystem can be restored to the same timeframe as the server.
                 Unfortunately, there are some cases that warrant a server not being able to have its entire filesystem backed up.  The order of precedence on how to continue is thus:
                 # Attempt to make a backup of the entire server filesystem.  If this is not an option, see #2.
                 # Attempt to backup any customized files (such as custom startup scripts in the '''bin''' directory, changed libraries in the '''lib''' directory, etc.) in addition to the '''var''' directory.  If this is not an option, see #3.
                 # Attempt to back up the entire '''var''' directory.  If this is not an option, see #4.
                 # Attempt to back up the most important parts of the '''var''' directory.  This includes the following:
                 ## '''artifacts''' - Where your build artifacts live for each buildlife.
                 ## '''codestation''' - Where your codestation project artifacts live for each codestation buildlife.
                 ## '''published''' - Where your published reports are stored.
                 ## '''logs''' - Where your server logs, in addition to job logs, lie.
                 Make sure that whichever method you choose, you have an archive of it, and be sure to '''TEST THE ARCHIVE''' after creation to verify its integrity.  For example, if backing up the entire server filesystem using 7-zip, one's command might look like thus:
                 <pre>7z a -t7z -m0=LZMA2 -mx9 -md256m -ms=on -mmt2 %ARCHIVE_DIRECTORY%\backup.7z %SERVER_HOME%</pre>
                 === Filesystem Restoration ===
                 It would be best to rename the old server installation (as to not lose the current file structure/contents if the unarchive should go awry) first before unarchiving a backup, but all you need to do is '''unarchive the backup into the %SERVER_HOME% directory'''.  Then, your server's filesystem should be back in the state the archive was.
                 === Database Restoration ===
                 '''Please consult your database vendor's documentation for restoring databases'''.