just one backup job for all vms?

[tym]

Hi,

we have 16 vms, 2 of them are sql servers, 1 exchange 2010 and 1 big file server (30tb data). Would it be suitable to put this bunch of vms into one backup job? I don´t see any drawbacks right now. are there any?

Best,
Tim

[Gostev]

Hi, Tim

There are no limitations as far as the number of VMs in the job. Most users would split such a huge file server into a separate job though, in order to keep backup file size for the rest of production servers more manageable. This may help you in future in certain scenarios.

Thanks!

[alanbolte]

Block size ("storage optimization") of the job is also a consideration - the big file server will need to be set to the largest setting ("local 16+ TB"), but you might not want to do that for the other VMs because it can reduce the built-in deduplication and slow down file- and item-level restores.

[tym]

ok, thanks, so your suggestion would be to split the backup into
1. fileserver
2. everything else?
My thought was that with everything into one job, we could achive the best deduplication outcome (as our b2d target size might be an issue)

[tym]

Alan, can you explain more detailed, why I would have to set the file server to 16+tb? We plan to do only synthetic fulls once the first full is successful, so I assume that block size might not be an issue. I would rather like to have the best deduplication outcome possible. Does this sound reasonable?

when reading this
http://helpcenter.veeam.com/backup/80/h ... ation.html
It seems to me that choosing this option is a question of cpu and memory stressing. I am running the first full backup that includes the file server this evening. Maybe I can tell more tomorrow.

Best,
Tim

[adrianIDC]

You could group them five vm for each Backup Job.
A to be 5 vm have the same S.O

[Vitaliy S.]

Yes, I would also vote for this type of distribution:
1. file server
2. same OS

Alan, can you explain more detailed, why I would have to set the file server to 16+tb? We plan to do only synthetic fulls once the first full is successful, so I assume that block size might not be an issue. I would rather like to have the best deduplication outcome possible. Does this sound reasonable?

If you want to get maximum dedup then why not to use Windows Server 2012 deduplicated volume as a target for your repository?

[alanbolte]

Tim,

The best practices guide for v7 says:

For maximum performance and reliability, it is recommended to meet the following guidelines for total size of VM data within a job:
• Local Target (1MB blocks): 32TB
• LAN Target (512KB blocks): 16TB
• WAN Target (256KB blocks): 8TB

I think I remember some comments just after v8's release suggesting these values had increased, but we don't yet have a version of that best practices guide for v8 so I'm not completely sure. However, I have seen a number of cases with VMs smaller than 10 TB where using the largest (8 MB) block size was advisable, mainly because regardless of your backup method there will be operations involving the list of blocks in the backup, and the larger that list is the longer those operations will take (CPU and memory load certainly play a part in that, but so do CPU and memory speed, and for some operations storage performance). The most extreme example of this is a newly discovered issue with overbuild operations (occur sometimes in forever-incremental mode and backup copy) described in this thread: http://forums.veeam.com/veeam-backup-re ... 26815.html

Also note that in the current version the size of the list of blocks to deduplicate against is limited to around 8 million (I think that's per backup file, so at the default 1MB block size that's around 8TB) so with a VM that's tens of TB in size you won't necessarily get a smaller backup file by choosing a smaller block size. You might - it's hard to tell without direct testing.

Vitaly,

Using Server 2012 deduplication inside the 30TB VM to reduce the size of the data being backed up might work well, but I don't think Server 2012 duplication can handle backup files of tens of TB, unless there have been some recent improvements to it I'm not aware of. I recall the early versions of it didn't support files larger than 1TB; last I looked you still need to make sure your storage formatting and configuration perfectly matches best practices if you want to use files in the 1TB to around 4TB range, or eventually you start getting file system errors.

[tym]

Hi

first of all, thanks for your suggestions. Here´s what I found this morning: the backup is still running and at 51% completion (started friday afternoon). It started with approx. 190MB/s and it is now down to 50. Deduplication rate is nearly 1:1.
Bottleneck ist considered to be the network, which I do not believe, as network would be somewhat around 100MB/s at the worst (both servers, target and source have nic teams with 4 nics or more).
Nothing to fancy right now..

[foggy]

Tim what kind of target storage do you have and how it is added into Veeam B&R console (what type of repository is used)?

[tym]

its 3 iscsi equallogics ps4000 with 4 volumes (3x15tb, 1x3tb) combined into 1 spanned windows volume. io is quite low atm compared to what those devices are capable of.

[tym]

the backup finally failed after 72 hours with "snapshot not found" error -.-
Does Windows Server 2012 R2 delete snapshots after 72 hours? Is there any way to resume the backup, or do I have to re-run it completely?

[tym]

exact error message was:
30.03.2015 15:51:05 :: Error: Snapshot with id '{97440f86-2e9b-4515-bbcd-d75c6d356afa}' was not found. --tr:Failed to complete VM backup. Snapshot id: '{97440f86-2e9b-4515-bbcd-75c6d356afa}'. Snapshot with id '{97440f86-2e9b-4515-bbcd-d75c6d356afa}' was not found.

I searched the onhost proxy for snapshot creation or deletion events but found nothing. There is also plenty of space on the volume where the vhdx is located.
Should I start a new thread as I think I am moving away from the initial thread subject..

[foggy]

Tim, it's always better to contact technical support directly with such issues, since logs investigation is most likely required.

[tym]

Thanks Alexander, we are currently evaluating the software, so we are no customers yet (will likely be one once we solved this issue;-)
Should I nontheless contact the support?

[foggy]

Yes, since everyone on the official evaluation period is allowed for getting support (based on staff availability, though).

[alanbolte]

Does Windows Server 2012 R2 delete snapshots after 72 hours?

I believe this is a Veeam limitation. You can ask Support about a registry value, though you might instead want to focus the support case on improving performance to fit the backup within that window.

[tym]

Thanks Alan, I doubt that the we will be able to fit the backup into 72 hours, as bottleneck is the network with 1GBit. This is the reason why I would like to go synthetic full once the initial backup ran successful. Support does not seem to answer me (for the time being), so If you or someone else is aware of this reg setting, I would really appreciate to have this info: We have to decide this week whether or not choose VEEAM or stick to BackupExec..

[foggy]

The key is mentioned in the v7 Patch 3 notes:

• Maximum volume snapshot life time is now customizable using the hvSnapshotLifeTimeHour (DWORD) registry value. Default value is 72 hours, but customization may be necessary to allow full backup of very large VMs on slow backup hardware.

[tym]

Hi, just to follow up - setting the reg key worked. Backup finished after 140 hours!

edit says: I am now wondering whether I can set the deduplication ratio to a better rate now that we are running synthetic fulls only..

[foggy]

Considering the size of your backup file, I would recommend to go with the "Local 16+ TB" setting, performance-wise.