File Server Backup Best Practices

[cwilson]

Hi Group,

As we all know, with Veeam there is so much flexibility in designing your backup strategy, that there really is no way to provide a best practice recommendation per say, since all environment differ. However I am looking for some feedback from some of the larger customers on how you are handling your file server backups that contain large data sets. We have roughly 15tb of file server data (just file server data, not counting 10tb of SQL/Linux volume sitting on file shares as well) that is currently being backed up by traditional 3rd party backup products. We are looking at bringing this data into Veeam, *If* we can accommodate it conveniently. My biggest concern here is dealing with large VMDK's files exceeding 3tb+ in size. If we had lots of smaller 200-600gb vmdk's for instance, it would be much simpler. But looking at the size of our vmdk's, and the amount of time required for CBT to scan and then back up changed data, I am thinking we might run into problems.

The second stage to this, is getting all of this data offsite. Currently we are using BackupExec, Symantec CPS, rSync, Robocopy, and some other rudimentary means of backing up and replicating this data. I would like to ideally consolidate everything on Veeam, but obviously this is a large hurdle to overcome, and I am interested to hear from others who have may have standardized on Veeam, and use it to backup up all their file server data.

I did not go into a lot of technical detail to keep the post short. I can provide additional information however.

Interested in hearing from others.

Thanks

[veremin]

But looking at the size of our vmdk's, and the amount of time required for CBT to scan and then back up changed data, I am thinking we might run into problems.

Have you had a chance to run a job against this server? I'm asking since, typically, file servers are not known for producing high amount of changes, thus, the time required for CBT operation shouldn't be that long. Similarly, the size of incrementals is more or less acceptable.

The second stage to this, is getting all of this data offsite.

You can copy backup data offsite, using Backup Copy job. As to archiving data to tape appliance, then, tape functionality should be your way to go.

Thanks.

[dellock6]

CBT does not "scan" disks. It's a log file, where all the changed blocks are registered, so Veeam can read it and point directly to changed blocks, instead of scanning the whole disk. CBT exists right to avoid vmdk scans...
Apart of this, there are several customers backing up vmdk really large VMs. With vSphere 5.5 you can for sure go above 2 TB vmdk files, but I would also consider parallel processing in Veeam. A single huge VMDK file can only be processed by a single Veeam proxy. If the same amount of space is divided into multiple VMDKs, then parallel processing can process all VMDKs at the same time, thus resulting in an increased backup speed. Large VMs are exactly one of the best use cases for parallel processing.

Luca.