VBR application aware restore doesn't list all VB65 backups

[brkdncr]

* i'm backing up m365 data daily to a vb365 local repository that keeps the data for 1 week.
* I'm backing up the vb365 repository/proxy daily and keeping the data for 3 weeks using VBR
* I'm expecting to be able to restore items from 1 month. If today is 1/22, i'd expect to be able to go back in time to 12/22. 
* I use VBR to perform an application restore for Exchange data on the proxy and am presented with the oldest restore point of 1/12.
* If I open that restore point, Veeam explorer for MS Exchange doesn't ask me what vb365 repository point in time i want to look at.

I know the vb365 repository/proxy that i backed up has data going back to 12/22. how do i get access to this data?

Veeam Explorer for Exchange v 11.0.1.1261/1401
vb365 7.1.0.1401 p20231218
vbr 11.0.1.1261 p20230027

[Mildur]

Hi Brkdncr

* i'm backing up m365 data daily to a vb365 local repository that keeps the data for 1 week.
* I'm backing up the vb365 repository/proxy daily and keeping the data for 3 weeks using VBR
* I'm expecting to be able to restore items from 1 month. If today is 1/22, i'd expect to be able to go back in time to 12/22.

I recommend to not rely on VBR to extend retention longer than the 1 week of VB365.
VB365 should be configured to keep backups for 4 weeks, if your business requirement is to keep backups for 4 weeks. This makes restore much easier. VBR is only used in case of a DR scenario.

* I use VBR to perform an application restore for Exchange data on the proxy and am presented with the oldest restore point of 1/12.
* If I open that restore point, Veeam explorer for MS Exchange doesn't ask me what vb365 repository point in time i want to look at.

In VBR, the most recent VB365 restore point will be automatically loaded in the explorer. If you choose to recover from the 1/12 VBR restore point, you will get the VB365 1/12 restore point.
If you want to restore from 12/22, you need to use instant recovery to power-on a backup of the VB365 server as a new VM. Use RDP or similar remote tools to connect to the VM, open the VB365 console and then start your recovery from the 12/22 restore point.

Best,
Fabian

[brkdncr]

I want to tier my vb365 backups from expensive storage to cheap data domain storage. how do i do this without also having to jump through extra hoops? the best practices documentation doesn't say there are limitations to app-aware restore.

I now have to look into finding budget for additional storage, or look at using a different product altogether that's much cheaper to account for this oversight.

https://bp.veeam.com/vb365/guide/design ... h_vbr.html

"Protecting the VB365 deployments using the Veeam Backup and Replication solution (VBR) allows to send and manage independent copies to separate storage tiers for longer retention. Using VBR this can be a Scale-Out-Backup-Repository, Tape or a Cloud-Connect Provider. VBR is using the VSS integration of VB365 for application consistent backups of the VB365 data. Additionally VBR recognizes the dataset and allows you to directly restore single-items out of the image-based backups using the regular explorers within VBR."

[Mildur]

Hi Brkdncr

To be honest, I don't expect huge space savings with your retention of 4 weeks. And the jet database files in your VB365 repositories will keep their size, even if your retention has deleted a restore point. They won't get smaller and are still using your "expensive storage".
What's the daily change rate? And are you deleting a lot of files in your M365 tenant? If your M365 users never delete any data, then the VB365 repository will keep growing and your tiering approach to save storage will not get the space saving you may expect.

Our recommended repository type for VB365 is object storage. New repository features will most likely come for Object Storage repositories only. And Object storage repositories for VB365 gives you approximately 40-50% compression for the backups.
You could use a copy job to copy the data to a cheaper object storage solution and also make it immutable. The source job can have your 1 week retention, the copy job 4 weeks.
In my opinion, this is the better approach for your use case. Backups are deleted on the primary repository after 1 week, and all copied backups are available for restore in the VB365 backup console without needing any "hack" such as instant recovery.

Best,
Fabian

[brkdncr]

Thanks. suggesting we replace our existing backup storage infrastructure and change retention to a week doesn’t address the issue that vbr doesnt support vb365 that well.

[Mildur]

Hi brkdncr

I never suggested to change retention to 1 week. 1 week of retention for VB365 was mentioned by you in your starter post:

* i'm backing up m365 data daily to a vb365 local repository that keeps the data for 1 week.

Best,
Fabian

[brkdncr]

Your recommendation is noted. I'm asking that VBR implement a feature so that VBR presents a point-in-time prompt during the app-aware restore of vb365 so that I can continue to use our backup infrastructure instead of primary storage.