Build a 3-2-1-1 Backup: The Offline Copy Changes the Plan

For a 3-2-1-1 backup, keep three copies of critical data on two media types, place one offsite and keep at least one offline, as New Zealand’s NCSC guidance recommends. Start by naming the data that must be recovered, assigning each copy a storage target and deciding who can retrieve the disconnected copy and its decryption key.

Distance alone does not protect a backup that the live environment can still change. The UK NCSC’s offline-backup guidance describes ransomware affecting connected USB, network and cloud backup storage; it notes that the standard 3-2-1 rule does not require an offline copy. Plan transfers so a recoverable copy remains disconnected even while another backup is being updated.

Set recovery targets before choosing storage

List the systems, databases and data sets needed to resume essential work. Include application configuration and the credentials, keys, software or hardware needed to restore them. Assign a business owner to each data set; that person should decide how much recent work the organisation can afford to lose and how long the service can be unavailable.

Record those limits as a recovery point objective (RPO) and a recovery time objective (RTO). The RPO determines how recent a usable copy must be, while the RTO determines how quickly the service must be restored. Use both when choosing backup frequency, retention, media and location: an offsite copy may take longer to retrieve, and an offline copy may be older than a frequently updated local backup.

Fill in a copy map for each critical data set

Count the production data as one copy, then identify the backup targets by name. A label such as “cloud” does not tell a recovery team which account holds the copy, who can alter it or how it will be retrieved. Fill in this worksheet for each data set rather than assuming that one backup job covers every application and dependency:

• Data and recovery target: data set ____; business owner ____; source system ____; RPO ____; RTO ____.
• Production copy: media or platform ____; location ____; accounts with write access ____.
• Local backup: named target ____; media type ____; location ____; accounts with write access ____; schedule ____.
• Offsite offline backup: named target ____; media type ____; storage location ____; method of disconnection ____; last completed copy ____.
• Recovery access: decryption key location ____; authorised retrievers ____; software or hardware needed to read the copy ____.

Check the completed map for distinct media types and a copy stored away from a local incident. One copy can satisfy both the offsite and offline requirements if it is disconnected while stored. If updating it requires a temporary connection, rotate media or use another isolated copy so that the only protected backup is never exposed during a transfer.

Make the offline copy usable and protected

For removable media, specify who connects it, when the transfer runs, how completion is checked and where the device goes afterward. Unplug it when the transfer is complete and store it securely away from the live environment. For a cloud destination intended to be offline, control the authorised clients and credentials, and deny connections outside the backup window where the service allows it.

Encrypt backups at rest and keep a protected recovery route to the decryption key that does not depend on a compromised production system. Record who can obtain the key during an incident, then include decryption in a restore drill. Encryption protects the contents from unauthorised reading; it cannot make a connected copy safe from someone who has permission to overwrite or delete it.

Alert when a copy is missing or exposed

Schedule each backup to meet its data set’s RPO. Send failed-job and missed-run alerts to a named operator and a backup contact; also watch for unexpected configuration changes or access to backup infrastructure. The owner should establish whether a usable recent copy exists, fix the failure and record any period in which the RPO was missed.

Track the age of the offsite offline copy separately from routine job status. A successful local job does not show that removable media was updated and stored, or that a cloud destination was disconnected after its backup window. Add new systems and changed data locations to the copy map before treating them as covered.

Put restoration drills on the calendar

Use a recurring schedule that exercises different recovery paths. An illustrative starting calendar is a monthly single-file restore, a quarterly application and database restore, and an annual full-system restore; shorten the intervals where the business impact or rate of change warrants it. Include the offline copy in the drills so its retrieval time and key access are measured, rather than assumed.

1. Restore a selected file version from a named target and have its owner confirm that it opens and contains usable data.
2. Restore an application with its dependent database and configuration in an isolated environment, then run a representative workflow.
3. Retrieve the offline copy, obtain its key, rebuild the required system and time the process against the RTO.

Log the backup version used, its age, the time to restore it and any missing dependencies. Compare the version’s age with the RPO and the elapsed time with the RTO. If a drill misses either target, change the schedule, storage placement or recovery procedure and repeat that drill. A completed backup job shows that a copy was made; the restore establishes whether the team can use it.

Also read:

• ChatGPT vs Perplexity for Research: Source Credibility Changes the Winner