<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>The Data Protection Review</title><link>https://backup-manager.org/</link><description>Recent content on The Data Protection Review</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 13 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://backup-manager.org/index.xml" rel="self" type="application/rss+xml"/><item><title>Holiday Change-Freeze Backup Readiness: Skeleton-Crew Recovery Runbooks for Q4</title><link>https://backup-manager.org/disaster-recovery/holiday-backup-readiness-checklist-runbooks/</link><pubDate>Tue, 13 Oct 2026 00:00:00 +0000</pubDate><guid>https://backup-manager.org/disaster-recovery/holiday-backup-readiness-checklist-runbooks/</guid><description>&lt;p&gt;The change freeze exists to protect production from well-meaning engineers. It also removes the people who understand your backup estate at exactly the moment attackers and hardware failures are most likely to test it. Q4 recovery planning is therefore a staffing problem as much as a technical one: the question is not whether your backups work, but whether the person on call at 2 a.m. on a holiday can restore from them without calling the one engineer who is on a plane.&lt;/p&gt;</description></item><item><title>2026 Data Protection Budgets: Where the Spending Increase Is Actually Going</title><link>https://backup-manager.org/backup-strategy/2026-data-protection-budgets-spending/</link><pubDate>Wed, 05 Aug 2026 09:00:00 -0400</pubDate><guid>https://backup-manager.org/backup-strategy/2026-data-protection-budgets-spending/</guid><description>&lt;p&gt;The aggregate numbers for 2026 security spending look uniformly healthy. Gartner&amp;rsquo;s second-quarter forecast puts worldwide end-user information security spending at $248.9 billion, a 12.7% increase year over year, following $213 billion in 2025. Marsh, surveying more than 2,200 cybersecurity leaders across 20 countries, found 66% planning to increase cyber risk prevention investment over the next twelve months, with more than a quarter planning increases above 25%.&lt;/p&gt;
&lt;p&gt;Then you look at data protection specifically, and the picture fractures. Veeam&amp;rsquo;s 2026 Data Trust and Resilience Report, drawing on 900-plus senior IT, security and risk leaders, found 49% increased cybersecurity budgets year over year while 51% held flat or cut. Roughly half of this market is not participating in the growth story at all.&lt;/p&gt;</description></item><item><title>Sophos State of Ransomware 2026: Backup-Based Recovery Overtakes Ransom Payment for the First Time</title><link>https://backup-manager.org/ransomware-resilience/sophos-state-ransomware-2026-backup-recovery/</link><pubDate>Wed, 05 Aug 2026 09:00:00 -0400</pubDate><guid>https://backup-manager.org/ransomware-resilience/sophos-state-ransomware-2026-backup-recovery/</guid><description>&lt;p&gt;Sophos published the seventh edition of its State of Ransomware survey with a headline number that backup teams have been waiting a decade to see: of organizations whose data was encrypted, 66% restored from backups — up 12 percentage points year over year — while 48% paid a ransom. For the first time in the survey&amp;rsquo;s history, restoring from your own copies is not merely competitive with paying an extortionist. It is the majority path.&lt;/p&gt;</description></item><item><title>The Veeam 2026 Data Trust Report: Why 90% of Leaders Are Confident but Only 28% Fully Recover</title><link>https://backup-manager.org/disaster-recovery/veeam-data-trust-report-2026-recovery-gap/</link><pubDate>Wed, 05 Aug 2026 09:00:00 -0400</pubDate><guid>https://backup-manager.org/disaster-recovery/veeam-data-trust-report-2026-recovery-gap/</guid><description>&lt;p&gt;Veeam&amp;rsquo;s Data Trust and Resilience Report, published in April 2026 from responses by more than 900 senior IT, security and risk leaders, contains a pairing that ought to stop any backup team mid-sentence. Ninety percent of organizations expressed confidence in their ability to recover from a cyber incident. Among those actually hit by ransomware, 28% fully recovered all affected data.&lt;/p&gt;
&lt;p&gt;The easy interpretation is that executives are overconfident. That reading is available, and it is not entirely wrong, but it is not very useful — telling people to be less confident does not improve recovery outcomes. The more productive reading is that these two numbers are measuring different things, and the gap between them is where most data-protection programmes quietly fail.&lt;/p&gt;</description></item><item><title>Why 96% of Ransomware Attacks Now Target the Backup Repository First</title><link>https://backup-manager.org/ransomware-resilience/ransomware-targets-backup-repository-first/</link><pubDate>Wed, 05 Aug 2026 09:00:00 -0400</pubDate><guid>https://backup-manager.org/ransomware-resilience/ransomware-targets-backup-repository-first/</guid><description>&lt;p&gt;The figure gets quoted constantly, usually without a source attached: 96% of ransomware attacks target backup repositories. It comes from Veeam&amp;rsquo;s 2024 Ransomware Trends Report, where it described attacks that &lt;em&gt;prioritised&lt;/em&gt; backup repositories — up from 93% in the 2023 edition of the same survey. It is worth being precise about its vintage, because a number repeated for two years as though it were fresh tends to get treated as folklore rather than evidence.&lt;/p&gt;</description></item><item><title>Ransomware Recovery Readiness Checklist for IT Managers</title><link>https://backup-manager.org/ransomware-resilience/ransomware-recovery-readiness-checklist/</link><pubDate>Mon, 20 Jul 2026 00:30:00 -0400</pubDate><guid>https://backup-manager.org/ransomware-resilience/ransomware-recovery-readiness-checklist/</guid><description>&lt;p&gt;Ransomware incidents are rarely decided by how fast the encryption wave is detected. They are decided by whether the recovery path still exists when detection finally happens. Attackers know this. Contemporary playbooks routinely include locating backup consoles, shortening retention, deleting snapshots, and disabling replication &lt;em&gt;before&lt;/em&gt; the ransom note appears. If your readiness plan starts at &amp;ldquo;restore from backup&amp;rdquo; without proving those backups are unreachable and restorable, you are rehearsing optimism, not recovery.&lt;/p&gt;</description></item><item><title>The 3-2-1 Backup Rule for Small Business in 2026</title><link>https://backup-manager.org/backup-strategy/3-2-1-backup-rule-small-business-2026/</link><pubDate>Mon, 20 Jul 2026 00:15:00 -0400</pubDate><guid>https://backup-manager.org/backup-strategy/3-2-1-backup-rule-small-business-2026/</guid><description>&lt;p&gt;Most small businesses do not fail at backups because they ignore the idea. They fail because the &amp;ldquo;backup&amp;rdquo; is a single external drive under the reception desk, a OneDrive sync of the shared folder, or a managed service nobody has restored from since the contract was signed. When ransomware, a stolen laptop, a flooded office, or a corrupted accounting database shows up, that arrangement collapses for the same reason every time: there was never a second failure domain.&lt;/p&gt;</description></item><item><title>S3 Immutable Backup: How Object Lock Stops Deletion</title><link>https://backup-manager.org/cloud-backup/s3-immutable-backup-object-lock/</link><pubDate>Fri, 30 Aug 2024 09:00:00 -0500</pubDate><guid>https://backup-manager.org/cloud-backup/s3-immutable-backup-object-lock/</guid><description>&lt;p&gt;A ransomware crew that has been sitting quietly on a network for three weeks doesn&amp;rsquo;t need to break your encryption to ruin your week. They just need your backup admin&amp;rsquo;s password. Once they have valid credentials, they can log into the backup console like anyone else, walk through the retention settings, and delete every recovery point they can find — often minutes before detonating the payload on production. This is now a standard part of the ransomware playbook, and it&amp;rsquo;s the reason &amp;ldquo;we have backups&amp;rdquo; stopped being a sufficient answer years ago.&lt;/p&gt;</description></item><item><title>Air-Gapped Backup Strategy: Why It Still Stops Ransomware</title><link>https://backup-manager.org/ransomware-resilience/air-gapped-backup-strategy/</link><pubDate>Wed, 25 Jan 2023 09:00:00 -0500</pubDate><guid>https://backup-manager.org/ransomware-resilience/air-gapped-backup-strategy/</guid><description>&lt;p&gt;The ransomware note usually arrives after the damage is done — but for a growing number of victims, the worse discovery isn&amp;rsquo;t the encrypted production data. It&amp;rsquo;s opening the backup console and finding the recovery points are gone too. Modern ransomware operators don&amp;rsquo;t just encrypt live systems; they actively hunt for backup repositories, delete snapshots, and disable retention policies before detonating the payload. When the backup is reachable from the same network as everything else, it is not a separate line of defense — it&amp;rsquo;s just another target with a slightly longer fuse.&lt;/p&gt;</description></item><item><title>Microsoft 365 Backup: Why Retention Isn't Enough</title><link>https://backup-manager.org/cloud-backup/microsoft-365-backup-guide/</link><pubDate>Fri, 17 Jun 2022 09:00:00 -0500</pubDate><guid>https://backup-manager.org/cloud-backup/microsoft-365-backup-guide/</guid><description>&lt;p&gt;A department head accidentally runs a bulk delete script against a SharePoint document library instead of a test site. Three weeks later, someone asks for a file that was deleted twenty-two days into that window. The organization&amp;rsquo;s retention policy covered it. A month after that, a different team loses a mailbox to a phishing-triggered mass delete, and by the time anyone notices, the recoverable items window has already closed. Both incidents are common, both are preventable, and both expose the same misunderstanding: that Microsoft 365 comes with backup built in.&lt;/p&gt;</description></item><item><title>Immutable Backups: The Ransomware Recovery Backstop</title><link>https://backup-manager.org/ransomware-resilience/immutable-backups-ransomware-recovery/</link><pubDate>Tue, 09 Mar 2021 09:00:00 -0500</pubDate><guid>https://backup-manager.org/ransomware-resilience/immutable-backups-ransomware-recovery/</guid><description>&lt;p&gt;The ransomware note rarely arrives first. What arrives first, quietly, is a login to the backup console using credentials the attacker has been sitting on for days or weeks. By the time files start encrypting on production servers, the backup repository has often already been altered, its retention policies shortened, its snapshots deleted, its replication jobs disabled. The encryption of live data is the visible part of the attack. The invisible part, and the one that determines whether an organization pays a ransom or simply restores from backup, happened earlier and targeted the recovery path itself.&lt;/p&gt;</description></item><item><title>RAID Is Not a Backup: Why Redundancy Isn't Recovery</title><link>https://backup-manager.org/storage-data-protection/raid-is-not-a-backup/</link><pubDate>Mon, 12 Oct 2020 09:00:00 -0500</pubDate><guid>https://backup-manager.org/storage-data-protection/raid-is-not-a-backup/</guid><description>&lt;p&gt;A drive fails in a RAID array on a Tuesday afternoon. Nobody panics — that&amp;rsquo;s what the redundancy was for. A hot spare rebuilds automatically, an alert fires, and by Wednesday morning the array is back to full health. This is RAID working exactly as designed.&lt;/p&gt;
&lt;p&gt;Now change the scenario. On that same Tuesday afternoon, a script running with the wrong permissions deletes a directory tree across a mounted volume. Or a ransomware payload finishes encrypting every file it can reach. Or the array&amp;rsquo;s controller firmware corrupts its own metadata during a routine rebuild. In every one of these cases, RAID doesn&amp;rsquo;t help at all — and worse, it actively participates in destroying the data, faithfully mirroring the deletion, the encryption, or the corruption across every disk in the set at the same speed it would replicate a legitimate write.&lt;/p&gt;</description></item><item><title>Writing a Reliable rsync Backup Script (With Examples)</title><link>https://backup-manager.org/linux-backup/rsync-backup-script-guide/</link><pubDate>Wed, 22 May 2019 09:00:00 -0500</pubDate><guid>https://backup-manager.org/linux-backup/rsync-backup-script-guide/</guid><description>&lt;p&gt;Most Linux administrators write their first backup script the same way: a single &lt;code&gt;rsync -av /source /destination&lt;/code&gt; line dropped into a cron job, run once, and forgotten. It works right up until a drive fills up, a network path drops mid-transfer, or someone needs a restore point from three Tuesdays ago and discovers every backup silently overwrote the last one. rsync is one of the most dependable data-movement tools in the Unix toolbox, but a backup script built on it only becomes dependable when someone accounts for the failure modes rsync itself doesn&amp;rsquo;t handle.&lt;/p&gt;</description></item><item><title>Linux Backup Command Line Tools: A Practitioner's Guide</title><link>https://backup-manager.org/linux-backup/linux-backup-command-line-tools/</link><pubDate>Thu, 06 Sep 2018 09:00:00 -0500</pubDate><guid>https://backup-manager.org/linux-backup/linux-backup-command-line-tools/</guid><description>&lt;p&gt;Ask ten Linux administrators how they back up their servers and you will get ten different answers — and most of them will involve a shell script, a cron entry, and a strong opinion about why their approach is the only sane one. That fragmentation isn&amp;rsquo;t a failure of the ecosystem; it&amp;rsquo;s a reflection of how differently Linux systems get used. A single-purpose web server, a multi-tenant file share, and a fleet of container hosts have almost nothing in common operationally, and the right backup command line tool for one is often the wrong choice for another.&lt;/p&gt;</description></item><item><title>Incremental vs Differential Backup: A Practical Guide</title><link>https://backup-manager.org/backup-strategy/incremental-vs-differential-backup/</link><pubDate>Wed, 14 Feb 2018 09:00:00 -0500</pubDate><guid>https://backup-manager.org/backup-strategy/incremental-vs-differential-backup/</guid><description>&lt;p&gt;Every backup schedule eventually runs into the same wall: a full backup of the entire dataset every night is safe, simple to restore, and completely unworkable once the dataset grows past a few hundred gigabytes. The backup window blows past its limit, the storage bill climbs, and the network link to the target starts to look like the bottleneck it is. The fix practitioners reach for is some combination of incremental and differential backup — but the two terms get used interchangeably often enough that teams design restore procedures around the wrong assumptions. That confusion is not academic. It shows up at 3 a.m. during an actual recovery, when someone discovers that &amp;ldquo;differential&amp;rdquo; restore they assumed would take one step actually requires walking a six-week chain of dependent files.&lt;/p&gt;</description></item><item><title>RPO vs RTO Explained: Setting Real Recovery Targets</title><link>https://backup-manager.org/disaster-recovery/rpo-vs-rto-explained/</link><pubDate>Wed, 19 Apr 2017 09:00:00 -0500</pubDate><guid>https://backup-manager.org/disaster-recovery/rpo-vs-rto-explained/</guid><description>&lt;p&gt;Every backup and disaster recovery conversation eventually hits the same wall: someone asks &amp;ldquo;how much data can we afford to lose, and how long can we afford to be down?&amp;rdquo; and the room goes quiet. Backup schedules get set by default — nightly full, hourly incremental, whatever the last engineer configured — without anyone tying that cadence back to what the business actually needs. Then a real outage happens, the restore takes fourteen hours instead of the two everyone assumed, and the conversation about Recovery Point Objective (RPO) and Recovery Time Objective (RTO) happens after the fact instead of before it.&lt;/p&gt;</description></item><item><title>The 3-2-1 Backup Rule Explained: Still Relevant in 2026?</title><link>https://backup-manager.org/backup-strategy/3-2-1-backup-rule-explained/</link><pubDate>Tue, 08 Nov 2016 09:00:00 -0500</pubDate><guid>https://backup-manager.org/backup-strategy/3-2-1-backup-rule-explained/</guid><description>&lt;p&gt;A production database gets encrypted at 2 a.m. on a Saturday. The on-call engineer pulls up the backup console and finds exactly one copy — sitting on the same SAN the ransomware just finished sweeping. The backup job succeeded every night for six months. It just never protected anything, because a single copy on shared infrastructure was never a backup strategy to begin with.&lt;/p&gt;
&lt;p&gt;This is the scenario the 3-2-1 backup rule was built to prevent, and it&amp;rsquo;s why the rule has outlived every specific technology it was originally written around. It predates cloud object storage, predates ransomware-as-a-service, and predates most of the tools practitioners use today. It is still the baseline every backup architecture gets measured against, because the failure modes it addresses — hardware failure, site loss, and correlated destruction — haven&amp;rsquo;t gone away. They&amp;rsquo;ve just gotten more automated on the attacker&amp;rsquo;s side.&lt;/p&gt;</description></item></channel></rss>