VMDK too big? VSA vs FS? Backup/Restore slow.

Last post 06-12-2019, 9:13 PM by Anthony.Hodges. 4 replies.
Sort Posts: Previous Next
  • VMDK too big? VSA vs FS? Backup/Restore slow.
    Posted: 06-11-2019, 4:55 PM

    My VMWare admin is asking is there a VMDK size that is just too big to be practical for backup and restore times? We have several that are getting above 2TB or more and take forever to restore. Should they be backed up via the VSA? By FS agent like they are physicals? What are others using? Is there a best practice? Suggestions please!!!

  • Re: VMDK too big? VSA vs FS? Backup/Restore slow.
    Posted: 06-12-2019, 9:37 AM

    my personal advise is to use max 500Gb vmdks, and use multiple vmdks. 
    In case you use deduplication, you can then make optimal use of muliple readers, increasing the backup performance.

     

  • Re: VMDK too big? VSA vs FS? Backup/Restore slow.
    Posted: 06-12-2019, 1:57 PM

    We've got a lot of these nowadays in our environment. I've started splitting out the very large VMs (4+TB) to their own subclient, and that helps a lot. There's also an additional setting that I've set on my media agents to allow multiple streams on each VM. Name: "nAllowMultiStreamsPerVM" Category: VirtualServer Type: Integer Value: 1. You'll never get more than one stream per vmdk, but this will let the vmdks run concurrently.

     

    The biggest help that I've had is with changing the backup type to hotadd vs NBD. Not sure how you've got your environment set up, but I'd highly recommend using SAN or HotAdd transport if you aren't already. 

     

    Best of luck!

  • Re: VMDK too big? VSA vs FS? Backup/Restore slow.
    Posted: 06-12-2019, 2:13 PM

    watch out with the nAllowMultiStreamsPerVM setting.


    This indeed increases(increased) the performance, but can cause huge problems, and is not 'supported' as far as I know.  On our environment(s) we stopped using this after a lot of failing backups. (V11)
    It's just my personal warning ;)

  • Re: VMDK too big? VSA vs FS? Backup/Restore slow.
    Posted: 06-12-2019, 9:13 PM

    Incremental forever for 4TB vmdk's is not going to be a problem for backups (depending on your change rate of course), but a restores will take hours.  If the end user application demands it then, then they have to own that application recovery time.  From my experience, the biggest reason why a backup administrator/operator would want to use a File System Backup over VSA is the time it takes to live browse to restore files in a VM with a very large file system.

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy