[Feature/Fix Request] Mail-items Receive Date

[iPhome]

Hello!
We encountered a really great problem (at least for our company, but I think many companies might get this issue too in the nearest future).
We have an O365 Tenant and Veeam Backup for Office 365. Our company currently migrates all mail-items from our Postfix servers to Exchange Online. We aren’t using any third party software, only the standard Exchange Online migration tool. We have migrated almost 4Tb of mail items by now, totally we have 20Tb of mail.
The problem is that the most part of our mails is copied/backed up only to Database named “2018”.
Our VBO Server is a virtual Windows Server 2012. The only working service is VBO. We have only one simple backup task – backup all except 3 mailboxes. We have only one directly attached disk, most of it allocated as a repository for VBO. In the root folder of repository, VBO created many child folders naming from 2005 to 2018, containing database files, logs and others. I thought these folders were equivalent to mail-items receive date and that’s might be good for us in the future (for example, we could copy these folders and database to another disk for archive, or backup it to tapes and enable retention policy). But most of these folders (from “2005” to “2017”) occupy 35Gb only, and the folder named “2018” occupies 3,7Tb. And this is a problem. We have a very huge backup database and it is growing and we can’t do anything with this. Making many repositories is not a solution – we have almost 1500 employees in our company, and creating many backup tasks for equable disk space utilization in various repositories would cause a lot of inconvenience and routine work. Furthermore, this will entail continuous backup to tapes – at the beginning we planned to make only one time backup to tape of all old mail for archive.
I created a Support Ticket (Case # 02974722) with this issue, and after some logs searches, the support engineer told me, that the problem is that VBO checks attribute “last_modified_date” for items. So, if we migrate all our mail in 2018 year – all of our mail items will have “last_modified_date”=2018. It’s terrible! And it doesn’t answer the question – why does VBO create many folders in the root folder, if it doesn’t backup mail items to these folders? Can you add another parameter for checking message date in the nearest future? Or maybe you could make patch, or script for the database fix? I think, many companies, that have mail for last 10-15 years, might get the same issue. We really need it fixed – keeping all mails in one folder regardless of their date is fundamentally wrong and might cause serious problems in future. Furthermore, using 20Tb of disk space is too expensive, especially when you have many tapes for this purpose.

[Mike Resseler]

Hi Maxim,

First: Welcome to the forums!
Second: It is correct that we backup on last modified date and not on creation date. This is to find incremental changes that have been done to items (think for example a contact that has been changed after being created, you don't want to miss that because the creation date remains the same but that would also mean that the change would not be protected)

From what I can see here, this means that the migration tool changes the modified date of each item whenever it is being created although some of the items their modified date (could be the folder structure) did not change otherwise you would not been able to see the folders from 2005 to 2017.

To be sure about this, could you look into Outlook of one of these new mailboxes, select an older mail and press ALT-ENTER to see the properties of that email. You should be able to see the modified date.
Second: What is your retention that you put on the repository?
Lastly: I am not sure what is the reason behind not being able to create more repositories? You can create multiple repositories per proxy server so they would all point to the same storage that you dedicated.

Let me know
Mike

[iPhome]

Hello Mike!
Thanks for your quick answer but the reason why you chose the last_modified_date attribute for backing up mail items seems not applicable to mail items as mail itself. It is a reasonable choice for backing up simple office files on a file server which are modified frequently and their modification_time changes as well. We are talking about mail messages which are received once and changed only once as well. We often edit contacts and distribution lists in our mail client but I cannot imagine why we should edit mail messages we received. I think backing up mail messages should be smarter and should analyze message headers primarily.
The first e-mail message in my outlook has a received_date and send_date of July 2017, but modified_date is April 2018 (date of migration of my mailbox).
We have no retention policy now. We can’t use it for our mails if it respects the faulty modified date attribute only and not the mail headers of messages. With the retention policy set to one year we would loose ALL our backed up mails in 2019, isnt'it? We were planning to use retention after all of our mail-items are migrated to O365. The idea was to backup all folders (VBO folders in repository) to tape, except 2016-2017-2018 for archive and then enable the retention policy, for saving only last 3 year of mail in VBO. And after that, in the end of each year, backup to tape another one folder.
Creating many repositories is not a problem. But as I understand, if you are using a few repositories, you must create a few backup-tasks. And then, each new employee must be added to backup-task manually. And I can’t create only one task, which will backup all mailboxes and choose the needed repository automatically. Correct me please if I'm not right. We have up to 20 new employees almost per day, and changing the backup task every day is tedious. Another problem is that we do not have an infinite disk space. Like I said, we have 20Tb of mail now, next year I think it will be 22Tb, and the next one is 24Tb and the next one…etc.
We need only one-time archive backup to tape for old mail after migration and it will be comfortable for us to do it per folder, not per user or per repository. If for some reason in the future we would need to restore mail-items for 2005, we could restore only this database folder, not all 20Tb of mail.
But now, we have the situation, that we can only backup all of our mail, and the backup it is one huge folder. How much time would 20Tb of mails back up to tape? A week?)) And how much time would it take to be restored?
Maybe we can somehow change the modified_attribute of all our mail-items so that it matches the received or sent date header and the mail is backed up to corresponding year folder? Or maybe you could add some feature, that admins could choose which attribute to respect for backup?

[mdaniels]

Interesting topic Maxim, we have just recently spent a few weeks investigating an issue with Veeam and Microsoft in regards to BigFunnel. It would seem that BigFunnel is modifying online archive/shared inboxes which is causing Veeam to backup the same emails over and over again. Our repository has almost tripled in size since we confirmed what the issue is related to, however we also experienced this only because Veeam office 365 uses the last modification date to determine what items need to be incrementally backed up. Having the ability to choose which attribute could be used for backup would have been beneficial for us in this specific case, but understand it will require a bit of work.

[Mike Resseler]

Maxim, Matthew,

I think what you are seeking (correct me if I understood wrong) is more the system that VBR uses. Restore points per day (or multiple times per day) so you can have the exact state of the mailbox (or mailboxes) on that exact moment.

Maxim: What you specifically are seeking is going to be a challenge for the VBO architecture at this moment I'm afraid. Some things you can do (starting from v2 you will be able to select O365 groups/ distribution and dynamic distribution lists and mail-enabled security groups, which will make the automatic adding of users possible. So working with different jobs will be possible then).

Working with those yearly folders and archive them off will be more challenging and I am not sure if that is possible. When you start a recovery, you will see items from the 2015, 2016, ... folder in the veeam explorer so I don't even know how that will work.

For the attribute, that could be challenging also. For example, Exchange online will change the modified date in a thread when a new reply is received. So if we would use the created date, and you restore a message from 2018, you risk in losing the entire thread when that one came in 2017.


Certainly all food for thought on our side, but not something that will arrive quickly.

From my point of view, I would suggest to look into installing VBO on a virtual machine, set a short retention range (30 days maybe) and then backup that VM daily with VBR (and save it to tape). VBR will recognize that backupped VM as a VBO server, which means you can do item-level recovery from it, without the need of restoring the entire VM. Not 100 percent sure if it will fits your needs, but I think interesting to investigate.

@Matthew: My google skills seem to fail me today, what is BigFunnel?