One file for Repository DB - and the questions that creates

[DEG]

Hi all,

im working for a small company with apx. 400 mailboxes.
I have a dedicated physical Server 2016 with 60TB local storage in RAID10 and the Veeam products that exists installed.

Backup for O365, have a repository, doing the backups.
But im a bit concerned about the jet blue DB of max 64TB.
Not that im ever going to hit that, but maybe 4TB or 8TB.

What does Veeam do to prevent file corruption? Expect NTFS or jet blue to have it under control?
How do I offload the data to offsite, correctly?
- Im imaging I cant just copy/paste it over my 1gig WAN and expect that to be good - ill find out once in a DR restore scenario, I guess?

I guessing the answer will be to let my B&R backup the O365 repository and use backup copy job for offsite offloading, but it just seems like *alot* when dealing with one file at several terabytes.

My general position on big files is 'dont'
Our datastores in VMware are 1TB or perhaps a bit bigger for a few VMDKS on file servers and SQL servers, but that is pretty much it.

So a 4TB-8TB jet blue DB from Veeam just seems...overwhelming.

Thanks for telling me know you have thought of all scenarios.

[Mike Resseler]

Hi Michael,

We did think of all scenario's .

First, let's start with the beginning:
* Corruption: Jet Blue has its own mechanisms to deal against corruption through logging system. Even in the case of a sudden server crash, the database can easily recover itself by the way it is designed. However, as we all know in IT, never say never and the weirdest things that can happen...
* 64TB size: An Exchange database is the same engine, so I have seen DB's or much larger sizes than 8TB that run stable as long as they have the right amount of resources. Also note that each year a new DB is started. So if you start your backup, items from 2015 will be in a database, items of 2016 in another and so on... So it will most probably (unless they are all new mailboxes) be multiple databases. Also, look at dividing your users per business unit/ title/ whatever you feel is the best into different repositories (and jobs) which divides the data again in different ESE databases.
* Offloading the data can be done by making the VBO server virtual and back it up with VBR. However, it seems that this is not a possibility for you so you can do 2 things: 1 possibility is keep the VBO server physical and deploy a (few) virtual proxies that hold the databases and back up those VM's. (VBR will also recognize it is a VBO proxy server and you will get ILR through there also) or use VAW to backup the data. You can always point the Veeam Explorer manually to the ESE DB for recovery.

Makes sense?

Mike

[DEG]

Hi,

thanks for quick and thorough answer.
I understand you automatically split per year, I have 2015-2018 now. (me migrated from Domino to Outlook last year so almost all my data is in 2017 as the mail objects are copied from Domino to Exchange Online).
To that I will say that large companies must have gigantic files, have the same thought as I, and then split as you mention with a repository per department/geolocation etc.
I have created backup jobs per department, but I expected Veeam to save a DB per mailbox for:
- minimizing DB file size
- segmenting so if the file is corrupt you only use that DB and not ALL for that entire year
- offloading to offsite server easier.
I think I will split into different respositories, its just an unnecessary administration overhead and im thinking back to my old Backup Exec where you have an instance per server you backup which is annoying.
If just Veeam would split per mailbox a lot of headaches whould have vanished.

Regarding offloading I can do what I want, make the server for VOB virtual etc. it just creates a more complex backup setup.
For a start I will go with VAW which already is running on the physical veeam server.

Will VAW be smart enough to look into the jet blue DB and only do changes(both backup new mails added to DB AND delete items as retention policy purges the DB) ?
The solution will be mounting an iSCSI target on the physical server for offloading using VAW, so im of course only interested in moving deltas but please elaborate on that in regards using VAW for this method.
The iSCSI target will be plenty fast on a 1Gig WAN link over VPN.

[Mike Resseler]

VAW will be smart enough when you perform entire computer backup (that is based on snapshot technology). when you do file-level backup, it won't

[DEG]

So to nitpick:
I must do a backup of the entire VM running VAW - then only deltas will be moved offsite, yes? (and that would be on a lets pretend static VM with only VAW installed, only that one single mail at 50KB it would have to move offsite?)
And if I did only "D:\O365" folder, on VAW VM, then it would do a full on that folder, everytime, yes?

[Mike Resseler]

Correct.