Cloud Backup — What Works and What's Just Marketing?

1. Introduction — Backup as a Foundation That’s Often a Fiction

Backup is one of the most basic IT practices. Everyone knows they should have one. Everyone claims they do. And yet, when an incident hits — it turns out the data can’t be restored, versions are missing, the backup doesn’t work, or… there never was one.

In the cloud, things get even more complicated. Many companies live with the belief that “the cloud does everything for us” — and backup is something that “happens somewhere out there.” The reality? Cloud providers are responsible for the infrastructure — but you’re responsible for your data. The shared responsibility model leaves no room for illusions: no backup strategy of your own = data loss risk.

On the other hand — the market is full of promises: zero configuration, auto-replication, 99.999% SLA, “native resilience.” Sounds great… until you have to restore week-old data from a test environment in a PaaS service. And then the marketing ends — and reality begins.

In this article we’ll:

• Tackle the myths around cloud backup,
• Show what works and what just sounds good in sales decks,
• And give you concrete tools to verify whether your backup actually protects data — or just gives you the illusion of safety.

2. Backup vs. Snapshot vs. Replication — What Each One Is, and What It Doesn’t Replace

One of the biggest traps in cloud environments is mistaking snapshots and replication for backup. They sound similar, run fast, happen automatically… but when something goes wrong, it turns out they’re not the same thing. The key to proper data protection? Understanding the differences.

Replication = high availability, not backup

Replication means syncing data between two locations — within the same region or across regions (multi-AZ, multi-region). The goal is availability, not protection from data loss.

Problem:

• If you accidentally delete data or someone runs a ransomware attack, the change gets replicated immediately.
• Replication doesn’t protect against business logic, human error, or sabotage.

Snapshot = a state of a resource, not a data backup

A snapshot is a point-in-time capture of a VM, volume, or database state. Usually performed within one cloud, often without encryption, retention, or automatic restore.

Problem:

• A snapshot doesn’t give you version control (often 1:1 with a specific moment),
• Often there’s no retention plan, recovery policy, or restore tests,
• Stored in the same region — so vulnerable to regional outages.

Backup = an independent, versioned copy with a recovery plan

A real backup is:

• A copy of data (or system state) stored separately from the source,
• Versioned — meaning you can recover data from X hours/days/weeks ago,
• Based on retention rules, with access control and restore tests,
• Independent of the service vendor (ideally: cross-region, cross-account, cross-platform).

Summary:

Mechanism	Purpose	Is it a backup?
Replication	Continuity of operations, availability	No
Snapshot	Technical state capture	No
Backup	Data protection and recoverability	Yes

In the next chapter we’ll show what actually works in practice — which backup models are worth using in cloud environments.

3. What Actually Works — Backup Models That Hold Up in Practice

A proper cloud backup isn’t about a single tool — it’s about a strategy fitted to architecture, data type, and business needs. Below is an overview of models and approaches that really work in production environments.

1. Agent-based backup (file-level)

Classic backup using an agent installed on VMs or servers:

• Runs independently of the cloud provider
• Allows granular file restore
• Can back up to another region or off-cloud

Good for: older systems, monolithic applications, hybrid environments

2. Native cloud service backup (managed services)

Cloud providers (AWS, Azure, GCP) offer “out of the box” backup for some services:

• AWS Backup (for RDS, EBS, DynamoDB, etc.)
• Azure Backup (for VMs, SQL, SAP HANA)
• GCP Snapshots + database backups

Good for: environments heavy on PaaS, simple use cases, when fast rollout matters

Note: you have to set retention, schedules, and restore tests yourself

3. Managed backup (Backup-as-a-Service, DRaaS)

Solutions like Veeam, Druva, Rubrik, Cohesity, Zerto:

• Multi-cloud, multi-tier backup with policies and versioning
• Compliance integration (GDPR, ISO, NIS2)
• Ability to back up SaaS environments (M365, Salesforce) and on-prem

Good for: complex environments needing compliance and cross-cloud backup

4. Snapshots with retention logic and cross-region replication

If snapshots are properly managed (versioned, tagged, copied across regions), they can serve as a fast backup mechanism.

Good for: environments needing very low RTO — databases, VMs with high uptime SLAs

5. Application (logical) backup

Data copies created at the application level (DB dump, configuration export):

• Independent of infrastructure
• Give you more control during migrations and outages

Good for: SaaS applications, microservices, custom solutions

An effective backup is one that works when you need it — regardless of conditions and provider.

In the next chapter we look at the other side of the coin: what doesn’t work — where backup ends and marketing begins.

4. Where Backup Ends and Marketing Begins

The cloud services market is full of promises: “full resilience,” “data always available,” “automatic data protection.” The problem is that often there’s no real backup functionality behind these slogans — just buzzwords that look good on slides.

Below are the most common marketing traps companies fall into.

1. “A snapshot is a backup”

A snapshot is a point-in-time capture — often without versioning, retention control, or encryption.

Myth: “We take daily snapshots, so we have backup.”

Fact: Deleting data = deleting the snapshot, if you don’t have an archive policy.

2. “PaaS does backup automatically”

Some services (e.g. databases) take system backups — but:

• You can’t always restore them yourself,
• You don’t control them (location, encryption, retention),
• Recovery time can exceed your acceptable RTO.

Myth: “We use RDS, so AWS backs it up for us.”

Fact: Yes, but on their terms, not yours.

3. “We have backup because the data is in the cloud”

Cloud = availability. Not = backup.

The provider delivers infrastructure. You’re responsible for the data.

Myth: “The cloud doesn’t break.”

Fact: It does. And data gets deleted faster than you’d think — including by user accident.

4. “Backup? But we have a 99.999% SLA”

The SLA covers service availability, not a guarantee of data recovery.

99.999% uptime means nothing if a file got deleted and you don’t have a backup from a week ago.

5. “One level of backup is enough”

Backup must be designed in layers:

• local copy,
• cross-region copy,
• offline or off-cloud archive.

Myth: “We have backup, we’re fine.”

Fact: Without versioning, retention, and restore testing — it’s just an illusion of safety.

Backup isn’t about what you have. It’s about what you can recover — quickly, safely, and according to policy.

In the next chapter we’ll look at the most common gaps in real backup strategies.

5. The Most Common Gaps in Cloud Backup Strategies

Companies often claim they have backup. But once you dig in, it turns out the backup:

• doesn’t work,
• doesn’t cover key data,
• isn’t tested,
• or… nobody knows where it is or how to restore it.

Below are the most common mistakes and oversights in cloud backup strategies.

1. No retention and no versioning

• Backup runs, but… only overwrites the previous state
• You can’t recover data from 3 days ago, because backup is “continuous”
• No retention policy = data loss after a mistake or attack

Solution: set up versioning + retention period (e.g. 30, 90, 365 days)

2. No coverage for PaaS/SaaS services

• Backup covers only VMs — but what about data in RDS, GKE, Azure SQL?
• No backup of configuration and data from SaaS apps (M365, Jira, Salesforce)

Solution: Use tools that back up the application layer too, not just infrastructure

3. No automatic restore tests

• Backup ostensibly exists, but no one’s ever checked whether anything can actually be recovered
• Restore tests done once a year “as a drill” aren’t enough

Solution: DR test schedule + documentation + audit logs

4. No separation of backup data from production

• Backup stored in the same region, subscription, or VPC
• An attack on production = the backup gets encrypted too

Solution: Cross-region / cross-account / off-cloud backup + immutable storage

5. No documentation and no backup ownership

• Nobody knows who manages the backup
• Policies exist only “on paper”
• Audit? Chaos.

Solution: Define an owner, procedures, and an escalation process + introduce alerts on backup failures

Backup isn’t a checkbox. It’s real responsibility.

In the next chapter we’ll show what happens when backup has to work in multi-cloud and hybrid environments — not just one console.

6. Backup in Multi-Cloud and Hybrid Environments — What Works, What Doesn’t

Many CIOs and architects think: “If we have multi-cloud or hybrid, we’re safe.” But reality is more complex. Backup in a distributed environment isn’t just a technology question — it’s an operational, organizational, and compliance challenge.

The main backup challenges in complex environments:

Lack of a coherent approach across providers

• AWS, Azure, and GCP have their own tools, interfaces, and retention policies
• Hard to ensure uniform RTO/RPO and recovery rules

Solution: deploy an independent backup solution (Veeam, Druva, Rubrik) with central management

Data scatter = higher risk of being missed

• Some data is in VMs, some in PaaS, some in SaaS, some local
• Backup often only covers part of it — the rest “holds together somehow”

Solution: full data inventory + a “data coverage map” policy

No coherent backup security policy

• One provider has versioning, another doesn’t
• One region has encryption, another doesn’t
• No central control = risk of leak or backup encryption

Solution: unify access, encryption, location, and audit policies for backup

Costs and managing backup storage

• Each provider charges differently (transfer, storage, requests)
• Hard to estimate the total backup TCO across platforms

Solution: centralize cost management (FinOps + tagging + alerts)

No cross-provider recovery scenario

• Data backed up from AWS isn’t ready to restore in Azure or GCP right away
• RTO can exceed business assumptions
• No restore testing in an alternative environment

Solution: plan DR scenarios using tools that support multi-cloud recovery

Backup in multi-cloud isn’t just copying data. It’s a resilience architecture.

In the next chapter we’ll look at regulatory requirements — how to plan a backup aligned with GDPR, NIS2, and ISO.

7. How to Plan a Backup Aligned with GDPR, NIS2, and ISO?

Backup isn’t just a technical issue. In the regulatory reality (especially in the EU), it’s a legal obligation and an element of organizational accountability. If data is poorly stored, can’t be recovered, or ends up in the wrong hands — the consequences can be serious: financial, reputational, and legal.

GDPR:

Article 32 — Security of processing

The organization must ensure:

• continuity of operations and the ability to quickly restore access to data,
• regular testing of the effectiveness of security measures (i.e. backups),
• data encryption and confidentiality even in backups.

Implications:

• Backup must be encrypted and stored in a compliant location (e.g. EEA)
• You must be able to document a data recovery plan

NIS2 — the cybersecurity directive:

The new NIS2 directive (mandatory for many sectors from October 2024) requires:

• Ensuring continuity of operations and incident management,
• Protecting systems against outages and cyberattacks,
• Regular testing and documentation of backup and recovery procedures.

Implications:

• Backup can’t be just technical — it must be part of cybersecurity policy
• Auditability and reporting on backup state are needed

ISO standards (e.g. ISO/IEC 27001):

ISO standards clearly require:

• A backup policy,
• Procedures to test and verify effectiveness,
• Managing retention, access, and data integrity.

Implications:

• Non-compliance with ISO is grounds for rejection in tenders or partner reviews
• For certification — backup is a mandatory audit item

The most common compliance failures:

• Storing backups outside the EEA (e.g. US regions in AWS, GCP)
• No backup encryption or keys managed by the provider
• No restore tests with reports
• No documentation or assigned backup process owner

Compliant backup isn’t a choice — it’s the condition for running a modern business.

In the next chapter we’ll show what happens when backup has to run in multi-cloud and hybrid environments — not just one console.

8. Backup and FinOps — How Not to Overpay and Not to Pay for the “Illusion of Security”

Backup is supposed to protect data — but it shouldn’t eat half the cloud budget. In practice, companies either don’t back up at all, or they back up too much, with no retention, versioning, or cost control. The result? Bills go up, and security… still stays an illusion.

Main areas of “burning” backup costs:

1. Snapshots without retention

• Daily snapshots without removing old ones
• 300 snapshots per VM, because “it’s just a test box”

Effect: Storage balloons, backup delivers nothing

2. Backing up data that doesn’t need to be backed up

• Backing up logs, temporary test databases, cache data
• No selection = backing up everything “just in case”

Effect: More data = more cost = slower restores

3. Backup in expensive storage classes

• Keeping copies in S3 Standard, Azure Hot, or persistent disks
• No archive policy (S3 Glacier, Azure Archive)

Effect: You pay 5x more for data you never look at

4. Backups kept in the same region and subscription

• Data backed up in the same cloud and region = zero resilience
• In a ransomware attack, the backup goes down with production

Effect: Cost looks low but the backup is worthless

How to combine backup with FinOps in practice:

• Set retention and rotation — e.g. 7, 30, 90 days depending on the system
• Roll out backup tagging and cost allocation (showback/chargeback)
• Use cold storage or tiered storage — savings of 60-90%
• Build selective backup policies — not everything has to be copied daily
• Roll out alerts on backup cost and volume thresholds

An effective backup is one that works when needed — and doesn’t cost more than the value of the data it protects.

9. Checklist: Does Your Cloud Backup Make Sense?

Below is a quick self-assessment that will help you spot gaps in your backup strategy. Answer YES or NO. The more “NO” answers, the higher your operational and financial risk — and the more it’s worth talking to Dynaminds.

Self-check — 10 key questions:

1. Do you have a clearly defined backup policy (what, how often, where, and for how long)?
2. Do you back up data not just from VMs, but also from databases, PaaS, and SaaS?
3. Are your backups encrypted and stored outside the production environment?
4. Do you have versioning and retention (e.g. 7/30/90 days)?
5. Do you regularly test data restores and document the results?
6. Are snapshots not your only form of backup?
7. Do you know how much your backups cost and which resources drive the most cost?
8. Do you back up data in line with GDPR, NIS2, ISO?
9. Do you have a recovery procedure for a ransomware attack or human error?
10. Do you have a tool or dashboard for central backup management?

Score:

8-10 x YES: A strong backup strategy — operationally sound and compliant.

5-7 x YES: The basics are there, but processes and tests need polishing.

0-4 x YES: You have backup in name only — the risk of real data loss is high.

What’s next?

Dynaminds can help you:

• Design a real, multi-tier backup plan
• Roll out automation, versioning, retention, and tests
• Optimize backup costs in multi-cloud environments
• Ensure compliance with GDPR, ISO, and NIS2

Book a free consultation — before you find out the backup doesn’t work… after the incident.

Great — let’s close the article with a concrete call to action.

10. Verify Your Backup with Dynaminds Before You Find Out About It After an Attack

Backup isn’t a place for guesswork or marketing. It’s the last line of defense against data loss, operational downtime, and reputational crisis. And in the era of ransomware, human error, and increasingly complex systems — that line has to be tested, automated, and compliant.

Dynaminds will help you:

• Verify whether your backup actually works — not just “exists”
• Design a backup strategy fitted to your environment, data, and RTO/RPO requirements
• Protect data in the cloud, locally, and in hybrid environments
• Cut backup costs by up to 40% through retention policies and cold storage
• Ensure GDPR, NIS2, ISO compliance and audit readiness