You only understand what your data is worth after you lose it without a backup

Data behaves like a utility. It sits in the background, always available, apparently free, and almost invisible until the moment it stops working. A company can run for years on files, databases, email histories, design assets, contracts, accounting records, and customer records without ever assigning a number to any of it. The value stays hidden because nothing forces anyone to look. Then a drive dies, a folder is deleted, or an attacker encrypts a file server overnight, and the missing data suddenly acquires a very precise price: the cost of rebuilding it, the revenue lost while it is gone, the clients who leave, and in the worst cases the business that no longer exists.

The quiet asset nobody prices until it vanishes

The Slovak saying that names this article captures it exactly. We recognise the value of our data the moment we lose it and have no copy to fall back on. Until that moment, the value is theoretical. After it, the value is a spreadsheet of damage.

This is not a soft, motivational observation. It is measurable, and the measurements are getting worse. Roughly two out of three businesses report a major data-loss event in a single year, according to widely cited industry surveys, and a large share of them find out at the same time that their recovery plan was weaker than they assumed. The gap between what people believe about their own protection and what actually happens under pressure is the real subject here. Most organisations do not lose data because backups are impossible. They lose it because backups were an afterthought, were never tested, or were quietly destroyed by the same event that destroyed the originals.

The reason the topic deserves a serious treatment rather than a checklist is that the stakes have changed. A decade ago, the main enemies of data were a failing hard disk and a careless keystroke. Both still exist. But the dominant threat now is deliberate and adaptive. Ransomware operators study how companies protect themselves and design their attacks to defeat those protections first. Cloud platforms have shifted large parts of the responsibility for data recovery back onto the customer while leaving many customers convinced the provider handles it. Storage media that people trust for archives quietly lose data when left in a drawer. Each of these shifts widens the distance between a comfortable assumption and a survivable reality.

There is also a psychological pattern worth naming at the start, because it shapes behaviour more than any statistic. People who have never lost data are the least likely to protect it. In one 2025 survey, 37 percent of users who had never experienced data loss admitted they do not back up at all, compared with only 16 percent among those who had already been burned once. Losing everything, it turns out, is the most common way people finally learn to back up. The purpose of thinking about this in advance is to skip that expensive lesson.

This article looks at what data loss really is, how often it happens and why, what it costs across different sectors, how backup strategy has evolved to meet modern threats, and what a working plan looks like for both a company and a single professional. It uses real incidents where a missing or broken backup turned an ordinary bad day into a permanent one, and it separates confirmed facts from interpretation throughout. The goal is not to frighten anyone into buying a product. It is to make the hidden value of data visible before the loss makes it visible for you.

What data loss actually means in practice

Data loss is any event where information that mattered becomes inaccessible, corrupted, or permanently gone, with no reliable way to get it back. That definition sounds obvious, but the word covers a wider set of situations than most people picture, and the differences between them decide whether recovery is a minor inconvenience or a catastrophe.

The clearest case is destruction. A hard drive fails mechanically, a fire destroys a server room, or a device is stolen. The physical carrier of the data is gone, and if the only copy lived on that carrier, so is the data. This is the version everyone imagines, and paradoxically it is often the easiest to survive, because a second copy stored somewhere else solves it completely.

A second case is deletion. Someone removes a file, a folder, a database table, or an entire storage volume, sometimes by mistake and sometimes as a deliberate act by a departing employee or an attacker. The storage hardware is fine. The data is simply no longer there. Deletion is dangerous precisely because it is silent and fast, and because synchronisation tools will happily copy the deletion everywhere within seconds.

A third case is corruption. The file still exists and opens, but its contents are wrong. A failed software update, a bug, a partial write during a power cut, or slow physical degradation of the storage medium can leave data that looks present but is unusable. Corruption is the quietest failure mode, because it can spread into backups for weeks before anyone notices, at which point every recent copy carries the same damage.

A fourth case, the modern one, is denial. The data is intact and undeleted, but you cannot reach it because an attacker has encrypted it and holds the key. Ransomware is the defining example, and it is now the single most cited cause of serious data loss for businesses in several 2025 and 2026 surveys, accounting for over a third of incidents in some samples. The cruelty of denial is that the data is technically still there, taunting you, while being just as useless as if it had been incinerated.

The reason these distinctions matter is that a backup strategy has to answer all four, not just the first. A copy on a second drive in the same office protects against a single disk failure but not against a fire, a theft, or ransomware that spreads across the network. A cloud sync protects against local hardware failure but faithfully replicates deletions and corruption. Understanding which failure you are actually defending against is the difference between a plan that feels reassuring and one that works.

There is one more idea packed into the definition, and it is the crucial one: the phrase “no reliable way to get it back.” Data loss is not defined by whether something bad happened to the original. It is defined by whether a recovery path exists. A drive can die, a folder can be wiped, a whole data centre can burn, and none of it counts as data loss if a clean, recent, restorable copy exists somewhere the disaster could not reach. The event that people call “losing their data” is almost always two events stacked together: the original was destroyed, and the backup was missing, broken, or destroyed alongside it. The rest of this article is largely about preventing that second event, because the first one is inevitable and the second one is optional.

The numbers behind vanished data in 2025 and 2026

The scale of the problem is easier to grasp with figures, provided the figures are read carefully. Data-loss statistics come from vendors with something to sell, so the safest approach is to look for numbers that recur across independent sources and to treat single dramatic claims with caution.

Start with frequency. Multiple 2025 surveys converge on the finding that around two-thirds of businesses experienced a serious data-loss event in the previous twelve months. One US-focused study put the figure at 67.7 percent of businesses reporting serious loss, with only 32.3 percent describing the impact as minimal. Another global enterprise survey found more than 60 percent of organisations hit by at least one major incident in a year. The exact percentage moves with the sample, but the message is stable: this is not a rare misfortune, it is a routine business risk.

Then the causes. Here the sources disagree in an instructive way. A 2025 survey of 10,000 users attributed loss primarily to human error (34 percent), followed by hardware failure (27 percent) and malware (22 percent). A separate study weighted toward IT leaders found ransomware to be the most common single culprit at 36.7 percent. The disagreement is not really a contradiction. When you survey ordinary users, accidental deletion dominates. When you survey the people who manage business infrastructure, deliberate attacks dominate, because those are the incidents severe enough to reach an IT team’s desk. Both facts are true at once, and both need answers.

The cost figures are where the stakes become concrete. IBM’s 2025 Cost of a Data Breach Report, the twentieth edition and one of the most respected annual measurements, found the global average cost of a data breach was 4.44 million dollars, a nine percent fall from the previous year and the first decline in five years, which the report attributes to faster detection and containment driven by security automation. That global drop hides a sharp divergence: in the United States the average breach cost rose to an all-time high of 10.22 million dollars, pushed up by regulatory penalties and slower detection. The average time to identify and contain a breach fell to 241 days, a nine-year low, and the report is blunt that shorter breaches cost less because time really is the variable that drives the bill.

Downtime is the cost people forget to count. Research summarised by the Uptime Institute puts severe outages at up to 100,000 dollars per hour, with a quarter of unplanned outages costing more than a million dollars. Enterprise surveys from ITIC and others report that over 90 percent of mid-size and large companies estimate a single hour of downtime at more than 300,000 dollars, and a substantial minority put it between one and five million. For a small business those absolute numbers shrink, but the proportional damage is often worse, because a single afternoon of lost trading can erase a month’s margin for a small team.

The survival statistics are the ones that get quoted most and verified least, so they deserve a caveat. Figures such as 93 percent of companies that lose data for ten or more days filing for bankruptcy within a year, and 60 percent of small businesses closing within six months of a major loss, circulate widely across the industry. They originate from older studies that are hard to trace to a clean primary source, and they should be treated as directional rather than precise. What is well established, and repeated by independent analysts, is that businesses without a recent, tested backup are dramatically more likely to fail after a serious incident, and that a substantial share of ransomware victims never fully recover their data at all. One 2025 analysis reported that 28 percent of ransomware attacks led to data that was unrecoverable.

The pattern across all of these numbers is consistent. Loss is common, its causes are mixed between accident and attack, the financial damage is large and rising in the places that fine you for it, and the deciding factor in whether an incident is a bad week or a fatal one is almost always the quality of the backup, not the size of the disaster.

Human error still deletes more than hackers do

For all the attention ransomware receives, the most frequent single cause of data loss remains an ordinary person making an ordinary mistake. Depending on how you count, human error is tied to somewhere between a third and well over half of all incidents. It is unglamorous, which is exactly why it is underdefended. Companies buy firewalls to stop attackers and forget that the largest hole in their data is a tired employee with delete permissions.

Human error takes several shapes. The simplest is accidental deletion: dragging a folder to the trash, selecting the wrong files, or emptying a recycle bin that turned out to contain something important. The second is overwriting: saving a new version on top of an old one, or restoring an outdated file over a current one. The third is misconfiguration: setting a sync rule, a retention policy, or a permission incorrectly so that data is silently removed or exposed. The fourth is the destructive command run against the wrong target, which is rarer but catastrophic, because it tends to happen to the people with the most access to the most important systems.

What makes human error uniquely dangerous in a modern setup is speed and propagation. In the era of local files, a mistaken deletion sat in a recycle bin and could be undone. In the era of synchronised cloud folders, a deletion on one device replicates to every other device and to the cloud copy within seconds, and the “cloud” many people trust as their backup dutifully mirrors the loss. The convenience that makes synchronisation attractive is the same mechanism that turns one person’s mistake into a distributed, instant, everywhere deletion.

The other trait of human error is that it does not respect seniority or skill. Some of the most severe deletions on record were carried out by experienced engineers doing routine maintenance. A person under time pressure, working late, convinced they are connected to a test system when they are connected to production, is a more reliable source of catastrophic loss than most malware. Training reduces the rate but never to zero, because the failure is cognitive rather than technical.

The defences against human error are different from the defences against attack, which is why a plan built only around security leaves this gap open. Versioned backups that keep multiple historical copies mean a mistake made today can be reversed by restoring yesterday. Retention windows long enough that a deletion is noticed before the last good copy expires matter enormously, because accidental deletions are often discovered days or weeks later. Separation of the backup from the live system, so that a deletion in production does not reach the backup, is the structural fix. And restricting destructive permissions so that the number of people who can wipe critical systems is small and their actions are logged reduces the blast radius.

The honest conclusion is that you cannot eliminate human error, so a data strategy has to assume it will happen and be built to absorb it. A backup that only protects against hardware failure and attack, but faithfully copies every mistake, is protecting against the wrong enemy for the most common cause of loss.

Ransomware turned backups into the primary target

Ransomware changed the mathematics of data protection, and any plan written before that change is dangerously out of date. The original threat model behind most backup habits assumed the enemy was accident and equipment failure. Under that model, a single extra copy on a connected drive or a network share was a reasonable defence. Ransomware broke that assumption on purpose.

Modern ransomware operators do not simply encrypt the files in front of them. They study the environment first, identify where backups live, and destroy or encrypt those backups before they trigger the main attack, so that the victim has no clean copy to restore from and is forced to pay. This is not incidental. Backup repositories are targeted deliberately in the large majority of ransomware attacks. Independent analyses report that attackers attempt to compromise backup systems in roughly 96 percent of ransomware incidents, which means a backup sitting on the same network as the production data is not a safety net at all. It is another target.

The CloudNordic case, covered in detail later, is the clearest illustration: attackers reached the primary and secondary backup systems through the internal network and encrypted them alongside the live servers, and the company lost almost everything. The lesson generalises. A backup is only protection if the attack that destroys your data cannot also reach the backup.

The frequency and severity of these attacks continue to climb. Reporting through 2025 and into 2026 describes ransomware attacks rising sharply year over year, with one industry estimate putting the increase on track for roughly 40 percent higher than 2024 by the end of 2026, and around 400 percent higher than 2020. Specific sectors are hit disproportionately. By mid-2025, over half of healthcare organisations had reported ransomware attacks, with average ransom payments in that sector reported around 115,000 dollars, on top of the operational and clinical damage.

There is a more sophisticated wrinkle that plans need to account for. Many attackers now practise double extortion: they steal a copy of the data before encrypting it, then threaten to publish it if the ransom is unpaid. A perfect backup solves the availability problem, because you can restore and refuse to pay for a key. It does not solve the confidentiality problem, because the attacker still holds a copy of your customer records. This matters because it means a backup, while necessary, is not a complete answer to ransomware. It removes the power of encryption but not the threat of exposure, which is why backup has to sit alongside prevention, detection, and access control rather than replacing them.

The financial evidence points clearly toward recovery capability as the best defence. Organisations that detected ransomware internally, rather than being told by the attacker, saved hundreds of thousands of dollars on average, and payment rates have been falling as more organisations improve their ability to restore from clean backups and simply refuse to pay. The attackers’ business model depends on victims having no alternative. A tested, isolated, immutable backup is precisely the alternative that breaks it.

The practical takeaway is specific. Against ransomware, an ordinary backup is not enough. The backup must be isolated from the production network, immutable so it cannot be altered or deleted even by someone holding administrator credentials, and tested so you know a restore will actually work under pressure. Each of those requirements exists because attackers engineered their way around the version of backup that lacked it. This is why the old three-copy rule has grown into something more demanding, a point developed later in detail.

Hardware fails on its own schedule, not yours

Underneath every cloud service, every server, and every laptop sits physical hardware that degrades and eventually fails. This is the oldest cause of data loss and the one people most readily forget, precisely because modern storage is reliable enough to lull users into treating it as permanent. It is not.

Spinning hard disk drives fail at a measurable, predictable rate that rises with age. Large-scale reliability data shows an annualised failure rate that climbed to around 1.42 percent across a broad fleet in early 2025, with some individual drive models failing at rates as high as 9.47 percent. A 1.42 percent annual rate sounds small until you multiply it across a fleet or across years. Over the working life of a drive the cumulative probability of failure becomes substantial, and failure rates climb steeply as drives pass three or four years of service. A drive is not a permanent object. It is a component with a lifespan, and that lifespan is often shorter than the value of the data it holds.

Solid-state drives fail differently and, in one respect, more treacherously. They have no moving parts, so they tolerate physical shock far better than spinning disks, and for everyday use they are more durable. But their failure modes are electronic rather than mechanical, and recovery from a failed SSD is frequently harder and less certain than from a failed hard drive. When an SSD dies, it often dies completely and without warning, taking the data with it in a way that leaves fewer options for a recovery lab.

There is a subtler SSD problem that catches people who use them for archival storage. Flash memory stores data as a trapped electrical charge, and that charge leaks away over time when the drive is left unpowered. A consumer SSD left in a drawer can begin losing data within months to a couple of years, depending on the type of flash and the temperature it is stored at. This makes SSDs a poor choice for the “put a copy on a drive and leave it in a safe” style of backup that worked reasonably well with spinning disks. A hard drive left unpowered will usually hold its data for many years, and can sometimes be revived decades later; an unpowered SSD is on a much shorter clock.

Power events add another layer. A sudden outage during a write operation can corrupt files or, on older systems, damage the drive itself, because the energy needed to complete the final write is gone. Surges can destroy the electronics outright. None of these events announce themselves in advance.

The reason hardware failure remains relevant despite decades of engineering improvement is that reliability at the component level does not translate into safety at the data level when there is only one copy. A 1.42 percent annual failure rate means that if your only copy of something lives on a single drive, you are running a small but real annual lottery with your data as the stake, every year, forever, and the odds get worse as the drive ages. Redundancy inside a single machine, such as a mirrored pair of drives, reduces the risk of a single failure but does nothing against fire, theft, ransomware, or a controller fault that corrupts both drives at once. The only reliable answer is the same as for every other cause: at least one more copy, somewhere the same failure cannot reach.

Software bugs, corruption, and the silent decay of files

Not every loss involves a dramatic event. A large share of data quietly rots, breaks, or is mangled by the software meant to protect it, and this category is especially dangerous because it can spread into your backups before anyone realises anything is wrong.

Software corruption covers several mechanisms. An operating system crash mid-write can leave a file half-saved and unreadable. A file-system error, such as a damaged NTFS structure, can make files disappear or become inaccessible even though the underlying disk is healthy. A failed or interrupted software update can break a database. A bug in an application can write bad data over good, and a bug in a synchronisation client can propagate that bad data everywhere. Estimates vary, but software-related failures and corruption typically account for somewhere between 11 and 22 percent of data-loss events, a share large enough that it cannot be treated as an edge case.

The reason corruption is more insidious than deletion is timing. When a file is deleted, its absence is obvious the moment someone looks for it. When a file is corrupted, it may still appear in the folder, still show a plausible size, and still open partially, so the damage goes unnoticed. If backups run automatically every night, they will faithfully copy the corrupted version over the good one, night after night, until every retained copy carries the same damage. By the time a user opens the file and discovers it is broken, the clean version may have aged out of the backup rotation entirely. This is the specific failure that turns a good backup schedule into a false sense of security.

There is a slower, physical cousin of corruption known as bit rot, or data degradation. Over time, the physical medium storing a file can change state at the level of individual bits, flipping a value here and there. On a spinning disk this comes from magnetic decay and wear; on flash it comes from charge leakage; on optical media it comes from chemical breakdown of the dye layer. A single flipped bit may do nothing, or it may render a compressed archive or a database file unreadable. Bit rot is why serious archival systems do not simply store data and walk away. They use checksums to detect silent corruption and error-correcting techniques to repair it, and they periodically read and rewrite data to refresh it before it decays.

The defence against corruption is not more copies of the same moment. It is copies of different moments, kept long enough. Versioned, historical backups that retain daily or weekly snapshots for a long enough period mean that when today’s file turns out to be corrupt, you can reach back to a version from before the corruption started. Integrity checking, where the backup system verifies that stored data still matches its checksum, catches silent decay before a restore is needed. And crucially, testing restores confirms that the copies you hold can actually be opened and used, rather than being corrupt themselves.

Leading causes of data loss and what actually defends against each

The figures are drawn from several overlapping 2025 and 2026 surveys and should be read as ranges rather than precise constants, since the mix shifts with the audience surveyed. The pattern that matters is in the two right-hand columns: the same weak protection fails against every cause, and each cause demands a different property from the backup.

Cloud storage is not the same thing as a backup

The single most common and most expensive misunderstanding in modern data protection is the belief that using cloud storage means the data is backed up. It does not, and the confusion has cost a great many people their files.

The root of the confusion is that three different things all get called “the cloud.” The first is cloud sync, such as the default behaviour of consumer OneDrive, Google Drive, Dropbox, or iCloud. Sync keeps a folder identical across your devices and a copy in the provider’s data centre. The second is cloud storage as a live working system, such as the files inside a Microsoft 365 or Google Workspace tenant that your business runs on every day. The third is cloud backup, a service whose specific job is to keep separate, historical, restorable copies of data that live somewhere the working system cannot reach.

Only the third is actually a backup. The first two are working copies, and a working copy inherits every problem of the original. If you delete a file in a synced folder, sync deletes it from the cloud. If ransomware encrypts your files, sync uploads the encrypted versions. If a file is corrupted, the corruption syncs. Sync solves availability across devices and protects against a single laptop dying, which is genuinely useful, but it does not protect against the deletions, corruption, and attacks that cause most serious loss. Surveys bear this out: 43 percent of cloud users report having experienced accidental deletion or data corruption inside SaaS platforms, and the large majority of cloud data loss comes from misconfiguration or user error rather than any failure of the provider.

The providers themselves are extraordinarily reliable at the one thing they promise, which is not losing your data through their own fault. Major object-storage services advertise eleven nines of durability, meaning 99.999999999 percent annual durability. In plain terms, if you stored one million files, statistically you would expect to lose one file roughly every several hundred thousand years. That number is real, and it is why people trust the cloud. But it answers a question almost nobody is actually asking. Eleven nines describes the chance the provider’s infrastructure silently loses a file you asked it to keep. It says nothing about the far more likely events: you deleting the file, an attacker encrypting it, a bad sync propagating a mistake, or your account being compromised. The provider will preserve your deletion, your corruption, and your ransomware with the same eleven-nines reliability it preserves everything else.

There is also the durability-versus-recoverability gap. Durability means the bits are safe. Recoverability means you can get a specific earlier version of a specific file back after something goes wrong. A service can offer perfect durability and almost no recoverability, and most raw cloud storage does exactly that, because keeping old versions costs money and is not what the base service is for.

The practical rule is simple and worth stating without hedging. Sync is not backup. Live cloud data is not backup. A backup is a separate, versioned, independently controlled copy that survives the deletion, corruption, or compromise of the original. If your entire protection strategy is that your files are “in the cloud,” you have redundancy against one narrow failure and no protection against the failures that actually happen most often. The next section explains why the companies running that live cloud data are, by contract, largely on their own for recovery, whether or not they realise it.

The shared responsibility model most SaaS users misread

Every major software-as-a-service platform runs on a principle called the shared responsibility model, and misreading it is one of the most consequential mistakes a business can make with its data. The model divides duties between the provider and the customer, and the part that trips people up is which side owns recovery of the data itself.

Under the Microsoft 365 shared responsibility model, Microsoft is responsible for the platform: physical infrastructure, network availability, service uptime, and the geo-redundant replication that keeps the service running across data centres. The customer is responsible for the data inside their tenant, along with identity and access management, security configuration, and retention settings, across every workload including Exchange Online, SharePoint, Teams, and OneDrive. Google Workspace operates on the same division. The provider keeps the service running. The customer owns the recoverability of the data.

The critical sentence, which appears in the vendors’ own documentation and in independent analysis alike, is that replication is not backup. Microsoft copies your data across its data centres so the service survives a hardware failure. But if you delete something, the deletion replicates. If ransomware encrypts files synced to OneDrive, the encrypted files replicate. If an administrator or a compromised account destroys data inside the tenant, that destruction replicates. Geo-redundancy protects Microsoft’s service from Microsoft’s own infrastructure problems. It does not protect your data from you, your staff, or an attacker who has your credentials.

Microsoft’s native protections reinforce the gap rather than closing it. The recycle bins and retention policies built into the platform are time-limited, can be configured away, and can be cleared by an attacker who gains sufficient privileges. They are convenience features for short-term “undo,” not a backup system with independent control and real retention. Microsoft itself recommends in its services agreement that customers regularly back up their content using third-party applications, which is a striking thing for a provider to say and a line most customers have never read.

The reason this matters so much is the sheer concentration of business-critical data now living in these platforms. For a typical company, Microsoft 365 or Google Workspace holds the email history, the shared documents, the collaboration records in Teams or Chat, and often the primary file storage. All of it is subject to the shared responsibility model, which means all of it is the customer’s responsibility to be able to recover. Yet surveys consistently find that only around a quarter of organisations back up their SaaS data, with the rest relying on vendor retention policies they misunderstand as backup.

The independent-backup argument has a specific technical shape. Best practice for SaaS data is a backup stored separately from the source, under the customer’s own control, in a different data centre from the live tenant, with enough retention to recover from a deletion or compromise discovered weeks later, and with restore options granular enough to bring back a single mailbox or file rather than only an all-or-nothing rollback. Organisations that use independent third-party SaaS backup recover from incidents markedly faster than those relying solely on vendor retention, with one analysis putting the recovery-speed advantage at around 45 percent.

There is a compliance dimension too. Because the data is the customer’s responsibility, so are the legal obligations attached to it. If a regulator, an auditor, or a legal process requires you to produce or preserve specific records, “the provider had it” is not an answer if the provider’s retention window already expired. The responsibility to be able to produce the data sits with the organisation that owns it.

The honest summary is uncomfortable for anyone who assumed the cloud handled this. Moving to a major SaaS platform does not move the responsibility for recovering your data. It moves the infrastructure while leaving the data recoverability with you, and it does so in a way that most customers never explicitly agree to or even notice. The gap between what the contract says and what the customer believes is exactly the gap that turns into permanent loss when something goes wrong inside the tenant.

CloudNordic and the day a company lost every customer at once

Abstract warnings about backups on the same network never land as hard as a single concrete case, and the CloudNordic incident is the case that turns the theory into something you can see.

CloudNordic was a Danish cloud-hosting provider. In the early hours of Friday, 18 August 2023, it was hit by a ransomware attack that, in the company’s own words, shut down all systems: websites, email systems, customer systems, and customer websites. The company described the attack as having paralysed it completely. Hundreds of business customers relied on CloudNordic and its sister brand AzeroCloud, owned by the same parent company, for their hosting, and those customers were hit alongside the provider.

What makes the case a textbook lesson is the specific failure of the backups. The attack happened during a migration between data centres. Some servers had been infected before the move with a dormant infection the company was unaware of. During the migration, those previously separated servers were connected to the company’s internal network, and that connection gave the attackers a path into the central administration systems and the backup systems. The result, in CloudNordic’s own account, was that the attackers succeeded in encrypting all servers’ disks as well as the primary and secondary backup systems. Every machine crashed, and access to all data was lost.

CloudNordic decided not to pay the ransom, partly on principle and partly, by some accounts, because the money was not there. Its team and external experts worked to recover what they could. The outcome was stated plainly on the company’s website: it had proved impossible to re-create more data, and the majority of customers had lost all their data. The company’s advice to those customers was to try to restore from any local backups they had kept themselves, and, remarkably, to recover website content from the Internet Archive’s Wayback Machine, essentially rebuilding from cached public copies because nothing else survived.

Several lessons stack up in this one event. The first is the central theme of this article: a backup connected to the same network as the production data is not a backup against ransomware. The primary and secondary backup systems were both reachable from the internal network, so the attack that destroyed the live data destroyed the backups in the same motion. Two copies were kept, but they shared a single fatal dependency.

The second lesson is that a dormant, unnoticed infection can sit in an environment for a long time and detonate at the worst possible moment, in this case during the vulnerability of a migration. This connects directly to the professional world, where server migrations are routine work, and where the interconnection of systems during a move is exactly when isolation matters most.

The third lesson is about dependency. CloudNordic’s customers had, in effect, outsourced their entire data existence to a single provider and kept no independent copy of their own. When the provider failed, they had nothing to fall back on. This is the shared responsibility model made brutally literal: the customers who survived best were the ones who had kept their own local backups, exactly as good practice dictates and exactly as most had not.

The company faced bankruptcy after the attack. The customers who had treated the provider as their only copy faced their own version of the same outcome. No single decision caused the disaster, but the absence of an isolated, independent backup is what turned an attack into an extinction event.

GitLab, five backups, and the one that actually worked

If CloudNordic shows what happens when backups share a fatal dependency, the GitLab incident of 2017 shows something even more sobering: an organisation can have five separate backup mechanisms and still nearly lose everything, because having a backup and having a working backup are not the same thing.

GitLab is a widely used software development platform. On 31 January 2017, an engineer was troubleshooting a replication problem between the primary database and a secondary replica that had fallen hours behind. During maintenance, the engineer ran a cleanup command intended for the replica while connected, by mistake, to the production database. Tables began disappearing within seconds. By the time the command was cancelled, a folder containing around 300 gigabytes of live production data had been reduced to roughly 4.5 gigabytes. The engineer had done ordinary work under pressure and hit the wrong target, the single most human failure imaginable.

Then came the part that turned a recoverable mistake into a public crisis. GitLab had, on paper, five different backup and replication methods. When the team went to restore, they discovered that none of the five were working reliably or had been set up correctly in the first place. The regular database dumps had been silently failing, and the destination bucket was empty. The disk snapshots were taken only once every 24 hours by default and were not configured for this database. The staging-environment copy was not a trustworthy restore source. The cloud-stored backups were incomplete, holding data from one server but not the database server. Each mechanism had a different flaw, and every flaw had gone unnoticed because nobody had ever tried to restore from them.

What saved GitLab was luck dressed up as a sixth option. An engineer had, six hours before the deletion, manually taken a snapshot of the database to a staging server for an unrelated reason. That manual, unscheduled, almost accidental copy was the only usable backup in the entire company. GitLab restored from it, losing roughly six hours of data and around eighteen hours of downtime. The gap between “five backups” and “one accidental copy that happened to exist” is the whole lesson.

GitLab handled the aftermath with unusual transparency, publishing live notes during the recovery and a detailed post-mortem afterward, and at one point live-streaming the restore to thousands of viewers. That openness is why the incident became a widely taught example rather than a quietly buried embarrassment. The technical failures it exposed are common; what was rare was the willingness to document them.

The lessons apply to organisations of every size. The first is the one GitLab’s own post-mortem made famous: a backup that has never been restored is not a backup, it is an assumption. Backups fail silently. A job that reports success can be writing to the wrong place, capturing the wrong data, or producing corrupt archives, and none of that is visible until the day you need to restore and cannot. The only way to know a backup works is to perform a real restore and confirm the data comes back intact.

The second lesson is that redundancy of broken mechanisms is not redundancy. Five backups that all fail are worth less than one backup that is tested monthly. Adding more untested methods creates a feeling of safety proportional to the number of methods and inversely proportional to the actual protection, which is the worst possible relationship.

The third lesson is about permissions and guardrails. The deletion happened because an engineer with production access could run a destructive command against the wrong system with nothing to stop them. Limiting who can execute destructive operations, adding confirmation steps for irreversible actions, and making it visually obvious which system a person is connected to are cheap controls that prevent expensive mistakes. Industry surveys since have consistently found that only around half of organisations test their disaster-recovery plans annually, and a large share never test at all, which means the GitLab situation, five backups and no confidence any of them work, is closer to the norm than most managers would like to believe.

Where money leaks when data disappears

The cost of a data-loss incident is almost always larger than the obvious number, and understanding where the money actually leaks is what turns backup from a grudging expense into an easy decision.

The most visible cost is recovery itself. If data can be recovered at all, it takes specialist time, sometimes a data-recovery lab, sometimes weeks of engineering effort to rebuild systems from whatever partial copies exist. For a serious incident at a small or mid-size business, recovery costs alone can reach into the hundreds of thousands of dollars once you account for external help, overtime, and replacement hardware.

The larger and more easily overlooked cost is downtime. While systems are down, the business is not fully operating, and revenue that would have been earned is simply not earned. This is why downtime is measured per hour rather than as a lump sum. As noted earlier, the Uptime Institute puts severe outages at up to 100,000 dollars per hour, a quarter of them exceeding a million dollars, and enterprise surveys report the majority of large firms estimating over 300,000 dollars per hour, with a sizeable minority in the one-to-five-million range. For an e-commerce operation, the figure can be higher still, because every hour offline is an hour of orders going to competitors. Ransomware downtime is particularly punishing, with the average affected business facing roughly 16 days of disruption.

Beyond recovery and downtime sit the costs that arrive later and last longer. Lost customers are the clearest. When a service fails and data is lost, some customers leave and do not come back, and acquiring their replacements costs far more than retaining them would have. Reputational damage compounds this, because news of a data loss, especially one involving customer records, spreads and deters prospective customers who never even become statistics in your churn report.

Regulatory penalties are increasingly the decisive factor, and they explain why US breach costs have risen even as global averages fell. When lost or breached data includes personal information, data-protection regulators can impose substantial fines, and the cost of notification, legal advice, and remediation stacks on top. IBM’s finding that the US average breach cost reached 10.22 million dollars, driven largely by regulatory penalties and slower detection, is the clearest signal that the legal environment now sets the price of failure more than the technical damage does.

There is also the cost of the data that cannot be rebuilt at any price. Some data is reconstructable: you can re-enter records, re-scan documents, re-derive analyses. Some is not. Original creative work, irreplaceable records, the institutional memory embedded in years of accumulated files, and the personal data of customers who cannot simply be re-created, all of these have a replacement cost of infinity when there is no copy, because no amount of money brings them back. This is the category that the opening saying is really about. The value of that data was always there; the loss just made it visible.

Set against all of this, the cost of a competent backup system is small and predictable. A serious backup solution for a small business runs in the low four figures per month at most, and often far less; for an individual it can be a few dollars a month plus the price of a couple of external drives. The asymmetry is the entire argument. The recurring cost of protection is a known, modest number. The cost of a single loss is a large, uncertain number that can reach the value of the whole business. Backup is the rare expense where the worst case of spending the money is trivial and the worst case of not spending it is fatal.

Recovery time and recovery point, the two numbers that decide survival

Two technical terms sit at the centre of every serious data-protection plan, and once you understand them, the whole subject becomes concrete rather than vague. They are Recovery Time Objective and Recovery Point Objective, usually shortened to RTO and RPO. They are not jargon for its own sake. They are the two questions that decide how much a disaster actually hurts.

Recovery Time Objective answers the question: how long can we afford to be down? It is the maximum acceptable time between the moment something fails and the moment operations are restored. If your online store must be trading again within two hours to avoid serious harm, your RTO is two hours. RTO drives the design of the recovery system, because a short RTO requires faster, more expensive infrastructure: standby systems ready to take over, rapid restore capability, and rehearsed procedures. A long RTO can tolerate a slower, cheaper approach such as restoring from off-site storage over a day.

Recovery Point Objective answers a different question: how much data can we afford to lose? It is the maximum acceptable amount of data, measured in time, that can be lost in an incident. If you back up once every 24 hours, your RPO is 24 hours, because a failure just before the next backup could cost you a full day of work. If you cannot afford to lose more than fifteen minutes of data, as is common for healthcare or financial systems, you need backups or replication running at least that often. RPO drives backup frequency. RTO drives recovery capability. They are related but distinct, and confusing them leads to plans that solve the wrong problem.

The reason these two numbers matter more than any product choice is that they translate a fuzzy fear into a budget and a design. Instead of asking “are we protected,” which has no answerable meaning, you ask “what is our RTO and RPO for each system, and does our current setup actually meet them.” That question can be tested. Most organisations that believe they are protected have never defined either number, which means they have never checked whether their backups can deliver what the business actually needs.

The right values differ by system, and treating everything identically wastes money on low-value data and under-protects the crown jewels. A payment system, an order database, or a clinical record system justifies aggressive targets: minutes of RPO, hours or less of RTO. A back-office archive or an internal wiki can tolerate a day of RPO and several days of RTO without harming the business. Mature organisations group their systems by business importance and assign targets suited to each, so that the expensive, fast recovery is spent only where it earns its cost.

There is a financial logic that makes the trade-off visible. As you shorten RTO, the cost of the recovery solution rises, because speed is expensive. As you lengthen RTO, the cost of downtime rises, because every extra hour offline burns revenue and trust. Plotted together, one curve rises as the other falls, and the sensible investment level sits near where they cross. Below that point you are under-protected and exposed to downtime cost; above it you are overspending on speed you do not need. This is the conversation that separates a considered plan from either negligence or panic buying.

A final and often ignored point: an RTO is only real if it has been measured under realistic conditions. The recovery time you achieved in a calm test, or the aspirational number in a policy document, is not the number you will hit during an actual crisis with systems down, people stressed, and dependencies failing. The only trustworthy RTO is one observed during a genuine disaster-recovery test or a real incident. A plan with a two-hour RTO on paper and a never-tested restore process has an RTO of “unknown,” which in practice means “too long.”

The 3-2-1 rule and why it grew two more digits

The most durable piece of advice in data protection is the 3-2-1 rule, and understanding both why it works and why it is no longer sufficient on its own is the core of a modern backup strategy.

The rule was popularised by the photographer Peter Krogh and adopted broadly across IT. It says: keep three copies of your data, on two different types of media, with one copy off-site. Each number targets a specific failure. Three copies mean that if one is lost or corrupted, you still have two, so a single failure never leaves you at zero. Two types of media, such as an internal disk plus cloud object storage, or disk plus tape, mean that a flaw affecting one storage technology does not wipe out every copy at once. One copy off-site means that a fire, flood, theft, or site-level disaster that destroys your premises cannot destroy all your data, because one copy lives somewhere else entirely.

The elegance of the rule is that it defends against the classic threats, hardware failure, accidental deletion, and physical disaster, with a structure simple enough to remember and cheap enough to implement. For a long time it was genuinely enough, and it remains the correct foundation. Any plan that does not at least satisfy 3-2-1 is not a serious plan.

But ransomware changed the threat, and the rule had to grow to meet it. The problem is that classic 3-2-1 says nothing about whether the copies are reachable by an attacker. If all three copies sit on systems connected to the same network, a ransomware attack can encrypt all of them at once, which is exactly what happened to CloudNordic. The rule protected against the twentieth-century enemies and left the twenty-first-century one a clear path.

The modern extension is called the 3-2-1-1-0 rule. It keeps the original three requirements and adds two more. The extra 1 is one copy that is offline or air-gapped or immutable, meaning a copy that ransomware cannot reach and cannot alter or delete even if the attacker holds administrator credentials. This could be a tape stored physically disconnected, a cold-storage vault, or immutable cloud storage where data cannot be overwritten or deleted for a defined retention period. The 0 stands for zero errors, meaning every backup is verified and tested, so you never discover at restore time that your copies are corrupt or incomplete. That final zero is the GitLab lesson written into the rule.

The two additions map precisely onto the two failures that defeated older plans. The immutable copy defeats the ransomware tactic of destroying connected backups. The zero-errors requirement defeats the silent-failure tactic that leaves organisations with backups that exist but do not work. Together they turn a redundancy plan into a resilience plan.

There are further variants for demanding environments, such as the 4-3-2 approach favoured by some managed providers, which calls for four copies across three locations with two of them off-site, adding geographic diversity for organisations that cannot tolerate losing an entire region. But for the overwhelming majority of businesses and individuals, 3-2-1-1-0 is the current standard worth aiming for, and 3-2-1 remains the non-negotiable minimum. The next two sections examine the two new digits in detail, because they are where most real-world plans still fall short.

Immutability and the air gap that ransomware cannot cross

The single most important upgrade to a backup strategy in the ransomware era is the addition of a copy that cannot be changed or destroyed by anyone, including an attacker who has taken full control of your systems. This is the idea behind immutability and the air gap, and it is worth understanding precisely because vendors use the words loosely.

An air gap is physical or logical isolation. In its original form it meant a copy stored on media that is physically disconnected from any network, such as a tape removed from the drive and locked in a safe, or a backup drive that is unplugged after each backup completes. Nothing on the network can reach it because there is a literal gap of air between it and everything else. Ransomware, which spreads across network connections, simply cannot touch a disconnected tape. The weakness of the classic air gap is operational: it depends on a human reliably disconnecting and rotating media, which is exactly the kind of task that gets skipped under pressure.

Immutability achieves a similar result through software rather than disconnection. An immutable backup is written in a way that makes it impossible to modify or delete for a defined retention period, even by an administrator. In cloud object storage this is implemented through an object-lock feature, where each stored object is locked for a set number of days and cannot be overwritten or erased until the lock expires, regardless of what credentials someone presents. The practical effect is that even if an attacker fully compromises your environment and obtains your backup system’s admin password, they cannot delete or encrypt the immutable copies. They can only wait for the retention period to expire, by which point you have detected the attack and restored.

The reason this specific property matters is that it directly defeats the attacker’s playbook. Recall that attackers target backup repositories in roughly 96 percent of ransomware incidents, because destroying the backup is what forces the ransom payment. Immutability removes their ability to do that. It is the technical answer to the CloudNordic failure, where connected backups were encrypted alongside the live data. Had one copy been genuinely immutable or air-gapped, the company would have had something to restore from and might have survived.

Immutability is not a single guaranteed thing, and this is where care is needed. True immutability means the data cannot be altered even by a privileged insider or a compromised admin account, for the full retention period. Some products advertise immutability that can be shortened or disabled by an administrator, which is not immutability against an attacker who has become that administrator. When evaluating a backup product, the question to ask is specific: can this copy be deleted or altered by someone with full administrative control before the retention period ends? If the answer is yes, it is not protecting you against the threat that matters most.

There is a cost and convenience trade-off. Immutable storage cannot be tidied up early, so you pay to retain data for the full locked period even if you would rather delete it, and you must plan retention windows carefully to balance protection against storage cost. Cloud egress fees, the charges for retrieving data during a large restore, are a related and frequently underestimated cost; surveys report that the large majority of IT leaders have been surprised by unexpected cloud storage charges, so the economics of a restore should be understood before an emergency, not during one.

The takeaway is that the extra 1 in 3-2-1-1-0 is not a nice-to-have refinement. It is the specific countermeasure to the specific tactic that turns ransomware from a disruption into a catastrophe. A plan without at least one immutable or air-gapped copy is a plan that assumes the attacker will not go after your backups, and every piece of evidence says they will.

Backup, replication, and sync are three different promises

Three technologies are constantly confused with one another, and the confusion is not academic, because each makes a different promise and defends against a different failure. Treating any one of them as if it were the others is how people end up with a false sense of protection.

Synchronisation keeps two or more locations identical. When a file changes in one place, sync makes the same change everywhere else, as fast as it can. This is the model of consumer cloud drives and collaboration folders. Its promise is availability and consistency: the same current files, everywhere, on every device, all the time. Its defining limitation is that it propagates everything, including your mistakes. A deletion syncs. An encryption syncs. A corruption syncs. Sync answers the question “how do I have my current files on all my devices,” and it answers it well, but it is structurally incapable of answering “how do I get back a version from before something went wrong,” because keeping the past is the opposite of its job.

Replication keeps a live secondary copy of a system continuously updated so that it can take over quickly if the primary fails. This is how databases stay resilient and how services achieve high availability. Its promise is continuity: if the primary server dies, the replica is already running with current data and can take the load with minimal interruption. Its limitation is the same as sync’s, only faster and more complete. A replica reflects the primary in near real time, so if the primary is corrupted, deleted, or encrypted, the replica reflects that damage almost instantly. Replication protects against a component or server failing. It does not protect against the data itself being wrong, because its entire purpose is to make the secondary match the primary as closely as possible.

Backup keeps separate, historical, restorable copies of data as it existed at past points in time. Its promise is recovery: the ability to reach back to a known-good version from before an incident, whatever the incident was. This is the only one of the three that defends against deletion, corruption, and ransomware, because it is the only one that deliberately preserves the past rather than mirroring the present. A backup from yesterday, kept separately, is unaffected by today’s mistake or attack.

The reason organisations get this wrong is that replication and sync feel like protection. They involve extra copies, extra locations, and reassuring dashboards, and for the failure they are designed for, hardware or server failure, they genuinely work. But they were never designed to answer the recovery question, and using them as the answer leaves the most common causes of loss undefended. GitLab had replication, and replication is precisely what carried the deletion instantly from the primary to the systems around it; what saved the company was a backup, an unscheduled manual snapshot that captured a past state.

A working data-protection strategy usually uses all three, because they solve different problems. Replication or high availability keeps the service running through hardware failure. Sync keeps people productive across devices. And backup, separate, versioned, and ideally immutable, is the layer that lets you recover from the failures the other two propagate. The mistake is not using sync or replication. The mistake is believing either one is a backup. They are three different promises, and only one of them is a promise to give you back what you lost.

A backup you have never restored is only a hope

The most expensive words in data protection are “we have backups.” They are expensive because they are so often said with confidence by people who have never once tested whether the backups actually work, and untested backups fail at a rate that would shock the managers who rely on them.

The uncomfortable statistics tell the story. Industry data indicates that only around 57 percent of backups complete successfully, and only around 61 percent of restores succeed. Read those numbers slowly. Roughly two in five backup jobs do not fully complete, and roughly two in five attempted restores do not fully succeed. A backup regime that runs every night and reports green checkmarks can still be, on these figures, close to a coin flip when the moment of truth arrives. And the moment of truth is the only test that counts, because backups fail silently in ways that a success message cannot detect.

There are many ways a backup that appears to work can be useless. The job can be writing to a destination that is full, unreachable, or wrong, as GitLab discovered when its cloud bucket turned out to be empty. It can be capturing the wrong data, backing up an application’s files but not its database, or a user directory but not the system state needed to make it usable. It can be producing corrupt archives that cannot be opened. It can be encrypted with a key nobody can find. It can be complete and correct but so slow to restore that the RTO is blown by days. Every one of these failures is invisible until someone attempts a real restore.

This is why the 0 in 3-2-1-1-0, meaning zero errors and verified backups, is not optional. Verification has two levels. The lower level is automated integrity checking, where the backup system confirms that stored data still matches its checksums and that jobs completed without error. This catches silent corruption and failed jobs and should run continuously. The higher level, and the one almost everyone skips, is the actual restore test: taking a backup and bringing the data back to a working state, opening the files, running the application, confirming the database is intact. Only a real restore proves the whole chain works, from the backup media through the restore software to usable data.

Restore testing should be routine and realistic. Routine means scheduled, not “when we get around to it,” because the interval between tests is the interval during which your backups could have silently broken without anyone knowing. Realistic means testing the scenarios you actually fear: restoring a single deleted file, restoring after a full server loss, restoring an entire environment from the off-site immutable copy as if the primary site were gone. The number that matters is not whether a test restore is possible in principle but how long it takes and whether it produces working systems, because that is your true, measured RTO.

Testing also builds the human capability that matters during a crisis. A team that has rehearsed restores knows the procedure, has fixed the surprises in advance, and can execute under pressure without improvising. A team that has never done it will be learning the process for the first time during the worst day of the year, with executives watching and the clock running. Disaster recovery is a skill, and skills decay without practice.

The organisations that survive incidents are not the ones with the most backup technology. They are the ones that treat a successful restore as the metric of reliability, not a successful backup. A backup is a claim. A restore is the proof. Until you have performed the restore, you do not have a backup; you have a hope, and hope has a documented failure rate of around 40 percent.

Storage media age, and each type ages differently

The physical medium you choose to store a backup on is not a neutral detail. Each type of storage ages, fails, and degrades in its own characteristic way, and matching the medium to the job is part of building a plan that actually holds data for as long as you need it.

Spinning hard disk drives are the workhorse of bulk storage. They are cheap per terabyte, hold data well when powered periodically, and can retain data for many years even when left unpowered, which makes them a reasonable choice for a cold copy kept in a safe. Their weakness is mechanical: they contain moving parts that wear out, and their annual failure rate rises steeply with age, from around 1.4 percent across a broad fleet to far higher for old or troubled models. A hard drive is a good medium for a backup you refresh and eventually replace, not a set-and-forget archive for decades.

Solid-state drives are fast, shock-resistant, and increasingly common, but they are a poor choice for the specific job of a long-term unpowered backup. Flash memory holds data as a trapped electrical charge, and that charge leaks away over time when the drive has no power. A consumer SSD left in a drawer can start losing data within a year or two, and warm storage conditions accelerate the decay. For an archive that sits untouched, this is disqualifying. SSDs are excellent for the working copy and for fast restores; they are the wrong medium for the copy you intend to leave alone.

Tape is the medium people assume is obsolete and keep discovering is not. It is slow to access, which makes it useless for fast restores, but it is cheap, extremely durable over decades, and, crucially, offline by nature. A tape sitting in a vault is air-gapped by default, immune to ransomware because nothing on the network can reach it. This is why tape remains in wide use for archival and compliance storage, with surveys showing a substantial share of businesses still relying on it precisely because being disconnected is a feature, not a flaw. For the “one offline copy” in 3-2-1-1-0, tape is a natural fit for organisations with the volume to justify it.

Optical media such as archival-grade discs occupy a niche for very long-term storage. Standard writable discs use organic dyes that degrade over years, but specialised archival discs carve data into an inorganic, rock-like layer designed to last for a century or more, immune to the charge leakage and magnetic decay that limit other media. For a small volume of truly irreplaceable data that must survive for decades, this class of media is one of the few honest answers, though it is impractical for large or frequently changing data sets.

Cloud object storage is, in effect, a managed medium where the provider handles the underlying disks, replicates across locations, and offers durability figures like eleven nines. For the off-site copy, and increasingly for the immutable copy through object-lock features, cloud storage is convenient and reliable, provided you understand that the durability figure protects against the provider’s own failures, not against your deletions, and that retrieval costs can be substantial during a large restore.

The reason media choice matters is that a backup is only as good as the medium’s ability to hold the data until you need it, and the two failure modes people trip over are trusting SSDs for cold storage and forgetting that all media eventually ages out. The disciplined approach is to use different media for different roles, which is exactly what the “two different types of media” requirement in 3-2-1 was always about, and to refresh and migrate archives before the medium reaches the end of its reliable life. Data does not decay all at once; it decays quietly, and the medium is where the quiet decay begins.

The retail sector and the cost of a frozen checkout

Retail and e-commerce feel the loss of data with unusual immediacy, because in retail the data is directly tied to money moving in real time. When systems go down, sales stop, and unlike a service business that can catch up later, a retailer’s lost hour of trade is usually gone for good, spent by customers who bought elsewhere.

The most acute failure is a checkout or payment system going offline. For an online store, every minute the site cannot process orders is revenue redirected to competitors, and the per-hour cost of downtime for a busy e-commerce operation can far exceed the six-figure hourly figures quoted for enterprises generally. A physical retailer whose point-of-sale system fails faces a different but equally damaging version: queues, abandoned baskets, and customers who leave. The data underneath, the product catalogue, pricing, inventory levels, and transaction records, has to be both available and correct for a single sale to complete.

Inventory data is a quieter but serious exposure. If the records of what is in stock, what has been ordered, and what has been shipped are lost or corrupted, the business cannot fulfil orders accurately even after systems come back. Overselling stock that does not exist, or failing to ship stock that does, damages customer trust in ways that outlast the outage. Reconstructing inventory state without a clean backup can mean a physical stock count across every location, days of work, and a period of operating blind.

Retail also sits squarely in the sights of attackers because it processes payment data at scale. Retail and healthcare are repeatedly named among the most-targeted sectors, and major 2025 breaches in retail exposed millions of records. Payment-card data carries specific compliance obligations, and a breach or loss involving it brings both regulatory consequences and the direct cost of card reissuance and fraud monitoring. For retailers, the backup conversation is inseparable from the security conversation, because the same event that loses the data often exposes it.

The seasonal dimension sharpens everything. A retailer’s data-loss incident during a quiet week is painful; the same incident during a peak sales period, a holiday, or a promotional event can represent a disproportionate share of the year’s revenue lost in a single window that cannot be rescheduled. This is why retail RTO and RPO targets for transactional systems are typically aggressive, measured in minutes and hours, and why the recovery capability has to be tested before the peak rather than discovered during it.

The practical shape of protection for retail follows from these pressures. Transactional and payment systems need short RPOs, meaning frequent backups or continuous data protection, so that a failure costs minutes of orders rather than a day. They need short RTOs backed by tested, rapid restore, so trading resumes fast. Inventory and catalogue data need versioned backups so that corruption can be rolled back without a full physical count. And because retail is a prime attack target, at least one immutable copy is necessary, so that ransomware cannot take both the live systems and the backups and hold the business’s entire trading capability hostage during its busiest week.

Healthcare data loss carries a human price, not just a financial one

Healthcare is the sector where data loss stops being purely a business problem and becomes a safety problem, because the data in question is often needed to treat a patient correctly, sometimes urgently. This changes both the stakes and the rules, and it makes healthcare a revealing case for how seriously the rest of us should take our own data.

The financial figures alone are severe. IBM’s 2025 report found healthcare breaches to be the most expensive of any sector at an average of 7.42 million dollars, and healthcare took the longest of any industry to identify and contain a breach, around nine months, more than a month longer than the global average. Longer detection means longer exposure, more damage, and higher cost, and healthcare’s complexity, with its sprawling systems and sensitive records, makes fast containment genuinely hard.

The attack pressure is intense and rising. By mid-2025, over half of healthcare organisations had reported ransomware attacks, a sharp increase, with average ransom payments in the sector reported around 115,000 dollars on top of the operational damage. Attackers target healthcare precisely because the data is critical and the pressure to restore service is extreme; a hospital with encrypted records cannot simply wait, because the disruption endangers patients, which makes the victim more likely to pay. This is a grim illustration of the general point that the value of data determines how much its loss hurts.

The human dimension is what sets healthcare apart. When patient records are unavailable, care is delayed or degraded. Clinicians lose access to histories, medication lists, allergies, and test results, and revert to slower, riskier manual processes. Surgeries and appointments get cancelled. The cost is measured not only in money but in delayed treatment and elevated risk, which is why healthcare typically maintains the most demanding recovery objectives of any sector, with RPOs for patient data often set under fifteen minutes.

Regulatory weight compounds the stakes. Health data is among the most heavily protected categories of personal data under regimes like the GDPR in Europe and sector-specific rules elsewhere, and its loss or exposure triggers strict obligations and substantial penalties. The organisation is responsible for both keeping the data recoverable and keeping it confidential, and a single incident can breach both duties at once.

The lesson healthcare offers to every other sector is about proportionality. Healthcare invests heavily in short RPOs, tested rapid recovery, immutable and isolated backups, and rigorous restore drills, not because it is more cautious by temperament but because the value of its data, measured in human terms, is so obviously high that under-protecting it is indefensible. The rest of us rarely face stakes that stark, but the reasoning transfers directly: the more a piece of data matters, the shorter its acceptable RPO, the faster its required RTO, and the less excuse there is for having no tested, isolated copy. Healthcare simply makes the calculation impossible to ignore.

Professional services and the trust that evaporates with the files

Professional services firms, the agencies, law practices, accountancies, consultancies, architects, and design studios, hold a particular kind of data whose loss is quietly devastating: the accumulated work product and client records that are, in a real sense, the entire business. A manufacturer that loses data still has its machines; a services firm that loses its files has lost the thing it sells.

The core asset is the work itself. Years of client deliverables, case files, designs, financial models, contracts, correspondence, and the institutional knowledge embedded in shared documents represent thousands of hours of billable work that cannot be reconstructed from memory. Unlike inventory, which can be recounted, or transactions, which can sometimes be re-entered from receipts, creative and analytical work product is often genuinely irreplaceable. A design that took weeks to develop, a legal argument built across hundreds of documents, an audit trail assembled over months, none of these can be recreated at any reasonable cost once the files are gone.

Client trust is the second asset, and it is even more fragile. When a professional firm loses a client’s data, or has to admit it cannot retrieve the client’s project, the damage to the relationship is frequently terminal. Clients hand over their information on the implicit promise that it will be kept safely, and a firm that breaks that promise loses not only the affected client but its reputation among the client’s network. In services, reputation is the primary source of new business, so a single visible data-loss incident can reduce the future revenue pipeline in ways that never appear as a line item.

Confidentiality obligations add legal exposure. Law firms carry duties of confidentiality and privilege; accountancies handle sensitive financial data; agencies hold clients’ commercial secrets and often their customers’ personal data. Losing or exposing this data can breach professional obligations, contractual commitments, and data-protection law simultaneously, turning a technical failure into a professional-conduct problem.

Professional firms also tend to carry a specific structural vulnerability: their data is often concentrated on a small number of machines and lightly protected, because the firm sees itself as a knowledge business rather than an IT operation. A small agency may run on a shared drive, a few laptops, and a cloud collaboration suite, with no dedicated IT staff and no considered backup beyond whatever sync the collaboration tools provide by default. That default sync, as established earlier, protects against a lost laptop and nothing else. The mistake, corruption, or ransomware that hits the shared workspace propagates everywhere, and there is no historical, isolated copy to recover from.

The protection that fits professional services is not exotic. It is a genuine backup of the collaboration and file systems, independent of the live cloud tenant, with enough version history to recover a project as it stood before an incident, and enough retention to recover from a deletion or corruption discovered weeks later. It is at least one immutable copy, because agencies and firms are attractive ransomware targets given how completely they depend on their files. And it is a habit of testing restores, because the moment a client asks for a deliverable that has been lost is the wrong moment to discover the backup never worked. For a firm whose whole value is its accumulated work and its clients’ trust, the backup is not an IT expense. It is insurance on the only assets the business actually has.

Manufacturing, logistics, and the cost of a stalled line

Manufacturing and logistics show a different face of data loss, one where the data is inseparable from physical operations, and where losing it does not just stop a screen, it stops a production line or a supply chain.

Modern manufacturing runs on data at every level. Production schedules, machine configurations, quality-control records, bills of materials, and the control systems that drive automated equipment all depend on data being available and correct. When that data is lost or systems go down, the physical process halts. A stalled production line is not merely idle; it burns fixed costs, misses delivery commitments, and can spoil in-process materials, and restarting a complex line is itself slow and expensive. The per-hour cost of downtime in manufacturing routinely lands in the high figures precisely because the physical plant keeps costing money whether or not it is producing.

Logistics and supply-chain operations are similarly data-dependent and even more time-sensitive. The records of what is where, what is en route, what has been received, and what is due to ship are the nervous system of a distribution operation. Lose or corrupt that data and the physical goods keep moving while the system that tracks them goes blind, producing misdeliveries, lost shipments, and a reconciliation problem that can take weeks to untangle. In just-in-time operations, where inventory buffers are deliberately thin, a data outage propagates quickly into stockouts and stalled downstream production at customers.

Manufacturing carries a specific technical wrinkle: operational technology. The industrial control systems and equipment on a factory floor often run older software on long lifecycles, are harder to patch than office systems, and were frequently designed for isolated networks in an era before ransomware. As these systems have become connected for efficiency and monitoring, they have also become reachable by attackers, and a ransomware incident that jumps from the office network to the operational network can halt physical production directly. The configurations and programs that run this equipment are exactly the kind of hard-to-recreate data that needs isolated, versioned backups, because rebuilding a line’s control configuration from scratch is a major undertaking.

Supply-chain interdependence multiplies the reach of any single loss. IBM’s 2025 report found supply-chain compromises to be the second-most-common attack vector, at nearly 15 percent, and a data-loss incident at one link in a chain cascades to every partner that depends on it. The CloudNordic case is again instructive at a smaller scale: hundreds of businesses lost their data not because of their own failures but because a provider they depended on was hit and had no recoverable backup. Concentration of dependency is a risk in itself.

The protection pattern for manufacturing and logistics emphasises isolation and configuration recovery. Operational-technology systems need backups of their configurations and control programs, stored separately from the systems themselves and isolated from the networks that ransomware travels. Scheduling and inventory data need short enough RPOs that a failure costs minutes rather than a shift. And because the cost of downtime is measured against continuously running physical plant, RTO targets have to be short and, above all, tested, because in manufacturing the difference between a two-hour and a two-day recovery is the difference between an inconvenience and a missed delivery season.

Small businesses and the failure rate nobody wants to quote

Small businesses occupy the most dangerous position in the entire data-loss picture, because they combine the exposure of a real business with the protection of a home user. They hold customer records, financial data, and operational systems that matter, yet they typically lack dedicated IT staff, a considered backup strategy, or the cash reserves to absorb a serious incident. The result is a failure rate that vendors quote constantly and verify rarely, and even discounting the shakiest numbers, the underlying reality is grim.

The widely circulated figures, that around 60 percent of small businesses close within six months of a major data loss, and that companies unable to recover within ten days overwhelmingly file for bankruptcy within a year, should be treated with caution because they trace back to older studies that are hard to pin down. But the caution cuts only so far. What is well supported across independent analysis is that small businesses are far less likely to survive a serious incident than larger ones, for reasons that are structural rather than statistical artefacts. A large enterprise can absorb a seven-figure loss, mobilise a response team, and continue operating from reserves. A small business often cannot do any of those things, so an incident that a large firm would survive as a bad quarter can end a small one outright.

The vulnerability has several roots. Small businesses rarely have anyone whose actual job is data protection, so backup is either nobody’s responsibility or an afterthought bolted onto whoever is most comfortable with computers. They tend to rely on the default protections of consumer or small-business cloud tools, which, as established, provide sync rather than backup. They frequently keep critical data on a single machine or a single shared drive, with no off-site or immutable copy. And they are increasingly targeted deliberately, because attackers have learned that small businesses are both poorly defended and, given how completely they depend on their few systems, highly motivated to pay a ransom.

The confidence gap makes it worse. Surveys repeatedly find that a large share of businesses believe their backups would protect them, while a much smaller share have ever tested that belief. Only around half of organisations test their disaster-recovery plans annually, and among smaller firms the rate is lower still. The combination of untested backups and no financial cushion is precisely the combination that turns an ordinary incident into a closure.

There is also a specific dependency risk for small businesses, which is over-reliance on a single external provider. The small firms that survived the CloudNordic collapse were the ones that had kept their own local copies; the ones that treated the host as their only copy lost everything. A small business that has outsourced its email, files, website, and applications to cloud providers and kept no independent backup has concentrated its entire data existence in systems it does not control and cannot recover on its own.

The encouraging part is that competent protection is genuinely affordable at small scale, which makes the exposure a matter of attention rather than budget. A workable plan for a small business, developed in detail later, costs a modest, predictable amount per month, far less than the losses a single incident would inflict, and it does not require an IT department to implement. The barrier is not cost or complexity. It is the belief, common until the day it is disproven, that nothing bad will happen because nothing bad has happened yet. Small businesses are where that belief is most common and most expensive.

The individual professional and a lifetime of files on one laptop

Data loss is not only a business problem, and the individual professional, the freelancer, the sole trader, the person whose working life lives on a single laptop, faces a concentrated version of every risk discussed so far, usually with the least protection of anyone.

The exposure is total in a way that larger operations rarely experience. A freelancer’s laptop often holds the entire business: client work, contracts, invoices, financial records, portfolios, correspondence, and the accumulated files of a career. There is no server, no IT department, no redundancy, just one machine carrying everything, plus perhaps a phone with a similarly concentrated store of photos, messages, and documents. The loss of that one device to theft, failure, or a spilled drink can erase years of work in an instant.

The psychology is the same one identified at the start, only more so. Individuals are the least likely group to back up, with surveys putting the share who never back up at roughly one in five to nearly one in three depending on the country. The reason is the familiar one: nothing has gone wrong, so the risk feels theoretical, and backup feels like a chore with no visible payoff. The payoff, of course, is invisible right up until the moment it becomes the only thing that matters, and by then it is too late to create.

Accidental deletion and everyday accidents dominate individual data loss, ahead of dramatic hacking. Bitdefender’s consumer research and similar surveys consistently find that ordinary mistakes and mishaps, not cybercriminals, are the leading way individuals lose data, with human error responsible for a large share and simple device loss or damage close behind. This matters for the choice of protection, because it means an individual’s plan needs to defend against deletion and device loss first, not against exotic threats.

The additional trap for individuals is the same cloud confusion that catches businesses. Many people believe that because their photos are on iCloud or their documents are in Google Drive, they are backed up. They are synced, which protects against the loss of one device, but a deletion or an account compromise takes the cloud copy with it, and account lockouts, where a person loses access to the very account holding all their data, are a real and underappreciated failure mode. Sync across devices is not a backup, and for an individual whose whole life is in one account, that distinction can be everything.

The good news is that protecting an individual’s data is cheap, simple, and almost entirely automatable, and the detailed plan later in this article lays out exactly how. It amounts to a couple of external drives, a real backup service distinct from sync, and a habit of leaving the automation to do its job. The value of a lifetime of files is enormous, the cost of protecting them is trivial, and the only thing standing between the two is the decision to act before rather than after the loss. For an individual as much as for any enterprise, the value of the data becomes visible the day it is gone; the entire point is to make that day one you can recover from.

GDPR, retention, and the legal weight of the data you keep

For any business handling personal data in Europe, and for many outside it that serve European customers, data protection is not only a matter of business survival but of legal obligation, and the General Data Protection Regulation shapes how backups must be designed in ways that are easy to get wrong.

The GDPR applies to any organisation that collects or processes the personal data of people in the EU, regardless of where the organisation is based. It imposes duties that pull in two directions at once, and reconciling them is the practical challenge. On one side, it effectively requires organisations to keep personal data secure and available, which implies having backups and disaster-recovery capability; losing customer data through negligence is itself a compliance failure. On the other side, it requires organisations to delete personal data in defined circumstances, including honouring a valid erasure request, the so-called right to be forgotten, and removing data once its retention period expires. A backup system has to satisfy both the duty to keep data recoverable and the duty to delete it, and those goals conflict.

The specific tension sits in backups. When someone exercises their right to erasure, the organisation must delete their personal data from its live systems without undue delay, generally interpreted as about a month. But that same data may sit inside historical backups that cannot easily be searched for a single record, and restoring an entire backup to remove one person’s data, then re-backing it up, is often impractical. The GDPR text does not carve out an exception for backups, which unsettles a lot of organisations, but the guidance from supervisory authorities has converged on a workable position.

Regulators, including the UK’s ICO and France’s CNIL, have indicated that data may remain in backups for a limited period until those backups are overwritten in the normal course of the retention schedule, provided the data is put “beyond use.” Beyond use means the backed-up data cannot be accessed or processed for any ordinary purpose, is protected, and is scheduled for deletion when the backup naturally expires. The organisation must be transparent with the individual, explaining that their data has been removed from live systems and will persist in backups only until those backups age out, with the timeframe set by a documented retention policy. The emerging best practice, reflected in recent regulatory commentary, is to maintain a deletion index so that if a backup is ever restored, the records flagged for erasure are automatically re-deleted as part of the restore process, preventing erased data from silently returning to live systems.

Two further points matter for planning. First, the GDPR does not prescribe specific retention periods. Organisations must justify how long they keep data based on the purpose and any applicable legal obligations, which means backup retention windows are not arbitrary technical settings but decisions that must align with a defensible data-retention policy. Some data must be kept for minimum periods under sector rules, such as financial and tax records, and those legal-retention obligations are one of the recognised exceptions that allow data to be kept despite an erasure request.

Second, the responsibility is unavoidable and personal to the organisation. Because the data is the controller’s responsibility, so is proving that retention and deletion are handled correctly, including keeping deletion logs. A regulator asking how you handle erasure in backups will not accept a shrug about technical difficulty; the difficulty is expected to be solved through policy and process.

The strategic reading of all this is that backup and compliance are the same conversation, not separate ones. A backup plan designed without regard to retention and erasure creates legal exposure; a compliance plan designed without regard to backup creates operational fragility. For a business subject to the GDPR, the data it holds carries legal weight, and the systems that protect that data must be built to keep it recoverable, keep it confidential, and let it go when the law requires, all at once. That is a higher bar than “we have backups,” and meeting it is part of what it means to treat data as the serious asset it is.

Insurance, contracts, and the fine print of who pays

When data is lost, the question of who ultimately bears the cost is answered not by fairness but by contracts and insurance policies written long before the incident, and the answers are frequently unwelcome surprises to the people who assumed someone else was covering them.

Cyber insurance has grown from a niche product into a common line of business cover, and it can genuinely reduce the financial blow of a data-loss incident, covering elements such as recovery costs, business-interruption losses, legal fees, notification expenses, and sometimes ransom payments. But cyber policies have become far more demanding about what the insured must have in place, precisely because insurers have paid out on too many preventable incidents. Policies increasingly require, as a condition of cover, that the organisation maintain tested backups, multi-factor authentication, and specific security controls, and a claim can be reduced or denied if the insurer finds those controls were absent or the backups were never tested. The insurance does not replace the need for good backups; it increasingly presupposes them, and reading the policy’s conditions before an incident is the only way to know whether a claim will actually be honoured.

Provider contracts are the other document that decides who pays, and here the shared responsibility model reappears in legal form. The service agreements of cloud and hosting providers typically limit the provider’s liability sharply and place the responsibility for data recovery on the customer. When CloudNordic’s customers lost their data, their recourse against the provider was limited both by the provider’s near-bankruptcy and by contract terms that never promised to be the customer’s backup. The lesson generalises: the standard terms of most providers do not make them liable for the value of your lost data, and assuming otherwise is a contractual mistake with an unlimited downside.

Service-level agreements are frequently misread as data guarantees when they are usually availability guarantees. An SLA promising a high percentage of uptime addresses whether the service is running, not whether your data is recoverable after you delete it, corrupt it, or have it encrypted. The remedy for an SLA breach is typically a service credit, a small refund, not compensation for lost data or lost business. Confusing an availability SLA with a data guarantee is a common and expensive error.

For businesses that handle other organisations’ data, agencies, hosts, processors of any kind, the contracts run in the other direction too. A firm holding client data usually carries contractual obligations to protect and be able to produce that data, and losing it can trigger liability to the client on top of any regulatory penalty. This is why the professional-services exposure discussed earlier is not only reputational but contractual: the firm may owe the client for the loss, and its own insurance may or may not respond depending on the controls it had in place.

The practical conclusion is that the financial protection around data loss is only as good as the paperwork behind it, and the paperwork rewards preparation. Understanding what your cyber policy actually requires and covers, understanding that your providers’ contracts leave recovery to you, and understanding your own obligations to clients, all of this should be settled while systems are running. The organisations that come through incidents in reasonable financial shape are the ones that read the fine print in advance and built their backups to satisfy it. The ones that read it during the crisis discover, too late, that the coverage they assumed was theirs was conditional on protections they never put in place.

A practical backup plan for a business that has none

Turning all of this into action is simpler than the volume of theory suggests, because the principles collapse into a short sequence of decisions. This is a working plan a business with no serious backup can implement without an IT department, in the order the steps should be taken.

Start by finding out what data you actually have and where it lives. Most businesses have never mapped this, and you cannot protect what you have not located. List the systems that hold important data: the file storage, the email and collaboration platform such as Microsoft 365 or Google Workspace, the accounting system, the customer database or CRM, the website and its database, and any line-of-business applications. For each, note where the data physically sits and who controls it. This inventory is the foundation, because it reveals the dependencies, especially the cloud services you assumed were backed up and are not.

Next, classify the data by importance, because protecting everything identically wastes money and attention. Separate the data whose loss would seriously harm or end the business, the customer records, financial data, and core work product, from data that is merely inconvenient to lose. The critical tier justifies aggressive protection; the rest can be handled more cheaply. This classification is what lets you assign sensible recovery objectives instead of a single blunt policy.

Then set recovery objectives for each tier. For the critical systems, decide the RPO, how much data you can afford to lose, which sets backup frequency, and the RTO, how fast you need to be running again, which sets recovery capability. For most small businesses, a critical-tier RPO of a few hours and an RTO of a day is a reasonable starting point, tightened for anything transactional. Writing these numbers down converts a vague sense of protection into a testable specification.

With objectives set, build the copies to satisfy 3-2-1-1-0. In concrete terms for a typical small business: the live data is copy one. A backup to a local device such as a network-attached storage box or an external drive, on different media, is copy two, giving fast local restores. A backup to a cloud backup service, genuinely separate from your live cloud tenant and off-site by nature, is copy three. At least one of these copies must be immutable or offline, achieved through a cloud backup with object-lock immutability or a rotated offline drive, so ransomware cannot take everything. And the whole system must run to zero errors, meaning verified and tested.

Critically, back up your SaaS data explicitly. If your business runs on Microsoft 365 or Google Workspace, the earlier sections established that the provider does not back it up for you. A third-party SaaS backup that copies your email, files, and collaboration data to independent, immutable storage under your control, with adequate retention and granular restore, closes the single largest gap most modern small businesses have. This is often the highest-value single action available.

A tiered backup plan for a small business

This structure implements 3-2-1-1-0 for an organisation that has no dedicated IT function, using services that exist off the shelf. The columns matter as much as the rows: each layer answers a failure the others do not.

Automate everything you can, because a backup that depends on a person remembering is a backup that will lapse. Schedule the jobs, enable alerting so a failed job is noticed, and remove manual steps wherever possible. The one thing that cannot be fully automated is the restore test, so schedule that as a recurring calendar commitment, perform a real restore at least quarterly for critical systems, and record how long it took, which becomes your measured RTO.

Finally, document the plan and the recovery procedure, and store that documentation somewhere it will survive the incident, not only on the systems it is meant to recover. During a crisis, the person who set everything up may be unavailable, and a written runbook, who to call, where the backups are, how to restore, and in what order to bring systems back, is the difference between a controlled recovery and improvised panic. The plan is not finished when the backups run; it is finished when someone other than its author could execute a full recovery from the documentation alone.

A practical backup plan for an individual or a freelancer

The individual version of the plan is shorter, cheaper, and almost entirely automatic, and it protects the one machine that carries a working life. The same principles apply, scaled down to a person rather than an organisation.

Begin with the same first step: know what you have and where it is. For most individuals the critical data is a manageable list, current work and client files, financial and tax records, contracts and important documents, photos and personal records, and the contents of key online accounts. Note which of these live only on your laptop, which are only on your phone, and which are only in a single cloud account, because anything with only one copy is at risk right now.

Apply a simplified 3-2-1 with an immutable or offline touch. The three copies for an individual are typically the working copy on your laptop, a local backup on an external drive, and an off-site backup in a real backup service. The two media are the internal drive and the external drive or cloud. The one off-site copy is the cloud backup. Adding an occasional offline copy, an external drive that you back up to and then disconnect and store elsewhere, gives you the ransomware-resistant layer without any complexity, and it is the single cheapest way to hold an air-gapped copy.

Choose a real backup service rather than relying on sync. This is the pivotal decision for individuals, because it is where most go wrong. Automatic backup software, whether the operating system’s built-in tool backing up to an external drive, or a cloud backup service that continuously copies your files to versioned, off-site storage, is fundamentally different from the sync in a cloud drive. Backup keeps history, so a deletion or corruption today can be reversed by restoring yesterday, and it is not linked to the account holding your live files, so an account lockout does not take it with it. Sync is a convenience worth keeping, but it is not the backup.

Protect your accounts as part of protecting your data, because for an individual, losing access to the account that holds everything is a form of data loss. Enable strong authentication on your important accounts, keep recovery methods current, and understand that a single compromised or locked account should never be able to erase your only copy of anything. This is why an independent backup, outside the account ecosystem, matters so much for individuals.

Automate and then leave it alone, but verify occasionally. Set the backup software to run continuously or daily without prompting, so protection does not depend on remembering. Then, a few times a year, do the one thing almost nobody does: open the backup and confirm you can actually restore a file. This takes minutes and is the only proof that the automation is doing what it claims. An individual’s untested backup fails as silently as a corporation’s.

The entire individual plan costs very little, a few dollars a month for a cloud backup service and the one-time price of a couple of external drives, against the value of every file a person owns. The barrier, once again, is not cost. It is acting before the loss rather than after, and the person who sets this up on an ordinary day, when nothing is wrong, is buying the ability to shrug off the day when something is.

Mistakes that quietly break otherwise good backup plans

Plenty of organisations and individuals do set up backups and still lose data, because a backup plan can be undermined by mistakes that leave the system looking healthy while quietly failing. These are the traps that catch the people who thought they had done enough.

The most common is never testing the restore, covered earlier but worth naming again as the single largest killer of otherwise reasonable plans. A backup that has never been restored is an assumption, and given documented backup and restore success rates well below 100 percent, it is an assumption with roughly even odds. The fix is boring and non-negotiable: a scheduled, real restore, treated as the measure of whether the plan works.

The second is keeping every copy reachable from the same network. This is the CloudNordic mistake. Multiple backups feel safe, but if ransomware or a destructive command can reach all of them at once because they share a network, they are effectively one copy with a single point of failure. The fix is at least one copy that is genuinely isolated, immutable, or offline, unreachable by whatever destroys the rest.

The third is backing up the data but not what makes it usable. A backup of a database’s files without the ability to reconstruct the database, or of user documents without the system configuration needed to run the applications that open them, produces a restore that returns data you cannot actually use. The fix is to test restores to a working state, not just to confirm files copied, because that is the only way this gap becomes visible.

The fourth is retention that is too short. If backups are overwritten quickly, a deletion or corruption discovered weeks later cannot be recovered, because the last good copy has already aged out. Corruption in particular hides for a long time, so retention must be long enough to reach back past the point where problems typically surface. The fix is deliberate retention windows tied to how long incidents realistically take to notice, not the shortest window that saves storage.

The fifth is trusting sync and replication as backups, the confusion that runs through this whole article. Both propagate the failures that cause most loss, and both feel like protection while providing none against deletion, corruption, and ransomware. The fix is to add a real backup layer alongside them rather than mistaking them for one.

The sixth is ignoring SaaS data because the provider is assumed to handle it. The shared responsibility model leaves recovery of Microsoft 365 and Google Workspace data with the customer, and most customers never back it up, leaving the platform that holds their email and files as an unprotected single copy. The fix is explicit third-party SaaS backup.

The seventh is letting the plan depend on one person. When the individual who understands the backups leaves or is unavailable during a crisis, an undocumented plan becomes no plan. The fix is written procedures that someone else could follow, stored where they survive the incident.

The eighth is treating backup as a one-time project rather than an ongoing practice. Environments change, new systems appear, data moves, and a plan that fit last year can have blind spots this year. Backups need periodic review against the current reality of what data exists and where. The through-line of all eight mistakes is the same: they let a plan look finished while leaving it unable to actually recover data. Avoiding them is less about buying better technology than about the discipline of verifying, isolating, retaining, documenting, and revisiting, which is exactly the discipline the 3-2-1-1-0 rule was designed to encode.

Catching loss early is cheaper than fixing it late

Most of this article has been about having a copy to fall back on, but there is a parallel discipline that decides how bad an incident becomes: how quickly you notice something has gone wrong. A loss caught within minutes is often a minor restore. The same loss caught after weeks can be unrecoverable, because by then the corruption has spread into every backup or the last clean copy has aged out. Detection is the difference between the two, and it is consistently underinvested.

The financial evidence for early detection is unusually clear. IBM’s 2025 report tied the first global decline in breach costs in five years directly to faster identification and containment, with the average time to identify and contain a breach falling to 241 days, a nine-year low, and it stated plainly that shorter breaches cost less because time is the variable that drives the damage. The same pattern appears in ransomware specifically: organisations that detected an attack internally, rather than being informed by the attacker, saved hundreds of thousands of dollars on average. Every hour that a problem goes unnoticed is an hour it continues to spread, and the cost curve is steep.

Detection matters most for the failure modes that are silent by nature. A dramatic ransomware attack announces itself with a ransom note, so detection there is really about spotting the earlier stages, the unusual access, the mass file changes, before the encryption completes. But corruption, silent bit rot, a backup job that has begun failing, and a slow data-integrity problem give no such warning. They are discovered only if something is actively looking for them, and if nothing is, they surface at the worst possible time, when someone finally opens the file and finds it broken, long after the clean version is gone.

Building detection into a data strategy has a few concrete components. The first is monitoring the backups themselves. A backup system should alert loudly when a job fails, when a job has not run when it should have, or when the data it is capturing looks abnormal, such as a sudden mass change consistent with encryption. The GitLab incident happened in part because backup mechanisms had been failing silently for a long time with nobody watching; a simple alert on the empty destination bucket would have surfaced the problem months before it mattered. Monitoring turns a silent failure into a noticed one, which is the entire point.

The second is integrity checking of the data, not just the jobs. Automated verification that stored data still matches its checksums catches bit rot and corruption while a clean copy still exists to restore from. This is the continuous, low-level version of the zero-errors principle, and it is what lets you trust that the copies you hold are actually intact rather than quietly decaying.

The third is anomaly detection on the live systems, watching for the behaviour that precedes loss. Unusual login patterns, mass file modifications, access to backup systems from unexpected places, and the other early signatures of an attack are the signals that let an organisation intervene before encryption or deletion completes. This is where security automation and, increasingly, AI-assisted detection earn their place, by watching more continuously and reacting faster than a human team can, which is precisely the mechanism IBM credited for the fall in breach costs.

The fourth is human attention through routine review. Automated alerts only help if someone acts on them, and alert fatigue, where warnings are so frequent that they are ignored, is a real failure mode. A periodic human review of backup status, restore-test results, and security alerts keeps the automation honest and catches the slow drifts that no single alert flags.

There is an important sequencing insight here. Detection and backup are not alternatives; they are partners that cover each other’s weaknesses. A good backup with poor detection means you can recover, but only after the damage has spread widely and the recovery point is old. Good detection with a poor backup means you know quickly that you are in trouble but cannot do much about it. Together, they mean you notice a problem while it is small and have a clean copy to restore from, which is the combination that turns incidents into non-events.

For individuals and small businesses, the scaled-down version is still worthwhile. Enabling the alerts that backup software and cloud accounts already offer, occasionally checking that backups are current, and paying attention to the security notifications that services send, all cost nothing and shorten the gap between a problem starting and being noticed. The person who gets an alert that a backup has not run in a week can fix it before it matters; the person who never looks discovers the lapse only when they need the backup that was not there.

The underlying principle connects back to the value of data. If the data is worth protecting with a backup, it is worth watching so that you know when it is under threat. Detection is the early-warning system that keeps the value visible while there is still time to act, rather than letting the loss be the thing that finally reveals what the data was worth. Noticing early is cheaper than recovering late, and far cheaper than not recovering at all.

The strategic case for treating data as an asset on the books

The deepest reason organisations under-protect their data is that they do not think of it as an asset in the first place. It appears nowhere on the balance sheet, it depreciates in no ledger, and it is managed as an IT cost centre rather than as a store of value. Changing that framing is what turns backup from a grudging expense into an obvious investment, and the shift is overdue.

Consider what the data actually represents. For most modern businesses, the value is no longer primarily in physical plant or inventory but in information: the customer relationships encoded in a CRM, the accumulated work product of years, the operational knowledge embedded in systems, the transaction history that lets the business understand itself. If a fire destroyed the office but spared the data, most knowledge businesses could rebuild. If the data vanished but the office stood, many could not. That asymmetry is a direct statement of where the value now sits, and it argues that data deserves at least the same protection a company gives its insured physical assets.

Pricing the data, even roughly, makes the protection decision trivial. The exercise is straightforward: for each category of critical data, estimate what it would cost to recreate if it could be recreated at all, add the revenue that would be lost during the recovery, add the regulatory and contractual liabilities its loss would trigger, and add the customers and reputation that would not return. The sum is almost always far larger than anyone expected, and it is the number that should be set against the modest recurring cost of protection. Once the data has a price, the fact that a competent backup costs a small fraction of it ends the debate. This is the balance-sheet version of the opening saying: the value was always there, and putting a number on it in advance is how you avoid learning the number the hard way.

The framing also changes who owns the problem. When data is an IT expense, backup competes for budget against every other IT line and loses, because it produces nothing visible until it saves everything. When data is recognised as a core asset, its protection becomes a business decision made by the people who own the business risk, and it is funded accordingly. The organisations that protect their data well are almost always the ones where a senior person genuinely understands that the data is the business, not a support function for it.

There is a resilience dividend beyond avoiding disaster. A business with tested, isolated backups can take risks that a fragile one cannot: it can migrate systems, adopt new tools, and recover from mistakes quickly, because it knows a bad outcome is recoverable rather than fatal. Confidence in recovery is itself an operational asset, freeing an organisation to move faster because failure is survivable. The same is true for individuals, whose ability to work without the low-grade fear of losing everything is worth more than the small cost of the protection that provides it.

The strategic conclusion is that data protection is not a technical topic that happens to have business consequences. It is a business topic that happens to be implemented technically. The decisions that matter, how much the data is worth, how much loss is acceptable, how fast recovery must be, are business decisions, and the technology merely executes them. Treating data as the asset it has become, pricing it honestly, and protecting it in proportion to its value is simply competent management of the most important thing most organisations now own. The saying that opened this article is, in the end, a warning against a specific management failure: the failure to see the value of an asset until it is gone. The remedy is to see it now.

Questions the evidence cannot fully settle yet

Honest analysis has to mark the edges of what the evidence supports, and several important questions about data loss and backup remain genuinely open, either because the data is thin, because the situation is changing, or because the answer depends on judgement rather than fact.

The reliability of the most-quoted survival statistics is the clearest example. The figures that businesses close within months of a major loss, or that companies unable to recover quickly go bankrupt within a year, are cited everywhere and traceable to solid primary sources almost nowhere. The direction they point, that small and unprepared businesses fail after serious incidents at much higher rates than large or prepared ones, is well supported by independent reasoning and partial evidence. The precise percentages are not, and anyone quoting them as hard facts is overstating what is known. The honest position is that the risk is severe and the exact magnitude is uncertain.

The role of artificial intelligence cuts both ways and is unsettled. IBM’s 2025 findings show AI already reshaping the picture: security automation is helping organisations detect and contain incidents faster, which lowered global breach costs for the first time in five years, while attackers are using AI to power more convincing phishing and deepfakes, and the rushed adoption of AI tools without governance is creating new exposure, with shadow AI adding materially to breach costs. Whether AI ends up net positive or net negative for data protection depends on choices not yet made, and the current evidence shows both effects running simultaneously. The one clear implication is that AI raises the stakes of the data itself, because the models and the data feeding them become new targets and new points of failure.

The long-term reliability of cloud immutability is not yet fully proven under adversarial pressure. Object-lock and immutable storage are the current best defence against ransomware destroying backups, and the logic is sound, but the arms race is ongoing. Attackers adapt, and it is reasonable to expect them to probe for ways around immutability guarantees, whether through implementation flaws, social engineering of provider support, or attacks on the systems that manage retention. Immutability is the right choice today; assuming it will remain sufficient forever would repeat the exact mistake that left classic 3-2-1 exposed to ransomware.

The durability of storage media over very long timescales is genuinely uncertain for anyone trying to preserve data for decades. The five-year unpowered limits of consumer SSDs, the multi-decade but finite life of tape and hard drives, and the century-plus claims of archival optical media are reasonably well characterised for the near term, but true long-term digital preservation, keeping data readable and intact for a lifetime or beyond, remains an unsolved problem that depends on active migration and refresh rather than any single durable medium. For personal archives meant to outlast their owner, there is no set-and-forget answer yet.

Finally, the regulatory treatment of backups under evolving privacy law will keep shifting. The current position that backed-up personal data can persist “beyond use” until it ages out is a pragmatic accommodation rather than a settled principle, and future guidance or case law could tighten it, forcing more granular deletion from backups than today’s technology handles gracefully. Organisations should design for flexibility here rather than assuming the current interpretation is permanent.

None of these open questions weakens the core conclusion, which the evidence supports firmly: data has real worth, loss is common, and a recent, tested, isolated backup is the decisive factor in whether an incident is survivable. What the open questions counsel is humility about the details and a willingness to revisit the plan as the threats, the technology, and the law continue to move. The value of data is not in doubt. The best ways to protect it will keep evolving, and the organisations that treat their backup strategy as a living practice rather than a finished task are the ones that will still have their data when the next unexpected thing arrives.

Common questions about data loss and keeping a backup

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

IBM Cost of a Data Breach Report 2025 IBM’s twentieth annual report and the primary source for the global average breach cost of 4.44 million dollars and the US record of 10.22 million.

Navigating the AI rush without sidelining security IBM’s own analysis of the 2025 findings, including the 241-day breach lifecycle and the added cost of shadow AI.

Average global data breach cost now $4.44 million Help Net Security’s summary of the 2025 IBM report and its findings on AI-related breaches and recovery timelines.

Data breach costs reach an all-time high in the US CyberScoop’s reporting on the divergence between falling global costs and the record US average driven by regulatory penalties.

Ransomware statistics 2025 Mimecast’s compilation of 2025 ransomware data, including the sharp rise in healthcare attacks and average ransom payments.

Ransomware statistics and trends Fortinet’s overview of ransomware incident volumes, losses, and the sectors most frequently targeted.

What is the 3-2-1 backup rule AvePoint’s 2026 guide to the 3-2-1 rule and its extension to 3-2-1-1-0 for the ransomware era.

The 3-2-1 rule and why it evolved to 3-2-1-1-0 AvePoint’s explanation of the immutable-copy and zero-errors additions and the reasoning behind them.

What is the 3-2-1 backup strategy Acronis on the origins of the 3-2-1 rule and modern variants including 3-2-1-1-0 and 4-3-2.

Shared responsibility model for Microsoft 365 AvePoint’s detailed breakdown of which duties fall to Microsoft and which fall to the customer, including data recovery.

The Microsoft 365 shared responsibility model Veeam’s visual explanation of the model and why replication is not a substitute for backup.

Danish cloud host says customers lost all data after ransomware TechCrunch’s report on the CloudNordic attack, including its statement that backups were encrypted alongside live systems.

Hosting provider CloudNordic loses all customer data SecurityWeek’s account of how a migration connected infected servers to backup systems, leading to total loss.

CloudNordic loses most customer data after ransomware attack TechTarget’s detailed reporting on the incident and the company’s decision not to pay the ransom.

GitLab.com melts down after wrong directory deleted, backups fail The Register’s contemporaneous account of the GitLab deletion and the discovery that five backup methods had failed.

GitLab suffers major backup failure after data deletion TechCrunch’s reporting on the incident and GitLab’s unusual transparency during recovery.

Business continuity and data recovery guide A summary of Uptime Institute research placing severe outage costs at up to 100,000 dollars per hour.

Data loss statistics in the US Infrascale’s survey of technology leaders on the leading causes of data loss and the backup methods in use.

15 data loss statistics all businesses should know Invenio IT’s compilation, including 2025 hard-drive failure rates and the share of businesses hit by major loss.

75+ data loss statistics for 2026 CrashPlan’s aggregation of backup and data-loss statistics, including backup and restore success rates and testing frequency.

GDPR data retention compliance guidelines Usercentrics on how GDPR retention and erasure obligations apply to backups and archives, not only live systems.

Erasing personal data from backup systems under GDPR VeraSafe’s analysis of the right to erasure as it applies to backups and the “beyond use” approach accepted by regulators.

Your unpowered SSD is slowly losing your data XDA Developers on flash charge leakage and why SSDs are a poor medium for long-term unpowered storage.

11-nines data durability explained The Register’s examination of what cloud durability figures like eleven nines actually mean and do not mean.

What are the causes of database loss CloudSecureTech on the causes of data loss and the finding that attackers target backup repositories in most ransomware attacks.

World Backup Day 2026 Bitdefender’s consumer research on how many people never back up and why accidental deletion, not hacking, drives most personal data loss.