EBS Volume Has No Recent Backup: Why It Matters and How to Fix It

EBS volumes hold some of the most important state in your AWS environment: database files, application data, boot disks for stateful instances. Unlike S3, EBS gives you no automatic durability guarantee against logical failures. A snapshot is your only point-in-time recovery option, and if the most recent one is weeks old, your recovery point is weeks old too. This Lensix check, ebs_nobackup, exists to catch volumes that have quietly fallen out of any backup routine.

---

What this check detects

The check inspects every EBS volume in the account and looks at the timestamp of its most recent snapshot. If no snapshot has been created in the past 14 days, the volume is flagged.

It does not care how the snapshot was created. Manual snapshots, AWS Backup jobs, and Data Lifecycle Manager (DLM) policies all count. What matters is recency. A volume with a snapshot from 90 days ago and a volume with no snapshots at all are both failures, because in both cases your recovery point is unacceptably stale.

---

Why it matters

EBS is durable in the sense that AWS replicates each volume within its Availability Zone to protect against hardware failure. That replication does nothing for the failure modes that actually destroy data in practice:

• Accidental deletion. Someone terminates an instance with DeleteOnTermination set to true, or runs a Terraform destroy against the wrong workspace. The volume is gone.
• Data corruption. A bad deploy writes garbage to disk, a filesystem corrupts, or a database hits an unrecoverable state. Replication faithfully copies the corruption.
• Ransomware. An attacker who gains instance access can encrypt the filesystem in place. Without a clean snapshot to roll back to, you are negotiating with them.
• AZ-level events. EBS volumes do not survive the loss of their Availability Zone. A snapshot, which is stored regionally, does.

The business impact is straightforward: the gap between your last snapshot and the moment of failure is the amount of data you permanently lose. With a 14-day-old backup, a database failure means reconstructing two weeks of transactions, if that is even possible.

---

How to fix it

Step 1: Take an immediate snapshot

First, close the gap by snapshotting the affected volume right now.

aws ec2 create-snapshot \
  --volume-id vol-0abcd1234ef567890 \
  --description "Manual snapshot - remediating ebs_nobackup" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=manual-remediation}]'

This gives you a recovery point as of now while you set up automation. Verify it completed:

aws ec2 describe-snapshots \
  --filters "Name=volume-id,Values=vol-0abcd1234ef567890" \
  --query 'Snapshots[*].[SnapshotId,State,StartTime]' \
  --output table

Step 2: Put the volume under automated backup

A one-off snapshot solves today's problem and recreates it tomorrow. The real fix is automation. You have two good options.

Option A: AWS Backup (recommended for most teams). AWS Backup gives you centralized backup plans, cross-account and cross-region copies, vault lock for immutability, and a single place to monitor compliance. Create a backup plan and assign resources by tag.

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "ebs-daily-14day",
  "Rules": [{
    "RuleName": "daily-snapshots",
    "TargetBackupVaultName": "Default",
    "ScheduleExpression": "cron(0 5 ? * * *)",
    "StartWindowMinutes": 60,
    "CompletionWindowMinutes": 180,
    "Lifecycle": { "DeleteAfterDays": 30 }
  }]
}'

Then tag the volumes you want included and create a selection that targets that tag:

aws ec2 create-tags \
  --resources vol-0abcd1234ef567890 \
  --tags Key=Backup,Value=daily

aws backup create-backup-selection \
  --backup-plan-id <plan-id-from-previous-step> \
  --backup-selection '{
    "SelectionName": "ebs-tagged-daily",
    "IamRoleArn": "arn:aws:iam::111122223333:role/service-role/AWSBackupDefaultServiceRole",
    "ListOfTags": [{
      "ConditionType": "STRINGEQUALS",
      "ConditionKey": "Backup",
      "ConditionValue": "daily"
    }]
  }'

Option B: Data Lifecycle Manager. If you only need EBS snapshots and prefer something lightweight, DLM creates and expires snapshots on a schedule based on volume tags.

aws dlm create-lifecycle-policy \
  --description "Daily EBS snapshots, 7 day retention" \
  --state ENABLED \
  --execution-role-arn arn:aws:iam::111122223333:role/AWSDataLifecycleManagerDefaultRole \
  --policy-details '{
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "Backup", "Value": "daily"}],
    "Schedules": [{
      "Name": "DailySnapshots",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["05:00"]},
      "RetainRule": {"Count": 7},
      "CopyTags": true
    }]
  }'

Step 3: Define it as code

If you manage infrastructure with Terraform, encode the backup policy so it applies to new volumes automatically.

resource "aws_dlm_lifecycle_policy" "ebs_daily" {
  description        = "Daily EBS snapshots with 7 day retention"
  execution_role_arn = aws_iam_role.dlm.arn
  state              = "ENABLED"

  policy_details {
    resource_types = ["VOLUME"]
    target_tags = {
      Backup = "daily"
    }

    schedule {
      name = "DailySnapshots"
      create_rule {
        interval      = 24
        interval_unit = "HOURS"
        times         = ["05:00"]
      }
      retain_rule {
        count = 7
      }
      copy_tags = true
    }
  }
}

---

How to prevent it from happening again

The reason volumes go unbacked is almost always the same: backup is opt-in, and someone forgot to opt a new volume in. Flip that model so coverage is the default and gaps are visible.

• Tag at creation, enforce with policy. Make a Backup tag mandatory on every volume. Use a Service Control Policy or AWS Config rule to deny or flag volumes created without it.
• Use AWS Config managed rules. The ebs-last-backup-recovery-point-created and ebs-resources-protected-by-backup-plan rules continuously evaluate whether volumes are covered and recently backed up.

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "ebs-protected-by-backup-plan",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "EBS_RESOURCES_PROTECTED_BY_BACKUP_PLAN"
  },
  "Scope": {
    "ComplianceResourceTypes": ["AWS::EC2::Volume"]
  }
}'

• Gate IaC in CI/CD. Add a check in your pipeline that fails any plan introducing an EBS volume without a backup tag. Tools like Checkov, tfsec, or OPA/Conftest can express this as a policy.

An example Conftest (Rego) policy that rejects untagged volumes in a Terraform plan:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_ebs_volume"
  not resource.change.after.tags.Backup
  msg := sprintf("EBS volume '%s' must have a Backup tag", [resource.address])
}

---

Best practices

• Match snapshot frequency to your RPO. If losing 24 hours of data is acceptable, daily snapshots are fine. For transactional databases, take snapshots more frequently or rely on the database's own point-in-time recovery in addition to EBS snapshots.
• Copy snapshots cross-region for critical data. A regional outage or a compromised account can take out both your volumes and their snapshots if everything lives in one place. AWS Backup makes cross-region copy a single setting.
• Make backups immutable for ransomware resilience. AWS Backup Vault Lock in compliance mode prevents snapshots from being deleted before their retention expires, even by an administrator. This is the difference between recovering from ransomware and not.
• Test restores, do not just take backups. An untested backup is a hope, not a recovery plan. Periodically restore a snapshot to a new volume, attach it, and confirm the data mounts cleanly.
• Encrypt snapshots. Snapshots inherit encryption from their source volume. Ensure your volumes are encrypted so the backups carry the same protection.

Backups are one of those controls that cost almost nothing to maintain and everything to lack at the wrong moment. Getting every EBS volume under an automated, tag-driven backup plan, and keeping a check like ebs_nobackup watching for gaps, turns recovery from a scramble into a routine.