Hopefully someone here can help me:
I have two Windows Clusters, one in Site A and one in Site B. Inside these windows clusters are two Windows File Server Clusters as guest clusters consisting of three nodes in Site A (FS_CLUSA) and two nodes in Site B (FS_CLUSB) . Each fileserver cluster is using a shared vhdx file as the storage volume.
Ideally I would like to replicate FS_CLUSA → FS_CLUSB however Veeam does not support replication of virtual machines with shared VHDX or CSV volumes.
We settled on the idea of simply doing a volume level backup of FS_CLUSA and restoring it to FS_CLUSB to keep the two clusters up to date (give or take a few hours). I have been able to restore the volume from FS_CLUSA to FS_CLUSB via the console no problem, because I can specify a different target to the host.
However reading the veeam powershell documentation to start to automate this process, leads me to the command Start-VBRComputerVolumeRestore (which only supports restoration to the original location)
What would be the correct powershell command to use to replicate what I can do in the console, or is there another (better) way to acheive what I want to do?
Thanks in Advance
Windows Agent Volume Restore Automation
Best answer by david.millward
It does not work very well. You need to completely detach the shared vhdx files from the VMs in order to rename or remove the old vhdx file.
I did this all manually to start with:
Stopped the FS_CLUSB, detached the old VHDX from both nodes, renamed the old VHDX, renamed the restored VHDX to the original name, re-attached this VHDX as the shared drive to both notes and started the FS_CLUSB.
To verify I deleted a bunch of data from the old disk, to ensure nothing was cached, and the restore was a success. I just have a lot more steps to script, automate and check - but in principal it works.
+20Hi
Interesting task. Cool that you found a workaround in the Console. So, you didn’t explicitly state so..but are you performing an Agent Backup of your Cluster using through VBR? As far as PoSH cmds to help you automate what you wanna do, I also didn’t see anything in Veeam’s PoSH Ref Guide for cmdlet to point to a new location. Unless someone else chimes in with something, I think your best bet would be to go directly to the source → ping Veeam Support to see if there’s a cmdlet not listed in the Guide, or some other automation tool to help you achieve your goal.
+21Interesting problem and I cannot add anything that Shane has already not. Automation is something I am getting in to but as far as I know there isn’t anything that will be easy for this.
Not sure but something to investigate which could potentially help is Veeam Recovery Orchestrator possibly? Not sure if it would for sure but might be something to check.
That was my first port of call: I saw that there seemed to be a mis-match in capabilities between powershell and their console. So I logged a ticket, and they told me to ask here.
I thought of a differnet workaround - which is a bit creative so bear with me:
Step 1: Leave FS_CLUSB Disk permanently offline.
Step 2: Prior to backup. write a verification file on FS_CLUSA to ensure some new data is in the backup file.
Step 3: Use the Start-VBRRestoreVirtualDisks to export the volume from the agent backup as a VHDX file directly to the Physical host running the parent cluster in SITE B. This command will let you specify the target machine, what type of disk you want and the path to where you want to restore it (in my case C:\clusterstorage\FS_CLUSB_Volume).
Step 4: Bring the shared disk online in FS_CLUSB and check the the existence of the verification file
Step 5: Report on the success or failure of the restore and take the disk in FS_CLUSB back offline (it is there for DR purposes and does not need to be online permanently.)
Its a bit clunky, but that will probably do the job…
+20From what I can see, that sounds like it would work. Not as smooth as you may want, but certainly worth the attempt. Can you clone your systems and put them in somewhat of an isolated environment to test your solution against before implementing in prod?
+20Hey
+21That sounds like a pretty good workaround all things considered. Let us know how it goes and if successful or not.
The Cluster in site B is currently in Pre-production. There is nothing on it aside from the FS_CLUSB so I can do what I want with it, provided I don’t accidentally restore files to their original location and take FS_CLUSA offline (thats the critially important one hence the serveral layers of redundancy).
Using the Start-VBRRestoreVirtualDisks command works as expected.
A new vhdx file was created in the parent cluster in SITE B on the correct CSV in the correct folder.
The only issue is, it insists on writing the name of the server it came from in the name of the VHDX file.
As the volume could come from any one of three servers in the FS_CLUSA it could potentially have three names. Which if I am not careful will triple the amount of space required on the CSV (we are talking almost 2TB of data here, so not insignificant).
I will need to delete the old VHDX file before doing the restore, and then rename the restored VHDX file to match what is attached in the VM settings.
Easy enough to script, but massivley overly complicated for the want of a proper parameter in the Start-VBRComputerVolumeRestore command.
+20Using the Start-VBRRestoreVirtualDisks command works as expected.
A new vhdx file was created in the parent cluster in SITE B on the correct CSV in the correct folder.
The only issue is, it insists on writing the name of the server it came from in the name of the VHDX file.
As the volume could come from any one of three servers in the FS_CLUSA it could potentially have three names. Which if I am not careful will triple the amount of space required on the CSV (we are talking almost 2TB of data here, so not insignificant).
I will need to delete the old VHDX file before doing the restore, and then rename the restored VHDX file to match what is attached in the VM settings.
Easy enough to script, but massivley overly complicated for the want of a proper parameter in the Start-VBRComputerVolumeRestore command.
Yes, indeed.. & understood. Let us know how it goes.
+21Using the Start-VBRRestoreVirtualDisks command works as expected.
A new vhdx file was created in the parent cluster in SITE B on the correct CSV in the correct folder.
The only issue is, it insists on writing the name of the server it came from in the name of the VHDX file.
As the volume could come from any one of three servers in the FS_CLUSA it could potentially have three names. Which if I am not careful will triple the amount of space required on the CSV (we are talking almost 2TB of data here, so not insignificant).
I will need to delete the old VHDX file before doing the restore, and then rename the restored VHDX file to match what is attached in the VM settings.
Easy enough to script, but massivley overly complicated for the want of a proper parameter in the Start-VBRComputerVolumeRestore command.
Hopefully you can do a rename after the copy maybe to resolve that. Let us know how things progress.
It does not work very well. You need to completely detach the shared vhdx files from the VMs in order to rename or remove the old vhdx file.
I did this all manually to start with:
Stopped the FS_CLUSB, detached the old VHDX from both nodes, renamed the old VHDX, renamed the restored VHDX to the original name, re-attached this VHDX as the shared drive to both notes and started the FS_CLUSB.
To verify I deleted a bunch of data from the old disk, to ensure nothing was cached, and the restore was a success. I just have a lot more steps to script, automate and check - but in principal it works.
+21It does not work very well. You need to completely detach the shared vhdx files from the VMs in order to rename or remove the old vhdx file.
I did this all manually to start with:
Stopped the FS_CLUSB, detached the old VHDX from both nodes, renamed the old VHDX, renamed the restored VHDX to the original name, re-attached this VHDX as the shared drive to both notes and started the FS_CLUSB.
To verify I deleted a bunch of data from the old disk, to ensure nothing was cached, and the restore was a success. I just have a lot more steps to script, automate and check - but in principal it works.
Well best of luck and share the results when done as I am sure everyone would love to know how the script works. PS for the win! 😎
+20It does not work very well. You need to completely detach the shared vhdx files from the VMs in order to rename or remove the old vhdx file.
I did this all manually to start with:
Stopped the FS_CLUSB, detached the old VHDX from both nodes, renamed the old VHDX, renamed the restored VHDX to the original name, re-attached this VHDX as the shared drive to both notes and started the FS_CLUSB.
To verify I deleted a bunch of data from the old disk, to ensure nothing was cached, and the restore was a success. I just have a lot more steps to script, automate and check - but in principal it works.
Yeah...wish there’s was something not as complex for you to achieve what you’re needing. Maybe Steve can chime in at some point.
+11Hey
Cheers,
Steve
+20Thanks for chiming in Steve. Really appeciate it.
Comment
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.