Changing to Per-Machine Backup Files

[HouliNZ]

Okay,

We have recently learnt that Per-Machine Backup Files is a better choice to combined VM's in a single file that we are currently running for the majority of our repositories.

I see that we can alter the repository at any time (by clicking ADVANCED and then "per-machine backup files" option under the repository properties) but I am concerned about the consequences of doing this in the short-term will be (well until the 30 day retention period is exhausted).

Does anyone know?

Any advice on moving from combined VM's into a single backup file (and incremental's being stored the same way) to Per-machine backup files? Any help you could give would be much appreciated.

Thanks Glen

[Mildur]

I see that we can alter the repository at any time (by clicking ADVANCED and then "per-machine backup files" option under the repository properties) but I am concerned about the consequences of doing this in the short-term will be (well until the 30 day retention period is exhausted).

As long you are not doing an active full, there will be no consequences. If you want to change this setting on an active job, you need to run an active full on the job before the setting will be doing anything.

I only see advantages in my environment. Backup files are smaller and more transportable, if a customer wishes to have the backup files on a usb disk. If one file goes corrupt, not all machines are affected. If I need to delete a backup before the retention is over, I can do that on a machine level and don‘t need to wait until the rentention of all backups are over.

The only disadvantage for you could be, that it will need to write an active full, you will need space to convert the job. After that, synthetic fulls with FastClone are possible again.
And with per machine backup chain, veeam dedup will only work per vm and not anymore per backup job.

I heard, that veeam make this setting the new default with V12.

[HouliNZ]

Thanks @mildur - that is excellent! I think we will move to Per-Machine Backup Files on the night BEFORE the next Full Active Backup. That way when the new weekly full is created, it can start the incrementals.

Magic.

Thanks!

[Mildur]

Your welcome
Good plan.

[bg.ranken]

One thing to note here is there are benefits to not using per-vm backup files, and that is space.

Take for instance you have 50 VMs that are IIS servers. They all basically just run IIS services on them and nothing else. Using a per-vm repository, each of those servers will be a separate file on your repository. This means that you only get the Veeam deduplication and compression across each VM individually, not globally. This is not a huge deal if your repository is running deduplication of some sort, but if not, that means there is quite a bit of potential space that could be saved.

Now take the same 50 servers and point them to a repository that is not using the per-vm options (call this per-job). All 50 VMs are stored within the same backup file, and as such the commonalities (OS, IIS install files, etc.) will end up generating blocks that can be deduped across the entire file, getting you a sort of global dedupe across the whole file. Yes you are giving up the performance and ease of management you get from using per-vm backup files, but that across enough servers that could come with massive savings depending on your source VMs.

It really comes down to how much you want to manage your space on your repositories. If you have the space and don't want to have to actively manage things, then per-vm is the better choice. But if you want to try to get as much space as you can out of your current repositories to possibly extend your backup retention then looking into per-job settings might show some benefit. Also remember that there may actually be some performance benefits as well, as things like backup copy jobs or SoBRs with cloud capacity tiers will copy less data if your overall backups are smaller, and you could even get cost savings as well if you're using a cloud provider as smaller backup files will save there.

For our setup, we currently use two separate SoBRs, one for per-job and one for per-vm, both identically configured with the only difference being that per-vm checkbox. We then separate out servers depending on type. SQL servers, exchange, large servers (over 300GB, to prevent inflating the backup files) go to the per-vm SoBR. App servers, domain controllers, and other small servers go to the per-job SoBR. Just make sure you try to keep your per-job data files as small as you can. We aim for under 2TB per file, and just spread out all our app VMs to multiple different app jobs. DCs, and SCCM servers get their own job because of their use case (DCs because they often have the same OS and configuration, SCCM because all the distribution points have the same files on them which makes for good duplication ratios). We also separate OSs, only between Linux and Windows, so app jobs specific to Linux servers and the other app jobs have Windows VMs. We found that trying to group VMs by specific Windows versions didn't yield enough benefit to make it worthwhile for the extra work that would be involved with managing that.

So really, you can make your design as complicated as you want it to be, but often times just going the simple approach (per-vm) is the best approach. But there are legitimate reasons and use cases to invest the extra time, as in a large company you can be looking at hundreds of TBs of saved space if done correctly.

[Ve2Luk]

Hello,
@bg.ranken thank you for sharing the details about tests conducted. Can you share approximate deduplication saving, regarding to described configuration?

regards,
Łukasz.

[HannesK]

Hello,
the dedupe saving is great directly after you cloned the VMs from a template. Over time, it becomes irrelevant because updates get applied and all VMs have different data (except corner cases).

Per-VM chains are "the way to go" as the benefits are much higher than that little amount of disk space savings. Yes, in V12, per-machines chains will be the default. For backup copy jobs, they will be mandatory.

The advantages today are for example
- Easier tape restore
- More performance through parallel processing
- Easier job management (put more VMs in one job)
- Resource usage with SOBR
- Easy deletion of VMs from backups
- Per VM accounting

In V12, more advantages are coming

Best regards,
Hannes

[StoopidMonkey]

What's the ETA in V12?

[veremin]

We cannot share any ETA at the moment. Thanks!

[vmtech123]

So for myself, My file servers are all individual jobs because of their size. They range from 2 - 40 TB a server.. Most hovering around 20-25TB.

If I need a Tape restore it's a slow process.

Even on smaller VM's when I check the job, I usually get decent Dedupe and Compression. I am wondering how different it would be with Each VM being individual however. Does Veeam count the zeroed blocks as Dedupe or Compression?

Things like tape restores make this seem like a good switch to me though. I will have to do some testing and if it is the new default I would imagine this is based on research done by Veeam as well.

[HannesK]

I also get good data reduction on per-machine chains. that's why I wrote it's not worth thinking about legacy per-job chains

[vmtech123]

Interesting. My SAN is full so when I can, you've convinced me to try it

[vmtech123]

Hey HannesK,

The size of the job was quite similar, and performance was much better so thanks (I tested on 3 jobs so far)

How does this relate to copy jobs though, is Veeam recommendation changing them to Per-VM as well? I have a copy job set up to another SAN so would it make sense to do so?

I'm going to assume yes but wanted to see what you guys recommend. I'd assume the advantages would still apply with smaller files, more parallel, etc.


I'll have to run all my active full backups again too won't I?

[foggy]

No, no need for the active full on source jobs in case you switch your backup copies to per-VM backup chains. But you would need to trigger active full for backup copies.

[sykerzner]

Coming back to the "V12 will make per-VM files mandatory for Copy Jobs".

1. So does that mean I can expect an Active Full for all our Backups Copy jobs on day 1 after installing Veeam 12?

2. At smaller locations, we usually had on VM per job anyways. Will those jobs also need a Active Full?

3. Another related question. We're actively looking at using S3 for SOBR Capacity extent. Our existing repo is not per-VM. If we set it up now, and later change to Per-VM, since there will be a new files for each VM, will Veeam also have to send an Active Fulls' set of data to S3?

[LickABrick]

As far as I've read per-VM will be the default, single file will not be removed. You can to convert your jobs to per-VM manually with the press of a button (this has to be done per job). So I suspect you won't need to create an active full.

[sykerzner]

Based on the Doc, it seems like it needs an Active Full to make the new per-vm files.

https://helpcenter.veeam.com/docs/backu ... positories

You can enable or disable the Use per-machine backup files option for existing backup repositories at which backup jobs are already targeted. The new setting will not have any effect on previously created backup files in the backup repository. It will affect new backup files created after the setting is changed.

Veeam Backup & Replication applies the new setting starting from the next active full backup. You can create an active full backup manually or wait for Veeam Backup & Replication to automatically create active full backup (if active full backups are scheduled). Synthetic full backups do not affect the Use per-machine backup files setting.

If that's right, and if backup Copies will HAVE to be pre-vm, then that's a lot of bandwidth and storage for some clients. Some of my clients have massive servers, and Synthetic Fulls and REFS has been great for offsite copies.

So I guess I want to know if how mandatory is mandatory?
And what would going from 1 file to x files do to S3 storage?

[HannesK]

Hello,

1. No, the jobs continue as they did before. But you cannot create new backup copy jobs with per-job chains (or clone jobs with per-job chains target)

2. existing per-machine chains are upgraded to the "improved per-machine chains" manually. No need for active / synthetic full.

3. Yes. I recommend to use per-machine chains since 2014 and can only re-emphasize to really do it in 2022

Best regards,
Hannes

[sykerzner]

Thank you Hannes

[vmtech123]

6 months later, no regrets. Per-VM is the only way to backup!

[ruddj]

Per-VM chains are "the way to go" as the benefits are much higher than that little amount of disk space savings. Yes, in V12, per-machines chains will be the default. For backup copy jobs, they will be mandatory.

Does this mean the per-machine backup files option will be available on a Standard Veeam license? At present only Veeam Backup & Replication Enterprise edition and higher has this option. We only have Standard Socket licenses so can not enable it at present.

[HannesK]

yes, per-machine chains will be in standard edition

[sergiosergio]

Hi there!

I need some help to achieve this. I already altered the repo config and enabled per-machine backup files option but it had no effect, I still get just one file for entire backup. I also manually launched an active full, but still get the same. There is something to do with the task or whatever?

Thank you in advance.

[Mildur]

Hi Sergio

Please reach out to our support team if an active full didn't started new per-machine backup chains.

Best,
Fabian