Within this blog post, I will talk about the different protection levels of your Veeam backups that you can achieve with different concepts and technologies. An important role is played by what protection goals you want to achieve. I will try to elaborate a bit on which Veeam Backup Protection Levels can solve which problems.
A concept you often hear in the Veeam Backup & Replication context is the 3-2-1 rule.
-
3: You must have at least three copies of your data: the original production data and two backups.
-
2: You must use at least two different types of media to store the copies of your data, for example, local disk and cloud.
-
1: You must keep at least one backup offsite, for example, in the cloud or in a remote site.
These rules are still important and valid, but they are no longer suitable for all protection goals without additional actions.
Note:
I don’t go into all the protection goals of backups in general (e.g. guest operating system corruption), but focus on the various concepts of Veeam Backup Protection Levels.
On-Premises Base Level of Protection
The On-Premises Base Level of Protection is from my perspective a concept that at least covers the 3-2-1 rule. The problem is that it is no longer equipped for all the challenges of the current threat situation.
Protection goals:
-
Primary Array Failure
-
Secondary Array Failure
-
Primary Site Failure (limited without DR Site)
This is a pretty common concept with Secondary Storage (Fast but not that much capacity) and an additional Deduplication Appliance (Slower bur more capacity), both On-Premises but the Deduplication Appliance is located in a dedicated site.
Base Level of Protection
Replacing your Backup Copy in a different site of your own environment with a Cloud Connect Repository in a cloud provider site adds another level of protection and addresses the current threat situation much better.
Protection goals:
-
Primary Array Failure
-
Secondary Array Failure
-
Ransomware Encryption in your On-Premises Site (high RTO though WAN)
-
Unintended or malicious loss of data in your On-Premises Site (high RTO though WAN)
-
Primary Site Failure (limited without DR Site)
The second On-Premises copy target is not required to meet the 3-2-1 rule, but might be useful to have good RTOs and have a good retention period on your own site. If WAN bandwidth/reliability is not a problem and Cloud Connect Repository is large enough, the deduplication appliance can be dropped from the concept.
Since this is now the first concept with Cloud Connect, I would like to raise another idea:
Large Enterprises are also allowed to use the Cloud Connect technology. Think about creating your own Cloud Connect infrastructure in an isolated environment that is only reachable via HTTPS to deliver the backups. This might be a pretty good DR Site (On-Premises).
Immutable Capacity Tier
With the rise of ransomware, the demand for immutable backups (unchangeable backups) came up. A simple and cost-efficient way to create immutable backups is an additional copy of the Secondary Storage.
Protection goals:
-
Primary Array Failure
-
Secondary Array Failure
-
Ransomware Encryption in your On-Premises Site (high RTO though WAN)
-
Unintended or malicious loss of data in your On-Premises Site (high RTO though WAN)
-
Ransomware Encryption on your Secondary Storage (medium RTO from S3 Storage)
-
Unintended or malicious loss of data on your Secondary Storage (medium RTO from S3 Storage)
-
Primary Site Failure (limited without DR Site)
To make the backup data immutable in this concept, Veeam Backup & Replication uses the Object Lock technology provided by Amazon and some S3-compatible providers. The data needs to be copied to the capacity tier (S3 Bucket) as soon as the files are created on the performance tier of a Scale-Out Backup Repository (SOBR).
If you do backup verification, you follow the extended Veeam 3-2-1-1-0 Golden Backup Rule. The Dedup Appliance (Second Copy) is not required to meet the 3-2-1-1-0 rule. If the required retention can be met on the Cloud Connect Provider side or with the object storage, it can be removed.
Immutable Performance Tier
With the Hardened Linux Repository Veeam introduced the capability to make the Secondary Storage (First backup Copy) fast and immutable. The same protection goals are addressed with a different concept. In detail, these concepts differ in the “quality” of immutability. S3 Object-Lock is pretty robust against insider malicious activity and the Hardened Linux Repository on the other hand uses file attributes that can be changed by advanced privileged users.
Protection goals:
-
Primary Array Failure
-
Secondary Array Failure
-
Ransomware Encryption in your On-Premises Site (high RTO though WAN)
-
Unintended or malicious loss of data in your On-Premises Site (high RTO though WAN)
-
Ransomware Encryption on your Secondary Storage (low RTO from Secodary Storage)
-
Unintended or malicious loss of data on your Secondary Storage (low RTO from Secondary Storage)
-
Primary Site Failure (limited without DR Site)
Unlike the previous concept, the Dedup Appliance (Second Copy) is required to implement the 3-2-1-1-0 rule.
It’s very important to strictly follow the compliance assessment report and the Deployment guide for the Hardened Linux Repository to guarantee the highest Veeam Backup Protection Levels. All additional hardening should be considered:
-
The server should not have any other role, such as SAN proxy
-
Physical servers are preferable to virtual ones
-
Use Single-use credentials for hardened repository
-
Change file permissions for authentication certificates on the Linux server
-
Configure the host firewall to the least required ports / IPs
-
Limit or disable SSH access
-
Limit or disable Remote Console Access (iLO, iDRAC, etc.)
-
Enable Network Transport Encryption for these Servers
-
Enable Backup Data Encryption
-
Place Servers in a Restricted Network Zone
-
Use locks and dedicated 19-inch racks
Immutable Primary Storage
This might be an (expensive) corner case, but there are Primary Storage Arrays on the Marked that support Immutable Storage Snapshots (e.g NetApp SnapLock or Pure Storage SafeMode SnapShots). The Pure Storage SafeMode is implanted in a way that allows combining is with Veeam Storage Integration for the Backup. This results in the Situation that the Veeam Snapshots are saved for the configured retention on the Primary Storage Array even if Veeam deletes the after the Backup.
Protection goals:
-
Primary Array Failure
-
Secondary Array Failure
-
Ransomware Encryption on your Primary Storage (Normal Storage Snapshots might also help)
-
Unintended or malicious loss of data on your Primary Storage (super low RTO from Primary Storage)
-
Primary Site Failure (limited without DR Site)
JD Wallace confirmed in his blog post Considerations when Enabling FlashArray SafeMode with Veeam Backup from Storage Snapshots the practicability of this concept and highlighted the drawbacks pretty well. One of the most critical risks might be running out of space in case of ransomware encryption of the primary storage (the running VMs). This type of encryption has a huge entropy and all the space savings mechanisms of the primary storage might fail.
Tripple-Play Immutability
This is a shameless plagiarism of Rick Vanovers Blog Post Beat Ransomware with Double-Play Immutability from Veeam to bring all the above Veeam Backup Protection Levels together.
This is a fictional scenario to show the possibilities. Such a need for protection levels will exist for very few customers.
Additional Recommendations
Backup Data Encryption
Backup Data Encryption can be added as an additional “feature” to all of the above concepts and has its own, additional, protection goals.
-
Unauthorized access
-
Data leaks
-
Wiretapping (Encryption takes place at the source)
You should especially consider the first two protection goals because a backup repository is a huge collection of previously distributed data that could be confidential.
A special consideration applies to deduplication appliances: The Veeam Encryption will break all deduplication savings on these devices, so encryption needs to be disabled at the Veeam level. If you use the DELL/EMC DD Boost protocol, native encryption is available, which also takes place at the source (in this case the gateway server).
Network Transport Encryption
Veeam uses Network Transport Encryption by default for public networks, but additional rules can be added. As with the previous point, this is an additional “feature” to all of the above concepts and has its own, additional, protection goals.
-
Wiretapping
-
“Man/Machine in the middle” attacks
Please keep in mind that Network Transport Encryption generates CPU overhead (especially at the source). It should therefore only be used when necessary, e.g. for communication in a DMZ or to a protected zone for the repository servers.
Security Hardening
Security Hardening of your Veeam Backup Plattform is a wide spectrum of possibilities. I would recommend you to go through the Security Chapter of the Veeam Backup & Replication Best Practices and think about each topic and the possible enhancement for your design or current setup.