Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

How far back should backups go? Retention depth and attacker dwell time

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Many backup schedules keep two weeks or a month of copies because that was the default when the system was set up. That works for a deleted file or a failed disk. It may not work after a cyber attack, because attackers are often inside a network for some time before anyone notices.

This guide is for IT managers, business owners and anyone setting backup retention. It explains what "dwell time" means, what published figures say about it, how retention depth relates to it, and how to assess whether older backups are restorable and what evidence supports their use after an incident.

Why it matters

If every backup you hold was taken after an attacker arrived, each restore point may contain their tools, accounts or changes (our reading). Restoring the newest backup may bring the problem straight back; restoring an older one is only possible if it still exists. Retention depth can preserve more candidate points; it cannot establish that any point predates the compromise or is free of attacker changes.

What dwell time means

Dwell time is the time between an attacker getting in and the intrusion being found (our understanding of the common usage). Mandiant's M-Trends 2025 summary, based on investigations of "targeted attack activity conducted between Jan. 1, 2024 and Dec. 31, 2024", reports:

  • "Global median dwell time rose to 11 days from 10 days in 2023."
  • "Global median dwell time was 26 days when external entities notified, 5 days when adversaries notified (notably in ransomware cases), and 10 days when organizations discovered malicious activity internally."

Two points follow, in our reading. First, the ransomware figure is short because the attacker announces themselves; the intrusion may have started well before the encryption. Second, a median means half of cases took longer. Some intrusions run for months, and the published median says nothing about how long the longest ones last.

Attackers who blend in

The Australian Signals Directorate (ASD) describes why some intrusions go unseen. In its Cyber Threat Report 2023–2024, it says state-sponsored actors "use built-in network administration tools to carry out their objectives and evade detection by blending in with normal system and network activities, enabling them to decide when to steal information or cause harm to an organisation's network at a time of their own choosing. This is known as living off the land (LOTL)."

It also notes a credential-based pattern: "As access is gained using legitimate credentials, traditional security measures – such as anti-virus software and network intrusion detection systems – often fail to detect the activity."

Mandiant describes advanced groups taking "extra steps to evade detection, stifle analysis, and ultimately stay on systems for longer periods of time." It also notes that "stolen credentials rose to the second most common in 2024 (16%)" as an initial infection vector.

In our reading, an attacker using a valid account and built-in tools leaves little that a backup scan would flag. The backups faithfully capture a system that looks normal.

What attackers do to backups

ASD's Essential Eight maturity model is direct about the risk: "Depending on their intent, malicious actors may also destroy all data (including backups) accessible to a user account with special privileges."

ASD's report also shows how common extortion is. It says the number of extortion-related incidents it responded to "increased by 9% compared to the last financial year. Around 71% of these incidents involved ransomware." For malware incidents, it advises: "Maintain backups of critical data applications and settings. Regularly test that you can restore from backups in a timely manner".

So retention depth has two jobs (our reading): to reach back before the intrusion, and to survive an attacker who tries to shorten or delete it.

What the standards say about retention

The Essential Eight does not set a number of days. It says: "Backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements." It adds that "Backups of data, applications and settings are retained in a secure and resilient manner."

At higher maturity levels it protects retention itself: "Backup administrator accounts are prevented from modifying and deleting backups during their retention period." It also requires that "Privileged user accounts (excluding backup administrator accounts) are prevented from modifying and deleting backups."

NIST SP 800-209, on storage security, ties copies to retention needs. It says snapshots used for backup should be configured "To meet retention requirements. For example, if hourly copies are required for at least 48 hours, ensure that a sufficient number of hourly snapshots is preserved." It recommends considering immutable storage, explaining: "Immutability involves the ability to lock data after it has been created, thereby preventing it from alteration or deletion."

NIST also points to a forensic benefit of keeping versions: "While potentially extremely time consuming, replaying to previous versions of data can help learn more about the attack profile, its timing, etc."

Choosing retention depth from detection time

The following method is our recommendation, not a published standard.

  1. Estimate how long you would take to notice. Be honest. If you have no monitoring and rely on someone else to tell you, the 26-day external-notification median is a closer guide than the 10-day internal one.
  2. Add investigation time. After discovery, it takes time to work out when the intrusion began.
  3. Add a margin for intrusions longer than the median.
  4. Use tiers rather than one period. Many short-interval copies for recent days, then fewer copies going further back: for example, daily for a month, weekly for three months, monthly for a year.
  5. Protect the oldest tiers most. They are the ones an attacker would want gone, and the ones you are least likely to notice missing.

Longer retention costs storage, and it keeps personal information for longer, which has its own legal duties (our understanding). The goal is to keep enough depth to recover, not to keep everything.

Why depth alone is not enough

An old backup only helps if three things are true (our reading):

  • Its use is supported by incident-response evidence. Assess the point against the investigation timeline, protected logs and known-good baselines, relevant scans and qualified review. Age alone and absence of known indicators do not establish that it is clean; record the remaining uncertainty.
  • It is complete. ASD expects backups "synchronised to enable restoration to a common point in time", so systems that depend on each other line up.
  • It is restorable. Old backups may need older software, keys or credentials that have since changed.

Logging matters here. Mandiant advises organisations to "Improve logging and monitoring practices to identify suspicious activity and reduce dwell time." In our reading, protected logs retained for the relevant history help assess candidate recovery points, alongside other incident-response evidence. If logs only go back a week and backups go back a year, choosing the right year-old point becomes guesswork.

A clean backup does not remove stolen access

Some access lives outside the systems you back up. ASD's report describes a hospital case in which "multi-factor authentication (MFA) controls had been bypassed as the hospital used cached sessions where users were not prompted for MFA for 14 days after a sign-in."

In our reading, restoring a server to a clean point does nothing about a stolen password, a cached session or an attacker-registered device held in a cloud identity service. If those are not reset at the same time, the attacker can simply sign in again to the freshly restored system. Mandiant's advice to "Enforce FIDO2-compliant multi-factor authentication across all user accounts, especially privileged accounts" points the same way: recovery and access control have to be handled together.

So a recovery plan built on retention depth should also list the credentials, sessions and keys to reset before restored systems go back online (our recommendation).

Bringing data forward

Restoring an older point also means losing everything since. Data from later backups may need to be checked and brought forward carefully, file by file, rather than restored wholesale (our recommendation).

Read-only checks

These checks only read information; they change nothing. On a Linux backup server, this bash command provides file-inventory clues sorted by modification date within two directory levels (the path is an example). It does not measure usable backup retention:

find /srv/backups -maxdepth 2 -type f -printf '%TY-%Tm-%Td %p\n' | sort | head -n 10

The %TY, %Tm and %Td fields report file modification time, not backup recovery-point time. Copied files can retain old dates, chunks/containers can be rewritten and the depth limit can miss relevant pieces. Use the backup catalog/manifest and job records to identify the oldest available candidate recovery point and its complete required chain. Record missing dependencies and coverage limits, then verify the selected point separately.

Then review:

  1. Oldest restore point per system. How many days back does each actually go, compared with the policy?
  2. Tier layout. Are older copies kept at all, or does everything expire at the same age?
  3. Who can shorten retention. Which accounts can change or delete retention settings, and is there an approval step or lock?
  4. Log retention. How far back do security and sign-in logs go, compared with backups?
  5. Detection path. Would you find an intrusion yourself, or wait to be told?

The inventory and catalog checks describe available candidates. A successful isolated restore can demonstrate readability and functionality for its tested scope; it does not prove absence of an attacker. Incident-response confidence requires a separate evidence assessment and documented uncertainty (our recommendation).

Safe restore rehearsal

  1. Choose a candidate point using its catalog/manifest, complete chain and required dependencies. Record its actual recovery point and the test scope; a file timestamp is not the selection basis.
  2. Restore approved test material into an isolated network with no production connection or outbound internet. Preserve evidence under the incident-response plan if an incident is involved.
  3. Check functionality separately: record whether data and applications open, whether the recovery-point baseline matches, which keys/software were needed and the elapsed time.
  4. Assess incident-response evidence separately. A qualified responder should review the documented timeline, protected logs and baselines, relevant malware/anomaly scans and account/task or configuration changes. Comparing two restores is only one source of clues. Record known findings, scan limits and unresolved uncertainty; a successful boot or clear scan is not a guarantee.
  5. Decide recovery and release under the authorised incident-response plan. This may require a trusted rebuild, carefully validated data recovery and remediation of stolen credentials, sessions, keys and other access before connection. Record who accepted the residual risk and how test material is handled without destroying required evidence.

Diagnosing what you find

  • The oldest point is much newer than policy: retention was shortened; storage filled and older copies were removed; or a newer job replaced an older one with its own retention.
  • The old restore will not start: the software version has changed; encryption keys were rotated and not kept; or dependent systems are from a different date.
  • You cannot tell whether a point is clean: logs do not reach back that far; there is no record of normal accounts and tasks; or no investigation timeline exists.
  • Retention could be changed by an ordinary admin: backup administration is not separated; there is no immutability or lock; or the backup console uses the same sign-in as everything else.

Worked example (illustrative)

In this invented scenario, a firm keeps 14 daily backups and later identifies a credential compromise that began at least 31 days earlier. All retained points may contain attacker changes; removing the known mail rule and administrator account alone would not establish eradication. The authorised incident-response team preserves evidence, builds the required services from trusted sources, recovers only data assessed under its plan and remediates credentials, sessions and other access. A hypothetical isolated validation confirms the specified application fixtures and that the known malicious rule/account and tested access paths are absent. It records remaining investigative uncertainty rather than declaring the estate clean. Longer protected backup and log retention is then planned according to the documented risk, recovery and legal requirements. No author-run incident or test is claimed.

Risks and limits

  • Dwell-time figures are medians from one firm's investigations and may not reflect small Australian businesses.
  • The Mandiant figures come from a summary of the report, not the full report.
  • The method for choosing retention is our recommendation, not a standard.
  • Longer retention has storage cost and privacy implications.

Sources

All accessed 14 November 2026.

Related future topics

  • Keeping security logs as long as backups
  • Locking backup retention against admin changes
  • Bringing data forward after restoring an old point

This article was originally published on .