Key takeaways

  • The 3-2-1 rule: three copies of important data, on two kinds of media, with one copy offsite. It protects against hardware failure, theft and local disasters.
  • Ransomware adds a requirement: at least one copy that an attacker with your administrator password cannot change or delete. That means offline or immutable storage.
  • A backup is only proven when you have restored from it. Test file restores monthly and a full system restore at least once a year, and time them.
  • Set two numbers per system: how much data you can lose (recovery point) and how long you can be down (recovery time). Buy backup features to meet them.
  • For coastal and hurricane-exposed firms, Florida above all, treat hurricane season (June 1 to November 30) as a scheduled test of your offsite copy, your remote access and your communication plan.

A backup is a promise you have not tested

Every business owner can say "we have backups." Ask three follow-up questions. When did you last restore a file from them? How long would it take to bring back your accounting system and your email if the server room were gone? Could someone who stole your IT administrator's password delete them? Many firms cannot answer at least one of the three with confidence.

This article explains what a backup design needs in order to survive the events that actually happen to small and mid-size businesses: a failed disk, a deleted folder, ransomware, a stolen laptop, a fire or a flood, and a hurricane. It draws on guidance from the US-CERT paper on data backup options, the joint #StopRansomware Guide, FEMA's Ready.gov and Amazon Web Services' documentation for object locking.

The 3-2-1 rule, and what it protects against

The 3-2-1 rule appears in the US-CERT paper "Data Backup Options." It says to keep three copies of any important file: one primary and two backups. Keep the files on two different media types, to protect against different hazards. Store one copy offsite, outside your home or business facility.

  • Three copies, because one copy can fail, be deleted or be corrupted, and a second copy can fail at the same moment as the first.
  • Two kinds of media, because the same flaw can hit identical devices. Examples are a disk array plus cloud storage, or disk plus tape or removable drives.
  • One copy offsite, because a fire, flood, theft or storm affects everything in the building, including the backup drive sitting next to the server.

The same paper lists weaknesses to design around. A rolling backup, which updates itself automatically, can silently copy corruption or malware from the primary files into the backup. Backups kept on the same drive as the primary data are lost with it. Removable media can be lost or stolen, so encrypt them. Cloud storage gives anytime access and helps in a disaster, but the customer depends on the internet and on the provider's practices, and should read the service agreement. None of these is a reason to avoid an option. Each is a reason to add a second layer.

Ransomware changed the rule: the extra 1 and the 0

Ransomware operators know where backups live. The #StopRansomware Guide from CISA, the FBI, the NSA and MS-ISAC tells organizations to keep encrypted backups offline and to test restores regularly. It also recommends golden images for fast rebuilds, offline copies of source code, templates and software licenses, and spare hardware that can host restored systems.

Many IT providers describe the result as "3-2-1-1-0." This label comes from the backup industry rather than from a government standard, but the idea is sound. The extra 1 stands for one copy that is offline, air-gapped or immutable, so that it cannot be altered even with stolen credentials. The 0 stands for zero errors: the copies are verified, and restore tests show that they work. If you remember one sentence, remember this: one copy must be out of reach of your own administrator account.

What immutable actually means

An immutable backup uses a write-once-read-many (WORM) model. Once written, it cannot be changed or deleted until a set date. Cloud object storage offers this. Amazon S3 Object Lock is a well-documented example, and other storage providers and backup products offer similar features under other names.

The S3 documentation describes how it works. A retention period protects an object version for a fixed or variable time. In compliance mode, no user, including the account's root user, can overwrite or delete the object during the period, and the period cannot be shortened. In governance mode, most users cannot delete, but users with a special permission can change the settings or delete. A legal hold keeps protection until someone removes it, which fits an audit or a legal matter. Object Lock only works in buckets with versioning enabled.

Two practical notes follow. First, compliance mode is stronger against a thief and also stronger against your own mistakes: a wrong retention date cannot be undone, so test with governance mode and a short period first. Second, immutability protects the stored copy only. It does not tell you whether the data inside was already corrupted when it was written. That is why restore tests and malware scanning of backups still matter.

Other clouds offer the same idea under different names. Google Cloud Storage has Bucket Lock, which locks a bucket's retention policy so it cannot be removed or shortened, plus Object Retention Lock for individual objects and object holds. Microsoft Azure Blob Storage has immutable storage, with time-based retention policies and legal holds, set per container or per blob version, and a retention policy must be locked to count as compliant. Oracle Cloud Infrastructure (OCI) Object Storage has retention rules that can be time-bound or indefinite, and once a rule is locked not even a tenancy administrator or Oracle Support can delete it. The details differ, so read each provider's page before you design around it.

Whole-backup services add a second layer. AWS Backup centralizes protection across AWS services and can keep backups in logically air-gapped vaults. Google Cloud's Backup and DR Service stores backups in backup vaults that its documentation describes as immutable and indelible. Azure Backup offers an immutable backup option that locks recovery points, alongside soft delete and isolated vault storage. OCI offers Block Volume and Boot Volume backups with backup policies. Whichever you choose, keep the encryption keys in a managed key service such as AWS Key Management Service (AWS KMS), Google Cloud KMS, Azure Key Vault or Oracle Cloud Infrastructure Vault (OCI Vault), and keep them apart from the data they protect.

Other ways to get a copy that an attacker cannot reach include tape or removable disks kept offline and rotated, a backup service with separate credentials that your directory administrators do not hold, and a vault that requires a second person's approval to delete. The common thread is that the credentials which can erase the backup are not the same credentials used to run the network. Turn on multi-factor authentication for the backup console, and use phishing-resistant methods where you can.

Set recovery targets before you choose tools

Ready.gov's IT disaster recovery guidance builds on a business impact analysis. Two numbers come out of it. The recovery point objective is how much data loss is acceptable: if you can lose one hour of work, you need a backup at least hourly. The recovery time objective is how long a system can be down before the business is hurt. Match each IT resource's recovery time to the recovery time objective of the business function that depends on it.

Write a short table with one row per system: email, file shares, accounting, the line-of-business application, phones, the website, and the identity system that logs everyone in. Give each a recovery point, a recovery time and an owner. Most firms find that two or three systems drive the budget and the rest can wait. This table also tells you the order of restoration, which the #StopRansomware Guide asks for: restore in order of critical-service priority.

Do not forget what is not on your servers. Software-as-a-service data, such as hosted email, shared drives and customer-management tools, is stored by the provider, but their backups may not cover a deletion by your own staff or a compromised account. Read the provider terms, and consider a separate backup for the data you cannot afford to lose. Also back up the configuration of firewalls, switches, the directory service and cloud accounts, and keep the installation keys and licenses. Rebuilding a network from memory is slow.

Restore testing: the part most firms skip

Ready.gov says to test the plan periodically to make sure it works, and to periodically verify that data has been backed up accurately. The #StopRansomware Guide says the same in its own words. Here is a schedule that small teams can keep.

  • Weekly: read the backup report. A failed or skipped job is an incident, not a note.
  • Monthly: restore a few random files and one mailbox item to a different location, and open them. Check the date of the newest recoverable version.
  • Quarterly: restore a full server or virtual machine into an isolated network, and boot it. Confirm the application starts and the data is current.
  • Yearly: run a recovery exercise for your most important system from the offsite or immutable copy, with a stopwatch. Compare the result with your recovery time objective, and write down what slowed you down.
  • After every major change: new server, new application, new cloud account. Check that it is in the backup scope.

Typical findings from the first real exercise are modest and fixable. A key or password needed to decrypt the backup was stored only on the encrypted server. The restore took longer than the business can tolerate, because the offsite copy is limited by internet speed. The application restored, but needed a license server or a database version that was not captured. Nobody knew who had permission to start the restore. Each of these is cheap to fix on a calm Tuesday and expensive on the worst day.

Keep the recovery instructions outside the systems they recover. Print the runbook, store it offsite, and keep the encryption keys in a place that does not depend on the servers being up. Treat the keys as seriously as the backups, because lost keys mean lost backups.

Hurricane season for coastal firms

The Atlantic hurricane season runs from June 1 to November 30, according to Ready.gov. A hurricane puts three separate pressures on a business at once. The building may flood or lose power for days. Staff may evacuate or be unable to reach the office. And the internet, phone service and the cloud providers' local links may be down in your area even when the provider is fine. The backup plan has to work with all three.

Ready.gov advises businesses to have a continuity plan, to prepare for evacuation, and to expect phone systems to be down or overloaded after a disaster, so text messages are often more reliable. Add the IT items below.

  • Offsite means outside the storm's path. A copy in the same county, or in a cloud region on the same coast, may be affected by the same event. Choose a location in a different region, or a provider with several regions.
  • Make sure the last backup completes before a storm. Set a rule: when a storm is forecast, run and verify a full backup, confirm the offsite copy is current, and record the time.
  • Know your remote-work path before the storm. Staff should be able to reach email, files and the phone system from home or from another city. Test VPN or cloud access, MFA devices and phone forwarding.
  • Protect the equipment. Move servers and network gear off the floor and away from windows, use surge protection and an uninterruptible power supply with a clean shutdown signal, and consider a generator and fuel plan if the office must stay up. Ready.gov warns not to touch electrical equipment that is wet and, if it is safe, to turn off power at the main breaker.
  • Keep a paper contact list: staff mobile numbers, the IT provider, the internet carrier, the landlord, the insurer, key clients. Phones and email may not be available.
  • Plan the return. After the storm, power returns in surges. Do not power servers back on until the electrical supply is stable and the room is dry. Check backup status first, then restore services in the priority order you wrote down.
  • Review insurance. Confirm what your policy says about flood, wind, business interruption and data restoration, and whether it covers cloud and cyber losses separately.

Hurricane preparation and cyber-incident preparation use the same muscles: an offsite copy, a tested restore, a printed plan, a priority list and out-of-band communication. Firms that practice for one handle the other better.

A short backup design checklist

  • At least three copies of important data, on two kinds of media, one offsite and in a different region.
  • One copy offline or immutable, protected by credentials separate from your normal admin accounts, with MFA.
  • Backups encrypted in transit and at rest, with keys stored outside the systems they protect.
  • Recovery point and recovery time written for each system, and the restore order agreed.
  • SaaS data, configurations and licenses included.
  • Restore tests on a calendar, with results recorded and problems fixed.
  • A printed runbook and contact list, and a storm checklist for hurricane season.

How Clayton Cybernetics can help

Our Managed IT team designs, runs and tests backup and recovery for offices and multi-site firms: backup architecture, immutable and offsite copies, restore exercises with timing, and storm readiness for hurricane-exposed offices in any state. Backups and redundancy are part of every deployment we manage. If you are not sure when your last restore test was, that is a good place to start.

Sources

This article is general information, not legal or insurance advice. Recovery needs, retention periods and legal-hold duties depend on your business, contracts and regulators. Confirm them with your counsel and insurer. Last reviewed .

Keep reading

Need help with this?

Your entire IT operation, run by engineers who have operated infrastructure for global enterprises.

Managed IT Services