Golden Rule for VB365

[Zew]

Hello all,

I want to make this post to clear the air a little bit, and I wanted to state my opinions on the matter. Which I know may not be agreed with, but I wanted to air my grivences.

1st and foremost, I understand the current "support model" to apply the 3-2-1, or 3-2-1-1-0 rule of backups in terms of VB365. Which is setup and install a new dedicated server for VB365, then use VBR to ensure alternative dataset are available. Here are my issues with this design.

1) It assumes anyone using VB365 is already using VBR.
2) You shouldn't have to rely on a company's other products to have a full support backup chain.

E.G. if you had just basic M365 users, with some basic M365 mailboxes, you should be able to back them up to a local repo and point it to a secondary destination (or more) right in VB365.

2nd If someone who already is running VBR, should be able to utilize that servers storage to save backup to regardless of the storage medium.

E.G. VBR setup utilize a iSCSI disk, using a NTFS filesystem. No other servers and use this storage medium unless it was shared out through additional overheard (SMB), which is unreal heavy (in terms of resources)

Here is the thread I created asking about it, post454450.html#p454450 but not recommended for the verify difficulty in following the 3-2-1 rule.

Which is unreal unfair to anyone wanting to just use VB365. OK logical rant over. Now I did an all in one setup (sole due to the 2nd point note above, storage), I then attempted to following to have a copy backup.

Create a file based backup, that targets the original M365 backup data, point it to a secondary storage point.

However to my dismay it appears the files are locked by (what I presume is the VB365 service), which is probably why Fabian(Mildur) said "It is possible to do that when you have installed it on the same server, but getting a second copy of the data will be complicated." but did not go into details.

As unfair as it really is (as stated above as to why its unfair), I would like to attempt an alternative method were I break out VB365 as its own server). As such what would my steps be?

1) Setup new server, install VB365
2) Stop VB365 service on VBR
3) copy and move all m365 Data manually to new VB365 server
4) tell new VB365 server where the data is
5) validate backup n recovery
6) uninstall VB365 from VBR

Does that sound correct?

[Mildur]

Hi Aemilianus

E.G. if you had just basic M365 users, with some basic M365 mailboxes, you should be able to back them up to a local repo and point it to a secondary destination (or more) right in VB365.

That‘s already possible if you use object storage (local object storage is also supported) as a backup repository. You can configure a backup copy job to AWS or Azure Archive Storage. For local block storage, vbr or our Agent still must be used.
Object Storage is the recommended storage solution, especially for doing backups of bigger M365 Tenants with thousands of objects.

Create a file based backup, that targets the original M365 backup data, point it to a secondary storage point.

However to my dismay it appears the files are locked by (what I presume is the VB365 service), which is probably why Fabian(Mildur) said "It is possible to do that when you have installed it on the same server, but getting a second copy of the data will be complicated." but did not go into details.

If you use block level storage for VB365, then our product stores the backed up data in database files (for each year a *.adb).
If you use the same server for VBR and VB365, there are two methods to do a backup of the database files to have a second copy.
What I meant with „complicated“ was the requirements for the volume level backup based method. The file based backup method brings another disadvantage.
See below the two methods.

Volume Based Backup Job
If you want to use volume based backup jobs, VB365 should use a dedicated volume.
Or you will end up doing a backup of volume D where the VBR files and the VB365 files are stored. If VB365 uses his own volume (drive E as an example), then it‘s easy to do the backup or just drive E (and probably drive C for the configuration).

The complicated part is that VBR servers most likely have only two volumes on the VBR server. One for OS, one for the backup data. If you don‘t have a dedicated volume for VB365, volume based backup doesn‘t make much sense to me.

Filebased Backup Job
The issue with this filebased approach is, that you will backup the entire database file each time again.
Imagine you have 3 years of M365 data backed up. Each year, the backed up data size was 300GB. Now you run a daily file backup job to protect the database files to a tape or linux harden repository. Each incremental backup will backup 900GB, because the source files are changing every day.
My recommendation, forget any file based approaches for this scenario.

As such what would my steps be?

1) Setup new server, install VB365
2) Stop VB365 service on VBR
3) copy and move all m365 Data manually to new VB365 server
4) tell new VB365 server where the data is
5) validate backup n recovery
6) uninstall VB365 from VBR

Does that sound correct?

You can find the prerequisites and steps in our Kb article. https://www.veeam.com/kb2649

So far, it looks good, but you must reconfigure the organization and all backup jobs after step 4.
The first Backup will take a little bit longer to verify that we have all items in the migrated repository, but it will be only an incremental backup.

Thanks
Fabian

[Zew]

That‘s already possible if you use object storage (local object storage is also supported) as a backup repository. You can configure a backup copy job to AWS or Azure Archive Storage. For local block storage, vbr or our Agent still must be used.

This is exactly the issue I'm talking about in my initial posting. You should be able to Follow the 3-2-1 rule natively in VB365 using nothing but bloc storage. It's as simple as that.

Since this ability was not built into VB365 (Why, I'd really love to know).

As for supporting large deployments that's fine, but this reminds me of the Backup Copy Job fiasco where I stated Customers should have a much simpler option available for backup copy jobs, and Veeam finally got the hint and provided a new type (As new restore point are available) vs the original type of (Continuous), in which Veeam made the exact same excuse (We didn't give you a simple option to support complex situations), which I can't seem to find any of my posts around that but I did find the one where the new feature was introduced but people couldn't just switch to it with their current backup jobs. veeam-backup-replication-f2/backup-copy ... kup%20copy anyway....

The point here remains the same, it's pretty redic to have to rely on either Object Storage or VBR to complete the 3-2-1 for M365 data. Customers *should* be able to utilize block storage right in VB365. Cause if this was built in it would be far easier to support an all in one Veeam server to backup On prem with VBR and cloud with VB365 while having 1 server to maintain, and one blockstorage.

Oh and salt on the wound... "At the time of writing this article, there is no way to export the configuration of Veeam Backup for Microsoft 365. As such, on the new server, all organizations and jobs will have to be recreated. If the steps below are performed correctly, the first run on the new server will be "incremental." The UI will show that a full is occurring, but only incremental data will be transferred."

Sure am loving this stuff...

[Mildur]

Thanks for the explanation. I understand your frustration. Unfortunately, that‘s our product works today.
But your concerns are noted. I saw you Feature request in the other topic for the copy job.

there is no way to export the configuration of Veeam Backup for Microsoft 365.

I‘m counting this as a request for built-in configuration backup of the VB365 configuration database. As my colleague Polina commented, it‘s already on our roadmap.

PS: Switching Backup Copy Job mode in VBR is planned for V12.

[Zew]

Thanks for listening.

PS: Switching Backup Copy Job mode in VBR is planned for V12.

That is very exciting to hear.