...
# On the command line, change to the backup directory:
{code}
cd /usr/local/groundwork/core/monarch/backup
{code}
# Look for your backup directory by date. The directories are named for the date of the backup, for example, August 10, 2010 at 09:05_04 am would be:
{code}
2010-08-10_09-05-04
{code}
{note:title=Note}
The way configurations are backed up affords you the chance to back up _before_ you commit. This means that whatever changes you were _about_ to make are what is backed up. If you want to revert your most recent changes, you have to restore from one backup before the date of the changes you wish to revert.
{note}
# cd to the directory containing the backup you want to restore. You will see a file in this directory named "monarch-<date and time stamp>.sql, for example:
{code}
monarch-2010-08-10_09-05-04.sql
{code}
# To restore, for example, the monarch-2010-08-10_09-05-04.sql file, type:
{code}
source /usr/local/groundwork/scripts/setenv.sh
mysql -umonarch -pgwrk monarch < monarch-2010-08-10_09-05-04.sql
{code}
# You will now have the configuration from the backup made August 10, 2010, at 09:05:04am loaded in the configuration database. It will not be active until you commit the configuration with the user interface using Configuration -> Control -> Commit.
!commit.jpg|border=1!
h3. Ok, so what if I want to restore a backup I made with an older version of GroundWork?
GroundWork versions often contain changes to the data schema for the configuration database. This means that the backups you made on older versions *can't* be used on the later versions *unless* you migrate them.
Fortunately, the migration is easy. Follow the procedure above, until you have the backup restore, but have not re-Committed the changes. At the command line, type:
{code}
/usr/local/groundwork/core/migration/migrate-monarch.pl
{code}
You will see the follwoing messages on the screen:
{noformat}
# /usr/local/groundwork/core/migration/migrate-monarch.pl
Checking tables ...
Update complete.
{noformat}
If you forget this step, you will probably have issues using the Configuration application, since the code will be expecting the updated database schema. Also, there have been some changes to the way performance graphs are processed, so the migration takes the standard configuration and updates it. If you have a non-standard configuration for performance data processing, it is left alone.
|
E-mail
