Veeam Backup 9.0 New Scale Out Repository best practice

[albertwt]

Hi All,

My current backup repository is running out of disk space as you can see below:


So I wonder if I can use the new Veeam Backup 9.0 newly introduced repository to overcome my problem as above ?

[nielsengelen]

Hi Albert,

Scale Out Repo will bundle all these repositories and do the placement for you. It will also use per-vm backups chains (by default) to leverage proper placement. I notice however you're using your repositories quite well already.

By switching to a SOBR management will become easier. Take a look at https://www.veeam.com/blog/introducing- ... te-v9.html where it is explained what it does and how it can/will help you.

In regards to your disk space usage/problem; this also somewhat depends on how many jobs you have now. Do you want to change anything in terms of retention? Which backup method are you using?

[albertwt]

Hi Niels,

Many thanks for the reply and explanation. Since I'm running out of disk space in my first stage repository, I will have to manually move around the Backup Folder almost daily to prevent backup failure.

Do you want to change anything in terms of retention?

So far all of the backup job is kept 20 backup. Not at the moment I do not plan to change or reduce them.

Which backup method are you using?

I'm using Reverse Incremental so I perform once Active Full backup and then the incremental forever for the next day until I need to make Active Full backup again.

Can I convert my existing backup set into Scale Out without doubling the disk space required ?

[nielsengelen]

You can add all the repositories into a SOBR, the amount of diskspace will still be the same however placement will be done for you solving the manually move

Do keep in mind that if you switch to this to enable the per-vm backup file chain an active full is needed to start with this.

[albertwt]

Cool, that sounds great for the automation.

At the moment I'm enabling the Bitlooker functionality one by one per backup job. Hence I also perform the manual Active Full backup to make it in effect.

So I guess once I've done them all, I can then switch or configure the SOBR feature with no issue ?

[nielsengelen]

If you want to use per vm chains before creating the SOBR you will have to configure it per repository.

Afterwards adding them is all you need to do.

Keep in mind that you can't use SOBR for:
- configuarations backups
- replica metadata

If this is being stored on one of the current repositories you can create an additional folder on the drive and configure it as a repository just for these things.

For example:
d:\backupssobr
D:\backupsrest

[albertwt]

AH I see,

Niels,

That was for the Backup Job Repository.

What about the Backup Copy repository ? are they both treated the same as above ?

- configuration backups --> is this the Veeam Backup configuration scheduled backup location ?
- replica metadata --> is this the .VBM file ?

[nielsengelen]

- configuration backups --> is this the Veeam Backup configuration scheduled backup location ?

Yes correct.

- replica metadata --> is this the .VBM file ?

No, if you have replication jobs you will have a tab where you configure where to store the replica metadata. If you don't have any replication jobs you're fine.

Have a look at https://helpcenter.veeam.com/backup/vsp ... _sobr.html where all limitations are listed however backup jobs, backup copy jobs & VeeamZIPs are fully supported.

[DaveWatkins]

Be aware, you'll need an Ent + license to make any use of it in your situation. Enterprise licenses are limited to 3 extents and a single SOBR.

Also there appears to be some missing logic around placement in the current version. I'd do some testing in an environment you care less about if I were you, or have a look through the forums for the issues posted and decide if they will impact you. Once you go SOBR, reverting to normal repo's can't be a challenge, especially if you don't have a lot of free space

[albertwt]

niels and Dave,

Many thanks for the assistance and reply so far.
I'll read through and will think about how can I approach this with my current VBR Enterprise Edition (non Plus).

Does that means I will need to consolidate the LUN on my SAN to be just one single drive letter instead ? [ is there any maximum limit]
after that I can then extend it again maximum 3 times.

[DaveWatkins]

On Ent, the 3 extents refer to 3 physical repositories in B&R, so in your case, 3 exposed LUN's on your server. If you can consolidate down to 3 LUN's then you could use the single SOBR and 3 extents available. However, if you can do that anyway, why not consolidate down to a single LUN and just present one big drive?

Of course that means wiping the existing LUN's, which is never pretty

[albertwt]

Yes, that does make sense.
So is there any maximum limit on the disk size or LUN capacity formatted as NTFS ?

[DaveWatkins]

Assuming Windows 2012 R2... not really, technically it's something like 16 exabytes. Going over 16TB means formatting with a larger cluster size, but you want to do that anyway for the kind of data you're storing anyway.

There are a decent amount of things within windows, and probably a heap of outside applications that will be unhappy with anything over 64TB. Windows Dedup is the one that comes immediately to mind but I imagine the list is probably fairly long so that's where I would draw the line personally. Probably 63TB LUN"s just to be on the safe side

Remember to format the drives with /L /A:64k /Q

[albertwt]

Ah Yes, you're right.
My current Veeam Backup Repo is Windows Server 2008 R2, but the Veeam Backup and Backup Copy repository is already on 2012 R2.

In that case the MBR type must be converted to GPT instead of MBR.

THanks for the suggestion.

[pkelly_sts]

I have a Scale-out repository destination for a copy job with 2 extents that I'd forgotten was NOT configured with per-VM so is currently doing traditional FF backups.

What happens if I now enable per-VM on that SOBR? Will it cause any kind of full backup (copy) or will it generate/create one locally?

This is coming in from a Remote site so just managing expectations of bandwith/timescale more than anything...

Actually, even the local (single) repository isn't configured for per-vm currently so I guess same question, what impact would the change to the source repository be?

Thanks!

[DGrinev]

Hi Paul,

If you enable per-VM on that SOBR, you will need to run an active full to start with this.
Until then, your copy jobs will continue running traditional FF backups.

Please, review this thread above for additional information.

Thanks!

[pkelly_sts]

Thanks Dmitry, so if I were to convert the local repository to per-vm, that would cause a local active full to take place which would then cause that active full to be copied to the backup copy repository (off-site) so I might as well convert both at the same time?

[DGrinev]

Paul,

Switching to per-VM option only happens when a full backup is triggered.
There is a script to execute active full backup for the jobs pointed to those repositories.

The same scenario should be applied to the BCJ.

Thanks!

[foggy]

Paul, what Dmitry is meaning is that for the per-VM option to take effect, you need to trigger active full (either manually or by schedule). Until that, your backup chains will continue to keep all VMs in a single restore point. This is valid both for backup and backup copy jobs.

[pkelly_sts]

Ah, understood, thanks Foggy, so I can reconfigure the repo, then when it suits, schedule in an active full to start making use of it...