AWS Backup EBS Restoration: Volume Availability vs. Filesystem Readiness

Answer

No. A COMPLETED AWS Backup restore job means the control-plane restore operation finished and the EBS volume resource is available in the target Availability Zone. It is not a guest-OS signal that the filesystem is ready to mount.

Confirmed facts vs. likely explanation

Confirmed: AWS Backup restore-job status and EC2 DescribeVolumes report resource and attachment state, not in-guest block-device enumeration or filesystem consistency.

Likely explanation for inconsistent immediate mounts: the volume can be available before the instance has enumerated the attached device, before NVMe device naming settles, or before a dirty filesystem journal is replayed.

Programmatic readiness gate

Poll DescribeRestoreJob until COMPLETED, then poll DescribeVolumes until the restored volume State is available. Attach the volume and poll the attachment state until attached. Only then run an in-guest readiness check via SSM Run Command or your instance agent.

One missing detail changes the exact commands: the target OS and filesystem. The steps below assume Linux with ext4/XFS; for Windows or another filesystem, replace the in-guest checks with the OS equivalent while keeping the same EC2 availability gate.

In-guest verification (Linux example)

1. Wait for the device to settle and enumerate:

udevadm settle
lsblk

1. Identify the device by expected filesystem UUID or type, not by a fixed /dev name:

lsblk -f
blkid

1. Run a read-only check on the unmounted device and require a clean result:

# ext4
fsck -n /dev/nvme1n1

# XFS
xfs_repair -n /dev/nvme1n1

1. Mount read-only first, then read-write if the check passes:

mount -o ro /dev/nvme1n1 /mnt/verify
# ... verify ...
mount -o remount,rw /mnt/verify

Safety notes

• Never run fsck or chkdsk against a mounted or in-use device. Confirm the volume ID and unmount every partition first.
• NVMe EBS device names are not guaranteed to be stable across instance stops/starts, so match by filesystem UUID or volume serial rather than a fixed /dev path.
• If replacing an existing volume, detach the old volume and confirm the new volume ID is attached to the intended instance before mounting.
• Filesystem readiness is not data integrity; application-level checksums are still required after restore.

Practical verification

In a test restore, poll DescribeRestoreJob until COMPLETED, then immediately call DescribeVolumes and record whether State is already available and how long until the guest device appears. Attach the restored volume to a scratch instance and run lsblk -f plus blkid to confirm the expected filesystem type and UUID before any read-write mount. Run the filesystem-appropriate read-only checker on the unmounted device and require a clean result before mounting read-only, then read-write. Repeat on a different instance or after a stop/start to confirm device naming and readiness timing.

Cross-AZ restore adds snapshot-copy latency before the restore job starts; that affects timing, not the readiness gate.