Hello All,
We recently deployed ESXi Nutanix Clusters in 2 locations, site "A", and site "B". We have setup a Nutanix Protection Domain, and are replicating VM's from site "B" to "A".
We have a requirement to backup several replicated VM's from site "B", to tape, with CommVault for long term retention, at site "A". While I have been able to accomplish this by "manually" browsing the datastore, and sifting through the .snapshot folder, and adding the VM(s) to inventory, I was wondering if this process could be automated or even simplified?
Does anyone know if the numbered folders inside the .snapshot folder change regularly? If they do not, then I could possibly automate with a script.
Thanks in Advance!
Tim
Page 1 / 1
AFAIK CommVault can do that natively, no?
Meaning you backup a VM running at Site B to commvault in Site B, then you have a CommVault policy to replicate the CVLT repository to Site A for retention
Adding MarkNijmeijer and dlink7 as well
Meaning you backup a VM running at Site B to commvault in Site B, then you have a CommVault policy to replicate the CVLT repository to Site A for retention
Adding MarkNijmeijer and dlink7 as well
Hi Jon, thank you for the reply back.
I assume you are referring to replication between Media Agents (Libraries). While I have not attempted this, I guess I should have added that the data link between Site "A and Site "B" is currently too small to accomodate increased traffic. In fact, our initial replication of (1) 2TB+ VM, started on 10/30 had to be throttled leaving 126 days left to complete.
Initially my plan was just to backup live VM(s) from Site "B", over the wire to Site "A", but soon scrapped that idea as well.
If there is a way to confirm that the numbered folders within the .snapshot folder do not change, my plan was to script and schedule the datastore browse, to that specific folder, and add to inventory, just prior to the CommVault scheduled job. Then another job to remove from inventory.
Or just assign someone the wonderful job of doing it all manually.
I assume you are referring to replication between Media Agents (Libraries). While I have not attempted this, I guess I should have added that the data link between Site "A and Site "B" is currently too small to accomodate increased traffic. In fact, our initial replication of (1) 2TB+ VM, started on 10/30 had to be throttled leaving 126 days left to complete.
Initially my plan was just to backup live VM(s) from Site "B", over the wire to Site "A", but soon scrapped that idea as well.
If there is a way to confirm that the numbered folders within the .snapshot folder do not change, my plan was to script and schedule the datastore browse, to that specific folder, and add to inventory, just prior to the CommVault scheduled job. Then another job to remove from inventory.
Or just assign someone the wonderful job of doing it all manually.
What your suggesting to work you would have to do a restore job everytime for this to work which would break change block tracking. The good part is the commvault dedupe database should kick in and should be fine. My understanding is that it would be a full backup everytime.
snapshot folders will change all the time, and honestly, aren't meant for human eyes.
As dlink7 suggested, every time you do what you're trying to do, it will be a full VMware backup, and your CommVault catalogue will be a nightmare, as the UUID of the VM you're backing up will change every time.
As dlink7 suggested, every time you do what you're trying to do, it will be a full VMware backup, and your CommVault catalogue will be a nightmare, as the UUID of the VM you're backing up will change every time.
dlink7, my concern was sort of along these lines? The longest retention for these FULL backups that I would run, would be for 1 year. So, aside from trying to figure out the backup process of of the snapshot, comes the concern at restore time. Changed blocks, etc. Most likely though, I would not have to restore the entire VM, rather files. But hard to say.
Btw, I have tested the backup, and restore of files by adding the vmdk file to another VM.
Btw, I have tested the backup, and restore of files by adding the vmdk file to another VM.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.