This is because only a cache is kept locally on the VB365 repository server when object storage is used. Namely, object storage and backing up the VB365 server and/or repository server(s) is incompatible. Whilst it’s certainly possible to protect the VB365 server, this scenario creates certain restrictions. However, this scenario changes when we start to utilise multiple applications, such as for the multiple backups, whereby it’s quite possible we could hit tenant-level throttling and impact the users working with the Microsoft 365 tenant, creating a bad user experience. Microsoft attempts to limit the wider impact of throttling by utilising the per-application throttles, preventing one application impacting all users. Microsoft apply per-application and per-tenant levels of throttling, and creating multiple backups can generate throttling events, especially during the initial backups.
#Cloud backup for veeam full#
The main drawback to taking multiple full backups, is the Microsoft enforced throttling policies that apply when VB365 is fetching content from the Microsoft 365 tenant. As I’ve not discussed these previously, lets highlight some key drawbacks of these approaches: Historically, we would need to achieve these three copies of data by either taking multiple full backups, or backing up the VB365 server after it had successfully taken a backup. As part of Veeam’s 3-2-1-1-0 backup best practices, we should have a minimum of three copies of data. VB365 v6 brought a strongly requested feature to the VB365 product, backup copies. New VB365 Feature: Backup Copies to ANY object storage Not only do I want to talk about these two features but, most importantly, how they are related to each other. Today I want to talk about not one, but two new features in Veeam Backup for Microsoft 365 (VB365) v7, these are: Immutability, and Backup Copies.
0 kommentar(er)
