Posts

Showing posts from June, 2017

VSAN Backup and Recovery Q&A

I'm just beginning to learn VSAN basics and of course my backup background immediately kicks in. I intend for this to be a living post with additional questions and answers being added in. *To clarify, this information is based on using the VDDK - HotAdd NDB portion of VADP 1) Q: Does VSAN support direct storage backup using VADP bypassing the VM Host running the data (such as how storage can be directly connected to with traditional storage)?: A: Currently, No , since VSAN does not operate like a traditional storage array using common protocols (iSCSI, NFS or FCoE) direct connection to the storage is not possible - this answer was provided by Jase McCarty via vBrownBag Session @jasemccarty 2)   Q: In a multinode VSAN environment, does the VMDKs transfer/copy to the host running the guest VM? A: No, the VMDK's do not tranfer/follow the guest from one host to another, BUT some data would be cached on the host running the Guest. This probably would not be a full set of in

CommVault VADP Backups - Single file restores gotcha Part Deux

I wanted to take a second to clarify a couple of parts that could be misleading or easily misunderstood. First, the "all or nothing" part of the restore mentioned refers ONLY to VMDK restores, not to single file restores. I included the comment in the post as this was part of the discussion as an option that I was provided by CommVault Support today. Second, the suggestion to use either the Linux Restore appliance or the VMDK restore method was recommended when restoring a total size >100GB or a very large number of files (think 1,000+ or so). Third, the total size of free space required is an amount equal to or greater than the TOTAL size of data to be restored, and needs to be available on both the staging disk (where the agent is installed by default) as well as the final destination location. An example discussed was if I wanted to restore a 10GB file to the D:\ drive, then by default, you would need 10GB+ available on both the D:\ (final destination) as we

CommVault VADP Backups - Single file restores gotcha

Ran in to this little issue today when performing single file restores from a CommVault 11 VMware VADP based backup: When running a single file restore from a VADP backup to an Agent based client recovery you have to be careful. The restore will queue up all data to be recovered to a temporary folder on the destination/proxy client, which by default is in the CommVault Client install path (defaults on C:\Program Files\CommVault). This means that if the TOTAL size of the restore is 200GB, then you MUST have 200+GB of FREE SPACE on the volume. It doesn't matter if it's 200 files 1GB in size, or 1 200GB file, you must have enough free space to buffer the ENTIRE restore. The work around I had to utilize today was to run multiple smaller restores that didn't exceed the free space on the drive that CommVault was installed. I know, you can load the Linux Appliance and use that as the proxy, or you could create a VMDK and mount it that way... There are other options, but th