Export to PST only saving partial mailbox

[pawel]

We have a mailbox that has well over 100,000 items in it and we're trying to use Veeam to save a copy of the mailbox to a PST file. However, the final export only has a little over 11,000 items and the file size is a small fraction of the full mailbox (3GB vs the actual 60GB mailbox size).

What is the reason for this? I tried using the limit PST size option as well as leaving it off. I tried exporting a folder at a time, and only partials of that folder were exported. I'll open a support ticket a bit later but curious if this is a widespread issue before I do that.

I have version 3 of Veeam Backup for Office 365 installed (3.0.0.422).

[Polina]

Hi pawel,

I'd check the retention settings first. Some items might be either not backed up (if you use item-level retention), or might have been cleaned up from the repository according to the specified retention period.

[pawel]

Thanks, this is pretty nuts. I found the documentation on this and looks like our retention wasn't set properly (item level vs snapshot):
https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=40

Maybe I'm crazy but the item level retention seems like a really dangerous option that should maybe be emphasized a bit more in the interface when a user selects it? According to the documentation if your item level retention is set at let's say 180 days then any item created 181 days ago no longer gets backed up (not only that it gets deleted from your backups). Even if that item was modified a day ago. This is insane. And from what I think most people understand retention to mean that is counter to how things usually work.

Also, not being able to change this setting after the fact isn't great either.

If I'm mistaken on how any of this works please let me know.

[Polina]

VBO offers two retention types, Item-level - one of them. This retention is based on items modification date and it also defines which items are backed up. For example, if your repository is configured with the 7-days Item-level retention, a backup job will only capture items modified within the last 7 days. Here's how it's described in our documentation: https://helpcenter.veeam.com/docs/vbo36 ... ?ver=40#ar

[Polina]

pawel,

Your understanding is correct. These different retention policies have been designed to fit different needs and for many scenarios, the item-level approach would be a preferred one and a better fit.

Now, thinking of how to resolve your current problem, I'd suggest the following: create a new repository with the desired retention policy, move there the existing backup data with PowerShell and point the backup job to the new repository. One the next job run all the missing data will be transferred to the new repository. This thread might be helpful.

[pawel]

Thanks for the quick reply. I don't see how an item-level approach is better. It seems like an insane approach where any files created before your retention will never be backed up. We have various company files that were created years ago that get modified daily. With item level these items would no longer be backed up unless our retention settings are configured to keep years of data. We also have users that need their emails going back years; same issue there where those emails are not going to be backed up.

Maybe this works for some orgs; but I think Veeam needs to do a better job in the interface of explaining the ramifications of what will and won't be backed up with item-level retention especially since that is the default option and based on what you're saying it seems to be Veeam's recommendation.

Finally, thanks for the link on moving item level retention repository to snapshot. But the documentation for Move-VBOEntityData states it does not support this type of migration; so I'll start fresh so I can have a supported setup. I see in your post on that thread that this needs to be changed in the documentation; but I can still see that note there.

[Polina]

Hi pawel,

Here on forums, there were many hot discussions about the benefits of each of the retention types, and I must admit that you're not alone in thinking that the Snapshot-base type should become the first suggested option in the wizard. For now, I can't promise any changes, but your feedback is heard and noted.

P.S. The documentation is now updated and the misleading warning has been removed.

Thanks!