Why Offline Backups on Removable Drives Still Matter: 3-2-1 and CISA

Offline backups on removable drives still matter because a copy that is unplugged and sitting in a drawer cannot be encrypted by ransomware, deleted by an attacker who took over your cloud account, or overwritten by a sync job that copied the damage. CISA's #StopRansomware Guide tells organizations to keep offline, encrypted backups and to test them regularly. A rotated, encrypted USB drive or external disk is the cheapest way for a small team or a household to meet that advice.

So should you go back to pen drives to be safe? Yes, for one job. A pen drive is not a backup strategy on its own; it is the offline leg of one. This guide covers what "offline" really means, where the 3-2-1 rule came from and what 3-2-1-1-0 adds, what CISA and the UK's National Cyber Security Centre (NCSC) actually say, which media suit which job, how to encrypt drives and keep the keys, how to rotate them, and how to prove a restore works.

Key takeaways

• Offline means disconnected. A drive left plugged in, an always-mounted share or an auto-syncing cloud folder is online, and the NCSC has seen ransomware reach all three.
• CISA's #StopRansomware Guide (joint with MS-ISAC, NSA and FBI) says to "Maintain offline, encrypted backups of critical data" and to test them in a disaster recovery scenario.
• The 3-2-1 rule (three copies, two media types, one offsite) appears in a 2012 US-CERT paper. It does not require an offline copy, which is why the NCSC adds a separate offline rule.
• 3-2-1-1-0 is industry convention, not a CISA rule: one more copy offline or immutable, and zero errors on verification and restore.
• Encrypt every removable backup and keep the recovery key somewhere other than the drive it unlocks.
• Rotate at least two drives so one is always disconnected, and keep one somewhere else.
• Back up the small, irreplaceable things first: recovery codes, a vault export, key backups and documents.
• A backup you have not restored is a hope. Check hashes and test restores on a schedule.

What does "offline" mean, and why does ransomware go after backups?

An offline backup, which the NCSC also calls a cold backup, is kept separate from your live systems so it can "remain unaffected should any incident impact your live environment," in the words of the NCSC's 2019 blog post on the subject. Separate means an attacker on your network, or holding your passwords, cannot reach it.

That rules out more than people expect:

• An external drive left plugged in. To the operating system it is just another volume, writable by anything running as you.
• A network share or NAS that is always mounted. Every machine that mounts it can damage it.
• A cloud folder that syncs automatically. CISA's guide warns that if local files are encrypted by an attacker, they sync to the cloud and can overwrite good data.
• A cloud backup account protected only by a password. Cloud storage cannot be unplugged, so the NCSC says it has to be digitally disconnected through identity controls, limited backup clients and access rules that block connections while the backup is cold.

The NCSC reports ransomware that encrypted not only data on disk but also connected USB drives, network storage and cloud backup storage. CISA's guide says most ransomware actors try to find and delete or encrypt accessible backups so that restoration is impossible unless the ransom is paid, that they hunt for stored credentials to reach backup systems, and that they exploit unpatched backup software. A victim with a clean backup does not need to pay, so destroying backups is an early step. A drive unplugged before the attack began is outside that reach. Our post on why ransomware attackers go after your backups covers the attacker side.

Offline copies also survive an account takeover that deletes your cloud data and its history, a bad bulk delete that syncs everywhere, a provider outage or account suspension, and a power surge. The 2012 US-CERT paper on backup options notes that physically separating backups from your computer protects them from both online attackers and power surges.

Where does the 3-2-1 rule come from?

The clearest government statement of the rule we found is "Data Backup Options," a 2012 paper by Paul Ruggiero and Matthew A. Heckathorn, published by US-CERT and still hosted on cisa.gov:

The paper footnotes the rule to the American Society of Media Photographers' backup overview, and its reading list includes Peter Krogh's The DAM Book: Digital Asset Management for Photographers (second edition, 2009). The rule is widely credited to Krogh and photography workflow practice. We confirmed that the US-CERT paper cites that guidance and lists his book; we could not confirm from a primary source who first coined it.

The NCSC endorses the rule as "at least 3 copies, on 2 devices, and 1 offsite," then makes the point that matters most here: 3-2-1 does not require any copy to be offline. An always-on NAS plus a synced cloud folder satisfies it on paper, and the same ransomware can encrypt both in the same hour.

What do the extra "1" and "0" add?

3-2-1-1-0 shows up in backup vendor material and industry guides. It is a convention, not something CISA, NIST or the NCSC publishes, and we could not find it in any of their documents; the CISA guide we fetched does not use the term. The usual reading:

• The extra 1: at least one copy is offline (air gapped) or immutable, meaning it cannot be changed or deleted for a set period.
• The 0: zero errors. You verified integrity and tested a restore, and both came back clean.

Both line up with what CISA and the NCSC do say, so it is a useful mnemonic. Just credit it to industry practice. For individuals and small teams, a removable drive rotation is the simplest way to get the extra 1. Immutable cloud storage can also provide it, though CISA cautions that immutable storage "does not meet compliance criteria for certain regulations" and that misconfiguration can be costly. Our post comparing immutable and offline backups for ransomware recovery covers that choice.

What does CISA's #StopRansomware Guide actually say about backups?

The guide is a joint publication of CISA, the Multi-State Information Sharing and Analysis Center (MS-ISAC), the NSA and the FBI. Its change record lists the original Ransomware Guide in September 2020. The current PDF is marked "Publication: October 2023," while CISA's web page links it as the "#StopRansomware Guide (September 2023)"; you will see both dates cited for the same guide.

Its backup advice, in plain terms:

1. Keep offline, encrypted backups of critical data, and regularly test their availability and integrity in a disaster recovery scenario (mapped to CISA Performance Goal 2.R).
2. Test backup procedures on a regular basis. No specific interval is given.
3. Maintain and update "golden images" of critical systems so you can rebuild quickly.
4. Keep infrastructure as code templates backed up offline, version controlled and audited.
5. Store source code or executables with the offline backups, with escrow and license agreements, because some images will not install on different hardware.
6. Retain backup hardware to rebuild systems.
7. Consider multi-cloud for cloud-to-cloud backups in case every account at one vendor is affected.
8. Use immutable storage with caution.
9. Keep a hard copy and an offline version of the incident response plan, plus offline copies of IT asset documentation.

For a small team choosing physical media, three points stand out. "Encrypted" is not optional, because a lost offline drive is otherwise a data breach. Software and rebuild material belong in the offline set, not just documents. And the response plan itself belongs offline, because your wiki may be unreachable on the worst day. Our offline, encrypted backups checklist turns this list into team steps.

The NCSC's 2019 post "Offline backups in an online world" reduces the same ideas to four rules: an offline rule (keep at least one backup disconnected at all times, protect backup accounts with multi-factor authentication, remove client credentials when storage is not in use), a recovery rule (check that your cloud provider can restore earlier versions and deleted files for a set period), the 3-2-1 rule, and a regular rule (back up frequently and test restores regularly). Rotating drives with dated folders gives you version history an attacker in your cloud account cannot reach.

Which removable media fit which job?

The 2012 US-CERT paper lays out the trade-offs, and most still hold.

All of the writable options can be encrypted with BitLocker To Go, encrypted APFS or LUKS; optical discs need files encrypted before burning. US-CERT gave capacities of 682 megabytes for a CD, up to 9.4 gigabytes for a DVD and up to 50 gigabytes for Blu-ray, which is why optical is now a niche. It keeps one property nothing else here has: a write-once disc cannot be changed by ransomware after it is burned.

Pen drive or external disk?

Decide by size. Under about 100 GB of truly critical material, two or three good USB flash drives in rotation are fine, and this is where pen drives earn their comeback. From hundreds of gigabytes to a few terabytes, use external SSDs or hard disks. For several terabytes of photos and video, use hard disks plus a write-once or offsite copy of the most precious sets.

Never use the backup stick to move files between computers. Every machine a backup drive meets is a chance for it to be written to, infected or lost.

How long do they last unpowered?

There is no honest single number. Flash stores data as electric charge that slowly leaks, and the rate depends on the type of flash, how worn the cells are and how warm the drive is kept. Consumer drive makers rarely publish an unpowered retention figure you can rely on. Hard disks do not leak charge the same way, but their mechanics age. Optical discs degrade with handling and storage; NIST's SP 500-252 (2003) is a guide for librarians and archivists on caring for them.

So: power up and verify every backup drive at least every few months (a rotation does this for you), replace flash backup media every few years or sooner if hash checks fail, never let one drive hold the only copy of anything, and store drives cool, dry and away from magnets.

How should you encrypt removable backups, and where do the keys live?

Encrypt them. NIST SP 800-111, its guide to storage encryption for end user devices, names removable media among the devices whose data can be accessed by unauthorized parties, and describes full disk, volume and file or folder encryption. For a backup drive, whole volume encryption is easiest to get right because nothing is ever written in clear.

Windows: BitLocker To Go. Microsoft's BitLocker FAQ describes it as BitLocker on removable data drives: USB flash drives, SD cards and external hard disks formatted with NTFS, FAT16, FAT32 or exFAT. Standard users can turn it on. A protected drive unlocks on another Windows computer with a password or smart card, and locks automatically when removed. BitLocker uses AES, 128-bit by default and 256-bit by policy. For removable drives the recovery key can be saved to a folder, a Microsoft account or printed, and by default cannot be stored on a removable drive. Microsoft states plainly that without the recovery information the drive is designed to be unrecoverable.

macOS: encrypted APFS. Apple's Disk Utility can erase an external drive and format it as APFS (Encrypted) or APFS (Case-sensitive, Encrypted). Apple says you must erase the device first, and you can change the password later from File, Change Password. If the drive must be read on Windows, Apple lists ExFAT for volumes over 32 GB, which has no built-in encryption, so encrypt sensitive files separately.

Linux: LUKS with cryptsetup. One detail from the cryptsetup-luksHeaderBackup manual page matters: a LUKS header backup, together with any passphrase valid when it was made, can decrypt the data even after that passphrase is changed or removed, and header backups defeat wiping a device by overwriting its header. Keep one, because a damaged header otherwise means a lost drive, but protect it like a key.

Hardware-encrypted drives with a keypad do not depend on the host to unlock. They cost more, and their security rests on the controller and firmware, so buy a model with a current FIPS 140-3 validation and look the certificate up yourself.

Where the keys live

1. Never store the key on the drive it unlocks, or in the same drawer.
2. Keep two copies of each recovery key: one in your password manager, one printed with your important papers.
3. Use a different password per backup drive, and not your laptop login.
4. Label drives neutrally (OFFLINE-A, OFFLINE-B) and keep the drive to key mapping with the keys.
5. Test the key on every rotation. A forgotten password is as fatal as a dead drive.

Our post on backup encryption keys and how not to lose them covers key escrow for teams.

How often should you rotate drives, and how many should you have?

The minimum that works is two drives, alternating, so one is always disconnected. Three is better, so one can live at a second location.

CISA and the NCSC say to back up frequently and test regularly without fixing an interval. Set yours by asking how much you would redo if ransomware hit an hour before the next run. If a week of work would hurt, combine a daily cloud backup with the weekly offline rotation.

Two rules prevent most failures: never connect all drives at once, or any offline drive to a machine you suspect is compromised; and do not overwrite the oldest copy until the newest has been verified, so a run that copies corrupted files cannot destroy your last good set.

What should you back up first?

Start with what is small, irreplaceable and needed to recover everything else:

1. Account recovery codes for email, password manager, code hosting, cloud provider and domain registrar. Print them too.
2. A password vault export or emergency kit, encrypted, using your password manager's documented method.
3. Backups of signing keys and other long-lived keys, where your process allows them to exist outside a hardware token, plus revocation details. Many key types should never be exported; follow the issuer's guidance.
4. Disk encryption recovery keys for every laptop and every other backup drive.
5. Legal, financial and identity documents.
6. Continuity material: the incident response plan, contacts, infrastructure as code templates, installers and license keys, which CISA wants kept offline.
7. For software teams: release archives and the SBOM for each shipped release.
8. Photos and personal media.
9. Project working directories, especially unpushed work and local configuration.

The first four items fit on the smallest USB stick you can buy. That is the strongest case for pen drives: an encrypted recovery stick, duplicated and kept in two places, removes a common cause of permanent lockout.

Step by step: build a rotating offline USB backup

Each platform follows the same four stages: identify the drive, encrypt it, copy and hash into a dated folder, then disconnect.

Warning: the encrypt and format steps erase everything on the target drive. Before each destructive command, run the device check shown and confirm the device name, size, model and connection type match the drive you intend to erase. Unplug every other external drive first.

Linux: LUKS2 and tar with a hash manifest

Step 1, identify the drive. Plug in only the backup drive:

lsblk -o NAME,SIZE,MODEL,SERIAL,TRAN,MOUNTPOINTS
# Confirm the target shows TRAN=usb, the expected SIZE and MODEL,
# and no MOUNTPOINTS you rely on. Below, /dev/sdX stands for that device.

Step 2, encrypt and format. Device check first: re-run lsblk and confirm /dev/sdX is still the USB drive.

# DESTROYS ALL DATA on /dev/sdX
sudo cryptsetup luksFormat --type luks2 /dev/sdX
sudo cryptsetup open /dev/sdX offline_a
sudo mkfs.ext4 -L OFFLINE-A /dev/mapper/offline_a
sudo mkdir -p /mnt/offline_a
sudo mount /dev/mapper/offline_a /mnt/offline_a

# Keep a header backup somewhere safe, NOT on this drive
sudo cryptsetup luksHeaderBackup /dev/sdX \
  --header-backup-file ~/offline-a-luks-header.img

Move the header backup into your encrypted key storage, then delete the local copy.

Step 3, copy into a dated folder and write a hash manifest:

STAMP=$(date +%Y-%m-%d)
sudo mkdir /mnt/offline_a/$STAMP
sudo tar -C "$HOME" -czf /mnt/offline_a/$STAMP/documents.tar.gz Documents
sudo tar -C "$HOME" -czf /mnt/offline_a/$STAMP/recovery.tar.gz recovery-kit
cd /mnt/offline_a/$STAMP && sha256sum *.tar.gz | sudo tee SHA256SUMS
sync

Step 4, disconnect:

cd ~
sudo umount /mnt/offline_a
sudo cryptsetup close offline_a
# Now unplug the drive and put it away

macOS: encrypted APFS and rsync

Step 1, identify the drive:

diskutil list external
# Note the identifier (for example disk4), size and name of the backup drive

Step 2, encrypt. Device check first: confirm in Disk Utility that the selected device matches the size and name from diskutil list external. Then follow Apple's steps: View, Show All Devices; select the external device; Erase; Scheme GUID Partition Map; format APFS (Encrypted); enter and verify a password; Erase. This erases everything on the selected device.

Step 3, copy and hash:

STAMP=$(date +%Y-%m-%d)
mkdir -p "/Volumes/OFFLINE-A/$STAMP"
rsync -a ~/Documents "/Volumes/OFFLINE-A/$STAMP/"
rsync -a ~/recovery-kit "/Volumes/OFFLINE-A/$STAMP/"
cd "/Volumes/OFFLINE-A/$STAMP" && \
  find . -type f ! -name SHA256SUMS -print0 | xargs -0 shasum -a 256 > SHA256SUMS

Step 4, eject:

cd ~
diskutil eject /Volumes/OFFLINE-A

If you use Time Machine, Apple's setup allows for one or more backup disks, so you can rotate two Time Machine drives too. The rotation discipline is what makes them offline.

Windows: BitLocker To Go and robocopy

Step 1, identify the drive in PowerShell:

Get-Disk | Where-Object BusType -eq 'USB' |
  Format-Table Number, FriendlyName, Size, PartitionStyle
Get-Volume | Format-Table DriveLetter, FileSystemLabel, Size, DriveType

Step 2, encrypt. If you reformat first, device check first: confirm the disk number, name and size from Get-Disk match your backup drive, because formatting erases it. Then turn on BitLocker from File Explorer or BitLocker Drive Encryption in Control Panel, with a password. Save the recovery key to your Microsoft account or print it. Check status:

manage-bde -status E:

Step 3, copy into a dated folder with a log, as Microsoft's robocopy reference recommends, and record hashes:

$stamp = Get-Date -Format 'yyyy-MM-dd'
robocopy "$env:USERPROFILE\Documents" "E:\$stamp\Documents" /E /COPY:DAT /R:2 /W:5 /LOG:"E:\$stamp\robocopy.log"
Get-ChildItem -Recurse -File "E:\$stamp\Documents" |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv "E:\$stamp\SHA256SUMS.csv" -NoTypeInformation

Robocopy exit codes of 8 or higher mean at least one file failed. Avoid /MIR on backup drives: Microsoft documents it as /E plus /PURGE, which deletes destination files no longer in the source, so a file deleted or encrypted at the source takes your good copy with it.

Step 4, lock and remove:

manage-bde -lock E:
# Then use Safely Remove Hardware and unplug the drive

How do you test a restore from a USB backup?

Check integrity on every rotation and do a full test restore at least quarterly.

Part 1, integrity. Mount read-only where you can and check the manifest:

# Linux
sudo cryptsetup open /dev/sdX offline_a
sudo mount -o ro /dev/mapper/offline_a /mnt/offline_a
cd /mnt/offline_a/2026-10-23 && sha256sum -c SHA256SUMS

# macOS
cd "/Volumes/OFFLINE-A/2026-10-23" && shasum -a 256 -c SHA256SUMS

# Windows: compare stored hashes with fresh ones
$saved = Import-Csv "E:\2026-10-23\SHA256SUMS.csv"
$bad = $saved | Where-Object { (Get-FileHash $_.Path -Algorithm SHA256).Hash -ne $_.Hash }
if ($bad) { $bad | Format-Table Path } else { 'All hashes match' }

A single mismatch makes that drive suspect. Keep it, but do not overwrite other drives until you know why.

Part 2, usability. Restore into a scratch location:

mkdir -p /tmp/restore-test
tar -xzf /mnt/offline_a/2026-10-23/documents.tar.gz -C /tmp/restore-test
diff -rq /tmp/restore-test/Documents "$HOME/Documents" | head -20

Then open a few documents and photos, unlock the vault export, confirm the recovery codes belong to the right accounts, and unlock the drive on a different computer using only what you would have after a disaster: the printed key and your memory. Time the restore; that number is part of your recovery plan. If the only copy of the drive's password lives in a vault that is itself on the drive, you have locked the key inside the box. Our post on backups, offline plans and tabletop exercises for the worst day turns this into a team exercise.

What are the failure modes?

• Silent corruption. A file is damaged and every new backup copies the damage. Hash manifests and dated folders let you see when it changed and go back.
• Rolling backups spreading the problem. US-CERT warned in 2012 that rolling backups may spread corruption and malware from primary files to backups. Keep several dated sets and never connect every drive at once.
• The drive left plugged in. It is now online. Make unplugging the last step, with a calendar reminder.
• The lost or stolen drive. US-CERT names loss and theft as the main downside of removable media. Encryption turns a breach into an inconvenience.
• The forgotten key. No key, no data. Test it every rotation.
• Aging media. Regular reads and planned replacement catch it.
• Format drift. Know how you would read the drive on the replacement computer you buy after a disaster.
• Backing up the wrong things. Review the include list every few months.
• Restoring onto the infected machine. After a compromise, restore onto a clean, rebuilt machine.

How does this fit with cloud backups and versioning?

Removable media and cloud backup fail in different ways, which is exactly what the "2" in 3-2-1 is about.

The combination to aim for: version control for code; a cloud backup with version history behind strong multi-factor authentication, ideally on an account separate from daily email, with retention checked as the NCSC's recovery rule asks; two or three rotated, encrypted drives with one offsite; and a duplicated recovery stick. That is 3-2-1-1-0 with ordinary hardware.

Teams running their own storage arrays or backup servers should read NIST SP 800-209 (2020), whose storage security guidelines cover data protection, isolation, restoration assurance and encryption in far more depth than a household needs.

Common mistakes

• Calling a sync folder a backup. Sync copies damage as faithfully as work.
• Leaving the backup drive connected. That makes it online storage.
• Using one drive. During every run your only offline copy is attached to a machine that might be infected.
• Not encrypting, or storing the recovery key on the drive or nowhere at all.
• Mirroring instead of versioning. Robocopy /MIR and rsync --delete make a source mistake permanent.
• Never testing a restore. That is what the "0" is for.
• Crediting 3-2-1-1-0 to CISA. Quote what CISA says: offline, encrypted, tested.
• Forgetting the offsite copy. Two drives in one drawer burn in one fire.

Where Safeguard fits, honestly

Safeguard does not back up files, encrypt drives, manage devices or scan removable media for malware, and nothing in the rotation above depends on it. The connection is narrower and applies to teams that build software.

CISA wants source code, executables, templates and golden images in the offline set, and for a software team the SBOM for each shipped release belongs there too. When you restore a project months later, its lockfiles may pin versions that now have known vulnerabilities. Safeguard scans repositories, container images and SBOM files for known vulnerable components (safeguard scan --dir ., --image <name>, --sbom <file>), writes results as JSON under ./output, and the platform shows which projects contain a given component and version. The local runner runs scans on your own machine and uploads only results, and the CLI can import a vulnerability database downloaded elsewhere; offline mode is plan dependent, so confirm it for your plan. See how the local runner and offline mode work and air-gapped vulnerability management.

Fix it without waiting for upstream

A restore from an offline drive brings old lockfiles and release archives back to life, and a dependency that was safe when you backed it up may have a published vulnerability by the time you restore. That gap is small for a photo archive and real for a software team rebuilding from an offline copy, so the habits that keep live projects current apply to restored ones.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

Are USB flash drives safe for backups?

Yes, for small, critical data sets, if you encrypt them, rotate at least two, keep one offsite and verify them regularly. They are a poor choice as the only copy of anything or for multi-terabyte archives.

What is the 3-2-1 backup rule?

Three copies of important data (the original plus two backups), on two types of storage, with one offsite. A 2012 US-CERT paper states it in those terms. It does not require an offline copy, so add one.

What does 3-2-1-1-0 mean, and is it a CISA rule?

It adds one offline or immutable copy and zero errors after verification and restore testing. It is industry convention, not a CISA rule, though it overlaps with CISA's advice to keep offline, encrypted, tested backups.

What does CISA recommend for ransomware backups?

Offline, encrypted backups of critical data, with their availability and integrity tested regularly in a disaster recovery scenario. It also recommends golden images, offline copies of templates and software, retained backup hardware, and caution with immutable storage.

How often should I back up to an external drive?

Often enough that losing the work since the last run would be tolerable. For most households and small teams that means weekly to rotating drives, with cloud backup in between, and a monthly offsite swap.

Should I keep my backup drive plugged in?

No. A connected drive is online storage, and the NCSC has seen ransomware encrypt connected USB backups. Plug it in for the run and the hash check, then unplug it.

How long does data last on an unplugged USB drive or SSD?

There is no reliable single figure. Flash charge leaks faster with heat and wear, and consumer makers rarely publish retention numbers. Verify drives every few months and replace flash backup media every few years.

Do I need to encrypt my backup drive?

Yes. CISA pairs offline with encrypted, and a lost unencrypted drive is a data breach. BitLocker To Go, APFS (Encrypted) and LUKS all work on ordinary drives.

Where should I store the recovery key for an encrypted backup drive?

Never on the drive it unlocks. Keep it in your password manager and on paper, and test it every rotation. Microsoft says a BitLocker drive is designed to be unrecoverable without its recovery information.

Is cloud backup enough on its own?

Not against ransomware and account takeover. CISA warns synced copies can be overwritten by encrypted local files, and an attacker in the account can delete data and history. Pair it with a rotated offline copy.

See how Safeguard would help

These demos do not touch a USB drive. They show the software side of restoring a project from an offline copy. To try them, download Safeguard and follow the CLI docs.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. After you restore a project and its lockfiles from an offline drive, this is how you get its dependency inventory and vulnerability results on hardware you control before the code is built again.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to "fix the lodash CVE in this repo"; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. A project restored from a months-old backup often needs exactly this kind of approved, step by step upgrade before it ships again.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CISA: #StopRansomware Guide (web page)
• CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide (PDF)
• US-CERT: Data Backup Options, Ruggiero and Heckathorn, 2012 (PDF)
• CISA: Cross-Sector Cybersecurity Performance Goals
• NCSC: Offline backups in an online world
• NIST SP 800-209: Security Guidelines for Storage Infrastructure
• NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices
• NIST SP 500-252: Care and Handling of CDs and DVDs
• Microsoft Learn: BitLocker FAQ
• Microsoft Learn: robocopy
• Apple Support: Erase and reformat a storage device in Disk Utility
• Apple Support: Encrypt and protect a storage device with a password in Disk Utility
• Apple Support: File system formats available in Disk Utility
• Apple Support: Back up your Mac with Time Machine
• man7.org: cryptsetup-luksHeaderBackup(8)
• Safeguard: How the local runner and offline mode work

Last reviewed: 23 October 2026.