Catastrophe Simulation and Data Recovery Plan

By | June 1, 2011 | Uncategorized

You’re probably reading this article because you already have a backup strategy in place, and a running schedule of automated backups. To ensure all pieces of your backup and recovery plan are in place, you must execute scheduled recovery simulations. If you only execute the backup part, without ever simulating the recovery part, well, you could be exposed to some unhappy surprises in the future. Ideally, your recovery plan should be tested on a monthly basis. In this article we will explain the detailed manual procedure to conduct such a recovery simulation.

The key points to keep in mind in a ProcessMaker recovery simulation procedure are the following:

  1. Testing server. Always conduct the recovery simulation on a testing server.
  2. Underlying platform versions. Your testing server must match as close as possible your production environment’s configuration. In particular, pay close attention to Apache, PHP, and MySQL major versions compatibility.
  3. Database server. If your production database resides on a separate server, your backup set is almost certainly pointing to your production database server. You must change the database configuration files in order to point to your testing database server. Such files are typically located in /opt/processmaker/shared/sites/<your workspace name>/db.php. If you don’t change them, you could overwrite production data.

So you must restore a working ProcessMaker server environment to some point in the past. The following section assumes the following:

  1. You want to restore the backup corresponding to last Monday. Thus, the backup file you’re looking for is /path/to/backups/processmaker_weekly_1.tgz
  2. You’re logged in as root user
  3. Your ProcessMaker and database servers are the same — localhost. Consequently, the SQL dump will be restored in the same server.

Follow these steps in order to restore a working ProcessMaker environment:

cd /
tar -xvzf /path/to/backups/processmaker_weekly_1.tgz
mysql -u root -psecret -e /tmp/processmaker_weekly_1.sql

Now, remember your configuration files are pointing to the production database server. You must edit the database credentials files for every workspace, which are located in /opt/processmaker/shared/sites/<your workspace name>/db.php and change the following directives:

define ('DB_HOST', 'localhost:3306' );
define ('DB_RBAC_HOST', 'localhost:3306' );
define ('DB_REPORT_HOST', 'localhost:3306' );

IMPORTANT! Repeat this procedure for every workspace.

Last thing: for performance reasons, ProcessMaker maintains a cache directory. You must clear it manually, just to make sure that it will not interfere with testing environment configuration:

cd /opt/processmaker/shared/compiled
rm -fr .

That’s pretty much it. You should now be able to access your testing ProcessMaker server. Enjoy!

«
»

Leave a comment