REQ: Improve backup and retention behavior!

[stvajnkf]

I mentioned this in another thread but added it here so the thread title will be clear that this is a request. I think many people would be horrified by the current behavior when they try to restore their backups and realize that their backups are missing all of their older data because the "retention policy" doesn't do what we assumed.

Here's my request (this is NOT the current behavior):

1) All backups should back up EVERY item (in the selected folders and types) regardless of age.
2) In the Repository settings, you specify the Retention age, which is how long to keep items in the Repository after the user has deleted them from their live 365 system. If an email is never deleted, it stays in the repo forever so that we can restore it in case of loss.

This way, Veeam will always have a 100% complete backup of my company's O365 data. If Microsoft loses everything or we get hit by a virus that deletes everything, we can simply restore from Veeam and get 100% of the data back. If a user deletes something from their mailbox and I have a 3 month retention period configured in Veeam, that means we have 3 months to recover the deleted item from the backup before it gets purged. Purging deleted items after the retention period expires on that item helps reduce the size of the Veeam repository. Easy and safe.

Why would anyone want to only back up the last 30 days (or 1 year or whatever) of emails/contacts/OneDrive, and pretend that everything created before that is ok to lose? If companies want to limit users' mailboxes to only keep data for 30 days then that should happen on the mailbox side, not the backup/recovery side.

This is a very important request for me (and probably many other users who dangerously assume it's already how it works).

[Mike Resseler]

Hey stvajnkf,

Allow me to explain the reasons behind this current behavior (and what our future plans are). The retention method you are looking for is known very well and used for years in the concept of image-level backup. The possibility to restore a VM, cloud machine or physical box the way it exactly was x-time ago. VBO is doing application-level backup and our retention policy was designed also so you can use legal retention on it. I won't go into it much but if your legal retention is 7 years, you want to be able to restore those 7 years but nothing older (that might get used against you).

However, we are hearing you (and others) loud and clear, and we are investigating and testing a way where the user can choose the retention type. It would be either the one that exists now (which is very useful for many of our customers) and the other one would be more in the line as you request it. Give me a backup once a day for 30 days and every mailbox should reflect that mailbox at that given time.

Would that solve your issue?

[stvajnkf]

If I understand you correctly, some companies want to keep backups of all emails for 7 years, even if a user deletes them from their mailbox sooner. After an email reaches 7 years, whether deleted by the user or not, it will be purged from backups.

I still maintain that those liability limits should be done on the mailbox side instead of the backup side. That's because, even if the backups are limited to 7 years, the mailboxes could still have emails over 10 years old that are subject to subpoena. Who cares if the backups are legally safe while the mailboxes still have the old emails in them? If, however, the mailboxes auto-delete objects over 7 years old, then those deletions will effortlessly flow through the backups and be purged automatically, leaving both the production and backup databases free of expired emails, and the administrator only had to set their retention policy in one place instead of two.

If Veeam really wants users to set liability policies directly on the backups, then I would like your idea of having two options for me to choose from. Some companies manage liability by purging deleted items before the 7 years occurs, as long as the user willingly deletes it before then. Plus, we want to keep the size of the backup repo as small as we can.

To be clear, your "30 days" example should be configurable so I can choose to be able to recover emails deleted even up to 2 years ago. If an entire mailbox gets lost, I can restore it 100% to the state just before the loss. If an individual email gets lost, I can go back and restore that individual email, as long as we catch it before the 30 day (or 2 year) deleted-item-retention-period expires and that email gets purged.

I hope that makes sense.

[IndyBri]

Question...Under General Options there are two choices for Retention...forever, and a certain number of weeks. Am I to understand this means items that have NOT been deleted? My repository is set to keep deleted items for one year. My general options say forever....while my legal retention period has not yet been set by the, well, legal department.

So I understand this means, all items will be kept forever unless they are deleted, and then they still have one year before they are actually gone.

Correct?

[Polina]

Hi Brian,

Apparently, there's some misunderstanding here. The backup retention policy is specified when adding/editing your repository on the "Specify retention policy" step. If your retention is set 1 year, it means that items with their modification date earlier than 1 year will be backed up on the first job run. It also means that regular clean-up jobs will remove from the repository items which modification date is "older" than 1 year. You can learn more about VBO retention policy specifics in the documentation and from this forum discussion.

Under General Options -> History tab there're parameters that define the period for keeping job's sessions history.

However, your point makes sense and we may think of revising the label for the sessions history settings.

[stvajnkf]

So IndyBri, unless I'm mistaken, I believe the answer is that you're wrong. That's totally understandable because Veeam's documentation and application are both very unclear, and from what I've seen, even their support people aren't making it clear enough with their explanations.

In the Repository settings, setting the "Retention Period" to 1 Year means that ONLY SOME of your emails are being backed up! Emails that were created/modified in the past 12 months are being backed up, but every email that was created/modified more than 1 year ago is NOT BACKED UP by Veeam. So if you lose everything tomorrow and restore your most recent backup, you'll find that you only have 1 year's worth of data, and everything older than 1 year is permanently lost. Yes, I think that's crazy too, and it's why I said that many users will be horrified when they realize that most of their data is permanently lost because their "backup program" is acting more like a "liability program".

Under General Options > History, if you set it to "Keep all sessions", I believe that only saves log files indefinitely. Not data. Just the logs that say stuff like "the backup on 11/1/2018 was successful."

The only way to do true "full backups" with Veeam is to set the Retention Policy to "Keep forever", but the downside to that is that deleted items never get purged. So if users follow good practice and keep their mailboxes cleanish by deleting unneeded emails, your backup repository will continue growing anyways and never purge the deleted items. Maybe that's what you want, but I prefer that deleted items eventually get purged from the backup repository to save space.

[IndyBri]

Thanks Polina....new Veeam Admin here...taking over a infrastructure that was built by someone else...trying to figure it all out.

Next question: In O365 backup, can I set up different retention policy for Email vs One Drive files? EX: Keep Email one year, One Drive files 3 months.

[stvajnkf]

I'd guess that you can create two backup repositories, one for email and the other for OneDrive. On the email repo, set the retention policy to 1 year. On the OneDrive repo, set the retention policy to 90 days. Then create two backup jobs, one for email and the other for OneDrive. Set the backup job for email to use the email repo, and the backup job for OneDrive to use the OneDrive repo. On the backup jobs, where you select which mailboxes to back up, you have to change the setting for each one to only back up "mail" or whatever, or else it will back up both email and OneDrive in the same backup job, which is not what you want. Note that you can highlight all the mailboxes at once and change them all to "mail" instead of having to do it individually for each mailbox.

As explained above, beware that any emails older than a year, or OneDrive files older than 90 days, will be purged from your backups and you will not be able to restore them, even if their owners still need them.

[Polina]

Brian,

There's no such option, but... Retention is set per repository, so what you can do is create several repositories with different retention settings, create different jobs for Exchange/SharePoint/ODFB and point each job to the corresponding repository with the retention specified the way you need it.

[IndyBri]

Got it...and thank you all.

I have some redesigning to do I think. No worries.

[thomas321]

Hi,

what is the maximum retention you can select for Mails, Sharepoint and Onedrive data?

Thanks!

[Polina]

You can set to keep them forever

[stvajnkf]

Polina just deleted my post and gave me a "board warning" because I posted a much more complete and helpful answer than hers, claiming that my answer only duplicated her answer. The exact wording is "Please respect other community members and avoid creating excessive posts which duplicate the existing information in the same thread."

Polina, your answer to thomas321 is 7 words long and has no details or other helpful information. Mine was much more thorough, and was thoughtful enough to warn thomas321 about a very harmful problem he could run into if he misunderstands this poorly documented feature. I request that you un-delete my post and keep this one public as well for honesty and transparency purposes.

Worst of all, look up a few posts and you'll see Polina committed exactly the same offense that she accused me of with her reply to IndyBri. I posted a nice thorough answer, and a few minutes later, she posted a very short answer with far less information. Now, I respect her post and don't believe that is worth assigning a "board warning" to Polina over this because she was only trying to be helpful. As a matter of fact, some duplication of information is actually a good thing as it proves that the information is more likely to be correct since multiple people posted it. However, if Polina finds that any duplication of information deserves a board warning, then Polina, please assign yourself a board warning for your offense to this thread.

[Gostev]

I sincerely apologize for this action by Polina. She's new to the PM team and it was my mistake to provide her with the moderator rights until she is well trained.

One of the cornerstones of these forums has always been the fact that we never delete user posts which are on topic and don't violate forum rules. Based on your description, there was absolutely no reason to delete your post. Even if it completely duplicated someone else prior answer but in your own words, it may still help other people - specifically because of using a different words to explain the same thing. Also, such posts help other users find this topic by ensuring more key words and search terms are leading to one.

So I take this issue very seriously. I will investigate this with her and her manager, and update here on the results.

Unfortunately, your post appears to be "hard deleted", but hopefully she made a copy of it before deleting.

[mweissen13]

Hello stvajnkf!
Thank you for your post. This really caught me off guard; as i was not expecting Veeam for O365 to work that way. Of course our customers are expecting a full restore of their Mailbox *exactly* the way it was for example 7 days ago, *including* mails which were received a long time ago. Many of our customers keep everything online, in other words their mailbox is at the same time their archive and they would burn us alive if they lost that data.
So at the current state it seems to me that the only working solution would be to set retention to "forever". This would however upset other customers who regularly delete their old mails and don't want to pay for the backup storage deleted mails use after the mails have been deleted. Luckily, we are in the habit of creating a repository per customer, so it's not a problem for us that this can only be set at the repository level.
But this is a *serious* issue for us, too.

thanks again,
Michael

[Tijz]

Hi stvajnkf,

I was just heading to the forum to create exactly the same post, but I think you stated the problem perfectly and clearly. Retention policy of Veeam for O365 is very counter intuitive and makes no sense for most use cases we can think of. Here's to hoping that Veeam fixes this in a timely manner... For now just using the forever retention...

On the other hand, I also tried two other products for O365 backup (Datto and SolarWinds), and both seemed to have the exact same behaviour regarding retention (Datto for sure). So maybe there is a reason for this (might it be due to an API limitation of O365?)

Thanks,
Mattijs

[user2]

Is this behavior only for backups of O365 or does this also apply to backups for on-prem Exchange?

[Tijz]

Hi user2,

When using the Veeam for Office 365 product, only this retention mechanism is available. It doesn't matter if you backup an O365, on-prem exchange or hybrid source.
If you manage the servers of the on-prem exchange as well, I would consider using Veeam Backup & Replication, and using a regular GFS retention scheme.

[ejenner]

So if you were to create an Exchange job which backed up full databases you wouldn't have any problem?

[stvajnkf]

Thank you Gostev. I actually tried to delete my last post about the board warning a couple days ago, after I cooled off, but the forum wouldn't allow me to delete it. I don't care to hurt Veeam over this, especially after you handled it so well, so feel free to delete that post. Thank you

[stvajnkf]

Hi stvajnkf,

I was just heading to the forum to create exactly the same post, but I think you stated the problem perfectly and clearly. Retention policy of Veeam for O365 is very counter intuitive and makes no sense for most use cases we can think of. Here's to hoping that Veeam fixes this in a timely manner... For now just using the forever retention...

On the other hand, I also tried two other products for O365 backup (Datto and SolarWinds), and both seemed to have the exact same behaviour regarding retention (Datto for sure). So maybe there is a reason for this (might it be due to an API limitation of O365?)

Thanks,
Mattijs

Thanks for agreeing. I think this issue needs a lot of urgent attention so your post helps other people learn about it too.

Not trying to advertise for anyone here, but I'm currently using CodeTwo Backup for Office 365, and it seems to work correctly in this way. It backs up ALL the data. My biggest problem with CodeTwo, which is why I'm researching Veeam, is that CodeTwo creates a unique file for every single email it backs up. So if you have 1,000,000 emails, you'll have 1,000,000 files on your backup drive, and that makes it super terrible to manage. Moving that many files around or changing permissions on them takes forever. CodeTwo has ignored my multiple requests to fix that issue. Another issue with CodeTwo is that their software sometimes breaks without any notification, and I realize weeks later that there's some bug with the license or something, and I have no backups for the past few weeks. And just now, I am noticing that the backup data seems corrupt because lots of my data is not recoverable. So I don't recommend CodeTwo unless you monitor it closely.

[stvajnkf]

Is this behavior only for backups of O365 or does this also apply to backups for on-prem Exchange?

I've never tried using this to back up on on-prem Exchange system, but if you're using the program called "Veeam Backup for Microsoft Office 365" then I'd expect that this issue applies to you too. Check the Retention Policy on your backup repository, and if you don't have "Keep Forever" selected, then you're probably not backing up lots of your data and you're vulnerable to major data loss.

[stvajnkf]

So if you were to create an Exchange job which backed up full databases you wouldn't have any problem?

Sorry, I'm not clear exactly what you're asking. It will help us understand your question if you specify the exact verbiage used in the program for the window title you're looking at, the setting you're looking at, and the actual value you selected.

[ejenner]

I think it's very clear actually. There are two kinds of Exchange backup. You either blindly backup the Exchange database so you can restore the entire server or you backup Exchange items. Granted, that may be one in the same thing in the case of Veeam but historically those two kinds of backup were distinct. So if you have the whole database you should be able to restore the whole database.

[stvajnkf]

@ejenner
Nope, still not clear. Now I wonder if you're even talking about Veeam's software at all.

You said "create an Exchange job" - Are you talking about creating a backup job from within Microsoft's Exchange software or a backup job from within Veeam's software? If Veeam's software, which software? They have multiple programs that can back up Exchange databases. If Microsoft's software, then why post that here, especially in this thread discussing Veeam's software? See the confusion?

You also said "which backed up full databases" - Obviously, if you truly backed up full databases with any reasonable program, then the data within those databases would be protected. But the issue this thread is discussing is the fact that VEEAM's software is misleading/confusing about whether a full backup is actually being done vs a partial backup. If you're confident that you're backing up "full databases" then you should be good to go. But if you're using Veeam's software and haven't read the PSA thread (veeam-backup-for-microsoft-office-365-f ... 55247.html), then I highly recommend you review that information for your own safety, to ensure that you're actually getting full backups out of Veeam.

[Polina]

Hi EJ,

To protect your on-premises Exchange Server, you can use either Veeam Backup for Microsoft Office 365 (VBO), or Veeam Backup & Replication (VBR).

With VBR, you indeed can create a full image-based VM backup and recover the data using application-item restore, FLR or recover the entire VM. VBR also allows for maintaining simple or GFS retention policies.

VBO offers a different backup (and retention) approach when you archive only the Exchange data itself, while still having the benefits of application-item level restore.

Hope this helps.

[AlexB82]

Completely agree with the first post. We have our retention policy set to "Forever" as I don't want to run the risk of only doing x years, and data being missing if a restore is ever needed. I can see why Veeam chose to implement this definition of "retention", but there's a big risk of lots of data not being backed up. If the data exists on the production servers, it needs to be included in the backup job.

[Polina]

Hi Alex,

We plan to make the corresponding changes in the next product versions. Thank you for the feedback!

[nmace]

I wholeheartedly agree with this post. We have been B&R users for years and just recently moved to O365 and Veeam for O365. It was very confusing to get the retention policy setup. I realized we had a problem when I mis-configured a O365 email retention policy and accidentally deleted a bunch of data out of my own Online Archive mailbox. I went to restore from Veeam and because I had the retention policy for Veeam set for 30 days (and all of the deleted emails were *years* old). It had also aged out of the dumpster on my mailbox. I'm lucky it was only my data and not a user's data.

Anyway, we have the retention policy set for Forever just because that's the only way to get what we need. I need the retention policy to work like it does for backing up on-prem Exchange mailboxes.

[Polina]

Hi nmace,

I'm sorry for the inconvenience you have had and hope this won't happen to your data in future. We have already updated the documentation with a more explicit explanation on the current retention mechanism to avoid any possible misunderstanding, and also plan to add an alternative retention behavior in the next releases so that you could choose the option that better fits your needs.

Thanks!