Cloud Backup for Hybrid and Multi-Cloud Environments

Hybrid cloud backup keeps a second, restorable copy of data away from where it runs. In a hybrid estate it is several jobs in several places, so it needs an order of work.

This guide is for an IT manager or head of infrastructure at a firm of roughly 250 to 2,000 people in India or the GCC. It has six steps, one per section. The scored checklist is a separate Signisys article, and so is the choice between native tools and one platform. The practices behind a good copy sit in the backup practices guide. This guide does not repeat them. Two provider pages ground it: the AWS Backup developer guide and the Azure Backup overview. Also, another Signisys article explains why protection gets harder across such an estate.

Cloud Backup in Short: Definition and Six Steps in Order

A working definition, in Signisys’ own words and not a standard: a restorable copy, held apart from the data it protects, in a form the firm can bring back. A synced copy is not that, because a sync can repeat a deletion. For the copy-type distinction, read how a backup differs from a snapshot.

The six steps run in this order.

The order matters because each step needs the one before. Also, a skipped step shows up later as a gap. A policy needs a list, and a restore needs a policy. The steps also give you a finish line. The work is done when every place on the list has an owner, a service, a policy, a separate copy, a key picture and a restore on record.

Step 1: Find Where the Data Lives

First, write one list. It covers four kinds of place: on-premises servers, each cloud account or subscription, each SaaS application, and the endpoints that hold business data. For each place, write down three things: the place, its owner and the business data it holds.

Then name one owner per line. The list has four columns by the end of step 2: place, owner, business data and the service that covers it. An owner is a person who can say what the place holds and who can approve a restore. A line with no owner is a gap. Also, a team name alone does not count.

Next, add the places that people forget. For example, a test account may hold real records. Also, a SaaS trial may have become a working system. Likewise, a laptop may hold the only copy of a spreadsheet. However, the list does not need to be perfect on the first pass. It needs to exist, and it needs a date.

The output of step 1 is one list with an owner per line. Every later step reads from it. Why this step is hard in a hybrid estate is the subject of a separate Signisys explainer.

Step 2: Read What Each Environment’s Own Backup Service Covers

The table sets two provider pages side by side. Each page describes its own service, so each row cites its own page.

Then, for each place in your step 1 list, write down which service covers it and what falls outside. A place with no service is a finding, not a failure. The next steps then close it. The AWS page also says AWS Backup integrates with CloudWatch, EventBridge and CloudTrail for monitoring. Read those reports as part of step 6.

Choosing between native tools and one platform is the subject of a separate Signisys article. However, this guide recommends neither side.

Step 3: Set One Policy and Apply It Everywhere

Write one policy for each class of data, in the firm’s own words. Two or three classes are enough to start: data the business has no other way to rebuild, data that can be rebuilt with effort, and convenience copies. A short policy, however, gets read. Keep it to four items:

• what is copied
• on what schedule
• how long the copy is kept
• who may delete it

Then apply it with each service’s own tools. The AWS page says backup plans act as policies and can be applied by tag. The Azure page says a policy defines schedule, frequency and retention. Also, use a tag or label wherever the service allows one, so the policy can reach a group of resources.

However, where a service does not apply the policy, record the exception and its owner. An exception with an owner is a managed difference. Meanwhile, an exception with no owner is a drift in waiting.

Recovery targets are a separate topic. The page on meeting recovery targets covers them. Also, this guide invents no number.

Step 4: Keep Every Cloud Backup Copy Apart From the Data It Protects

Put simply, a copy that sits beside its source can share the source’s fate. So keep the second copy in a separate account, subscription or tenant, and where it matters, in a separate region. The AWS page says AWS Backup can copy across Regions and accounts. The Azure page lists vault design across subscriptions, regions and environments as a design consideration.

Also, the copy must not share a login with the data. A person who can sign in to production should not be able to delete the copy with the same sign-in. If one stolen login reaches both, the copy is not truly apart. Then ask each environment the same question, as the table shows.

For a copy that survives stolen admin rights, read the guide to immutable backups.

In a hybrid estate, each environment needs its own answer to the same question: where does the second copy sit? Write the answer next to each line of the step 1 list. A copy that shares an account with its source is the first finding to fix.

Step 5: Encrypted Cloud Backup Across Environments: Who Holds Keys and Access

This step takes only the cross-environment angle. The practices for keys and locks sit in the backup practices guide. Hybrid cloud backup can widen the set of logins that reach the copies, so the lists need care.

Also, one identity, or one group, that can reach every environment’s copies is one target. So list who can read, delete or change the copies in each place. Keep the lists separate for each environment. In Signisys’ view, if each environment keeps its own keys, one stolen login may open fewer copies.

The lost-key point is covered in the practices guide and is not repeated here. A simple test for this step: pick any one login and ask which copies it can reach. If the answer is all of them, the step is not done.

Also, name no key-management product at this stage. First get the lists right. Then choose the tools.

Step 6: Restore Across Environments and Bring the Reports Together

First, restore one system from each environment’s copy to a clean place. Then note the time and who did it. A first restore that fails is better found now than on the day it is needed. For a full recovery test, read a checklist for a disaster recovery test.

Then bring the reports from each service to one place, read by one person. The reports from each service cover that service. Also, a report nobody reads is no better than a report that does not exist. Three Signisys posts cover the detail:

• A scored list of jobs, alerts and restore checks.
• The criteria for choosing what watches your jobs.
• Why jobs fail without anyone noticing.

The estate-wide scored list is a separate Signisys article.

Limits of Cloud Backup Guidance, and When to Ask for Help

Provider pages change, so check the date given here for the Azure page, and the live AWS guide. Also, this guide names no Indian or GCC rule and gives no legal advice. A regulator, contract or auditor sets any requirement. Likewise, it does not cover the scored checklist, the choice of a solution or failover design. The FAQ below covers the line between recovery and continuity.

When to ask for help. First, copies of one system sit in two clouds under two teams, and nobody can say which restores first. Second, an acquisition brings an account whose backups nobody has seen. Third, the first restore across environments fails or has never been tried.

Signisys provides data protection, backup and cyber recovery solutions, as well as cybersecurity services. Read this as a description of a Signisys service, not neutral advice. Our page on protecting data across environments sets out the approach.

Cloud Backup FAQ