PernixData Backup Best Practices - 1. Client based backups

The four different backups methods get explained in the following PernixData FVP Backup Best Practices series. We start with the first one which explains client based backups.

To understand backups it is important to understand what kind of backups are possible in a VMware environment and specifically how they interact and work well with PernixData FVP. A good first overview gives the official VMware documentation.

With a client based backups, a backup client / agent of a given backup vendor is installed within the VM. The communication happens between the backup server and the client installed within the Operating System. This way of doing backups was the historically initial method of doing backups. There are no specific dependencies on storage and/or if the Operating System is running within a Virtual Machine or on a physical server for these type of backups. The backup method usually does not involve any kind of specific snapshot integration either.

Figure 1: LAN based Client Backup

1. Backup triggers the backup to the remote OS through the Local Area Network (LAN) using the vendor's backup client software.
2. In certain cases the Backup Server uses Operating System mechanisms to make the data it backs up application and/or OS consistent. This could be a client integration software for e.g. SQL, Exchange using VSS under Windows.
3. Client reads the data from the datastore
4. Data is transferred to the Backup Server and saved on a given device e.g. a Tape Library, Disk, cloud etc.

The clear benefit of using this generic backup method is:

• simplicity of implementation/operation
• applicable irrespective of the system being a VM or physical server
• application - consistent backups

The downside is that it does not leverage any of the advanced and efficient options that the virtualization technology can provide.

From the FVP perspective as described previously there will be a plethora of False Writes when doing a Client Based Backup. While doing these False Writes, the  Acceleration Media will be filled up. In FVP terminology, this is referred to as Cache Pollution (please follow this article from Frank Denneman) which happens within the storage system as well, irrespective of whether  FVP is in the I/O path or not. The only difference is that FVP posses the mechanisms and features to change the behaviour. Since PernixData FVP 2.5 there is a way to suspend and resume I/O via PowerShell when these kind of backups are happening to preserve the hot data in the acceleration media where a VM really benefits from. There are three different options to suspend the I/O:

Suspend/Resume-PrnxReadDataPopulation: Use this cmdlet if you want to suspend false write operations by FVP for this particular virtual machine.

Suspend/Resume-PrnxWriteDataPopulation: Use this cmdlet if you only want to suspend tue write operations for the virtual machine. True writes typically occur when a virtual machine is configured in Write Back mode.

Suspend/Resume-PrnxReadWriteDataPopulation: Use this cmdlet if you want to suspend both true and false-write operations for the virtual machine.

Here are the steps to put a VM into Suspend Mode:

• Start PowerShell (recommended as Administrator)

• PS C:\Windows\system32> select (with older versions of PowerShell needed to get the correct output in later queries)
• PS C:\Windows\system32> import-module prnxcli
• PS C:\Windows\system32> connect-prnxserver <FVP_ManagementServer> -UserName <Domain>\<Username> -Password <Password> (alternatively you can just do connect-prnxserver plus the servername and you get asked for the credentials)

• PS C:\Windows\system32> Suspend-PrnxReadDataPopulation|Suspend-PrnxWriteDataPopulation|Suspend-PrnxReadWriteDataPopulation <VM>

• PS C:\Windows\system32> Resume-PrnxReadDataPopulation|Resume-PrnxWriteDataPopulation|Resume-PrnxReadWriteDataPopulation <VM>

• PS C:\Windows\system32> Get-PrnxObject -Name <VM> | Format-List effectivePolicy (effectivePolicy : <DefinedPolicy>)