Flushing cache to SAN before backups are initiated – Write-Back caching, Veeam Direct SAN access transport mode, and storage controller snapshots

This additional configuration in Veeam is only required if the below condition is true:

{[Veeam is configured to do SAN controller snapshots (and not VMware snapshots)] OR [Veeam is configured for ‘Direct SAN Access Transport Mode’]} AND [VirtuCache is in Write Back caching mode for one or more VMs].

If the above condition is true, then download the scripts from the link below.

Scripts to flush write cache to backend SAN appliance by moving VMs to Write-Through mode before backup starts and move VMs back to their original caching policy after backup process completes.

Reason for the Virtunet scripts for Veeam.

In Write-Back caching mode, VirtuCache cache writes to in-host SSD/RAM. Every few milliseconds a VirtuCache background job syncs the writes in the local cache media to the backend appliance. At any point in time, the local cache media will have some writes that are not on the backend SAN appliance. Now if Veeam initiates a storage controller snapshot or uses ‘Direct SAN Access Transport Mode’, these Veeam snapshots won’t capture the latest state of the LUN since some writes are still in the host cache. Now for Veeam to backup the most recent consistent state of the LUN, VirtuCache needs to flush all the writes from local cache media to the LUN before Veeam begins its backup process.

Also note that if [VirtuCache is configured in Write-Back caching mode] AND [Veeam is configured for ‘Virtual Appliance Transport Mode’ OR ‘Network Transport Mode’] AND [Veeam is taking VMware snapshots], then no additional configuration is required, since VirtuCache is in the storage IO path in this case and handles this operation seamlessly.

Steps to deploy scripts in Veeam.

Download the scripts from the link above. The first script is run before Veeam backup job starts and it moves the VMs to Write-Through mode, which flushes all writes in cache to the LUN . The second script is run after the backup job ends, and it moves the VMs back to their original caching policy.

First make sure you have the two *.bat files and two *.ps1 files.

These scripts call the VirtuCache 'quiesce' API that allows VMs to be transitioned to write-though policy and for those VMs to be transitioned back to their configured write-back policy, in a scripted fashion.

– before_backup.bat (batch file – It calls the before_backup.ps1 file)

– before_backup.ps1 (Powershell script containing the pre-backup processing logic)

– after_backup.bat    (batch file – It calls the after_backup.ps1 file)

– after_backup.ps1    (Powershell script containing the post-backup processing logic)

Instructions:

1) Transfer these scripts to the Windows VM/physical server on which Veeam is installed. Place the scripts in a folder, say C:\VirtuCache

2) Edit the before_backup.ps1 script as follows:

– specify the IP address of the vCenter server (in 'serverip' variable)

– specify the login credentials for the vCenter (in 'username' and 'password' variables)

– specify the IP address of the VirtuCache manager appliance and the name of the Datastores on which the VMs reside

e.g.
[void] $wc.UploadValues('https://10.0.0.73/datastore/store-simple-1/quiesce', $p)
[void] $wc.UploadValues('https://10.0.0.73/datastore/store-simple-2/quiesce', $p)

3) Similarly configure the settings in after_backup.ps1 script as well

4) Point these batch files in the Veeam configuration per the below screenshots. The before_backup.bat should run before Veeam backup starts. The after_backup.bat should run after Veeam backup ends.

 

 

 

 

 

 

 

Click ‘Advanced’ button.

 

 

 

 

 

 

 

 

 

Insert the after_backup.bat and before_backup.bat in the appropriate locations in the Veeam screen above.

Below is an example of the before_backup.ps1 and after_backup.ps1 scripts

In the scripts below 10.72.6.100 is vcenter IP with vcenter read-only userid and password. 10.72.6.132 is VirtuCache Manager VM IP

before_backup.ps1 file

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$p = New-Object System.Collections.Specialized.NameValueCollection

$p.Add('username','[email protected]')

$p.Add('password','vidanlogin$%^&')

$p.Add('serverip','10.72.6.100')

$wc = New-Object Net.WebClient

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 1/quiesce', $p)

[void] $wc.UploadValues('https:// 10.72.6.132/datastore/equallogic volume 2/quiesce', $p)

[void] $wc.UploadValues('https:// 10.72.6.132/datastore/equallogic volume 3/quiesce', $p)

[void] $wc.UploadValues('https:// 10.72.6.132/datastore/equallogic volume 4/quiesce', $p)

[void] $wc.UploadValues('https:// 10.72.6.132/datastore/equallogic volume 5/quiesce', $p)

[void] $wc.UploadValues('https:// 10.72.6.132/datastore/equallogic volume 6/quiesce', $p)

Start-Sleep 300

 

after_backup.ps1 file

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$p = New-Object System.Collections.Specialized.NameValueCollection

$p.Add('username', '[email protected]')

$p.Add('password', 'vidanlogin$%^&')

$p.Add('serverip', '10.72.6.100')

$wc = New-Object Net.WebClient

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 1/unquiesce', $p)

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 2/unquiesce', $p)

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 3/unquiesce', $p)

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 4/unquiesce', $p)

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 5/unquiesce', $p)

[void] $wc.UploadValues('https://10.72.6.132/datastore/equallogic volume 6/unquiesce', $p)