Backup of huge filesystems

Last post 03-09-2020, 7:18 AM by Colin. 3 replies.
Sort Posts: Previous Next
  • Backup of huge filesystems
    Posted: 03-02-2020, 1:02 PM

    Hi all.

    Just looking for some guidance from some who may have already done this.

    My institution is creating a file sharing and storage repository for researchers using Citrix.  If as successful as they think, we could be looking at housing over 1PB of data.  For backups, ai am looking at array snapshots and replication to another array across the campus.  This is a good start, but I am looking for ways to keep some backups long term.  I am considering using a disk array for backup with aux copies to another array.


    Issues are the cost of FS licensing.  Purchasing 1000TB of FS licensing is out of the question.  It was suggested by CV that I create many filesystems and mount them on VMs and use the VSA as the licensing costs are fractional.  Not sure how this works as the VSA seems to only look at the VMDK.  Even if I did purchase FS licensing, the time to backup and aux copy such an amount of data would be prohibitive.  Restore time would be really long.


    So, how do others backup/restore huge amounts of FS data?



  • Re: Backup of huge filesystems
    Posted: 03-06-2020, 3:15 PM

    I thought some of our file servers were rather large, but you have us beat for sure!  We have lots file servers in the 5 to 15 TB range.  They are all VMware guests and backed up using SAN transfer.  The largest can take anywhere from 10 to 18 hours to run a full backup.  The incremental backups are quick since they use the VMware change block tracking.   One thing to watch out for is when an VM admin adds space to one of the disks in vCenter, it re-sets the change block tracking for the VM so it ends up forcing the backup to be a full. (commvault will run an incremental, but the size is a full)
    From a CV licensing perspective this is great.  

    We are able to still run file level restores from these backups it takes a little longer than a traditional file level restores but not too bad.

    For a full server restore, the Full VM will be faster(SAN mode transfer) than a file level restore. 

    Are you looking to put the full petabyte on one server?  That would be scary if the server runs into any issues... server patches and what not.  I would try to spread it across a few servers.

    We do also use a Netapp for some file sharing.  It is set to replicate to another Netapp at our DR site.  The Commvault backups against it are super slow.   Luckily these files are a write once read many situations.  So, the data once written does not change.   So we are able to run one time backups of the older volumes and keep them in Commvault and they are good going forward.

    I think some folks would use the snapshots on the arrays to keep the backups.  I still subscribe to the 3-2-1 backup strategy.

    Cohesity and Rubrik look like interesting options for large fileservers.  We tried out Cohesity for a specific purpose, but it was not able to support the speeds we needed.  For normal user usage it would have been ok.

    Hopefully this helps a little bit.

    Good luck!

  • Re: Backup of huge filesystems
    Posted: 03-09-2020, 5:18 AM

    I'd consider build another commcell with CV-BR-OI licensing (Commvault Complete Backup & Recovery for Physical Servers, Per Operating Instance). This model has limited protected frontend TB, but it's negotiatiable.  

    It has Intellisnap license included. So you can use storage array snapshots and use as backup copy source. Also block level backup may be benefficial in such filesystem size.  

  • Re: Backup of huge filesystems
    Posted: 03-09-2020, 7:18 AM

    Thanks very much for the feedback.  Should have mentioned that this data will likely reside on an Isilon, so server issuew are not a problem.

    I will talk to CV about the licensing.

    Cheers, Colin

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.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy