Summary

  • Storage choice, restoration and workload exit should be assessed separately. Having a copy is not the same as having every component needed to rebuild a service.
  • The reviewed documents support neither a blanket assurance of provider-independent recovery nor a finding of lock-in. The decisive evidence would be a defined recovery or exit procedure, tested against the customer’s actual requirements.

A useful choice, with a separate dependency question

In its Business Backup description, Safe Swiss Cloud lists several possible backup destinations: its own S3-compatible object storage, AWS S3, FTP, SFTP, SWIFT and mounted filesystems. Customers can also use their own on-premise storage, according to the product description.

That is a meaningful capability statement. It describes a choice beyond keeping every backup in the provider’s default storage. But the choice answers where a copy can be placed, not every question about how it can be used. A customer assessing operational independence needs to establish whether the credentials, keys, backup metadata and restoration software required to reconstruct an application remain available under a specified failure condition.

The distinction matters because ordinary self-service and provider-independent recovery are not competing descriptions of the same thing. Self-service can let a customer initiate an operation through a provider’s working management interface. Independent recovery asks whether the necessary operation remains executable when a relevant provider component is unavailable. The latter is a stricter requirement, not a condition every managed service must satisfy to be useful.

Restoration control is more than a button

Safe Swiss Cloud describes file and full-backup restoration through a self-service web interface, with two-factor authentication for access to the backup management server. It also describes AES-256 encryption in transit and at rest, compression and client-side deduplication in its Business Backup material.

These descriptions establish what the company says customers can initiate and how it says backups are protected. They do not establish customer-exclusive custody of encryption keys or a complete restoration path that operates without the management service. Encryption strength and key availability are separate questions: a protected copy is useful for recovery only if the authorized party can obtain the means to reconstruct it.

This is an evidentiary limit, not a finding that independent restoration is unavailable. The reviewed description does not settle the question either way. A suitable demonstration would define the unavailable component, use a separate restoration target and record which services or people were still required.

The company itself encourages testing a restore after setup. Its description warns that a test can take more than 15 minutes depending on backup size and advises restoring image backups to a new server, virtual machine or desktop rather than risking the source device. That is testing guidance, not a guaranteed completion time or a measured customer outcome.

The 24-hour figure measures mirroring, not service recovery

The Business Backup FAQ says the default Safe Swiss Cloud object storage is automatically mirrored across two of the company’s data centres within 24 hours. The scope matters: this describes the default storage arrangement, not every external destination a customer might select.

The figure also describes a different operation from restoring an application. Mirroring a backup copy does not, by itself, establish how quickly a customer can obtain a functioning service, how recent its recovered transactions will be or whether the application will be internally consistent.

For an actual recovery test, record at least three separate observations: the backup’s timestamp, the latest transaction recovered in the application and the elapsed time until the service has been verified. Those observations answer different questions. None should be replaced by the mirroring interval simply because it is the most visible number on a product page.

A promise of movement is not an exit benchmark

Safe Swiss Cloud’s General FAQ makes an explicit bidirectional statement: “Customers can always move their workloads in and out of Safe Swiss Cloud themselves (self service).” That is positive evidence of the company’s stated approach to portability. It should not be dismissed merely because the reviewed material does not contain a complete outbound runbook.

The same FAQ discusses a basic export-and-import method in guidance about moving existing virtual machines into Safe Swiss Cloud. It warns that disk volumes over 100 GB may take hours to transfer and that the service is unavailable to end users during the transfer. It also describes replication and synchronization as another migration approach. These are inbound migration instructions, not an observed outbound exit time, a universal transfer limit or proof of an unsuccessful departure.

For a buyer, the next step is therefore specific: establish the supported outbound formats, necessary permissions, destination requirements, assistance, fees and likely elapsed time for a representative workload. A successful export is one checkpoint. Reconstructing and verifying the application at its destination is the more consequential one.

Deletion and access run on different clocks

The published Terms and Conditions say that service can be cancelled as of the end of any calendar month and that billing continues monthly until cancellation in writing. They also state: “The account data will be deleted within 60 days of termination.”

“Within” is not “after.” The sentence does not, by itself, promise 60 days of continued access or export assistance. Nor does the term “account data” establish here the precise treatment of every virtual machine, backup and object-storage item. Customers should settle those questions before relying on the deletion provision as a migration window.

The general terms describe the default service as “as is” and self-service, with default availability support provided on a best-effort basis. Additional support packages are available for higher service levels. Those provisions make the purchased agreement important; they do not justify importing another product’s support or uptime figures into a Business Backup recovery plan.

The bounded conclusion is that Safe Swiss Cloud documents useful choices, including external backup destinations and self-service movement in both directions. Whether a particular customer can recover independently or leave within an acceptable time and cost remains a configuration, contract and testing question.

This assessment reviews four company-published pages. It is not an infrastructure test, an independent audit or a review of a customer-specific agreement; no customer recovery or exit performance was measured. Publication dates for the pages have not been established, so the capabilities and wording discussed here should not be treated as a newly announced change.