Could You Restore Your Business on Another Cloud?

Imagine asking your IT team to restore the order-processing system on a different cloud provider. The database backup is available, the files are intact, and a new server is ready. Can someone in the warehouse actually open an order, check its attachments and record a dispatch?

That is a useful question to ask before a contract renewal or a migration decision. It turns a broad discussion about cloud independence into a test with an observable result. This article explains how to design that test, what to include beyond the data, and what its results can tell you about a future move.

On 3 September, OVHcloud and Plakar announced native backup integration for OVHcloud Public Cloud. Their announcement says customers retain their encryption keys, backup copies remain in Europe, and data can be restored elsewhere, including outside OVHcloud. Those are useful capabilities to investigate, with service coverage and availability still to confirm for your particular environment.

Our recommendation is to use that announcement as a prompt for a recovery exercise, whichever provider you use. Ask your team to demonstrate one important business process running from a backup on an alternative platform. Record exactly what they needed to make it work.

Define what you need to recover

Begin with a business process small enough to test properly. For a manufacturer, that might be retrieving an order and its production documents. For a healthcare organisation, it could be opening a representative record in an isolated test application, using appropriately protected test data.

Give the process an owner who can judge the result. An engineer can confirm that a database has started; an operations manager can confirm that the restored order contains the information needed to dispatch it. Agree on the acceptance checks together before anyone starts preparing the alternative environment.

Set two limits in ordinary language: how long the process may be unavailable, and how much recent work the business could tolerate losing. Engineers call these the recovery time objective and recovery point objective. For an illustrative order system, management might set a four-hour interruption limit and accept losing no more than fifteen minutes of recent updates; your limits should come from your own operations.

Then state the failure you are testing. Losing one server, losing access to the production account, and losing access to the original provider require different preparations. For this exercise, we suggest assuming that the original provider cannot help you restore, so the recovery copy and its essential supporting information must already be accessible elsewhere.

Check where the backup can actually go

Ask the team to identify the exact backup they would use and the software that can read it. A copy stored in another location is only a starting point. Your test needs to show that the target environment can interpret it and recover the information required by the chosen process.

Provider documentation can help separate different kinds of protection. AWS Backup's cross-account backup documentation, for example, describes copying backups between AWS accounts, with specific account, permission and encryption requirements. That is an AWS recovery mechanism; the documentation does not establish a way to restore those backups on a different provider.

For PostgreSQL, an open-source database, the official documentation describes portable exports through its pg_dump utility. It also explains that this utility exports one database and omits shared objects such as database roles, which define users and permissions. The companion pg_dumpall utility handles those shared objects, subject to the access available on the source system. PostgreSQL cautions that pg_dump is generally unsuitable for regular production backups outside simple cases, so treat this as a portability example and select a backup method that meets your recovery targets.

The practical lesson is to ask what your export leaves out. Have the engineer identify required users, permissions, database add-ons and version compatibility before the exercise. With a managed database, confirm what the source service lets you export and what the target service lets you recreate.

Request the same evidence from a backup supplier promising portability. Which of your services are covered, what is restored automatically, and what must your team rebuild? Treat a successful demonstration using your chosen application as stronger evidence than a general statement that restoration elsewhere is supported.

Prove access to keys and recovery accounts

Include encryption in the test from the beginning. Ask the team to demonstrate how it will decrypt the recovery copy when the original provider is unavailable. Record where the necessary keys are held, who can authorise access and which services must still be reachable.

The phrase "customer-managed key" needs closer inspection. AWS explains that KMS keys cannot be exported in plaintext from its Key Management Service, while distinguishing those keys from the data keys used to encrypt application data. Control over a key's settings therefore does not, by itself, demonstrate that your backup can be decrypted independently of AWS.

That does not mean an AWS-hosted application cannot have a portable backup. It means the backup design needs a tested route to independently recoverable data, prepared while the source is available. Keep encryption enabled and have the responsible engineer verify the entire decryption path rather than assuming that possession of an encrypted file is sufficient.

Apply the same test to human access. Can the recovery team sign in to the destination, retrieve its instructions and obtain authorised credentials without using systems included in the simulated failure? Keep emergency access controlled and auditable, and test it with the people who would actually respond.

We recommend giving a second engineer the recovery instructions during the rehearsal. Ask that person to follow the documented access process without borrowing a colleague's session or relying on remembered commands. Any missing step becomes a specific correction to make before the next test.

Rebuild enough of the application to do real work

Return to the order-processing example. Alongside the database, ask the team to account for application software, attached documents, sign-in, background tasks and connections to other systems. For each dependency, record whether it will be restored, replaced, deliberately simulated or left outside the exercise.

This extends established recovery guidance. The UK's National Cyber Security Centre recommends testing that cloud backups are recoverable and complete, including the files that describe how to recreate the infrastructure. Our additional question is whether those preparations work on the proposed destination without unrecorded help from the original provider.

Build the rehearsal environment separately from production. For the example order system, disable real dispatch instructions, customer emails and payment requests, then use controlled substitutes where needed. Record those substitutions so that a successful test does not imply you have proved the live integration works.

Choose checks that exercise the whole process. Sign in with an appropriate test user, retrieve a restored order, open its attachment, make an authorised update and confirm the expected result. Check that restricted users still cannot see records they should not access.

Compare related data as well as individual files. If an order refers to an attachment missing from the restored document store, count that as an incomplete recovery even if both backup jobs reported success. Agree in advance how the database and file copies will represent a consistent point in the business's activity.

Measure until the business process works

Start the exercise clock at the agreed declaration of failure. Record the time spent obtaining access, preparing infrastructure, transferring and restoring data, reconnecting the application, and completing business checks. Stop it only when the process owner accepts the result against the agreed criteria.

This distinction is visible in provider tooling too. AWS Backup documents validation as a separate step after restoration, with checks supplied by the customer. A completed restore job is therefore one useful milestone in the exercise, while application acceptance requires its own evidence.

Measure the age of the recovered business data as well. For the illustrative fifteen-minute target, identify the latest usable order or update and compare its timestamp with the simulated failure time. Include delays in copying or exporting data to the independent recovery location.

Be explicit about preparation. If the alternative environment was built before the clock started, report that as a condition of the result. A test using a small sample can establish that a method works, but leave full-volume recovery time marked as unproven until you have evidence at representative scale.

Finish with a short record: the process tested, backup used, destination, recovered data timestamp, elapsed time, acceptance results and remaining dependencies. Give every gap an owner and a next action. Keep enough detail for another engineer to repeat the exercise and understand what was actually demonstrated.

Use the result to decide your next move

A successful rehearsal gives management a precise statement: this process was recovered on this platform, under these conditions, within this measured time. It also gives the technical team a starting point for assessing a migration. Keep the scope attached to that statement; one recovered application does not establish that every business system can move.

A failed rehearsal is useful when it identifies a fixable obstacle. A missing permission can become an access change; an unsupported dependency can become a replacement decision; an unacceptable recovery time can lead to a different backup method. Those findings are more actionable than a general concern about being dependent on one provider.

Restoring a backup also leaves further migration work to assess. Before moving production, require separate evidence for expected workload, ongoing monitoring, live integrations and the handling of new transactions during the move. A recovery test can inform that plan without proving all of it.

For a lean IT team, we would begin with one important process and expand after addressing its findings. Repeat the exercise after material changes to the application, backup method or access arrangements, and agree a regular review interval. The useful outcome is a recovery route your team can demonstrate and maintain, with enough evidence for the business to decide what should move next.

Thinking about migration? Book a free consultation to discuss your situation.