One Veeam Backup job for all vms

[its-user01]

We have 1600 vms, (Linux and Windows).
I would like to make one big backup job for all vms, but do not know if that should be avoided?
Is it ok to make one big backup job for all vms?

[HannesK]

Hello,
yes, that should be avoided

Technically it could be possible (we tested even higher numbers in QA), but the best practices say something around 300 VMs with per-vm backup chains are a sweet spot. Depending on your hardware, you might go a little higher, but I would not go to 1600 VMs.

What I have seen at customers of your size is that they have a powershell scripts that distributes VMs over a couple of jobs. They use tags with "job 1...n" and just fill new VMs in the jobs until they reached 300

Best regards,
Hannes

[its-user01]

Hello,
Thanks for quick reply.
What is the reason for avoiding it?
We want to use ReFS so we, without wasting space, can make weekly full backups, so the chain is broken every week. Now we have about 30 jobs, and they all start at the same time. I we make one big job, they also start at the same time, so what it the difference?

[HannesK]

What is the reason for avoiding it?

not going to the limits is usually "to be on the safe side" - 300 became a "safe value" over the time but it is not a hard limit. I mean if you have enough resources, why not test it

can make weekly full backups

if you are talking about active full backups, then the merge argument does not apply, correct. As you also wrote "not wasting space", I'm not sure which backup mode you plan to use. Synthetic fulls (pointing to the same blocks again) only makes sense in rare use cases from my point of view.

I we make one big job, they also start at the same time, so what it the difference?

internally they are still queued. in the end, the amount of parallel backups depends on the concurrent tasks set in proxy / repository settings.

[its-user01]

We do not use per-vm backup, so what is the recommended number of vm´s per job, when using jobs with periodical synthetic full, on ReFS file system.

[HannesK]

Hello,
please see the link above: 30



May I ask your for the reason not using per-VM chains? I mean the files would become really huge and just for a few TB of space saving I would not go with all the disadvantages of classic "one file per job" chains.

As synthetic fulls point to exactly the same blocks, there are only a few tape use cases (over forever forward incremental) for that - do you use tape?

Best regards,
Hannes

[its-user01]

If I chose per-vm, would it then make sense to make full/synthetic backup periodically?

[veremin]

Generally speaking, there is no more need to run periodic active full backup at all. Check explanation provided here. Thanks!

[its-user01]

I just read this "The Use per-VM backup files option cannot be enabled for backup repositories with rotated drives." What does "rotated drives" mean? Old spinning hd? If it is, then we can not use it, because our backup repository are spinning disks.

[HannesK]

Hello,
rotated drives are drives that are rotated /changed manually by human interaction. It has nothing to do with the technology

from here

Rotated drives can be detachable USB or eSATA hard drives. This scenario can be helpful if you want to store backups on several external hard drives that you plan to regularly move between different locations.

Best regards,
Hannes

[its-user01]

Super, thanks;)
What do you thing would be fastest.
1. forever incremental backup, witch will use merge.
2. forever incremental backup with periodical synthetic backup, witch do not use merge?

I would think that number 2 would be the fastest, and not so hard on the storage system or??

[its-user01]

Ohh. forgot to mention that we will use ReFS if we use synthetic full, so it will not use any space on storage system.

[HannesK]

1 & 2 do merges, but on ReFS both is no problem.For simplicity I would go with option 1

creating synthetic fulls with ReFS has no advantage (except for some tape scenarios) as it just links to the same blocks

[its-user01]

But option 1. only merge when running synthetic full backup, so I save a lot of merge operations when using option 2 right?

[HannesK]

with ReFS it's always just moving pointers. no real merges.

option 1 does not have synthetic full backups.

On classic filesystems you see operations like in this animations