2

We have some very old file-based databases (multi-user, but not Server-based) that are running on some VMs on an VMWare ESXi.

Setup

HyperVisor

The ESXi is running ESXi version 5.1.0

Virtual Machines

The VM with Visual Fox Pro is running Windows Server 2003 Standard Edition version 5.2.3790 Service Pack 2 Build 3790 32-bit.

The VM with MS Access is running Windows Server 2003 Enterprise Edition 5.2.3790 Service Pack 2 Build 3790 32-bit.

Both VMs have VMware Tools 9.0.0, build-782409 installed...

File-based Non-quiescable File-based Databases

The file-based databases are Visual Fox Pro 9.0757 (free table directory of .dbf and .cdx files) and an MS Access 2003 Database backend .mdb.

Backup Method

The Esxi is backed up using Veeam 8.

The Veeam Backup and Replication is version 8.0.0.917 with Patch 1 installed and backs up to a NAS on a SAN with iSCSI (if it matters).

And it is a Reverse Incremental Backup which takes a snapshot of the VM during the backup.

Initially this Reverse Incremental Backup method takes a full backup and stores it in a .vbk file, and with each additional backup it stores the changes in a .vrb file.

The following settings have been applied for the backup:

Advanced settings dialog with the vSphere tab selected, and Enable VMware Tools quiescence unchecked, Use changed block tracking data (recommended) checked, and Enable Change Block Tracking for all protected VMs automatically, checked.

Edit Backup Job dialog, with Guest Processing selected in the left hand pane, Enable application-aware processing is checked, and Enable guest file system indexing is unchecked

Quiescable Databases and VSS

Microsoft Volume Shadow Copy Service (VSS) fires events to applications (notifies applications) that may be running on a server, such as SQL Server, so that any pending SQL transactions that may be running are completed before the backup, and so that all incoming operations are stopped before taking a backup of the files that store the database, this is known as the verb, quiesce. This is the reason for using a server process to house your database instead of just using files and a program that connects to them, a backup of the files can be done quickly and without locking everyone out.

Backing up File Based Databases

So what happens you backup your database and it doesn't have the ability to complete existing transactions and reject new ones? If users/processes are not forced to close the database file, and prevented from accessing them, when the backup copies are made, the backup copies are unusable. And it will not even tell you that this has occurred...you are doomed to find out the backup doesn't work later, when you need to restore it.

ewwhite
  • 197,159
  • 92
  • 443
  • 809
leeand00
  • 4,869
  • 15
  • 69
  • 110

2 Answers2

4

Without application-level quiescing, your backups would be crash-consistent. The recovered VM would look like it had suddenly had its power cut off...

For your purposes, it's important to understand how your application deals with sudden power loss or an unplanned hard reset. If it can recover gracefully, then the way Veeam backups are running should suffice. If not, you may want to have a process that works around the user activity. You only need to have users locked out of the system for the duration of the Veeam snapshot.

ewwhite
  • 197,159
  • 92
  • 443
  • 809
2

In order to avoid such nightmare, you should use pre-freeze/post-thaw scripts to setup for job which backs this VM up. If needed, check related topics in Veeam forum to ask others about their experience and scripts' examples.

  • Ah yes thank you Andrew! And this happens with just a snapshot right? What happens when a full backup is taken? Do the same scripts get executed? – leeand00 Feb 11 '15 at 18:11
  • 1
    Pre-freeze scripts are executed in prior to backup, just before snapshot creation moment, to make sure that data on hard disk is consistent and there is no ongoing operations (similar to VSS). Then snapshot is taken and backup starts. Once it finished post-thaw script is being run to make sure that application(s) is back to life and can continue working. – Andrew Zhelezko Feb 12 '15 at 08:33