The Father, the Son and the Grandfather: A Basic Backup Strategy

If you’re the person in charge of a ProcessMaker server, you must ensure a backup and recovery strategy is in place to protect existing information in case of data loss. In this article we will provide a basic backup plan, intended to be configured on a Linux server, combining tar, crontab, and mysqldump utilities. For the recovery part, take a look at this post. The hardware discussion is out of the scope of this article.

Backup Rotation Scheme

Once you have chosen the appropriate hardware and software solutions to address your backup needs, you must define a backup rotation scheme. This decision is quite important, as it will provide the answers to the following questions:

  1. When was the last available backup created?
  2. When was the oldest available backup created?

Trivial as these questions may seem, they typically arise in the catastrophic event of data loss or corruption. With an appropriate backup rotation scheme in place, you should be ready to provide fast and reliable answers to both of them.

The most common rotation schemes are: FIFO method, Grandfather-father-son backup, and Towers of Hanoi method. (For a detailed discussion we suggest this excellent Wikipedia topic.) As you probably inferred from this article’s title, we will apply the Grandfather-father-son strategy, with this configuration:

  • Grandfather: yearly backup.
  • Father: monthly backup. This set is composed of twelve backups, one for every month.
  • Son: weekly backup. This set is composed of five backups, one for every working day of the week.

This sums up to 18 backup sets for an entire year (add one for every additional year), providing backups as recent as the last working day, or as old as one year ago.

So, how do you actually configure this backup strategy? You will need a bash script and a crontab entry. Let’s start with the script.

The backup script: backup.sh

Create a bash script, named backup.sh, and turn on the execution attribute. Assuming you’re logged in as root user, and your scripts are in home folder:
touch /root/backup.sh
chmod u+x /root/backup.sh

Then copy the following lines to the script:

#!/bin/sh
# Created by:     Alex Saavedra
# Date created:   2011-05-11
# Last modified:  2010-05-11
# Purpose:        ProcessMaker backup.
# Change log:
# Syntax:  
#    backup.sh <periodicity> <period>
# Parameters:
#     <periodicity> = weekly, monthly, yearly
#     <period>      = specific week day, month or year

# Help
HELP="The backup is invoked as follows:n"
HELP=$HELP"  /root/backup.sh <type> <periodicity>n"
HELP=$HELP"where:n"
HELP=$HELP"  periodicity = weekly, monthly, yearlyn"
HELP=$HELP"  period      = specific day, month or yearn"

# Destination backup file construct.
DST=/path/to/backups/processmaker_$1_$2.tgz
# Now DST is similar to "/path/to/backups/processmaker_weekly_03.tgz"

# SQL dump file name construct
SQL=/tmp/processmaker_$1_$2.sql

if [ -z "$2" ]
  then
    # In recent distributions you may not need the -e parameter.
    echo -e $HELP
    exit 1
fi

# timestamp logging
echo "Starting date and time: $(date)"

# database dump: wf_workflow, rb_workflow and rp_workflow are ProcessMaker databases.
mysqldump --opt --add-drop-table -B -u root -psecret --result-file=$SQL wf_workflow rb_workflow rp_workflow 
# use the following line if you prefer a backup of all databases:
#mysqldump --opt --add-drop-table --all-databases -u root -psecret --result-file=$SQL 

# Source file construct
SRC=/opt/processmaker/ $SQL

# actual backup
tar -cvzf $DST $SRC > /dev/null

echo "Finished date and time: $(date)"
echo "The backup file $DST was successfully created."
ls -lh $DST

You may have noticed that a few parameters need to be changed, such as backup and ProcessMaker paths, MySQL credentials, and actual databases. You should manually test this script, for example:

./backup.sh weekly 4

The output should be similar to the following:

Starting date and time: Thu May 12 10:45:10 EST 2011
tar: Removing leading `/' from member names
Finished date and time: Thu May 12 10:45:16 EST 2011
The backup file /mnt/backups/processmaker_weekly_4.tgz was successfully created.
-rw-r--r-- 1 root root 14M 2011-05-12 10:45 /mnt/backups/processmaker_weekly_4.tgz

In case of trouble check the following:

  1. Did you provide the proper paths?
  2. Did you verify MySQL credentials?
  3. Are your databases properly referenced?

The Son: crontab Entry for the Weekly Backup

Now that we know that the above script is working (we do, right?), we will start configuring the automated weekly backup. A backup will be created for every working day — Monday to Friday, at 2:00 AM. In other words, the Monday backup will be created every Tuesday, at 2:00 AM, and so on. The easiest way to make a cron entry is with crontab utility:

crontab -e

In the interface, add the following lines (actually, only the last one is required, but it’s good practice to document for later review):

# 2011-05-12. Weekly ProcessMaker backup.
#m  h  dom mon   dow   command
0   2   *   *    2-6   /root/backup.sh weekly $(date -d "-1 day" +%w)

If you don’t know what these fields mean, the legend is: m=minute, h=hour, dom=day of month, mon=month, dow=day of week. So the crontab entry means:

Execute the command /root/backup.sh weekly $(date -d "-1 day" +%w) from Tuesday (day 2) to Saturday (day 6), at 2:00 AM

So what’s the meaning of $(date -d "-1 day" +%w)? We’re just asking for the number corresponding to the previous day of the week. The corresponding numbers are: 0=Sunday, 1=Monday, and so on. One week later, your backup files will have the following names:

processmaker_weekly_1.tgz
processmaker_weekly_2.tgz
processmaker_weekly_3.tgz
processmaker_weekly_4.tgz
processmaker_weekly_5.tgz

Now we need to configure the remaining backups.

The Father and the Grandfather: crontab Entries for Monthly and Yearly Backups

The monthly backup will be scheduled to occur the first day of the next month, at 1:00 AM. In other words, the May backup will be created on June 1st, at 1:00 AM.

# 2011-05-12. Monthly ProcessMaker backup.
#m  h  dom mon   dow   command
00  1   1   *     *    /root/backup.sh monthly $(date -d "-1 day" +%m)

Similarly, the yearly backup will be scheduled to happen every New Year’s Day, at 3:00 AM (while you’re partying):

# 2011-05-12. Yearly ProcessMaker backup.
#m  h  dom mon   dow   command
00  3   1   1     *    /root/backup.sh monthly $(date -d "-1 day" +%Y)

A year later, you should have a backup set similar to the following list:

processmaker_monthly_01.tgz
processmaker_monthly_02.tgz
processmaker_monthly_03.tgz
processmaker_monthly_04.tgz
processmaker_monthly_05.tgz
processmaker_monthly_06.tgz
processmaker_monthly_07.tgz
processmaker_monthly_08.tgz
processmaker_monthly_09.tgz
processmaker_monthly_10.tgz
processmaker_monthly_11.tgz
processmaker_monthly_12.tgz
processmaker_weekly_1.tgz
processmaker_weekly_2.tgz
processmaker_weekly_3.tgz
processmaker_weekly_4.tgz
processmaker_weekly_5.tgz
processmaker_yearly_2011.tgz

Congratulations! If you followed these steps, now you have a basic backup strategy up and running.

About This Author

Customer & Partner Support Manager for Colosa Inc. and ProcessMaker.

Comments are closed