Our SQL team has their own process for data recovery and they would like us to only protect their System Drives. The storage team does not wish to house all of the SQL data at the recovery site, if it is not going to be used for recovery as it just takes up space. I know you can mark a drive as swap and it will only perform an initial syn and that is it. But I would like to avoid the initial sync as it is terabytes of data.
My question is: If I use a Blank VMDK to seed my SQL Server data drives that are marked as SWAP, will it still perform the initial sync, or will it leave the disks blank? If it leaves em blank, our SAN will ignore the zeros and then everyone is happy!
If you were to pre-seed with a blank disk, the initial delta sync will still send over all the data since there would be differences between the source disk and destination disk.
Alternatively, you would be able to mount the data as a drive within the OS in order for ZVR to skip this (mounted) drive altogether. I know this would mean altering your currently server layout, but it is an option in order to skip the data completely.
Please send us the feature request including the ask, size of the environment this would impact, and timeline for your need to use this feature, as this will help our prioritization.
I do have a question around your DR process for the server(s) in question though. What is your recovery method to ensure the data recovery is in sync with the OS and application that would be replicated in this desired scenario? Does it limit your recoverability options? What types of outages/disasters would you be using ZVR to recover from? Would you want to be able to test OS and application patches and upgrades? Or test application recovery (applications that also rely on this SQL data)? If so, you’d want that data to also be available, and I wonder if the process for requesting the data (separately) is worth it versus having it all available with ZVR’s replicated data set.
Harry S.
