Veeam

This site uses Just the Docs, a documentation theme for Jekyll.

Search

3.7 Immutable Backups

Veeam Cloud Connect offers multiple options to protect backups from unwanted deletions, being them mistakes or malevolent operations from un-authorized users:

  • Insider Protection
  • Veeam Hardened Repository
  • S3 Object Lock

While they all reach the same goal - avoiding unwanted deletions - the way this result can be achieved and the limits of each solution are different. Hardened Repository and S3 Object Lock are well documented in general Veeam literature, while we have a dedicated chapter in this book for learning the details of Insider Protection.

In this chapter, we’ll focus on answering the ultimate question Which of the three solutions should I choose?.

Insider Protection vs Hardened Repository vs S3 Object Lock

With three different and powerful solutions to protect data from deletion, providers may be wondering which one they should use in their environments. All have their strenghts and limits, and depending on the environment that already exists at the service provider, one solution may be preferred.

Note that price per GB is not a factor we analyse here, but it may be the deciding factor in choosing one of the solutions: some providers may have favorable agreements with specific hardware vendors, so that a solution that could sound expensive to others could be cheap for this provider. But as we cannot control this parameter, we will only evaluate the technical aspects.

Insider Protection

This is the most simple and immediate solution that a provider can apply to an existing (or new) Cloud Connect deployment. Since it’s a feature that is enabled on the Backup Repository, once a Cloud Connect system is designed, it’s automatically ready to offer Insider Protection.

Also, it can be enabled by tenant, so a provider can choose to offer it as a premium feature only to those customers willing to pay for it.

On the other side, it’s limited as it protects files that are deleted by a dedicated command, either manually or by retention. It requires a specific backup mode (with periodic fulls) and files that are not yet deleted by retention for examples will still be subject to other possible attacks.

Finally, in it’s basic configuration it consumes the same storage of the SOBR performance tier, which may be expensive for the provider. An interesting solution to this problem can be the usage of the Capacity Tier, as shown in the dedicated chapter.

Hardened Repository

The Veeam Hardened Repository (VHR in short) is located in the Performance Tier of a SOBR group. Since this tier is the absolut minimum required to build a Cloud Connect storage, during the initial design of a new deployment or the refresh of an existing one, it could be very easy to plan for a new storage server running Linux, and to configure it to be a VHR. In these terms, VHR is as transparent as the Insider Protection, because it can use existing storage servers.

The biggest advantage of VHR however is that it protects any file that lands in the storage as soon as they are written. There’s no need to wait for retention or an attack to delete a file, since each written file is protected from the beginning. It still requires to configure the backup mode accordingly, like Insider Protection, since merge operations are not possible anymore: acting as a WORM (Write once - Read many) device, once a file is written it cannot be modified. Also, retention is longer: while Insider Protection can be configured for a maximum of 99 days, VHR can be configured from 7 days (the minimum value) to 999 days (almost 3 years).

The major limit is that VHR is enabled at the repository level, so every tenant consuming that repository will be affected by the configuration; it cannot be configured “per-tenant”.

S3 Object Lock

S3 Object lock main point of attention, in the design phase, is that requires a new and dedicated storage layer to be configured, to become the Performance or the Capacity Tier of a SOBR group.

The main advantage of S3OL is that it can leverage all the capabilities of an object storage: scalability, replication, erasure coding. All these combined allow the creation of a storage layer that can grow immensely and be highly redundant.

While using S3OL in a Performance Tier requires a dedicated re-design of the SOBR group, when used as the Capacity Tier S3OL allows the re-use (and thus the economic and operational maximization) of the existing Performance Tier, usually made with block storage.

The other great advantage, when used as Capacity Tier, is that allows Cloud Connect to have two copies of each backup file arriving from the tenants (if using copy mode).

The main limit obviously is that it requires a dedicated purchase, if there’s no in-house storage yet. Also, in order to be as effective as VHR, it needs to use copy mode so that files are immediately protected.

Finally, if providers are going to use a public object storage, remember that egress costs for restores may have an impact on the cost calculations.