Safely Restoring Files from AWS Snapshots When /etc/fstab Uses UUIDs

Restoring files from an AWS EBS snapshot sounds straightforward: create a volume, attach it to the server, mount it, copy what you need.

But if your Linux server uses UUID-based mounts in /etc/fstab (which is very common), there’s a nasty trap hiding here:

A volume created from a snapshot inherits the same filesystem UUID as the original volume.
If you mount that clone on the original server and then reboot without fixing the UUID, the clone can become the root filesystem.

Best case, the system boots from the wrong disk and confuses everyone. Worst case, files get overwritten or you lose data.

This post walks through a safe process for mounting snapshot-based volumes so you can restore files without risking your root filesystem.

The Problem: Snapshots and Duplicate UUIDs

Most modern Linux systems identify filesystems in /etc/fstab using the UUID= syntax instead of raw device names:

This is great for stability: /dev/nvme0n1p1 might appear as /dev/xvda1 on another boot, but the UUID remains the same.

However:

• When you create a new volume from an EBS snapshot, AWS copies the underlying block device exactly.
• That includes the filesystem UUID.
• If you then attach that cloned volume to the same server, the OS now sees two filesystems with the same UUID.

If the machine is rebooted while that cloned volume is still attached, the boot process may happily pick the wrong one as /, because both claim to be the same filesystem by UUID.

We want to use that cloned filesystem only as a source of files, never as an alternate root candidate.

The Strategy: Change the UUID Before Regular Use

The safe pattern:

1. Create a volume from the snapshot.
2. Attach it to the server.
3. Mount it once with options that ignore the UUID conflict (to process the journal cleanly).
4. Immediately change the filesystem UUID on the cloned volume.
5. Mount it normally wherever you want (e.g. /mnt/restore) and restore your files.

Once the UUID is changed, the cloned volume is just another independent filesystem. If the server reboots with it attached, there’s no chance it will be mistaken for the original root.

Assumptions

These steps assume:

• You’re on Linux (e.g. Amazon Linux, RHEL, CentOS, Alma, Rocky, Ubuntu, etc.).
• You’re using EBS volumes on AWS EC2.
• The filesystem is either:
  • XFS (very common for modern Linux root volumes), or
  • An ext-family filesystem (ext2/3/4).
• /etc/fstab uses UUID= for root and other critical mounts.

Step-by-Step: Safely Mounting a Snapshot Volume

1. Create the Volume from Snapshot

In AWS:

1. Go to EC2 → Elastic Block Store → Snapshots.
2. Select the snapshot you want.
3. Click Actions → Create volume from snapshot.
4. Choose the AZ that matches your EC2 instance and create the volume.

Wait until the volume is in the available state.

2. Check Current Block Devices on the Server

On the EC2 instance you’ll attach to, list existing block devices:

Typical output might look like:

This gives you a baseline before attaching the new volume.

If you want to see filesystem types and UUIDs, you can also use:

💡 Alternative: On very minimal systems where lsblk isn’t available, you can fall back to:

cat /proc/partitions

1 2	cat /proc/partitions

The output is less friendly, but it still lets you see what block devices exist before and after attaching the snapshot volume.

3. Attach the New Volume and Identify Its Device

In AWS:

1. Go to EC2 → Volumes.
2. Select the new volume.
3. Click Actions → Attach volume.
4. Choose the target instance and attach.

Back on the instance, run:

again and look for the new device. Common patterns we see:

• If the server already has a /data volume:
  • The new device often appears as something like /dev/nvme2n1 with a partition /dev/nvme2n1p1.
• If there’s no /data volume:
  • The new device may show up as /dev/nvme1n1 with /dev/nvme1n1p1.

If you’re using /proc/partitions, you can similarly compare the before and after output to spot the new device.

But don’t guess. Confirm exactly which block device is new.

⚠️ Double-check this. Using the wrong device in the next steps can damage your live filesystem.

For the rest of this article, we’ll assume the new partition is /dev/nvme2n1p1. Adjust as needed for your actual device.

4. Initial Mount/Unmount to Process the Journal

Before we change the UUID, we want the filesystem to be clean. That means mounting it once and then unmounting it.

For XFS, you must use the nouuid option when mounting a cloned filesystem that shares a UUID with an existing one:

What this does:

• -o nouuid tells XFS to ignore the UUID conflict so it will mount even though a filesystem with that UUID is already in use.
• Mounting and then unmounting allows the filesystem to replay any journals and be in a clean state before we modify its metadata.

If you’re dealing with an ext2/3/4 filesystem, nouuid is not required, but doing an initial mount/umount is still a good practice to ensure the filesystem is clean.

5. Reset the Filesystem UUID

Now we assign a brand-new UUID to the cloned volume.

Again, verify your device name before running these commands.

For XFS

This generates a new random UUID for the XFS filesystem.

For ext2/3/4

This writes a new random UUID to the ext filesystem.

After this step, the cloned volume no longer shares a UUID with the original disk. It’s now safe for the server to reboot with this volume attached.

You can confirm the new UUID with:

6. Mount the Restored Volume Normally

With the UUID fixed, mount the volume normally and restore your files:

Now you can browse and copy:

You can go AFK at this point without worrying that a reboot will cause the system to come up from the wrong root volume.

When you’re done:

1. Unmount the volume:
   
   umount /mnt/restore

   1 2	umount /mnt/restore

2. Detach it in AWS.
3. Optionally, delete the volume if you no longer need it.

Why Not Just Change the UUID Immediately?

You can technically change a filesystem’s UUID on an unmounted device using xfs_admin (for XFS) or tune2fs (for ext filesystems). So why do we bother with an initial mount and unmount?

When you create an EBS volume from a snapshot of a live filesystem, that snapshot is crash-consistent — the filesystem’s journal may still contain unflushed changes. The first time you mount it, the OS replays that journal and brings the filesystem into a clean state.

By doing:

before changing the UUID, we ensure:

• Any pending journal entries are replayed.
• We’re updating the UUID on a fully consistent filesystem.
• The process behaves predictably across both XFS and ext-based filesystems.

After that, changing the UUID with:

is safe, and the cloned volume can stay attached without any risk of being mistaken for your root filesystem on reboot.

Quick Reference: Safe Snapshot Restore Procedure

For convenience, here’s the whole procedure condensed:

1. Create volume from snapshot in AWS.
2. On the server, record current block devices:
   
   lsblk # or, on minimal systems: cat /proc/partitions

   1 2 3 4

   lsblk # or, on minimal systems: cat /proc/partitions

3. Attach the new volume to the instance in AWS.
4. Back on the server, identify the new device by comparing before and after lsblk (or /proc/partitions) output:
   
   lsblk # Determine e.g. /dev/nvme2n1p1

   1 2 3

   lsblk # Determine e.g. /dev/nvme2n1p1

5. Initial mount/umount to process the journal:
   
   mount /dev/nvme2n1p1 /mnt/restore -o nouuid umount /dev/nvme2n1p1

   1 2 3

   mount /dev/nvme2n1p1 /mnt/restore -o nouuid umount /dev/nvme2n1p1

6. Reset the UUID (pick the right command for your filesystem):
   
   # XFS xfs_admin -U generate /dev/nvme2n1p1 # ext2/3/4 tune2fs -U random /dev/nvme2n1p1

   1 2 3 4 5 6

   # XFS xfs_admin -U generate /dev/nvme2n1p1   # ext2/3/4 tune2fs -U random /dev/nvme2n1p1

7. Mount for restore:
   
   mount /dev/nvme2n1p1 /mnt/restore

   1 2	mount /dev/nvme2n1p1 /mnt/restore

8. Restore files, then unmount and detach when finished.

Wrap-Up

Snapshots and cloned volumes are powerful recovery tools—but when your system uses UUID-based mounts, they come with hidden sharp edges. By always resetting the UUID on volumes created from snapshots before regular use, you:

• Avoid root filesystem confusion at boot time.
• Prevent subtle, hard-to-debug data issues.
• Make your restore process predictable and repeatable.

If you’d like help reviewing your backup/restore procedures or automating snapshot restores safely across multiple servers, Reliable Penguin can help you formalize and test a robust runbook tailored to your environment.