The 3-2-1 rule is one of the basics when talking about data protection. This best practice tells you to have:
- Three copies of the data
- Stored on two different media
- of which one should be off-site (and maybe also offline)
You should consider these rules also during your planning of the backup for Microsoft 365. As a result it is important to protect the Veeam Backup for Microsoft 365 deployment against accidental loss. Protecting the Veeam Backup for Microsoft 365 deployment ensures Availability for the infrastructure components and more importantly for the data in the Veeam Backup for Microsoft 365 Backup Repositories.
A Veeam Backup for Microsoft 365 deployment can be either on a physical or virtual environment. As with both virtual or physical server installations, Veeam Backup & Replication™ oﬀers all the tools for application and crash consistent backups of VB365 deployments.
Each VB365 Server and Proxy installation includes a specific Veeam VSS writer. You can identify it by running
vssadmin list writers on the commandline:
|Writer Name||Veeam Backup for Microsoft 365 Writer|
|Writer ID|| |
This VSS writer ensures application consistent backups of the VB365 infrastructure components. Even while the VB365 Server and Proxies are running backup and restore jobs of Microsoft 365 data. Protecting a VB365 deployment with Veeam Backup & Replication (VBR) oﬀers the following advantages:
- Ensures swift VB365 components restores (ConfigDB, ProxyDB and associated files)
- Performs granular item restores from local repositories in the backup using Veeam Explorers available on the VBR Server (Veeam Backup and Replication 9.5 Update 4 and higher)
- Offload the backup data to an alternative location like Tape.
The protection planning must also include the additional VB365 Proxy Servers and Repositories. Should the VB365 Backup Repository use SMB shares, such shares need to be backed up separately. The configuration (ConfigDB) and Proxy (ProxyDb) folder on the VB365 Server and VB365 Proxy installations are very important. They include all the information and details for the VB365 infrastructure configuration. Restoring these components from a backup is the quickest way to maintain the existing (running) configuration without affecting the rest of the VB365 deployment and its jobs. Protecting a VB365 Server and its infrastructure is critical with advanced deployments. Having a protection plan which covers all components allows for agile recoveries of all Veeam Backup for Microsoft 365 major components: VB365 Server, Proxies and Backup data in the local repositories.
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.
Be aware that due to the nature of VBR’s image backups no backup of object storage repository content can be done.
Due to increasing popularity a special mention goes to the object storage. Since VB365 v4 Veeam supports the usage of object storage natively within VB365. Either in private or public clouds. Object storage is a good candidate for storing backup data as there are several cost-attractive solutions on the market. When using object storage VB365 is using a local cache for optimization and efficiency. This cache is metadata and is synchronized to the object storage to ensure availability. When the local VB365 cache gets lost it can be recovered from the object storage. Most object storage solutions can ensure data redundancy by storing all objects on multiple geo-locations/cluster nodes/hubs depending on the chosen solution. As all VB365 data and cache is stored within the object store these options can also support you to achieve the 3-2-1 rule.