Quiesce a Linux Progress Database with Veeam Backup

[fullermetric]

On Windows, Veeam can do application consistent backups through the Veeam Microsoft Volume Shadow Copy Services (VSS) integration for VSS aware applications. Unfortunately Linux does not have a system like Microsoft Volume Shadow Copy Services (VSS) that allows applications to be made application consistent by backup applications like VMware vDR or Veeam Backup.
A simple workaround is to leverage VMware tools ability to call custom freeze/thaw scripts during a quiesced snapshot to enable customers to do the required application quiescence.
The example below is for a Progress database, for other applications you need to know the application specific command to quiesce the application and modify the scripts below appropriately.

1. Make sure VMware Tools are installed in the Linux VM
VMware Tools MUST be installed and should be up to date in your Linux Virtual Machine.

2. On the VM setup change the MAC address configuration to Manual instead of Automatic. If you leave it in automatic mode on a restore the Mac address gets changed and a second network profile gets created on the Linux machine that will use DHCP at startup. The result of this is that the progress database startup will fail and the system most likely will hang when booting up.
Progress requires the /etc/hosts file to have the correct IP address entries and will fail to start if there are any errors there. (See troubleshooting at end if this happens)
*** When you change from automatic to manual make sure you then update the Linux network setup***

3. To quiesce a Progress/OpenEdge database we will execute a –proquiet- command to create a transaction consistent backup without downtime. The time to create the VM snapshot is surprisingly quite quick.
We create two scripts, one to quiet the databases and one to get it going again after the snapshot that Vmware tools runs if they exist. For Linux the scripts are /usr/sbin/pre-freeze-script and /usr/sbin/post-thaw-script (Vmware 4.1)

We need a way to check if the database is running. The easiest way it to look for the (youerdatabasebasename).lk file, if the database is running then the file exists.
We also have to make sure not to get any errors from the script otherwise the backup will fail and the database may stay frozen, for this purpose we pipe any potential error messages to null.
 
Script Examples

Code: Select all

/usr/sbin/pre-freeze-script 
if [ -f /(dbpath1)/(dbname1).lk ];
 then proquiet  /(dbpath1)/(dbname1) enable >/dev/null
fi
if [ -f /(dbpath2)/(dbname2).lk ];
 then proquiet  /(dbpath2)/(dbname2) enable >/dev/null
fi
/usr/sbin/post-thaw-script
if [ -f /(dbpath1)/(dbname1).lk ];
 then proquiet  /(dbpath1)/(dbname1) disable >/dev/null
fi
if [ -f /(dbpath2)/(dbname2).lk ];
 then proquiet  /(dbpath2)/(dbname2) disable >/dev/null
fi

4. Now make sure the scripts are executable, chmod 700
Test the scripts after you have created to make sure they run without problems and the db’s are suspended

5. The Veeam backup job setting "Enable VMware tools quiescence" under "Advanced Settings" -> "Advanced" needs to be checked
That is pretty well all that is needed.

Restoring the System
The best way that worked for us is to restore the VM files to a datastore of your choice but not to register the VM to the Vcenter server. If you want to do a full restore un-register the VM that you want to replace first. After the restore registering the system and selecting that you moved the VM. The system should boot up fine with the DB intact.
Boot up issues.

We have found that booting up a backed up system in a isolated network can be a problem probably due to the network IP address change to DHCP. The system still comes up but may hang at 3 possible positions. This is where we have had the problems.

CUPS – We are using HP printers, this seems to hang
Sendmail
Starting Progress database

If you have this problem you will have to modify the system to change the IP and MAC address.
1. Change the MAC address of the restored system to avoid a conflict.
2. Move the VM to another network so you can modify the setup. (Safety first)
3. Boot the system and do an interactive startup, From the VM console at the initial boot up option you can select “I” to do an interactive startup. Using this option you can bypass these above services and get the system up.
4. Change you network setting to the new IP address you wan to use.
5. Edit your /etc/hosts file to make sure it has the correct IP addresses.
In GUI side you can do this in the network setup also.
Should look like this.
127.0.0.1 localhost
192.168.1.x. server.domain.ext server <- your IP address
We have had an instance where the file looked fine but after deleting it and creating a new one the problem went away.
Good luck, I hoped this helped.

[pauliem]

This is a really useful post, we are about to switch our progress system from physical SCO Unix 5.0.7 to Linux virtual machines and I will be able to make use of your script below.

I know it is not relevant, but I would be interested to know:

What distribution and version of Linux are you using?
What version of progress are you running?

I've had the problem you describe with mac addresses before and although not quite the same situation that you are having have used "macchanger" in Linux to restore the old mac address, regardless of what VMWare has it set to.

Obviously you posted this a long time ago, so if you are still around be interested to hear how your progress/Veeam implementation has gone overall.