Security Architects & Cloud Backup Strategies

Cloud security architects should understand well-established backup concepts and patterns—such as RTO, RPO, and the Grandfather–Father–Son pattern—and newer ones, such as immutable backups. They should also know the relevant cloud-native backup features for the storage and database services in use by their organization.

However, understanding these features alone does not make a great security architect. These features are merely the cards he holds in his hand ?(alongside features of third-party backup solutions, whether already in place or under consideration). The game starts afterward. Security architects have to elaborate a comprehensive backup strategy and establish concrete guidelines, helping application teams to implement standard patterns across the overall application landscape rather than each team trying to figure out what makes sense from their perspective.

The primary objective of these guidelines and standards is, of course, to meet business needs. Answering the following key questions can help clarify those more efficiently and quickly:

• What are the backup requirements per domain or business unit? For example, keeping source code backups for one year might make more sense than keeping backups of operational data in logistics and production for over a week.
• Are existing backup policies in place and implemented, e.g., with the current backup solutions? Most organizations have long-standing backup processes, which can provide valuable insights from previous backup requirements engineering projects.
• Which aspects of these policies are actual business necessities, and which are merely remnants of outdated backup technologies? Policies demanding one nightly backup per day might not want to forbid point-in-time recovery backups for one day; the latter is simply a newer phenomenon.
• Is there a clear distinction between backups for restoring operations after mistakes or cyberattacks and data and document archiving for compliance (e.g., accounting or SOX-relevant records).

The final step is matching business requirements with the backup capabilities in the cloud. The main challenge here is the diversity of storage and database services with their varying backup features across cloud providers and among services within the same cloud platform. Do you want to retain monthly backups for a year while ensuring point-in-time recovery across all of your storage and database services for the last seven days? Even the clouds do not fulfill all imaginable backup requirements out of the box without additional tooling or scripting efforts.

Defining clear backup service levels (e.g., a "silver" tier might specify an RTO and RPO of eight hours) is essential to establish clear and actionable guidelines. The next step is determining the best way to implement these service levels for each specific cloud service across the cloud platforms. It is essential to be aware that, in some cases, certain workloads may not be compatible with available backup features for specific cloud services, so these services cannot be used.

Solving this puzzle can be complex, but it should also be fun and exciting for security architects!

P.S.: Didn’t read my previous articles on backups? Here is a list…

Immutable Backups and The Public Cloud – Part I

Backup Basics: On Backup Types, RTO & RPO | Cloud Security Architecture – AI and MLOps – Testing

Backups for Selected Database-as-a-Service Services in Azure and AWS | Cloud Security Architecture – AI and MLOps – Testing

Backup Strategies and Concepts in the Public Clouds | Cloud Security Architecture – AI and MLOps – Testing

?

?