Use per-machine backup files pros and cons

[rteglgaa]

Hi,

We have a remote repository for our offsite backups. This is all configured in a single offsite job, so the backup file is rather large.

If I enable "Use per-machine backup files" on the repository, will it affect dedublication and compression?

/Rasmus

[HannesK]

Hello,
yes, there will be an effect on it. But hard to predict how much. Irrelevant from my point of view as inter-VM-deduplication is usually only relevant for the initial full backup where operating system duplicate blocks can have some little effect.

Clear recommendation: always use per-machine chains (it will become default in V12).

Reasons since we have it:
- More performance through parallel processing
- Easier job management (put more VMs in one job)
- Better resource usage with SOBR
- Easier tape restore
- No 16TB files on wrong formatted NTFS volumes
- Easy deletion of VMs from backups
- Per-VM accounting

Best regards,
Hannes

[Kraken]

After upgrade to v12 and switching to per-machine backup, I can say that missing deduplication on these jobs killed our external repository. Maybe it would be nice to put a warning on the "Use per-machine backup files (recommended)" option in repository settings, that enabling this will disable the deduplication - currently, the description encourages users to enable this by stating "Enables additional backup management functionality".

We have few dozens of Windows machines on VMware, regularly updated (which should be standard I hope), most of them the same Windows version (aka "up-to-date"). This is obviously a huge factor for dedupe as suddenly the whole backup does not have 1,5 TB but 4 TB with even smaller retention. So contrary to the statement above, deduplication is still VERY relevant even after 3 years since the VM installation / upgrade from previous OS version and daily use.

I'm switching back and turning this off - I can understand this feature for large repositories with a lot of unused space and fast access. For slower and smaller ones, which is one of the cases for Backup Copy (safety copies on external drive in this case), it's definitely a bad idea.

[BostjanUNIJA]

Why deduplication doesnt work after enabling per vm backup chain?
Why Veeam doesnt calculate the same way which blocks are duplicate if it stores backup in a single file vs many files in the SAME JOB?

[vmtech123]

Deduplication still "Works" but it's for each VM individually rather than the entire job.

That being said, the portability of backups, ability to do faster restores, individual quick backups of VM's, and speed of backups when using SOBRS is a HUGE benefit to jobs.

Even in my environment of 100's of TB's I have switch to Per-VM and havn't looked back.

[importantchicken562]

Hi,

Somewhat related, but if we have all of our VMs packaged into one job, is there an easy way to convert them to Per-VM without having to create a new job?

[tyler.jurgens]

Change your repository to "Per-VM" and run an active full on your job. That will switch the new chain to "Per-VM"

[dognose]

Using per-VM will also be helpful in case your target media runs out of space.
Veeam is dropping data (according to retention policy) after an backup. If the backup fails, due to insufficient disk-space
it will be kind of stuck.

In that case, you can sacrifice a less important VM-Backup in order to get everything rolling again, and adjust retention to free more diskpace
to work properly in the future.