Backup security and retention answer two different but equally important questions: how do we protect recovery points from being changed or destroyed, and how long should those recovery points remain available?
A strong backup strategy does more than create copies. It considers offsite protection, encryption, immutability, retention, access control, monitoring, and recovery verification. The goal is not to keep every backup forever. The goal is to maintain useful recovery history while protecting the recovery points the organization may depend on after ransomware, accidental deletion, hardware failure, or another disruption.
Backup security and retention work together, but they solve different problems.
| Control | Question It Answers | Primary Risk Addressed |
|---|---|---|
| Encryption | Can an unauthorized person read the backup? | Unauthorized disclosure |
| Immutability | Can the protected recovery point be changed or deleted? | Ransomware, malicious deletion, or compromised administration |
| Offsite / Isolated Protection | Could one local event affect every copy? | Fire, theft, hardware loss, facility failure, or local compromise |
| Retention | How far back can we potentially recover? | Delayed discovery, accidental deletion, historical recovery needs |
| Verification | Can the recovery point actually be reconstructed or restored? | Undetected corruption or unusable recovery data |
No single one of these controls replaces the others.
Backups are valuable because they may be the organization’s last usable copy after a major incident. That also makes them valuable to an attacker.
Modern ransomware attacks may attempt to:
This is why modern backup protection should not depend only on having another writable copy connected to the same environment.
The traditional 3-2-1 backup rule provides a simple framework for reducing the chance that one incident destroys every copy of important data.
| Number | Meaning | Why It Matters |
|---|---|---|
| 3 | Three copies of important data, including production | One failure should not remove every copy. |
| 2 | Two different storage media or appropriately independent storage systems | Reduces dependency on one storage technology or failure domain. |
| 1 | One copy stored offsite | Protects against a local facility or infrastructure disaster. |
The traditional model remains useful. Modern cyber threats created a need for another protection layer.
The 3-2-1-1-0 backup rule expands the traditional strategy by adding protected storage and recovery verification.
| Rule | Meaning |
|---|---|
| 3 | Maintain three copies of important data, including production. |
| 2 | Use two different storage media or appropriately independent storage approaches. |
| 1 | Keep at least one copy offsite. |
| 1 | Keep at least one copy offline, air-gapped, immutable, or otherwise appropriately protected from modification. |
| 0 | Work toward zero unresolved recovery errors through backup and recovery verification. |
The framework helps answer a more complete question: Do we have enough independent copies, can an attacker destroy them, and have we verified that recovery works?
No. Adding immutable storage strengthens the additional “1” in the 3-2-1-1-0 model. It does not automatically prove that every other part of the model has been satisfied.
For example:
An immutable backup is protected against modification or deletion for a defined period. The purpose is to preserve a recovery point even if someone gains powerful administrative access.
Immutability can help protect against:
EasyITGuys managed backup standards use a 30-day immutable protection period where supported. This provides a protected near-term recovery window while other retention policies may preserve recovery history for longer periods.
This distinction is important. Immutability determines how long a recovery point cannot be changed or deleted. Retention determines how long the recovery point remains available before normal expiration.
Assume a backup is retained for six months. The first 30 days may be protected by an immutable period. After the immutable period expires, the recovery point can still remain within the six-month retention schedule until normal expiration.
| Time Period | Example Status |
|---|---|
| Days 1 through 30 | Retained and protected by immutability |
| Day 31 through retention expiration | Still retained according to policy, but the original immutable period may have expired |
| After retention expiration | Recovery point may expire according to the configured retention policy |
The actual behavior depends on the backup architecture and configuration.
No single security control should be described as completely ransomware-proof. Immutability is an important defense because it can make protected recovery points much harder to destroy.
Recovery can still depend on:
Immutability should be viewed as one important layer within a broader recovery strategy.
Encryption protects the confidentiality of backup data. EasyITGuys managed backup standards require backed-up data to be encrypted during transmission and while stored. Current Service Guide standards specify 256-bit AES encryption for backed-up data in transit and at rest.
Encryption helps protect information if:
Storage encryption and recovery authorization are also different concepts. A backup may be encrypted while still requiring controls over who is allowed to initiate recovery. For compliance-managed environments, an additional protected recovery credential is used to help prevent unauthorized recovery. The credential is maintained within protected IT documentation so authorized recovery can still occur when required. Non-compliance clients may request this additional recovery protection as well. It is not currently enabled by default for every non-compliance environment.
Backup retention determines how long historical recovery points remain available. Retention is useful because problems are not always discovered immediately. A user may notice a missing document several weeks later. An application problem may not become obvious until after several newer backups have already been created. Retention gives the organization the ability to look farther backward in time.
A backup can run every day and still keep months of historical recovery points. A system can also create multiple recovery opportunities each day while retaining only selected historical points as they age.
| Concept | Question |
|---|---|
| Frequency | How often is a recovery point created? |
| Retention | How far backward might we be able to recover? |
| Immutability | How long is a protected recovery point resistant to modification or deletion? |
Grandfather-Father-Son, commonly shortened to GFS, is a retention method that keeps more recovery detail for recent data while preserving fewer representative recovery points as the data becomes older.
The names traditionally mean:
| GFS Level | Typical Meaning |
|---|---|
| Son | Recent daily recovery points |
| Father | Weekly recovery points |
| Grandfather | Longer-term monthly recovery points |
The purpose is simple. You usually need more choices when recovering something from yesterday than when recovering something from six months ago.
A GFS plan might retain: 7 daily → 4 weekly → 6 monthly
This provides detailed recent recovery while still preserving selected historical recovery points. It does not mean every daily backup is retained for six months.
Different backup technologies use different retention structures. The following table summarizes current general EasyITGuys managed backup defaults. These are operating standards, not a substitute for reviewing the actual configuration of a specific organization.
| Protection Type | General Retention | How to Think About It |
|---|---|---|
| Traditional BDR File / Folder | 7 daily, 4 weekly, 6 monthly | Approximately six months of GFS file history |
| Traditional BDR Images | Approximately 31 individual daily image recovery points in the active image chain | Shorter rolling full-machine recovery history, separate from longer file-level history |
| Microsoft 365 Cloud Applications | 7 daily, 4 weekly, 6 monthly | Historical cloud application recovery using GFS retention |
| BCDR Local Recovery | Commonly 3 daily, 2 weekly, and monthly recovery points based on the selected local retention plan | Local history prioritizes faster recovery and recent recovery points. Standard configurations commonly target approximately 90 days locally. |
| BCDR Cloud Recovery | 3 daily, 2 weekly, 12 monthly | Approximately 12 months of longer-term cloud recovery history |
Some environments may use different schedules because of storage capacity, application requirements, compliance needs, recovery objectives, or an approved custom design.
Full-machine images and individual files solve different recovery problems. Image recovery is designed to reconstruct an entire machine. That can require substantially more storage than preserving selected file history. File and folder retention can therefore maintain a longer historical window while image recovery maintains more detailed recent system history.
This is another reason the question: “How long are our backups kept?” may not have one universal answer. The better question is: “How long is each type of recovery point kept?”
Local and cloud recovery layers have different strengths.
Local recovery can help reduce the amount of data that must travel across the internet during a major restoration. It can also support faster temporary recovery where local recovery infrastructure is available.
Cloud recovery protects against local events such as:
Cloud retention can also preserve historical recovery points beyond the normal local recovery window. A hybrid design therefore provides both local recovery capability and geographically separate protection.
No. Longer retention can provide more historical recovery options.
It can also increase:
Retention should match a reason. That reason might be operational recovery, compliance, legal requirements, insurance requirements, contractual obligations, or another documented business need.
No. This distinction is extremely important.
Those requirements may not be the same. For example, a regulation may require a business record to be maintained for several years. That does not automatically mean the organization must keep every daily backup containing that record for the same number of years. The business may preserve the required record through its normal application, archive, document-management system, or another approved record-retention method.
Normal backup expiration should not be assumed to satisfy a legal preservation requirement.
If the organization is subject to:
leadership should involve the appropriate legal, compliance, or records-management resource. IT can then help determine how the required information can be technically preserved.
Backup systems normally expire older recovery points according to the configured retention policy. This is expected behavior. It does not necessarily mean someone manually deleted the backup. Retention policies are designed to continuously maintain the intended historical window. As new recovery points are created, older points eventually age out.
Not until replacement protection and retention requirements are understood. A transition should avoid creating a backup gap.
Before retiring an old backup system, confirm:
Old backup copies should not be deleted simply because a new backup product has been installed.
The final “0” represents recovery confidence. A backup should not only exist. It should also be checked for problems.
Verification can include several layers:
| Verification Layer | What It Helps Confirm |
|---|---|
| Backup Job Completion | The scheduled backup process reported completion. |
| Checksum / Integrity Validation | Backup data passes structural integrity checks. |
| Recovery Point Reconstruction | The required backup chain can reconstruct the selected recovery point. |
| Image Boot / Heartbeat | The protected machine can start in an isolated recovery environment. |
| Screenshot Evidence | Provides visual confirmation that the recovery test reached an expected boot state. |
| Manual Restore Testing | Confirms files, folders, or machines can be recovered through a human-tested process. |
Checksum validation is a standard part of managed backup integrity verification. Supported traditional BDR environments are also being upgraded during Q3 and Q4 2026 to add automated image recovery validation, heartbeat checks, and screenshot evidence where supported. Before this automation became more broadly available, traditional BDR relied more heavily on scheduled manual recovery testing. Full business recovery exercises remain a separate process and are covered in the dedicated recovery-testing article.
Many image backup systems use an incremental backup chain. The newest recovery point may depend on data from previous portions of that chain.
A simplified example looks like this: Initial Backup → Incremental 1 → Incremental 2 → Incremental 3 → Latest Recovery Point
If the latest recovery point is successfully reconstructed, the backup system must also be able to access the earlier data required to create that recovery state. This provides more confidence than simply confirming that the newest incremental file was uploaded. It does not prove that every historical recovery point is perfect. It helps verify that the selected current recovery point can be reconstructed from the chain it depends on.
It can. Validation may require backup data to be read, reconstructed, mounted, or temporarily started as a virtual machine.
Depending on where validation occurs, this may use:
Local automated boot validation should therefore be scheduled with system capacity and normal business activity in mind. Off-hours scheduling can reduce unnecessary impact on production workloads.
Backup security is not solely an IT responsibility. IT can configure and monitor the backup architecture. Leadership must help identify what data matters, how long it should be retained, and what recovery requirements the business has.
| Participant | Typical Responsibility |
|---|---|
| Leadership | Defines business value, acceptable risk, and special retention requirements. |
| IT Department | Implements, monitors, protects, and tests covered backup infrastructure according to the selected service. |
| Application Owners | Identify application-specific data and recovery requirements. |
| Legal / Compliance | Identifies formal preservation, regulatory, contractual, or records-management requirements when applicable. |
You do not need to understand the backup platform’s technical settings.
Leadership should still be able to answer several basic questions:
Those questions create a much stronger conversation than simply asking whether backups are “green.”
Understanding backup security and retention helps separate several concepts that are often incorrectly treated as one backup setting.
A recovery point can be:
A stronger strategy considers these controls together. The goal is not simply to create more backups. The goal is to create recovery points that are protected, useful, appropriately retained, and reasonably recoverable.
Backup technologies and capabilities change over time. General operating standards may also be adjusted as technology, compliance needs, storage requirements, and recovery capabilities evolve. If exact retention or recovery capability is important to a business decision, review the organization’s current configuration rather than relying only on a general educational article. For current service coverage, review the EasyITGuys Service Guide and Master Services Agreement and Terms.
Backup security protects recovery data from unauthorized access, modification, or deletion. Retention determines how long historical recovery points remain available.
The traditional 3-2-1 strategy calls for three copies of important data, two different storage media or independent storage approaches, and one copy stored offsite.
It extends the traditional model by adding one offline, air-gapped, immutable, or otherwise appropriately protected copy and working toward zero unresolved recovery errors through verification.
No. Immutability strengthens the additional “1.” The organization still needs appropriate copies, independent storage, offsite protection, and recovery verification.
The current managed standard uses a 30-day immutable protection period where supported. Actual configuration remains the source of truth for a specific environment.
No. A recovery point may be protected against deletion for 30 days but retained for much longer. Immutability and retention are separate settings.
Managed backup standards require backed-up data to be encrypted during transmission and while stored. Current Service Guide standards specify 256-bit AES encryption in transit and at rest.
Compliance-managed environments use an additional protected recovery credential to help prevent unauthorized recovery. This adds an authorization layer beyond normal backup storage encryption.
Yes. Additional recovery protection can be requested. It is not currently enabled by default for every non-compliance environment.
Grandfather-Father-Son retention keeps more detailed recent recovery points and fewer representative weekly and monthly recovery points as history becomes older.
Keeping every recovery point indefinitely can consume significant storage and add cost and governance complexity. GFS preserves useful historical recovery without retaining every daily copy forever.
The current general BDR file and folder standard uses 7 daily, 4 weekly, and 6 monthly recovery points.
Traditional BDR image chains generally maintain approximately 31 individual daily image recovery points in the active image history. File and folder protection can maintain longer historical recovery separately.
The current general Microsoft 365 Cloud Application standard uses 7 daily, 4 weekly, and 6 monthly recovery points. Actual protection and retention should be confirmed for the specific organization.
Standard BCDR configurations commonly maintain recent local recovery history and longer cloud history. Cloud retention generally includes 3 daily, 2 weekly, and 12 monthly recovery points. Local monthly retention depends on the selected local retention plan and commonly targets approximately 90 days in the standard configuration.
No. Backup retention determines how long recovery points remain available. Legal or regulatory record retention determines how long specific business records must be preserved. The two should not automatically be treated as the same requirement.
Usually not. Retention should have a defined business, legal, contractual, compliance, insurance, or recovery purpose. Keeping unnecessary data indefinitely can create additional cost and governance obligations.
Immutability significantly strengthens ransomware recovery by protecting recovery points from modification or deletion during the protected period. It does not replace endpoint security, access control, monitoring, recovery verification, or a complete incident-response strategy.
No. A checksum helps verify backup data integrity. Boot validation goes further by reconstructing the protected machine and checking whether the operating system starts in a recovery environment.
It provides useful evidence because reconstructing the selected recovery point requires the earlier backup data that point depends on. It does not automatically prove every historical recovery point is usable.
No. Automated validation improves technical recovery confidence. A full recovery exercise also tests applications, people, vendors, communications, and business workflows.
No. Confirm replacement protection, historical retention needs, recovery credentials, and legal or business requirements before old backup systems or data are removed.
Technical issue or active outage? Contact the Support Desk.
Retention, compliance, recovery planning, backup security, vendor coordination, or another non-helpdesk discussion? Contact the IT Department or Mission Control / Operations. Booking a meeting is the best option for non-support matters so the appropriate team member can reserve time with you.
