VBO Retention policy? This is weird?

[Lennydk87]

Hello,

We've just started testing Veeam for Office 365 backup.

But I cant really grasp how weird this is made.

We are in the middel of migrating user from our Exchange 2016 On-prem to O365, today the On-prem Exchange is backed up like this:

1 time everyday for 30 days, after the 30 days has gone it starts all over and overwrites the oldest restore point.
1 time every month in 12 months, and after the 12 month it starts over and overwrites the oldest restore point.

This is weirdly enough not possible in VBO.
You cant choose to backup everything and then overwrite oldest restore point.

Why is it we cant choose a backup plan we use in VBR?

When is this going to change, because this i somewhat a deal breaker for us.
If we choose "Keep forever" then we will fill our storage with backup restore points.

We only need:

30 daily backup restore points and 12 montly restore points, and that should include ALL live data.

[nielsengelen]

Lennart,

Currently, it is true VBO uses a different retention policy compared to VBO. We make backups based on modification date. If you have a repository with a 1-year retention, we will backup everything between now and a year ago based on the modification date.

I understand you want the same retention as we leverage in VBR, the good news is this is coming in the next version so you'll be able to leverage the '1 backup for 30 days' and '1 time every 12 months'.

The best you can do now is either use the retention method on 'forever' or '2 years' assuring you'll have all the emails based on your needs. Once the next version is available, you'll be able to apply the VBR retention.

[ejenner]

Veeam is able to do what you want, but requires a different approach.

There are a few different ways to configure Veeam jobs.

Often you will have a 'backup chain' which means the individual backup files are linked behind the scenes.

Each backup performed creates a file. That file might be a full backup, a full backup which has been automatically generated from data already on the repository or an incremental. So unless you have your backups designed to create a full backup file every day then your idea of overwriting the oldest file at the beginning of a new cycle couldn't work. If you take out the first backup file in the chain then the chain breaks and none of the other backup files in that chain will work.

Backup chains with automatically generated files and incremental files provide massive performance improvements both in terms of time and required storage space.

To do the function you're looking to achieve you would use a combination of the regular backup scheduled to run daily with 30 restore points. Additionally, you'd have a 'backup copy' job on a longer schedule which would take a backup of your backup at the time you specify. That has no impact on your production servers as it reads the data from the backup system.

[Mike Resseler]

Just to make a few things clear...

What Niels said is more or less correct. We are introducing a new retention in the next version that is comparable with VBR retention. But there will be no GFS retention to start with.

Saying that, by using forever retention, you are using a lot of space is not entirely true. In the end, we are storing the differences only and not full blown restore points every time.
The introduction of this retention mode comes from the legal point of view. (Keep 7 years of email, based on parameters such as modification...). But we did hear a lot of you loud and clear and will give you an option in the future.

[Lennydk87]

Thanks Mike.

Its OK, we've set the retention policy for "Keep forever" until new release is here.

I've got another issue, at the moment we got 5 user mailboxes in Exchange Online.
But only 3 is backed up, I cant really figure out why the two other mailboxes arent backed up.

Ive got a supportcase running: 03348598

You got a clue of what is wrong?

[Mike Resseler]

Do you see any errors? What is the job policy?

[Lennydk87]

No not really any errors.

When I look through the log: Veeam.Archiver.Proxy_2019_01_04_19_53_39

It seems to run through the mailboxes.

The policy is:

Backup:
Our organisation (But only Mail, No archive, OneDrive or sites)

Excluded:
Discovery search mailbox and a usermailbox for some impersonation, and all O365 groups

[Mike Resseler]

All O365 groups? I think your mailbox will be in those groups, and by default that means that the internal people are also processed. So I am now guessing that those 2 mailboxes are excluded because they are in a group membership that is excluded

[Lennydk87]

Hey Mike,

That might be the answer.

Because the two mailboxes is part of some of the groups.

Is this intended behaviour that Veeam not backup up mailboxes which O365 groups is excluded?

[nielsengelen]

Correct, excludes overwrite include settings. If you remove the O365 group from the exclude list, it should work.

[Mike Resseler]

Another way is to keep the O365 group in the exlusion list, press edit for that group (or multiple groups) and deselect "members". See here: https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=20

(But to be fair, I don't like excluding and then make an exception on the exclusion... Doable with 5 mailboxes, with a couple of 1000 it becomes difficult to manage )