I restored an EBS volume and attached it to a new EC2 instance. When I lsblk, I can see it under the name /dev/nvme1n1.
More specifically, the output of lsblk is:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 25M 1 loop /snap/amazon-ssm-agent/4046 loop1 7:1 0 55.4M 1 loop /snap/core18/2128 loop2 7:2 0 61.9M 1 loop /snap/core20/1169 loop3 7:3 0 67.3M 1 loop /snap/lxd/21545 loop4 7:4 0 32.5M 1 loop /snap/snapd/13640 loop5 7:5 0 55.5M 1 loop /snap/core18/2246 loop6 7:6 0 67.2M 1 loop /snap/lxd/21835 nvme0n1 259:0 0 8G 0 disk └─nvme0n1p1 259:1 0 8G 0 part / nvme1n1 259:2 0 100G 0 disk As you can see, nvme1n1 has no partitions. As a result, when I try to mount it on a folder with:
sudo mkdir mount_point sudo mount /dev/nvme1n1 mount_point/ I get
mount: /home/ubuntu/mount_point: wrong fs type, bad option, bad superblock on /dev/nvme1n1, missing codepage or helper program, or other error. The volume has data inside:
ubuntu@ubuntu:~$ sudo file -s /dev/nvme1n1 /dev/nvme1n1: data Using sudo mkfs -t xfs /dev/nvme1n1 to create a filesystem is not an option as Amazon states that:
Warning
Do not use this command if you're mounting a volume that already has data on it (for example, a volume that was created from a snapshot). Otherwise, you'll format the volume and delete the existing data.
Indeed, I tried it with a second dummy EBS snapshot that I recovered, and all I got was a dummy lost+found linux folder.
This EBS recovered snapshot has useful data inside. How can I mount it without destroying it?
# parted -l /dev/nvme1n1 print Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme0n1: 8590MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 8590MB 8589MB primary ext4 boot Error: /dev/nvme1n1: unrecognised disk label Model: Amazon Elastic Block Store (nvme) Disk /dev/nvme1n1: 107GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: dmesg | grep nvme1n1 [ 68.475368] EXT4-fs (nvme1n1): VFS: Can't find ext4 filesystem [ 96.604971] EXT4-fs (nvme1n1): VFS: Can't find ext4 filesystem [ 254.674651] EXT4-fs (nvme1n1): VFS: Can't find ext4 filesystem [ 256.438712] EXT4-fs (nvme1n1): VFS: Can't find ext4 filesystem $ sudo fsck /dev/nvme1n1 fsck from util-linux 2.34 e2fsck 1.45.5 (07-Jan-2020) ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/nvme1n1 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device> 
mount -r -t ext4 /dev/nvme1n1 /some/mountpointwhich will mount the diskread-onlyand in this case (since dmesg is showing ext4) it most probably is an ext4 file system.nvme1n1p1. Herep1would refer to the first partition on the block device which you don't have as I mentioned in my previous comments which I deleted. You need to mount the whole disk since the partition (it seems ) has been created on the whole disk.-rflag? What does the dmesg show you then?dmesgis explicitly mentioningEXT4-fs (nvme1n1): VFS: Can't find ext4 filesystem. Thenvme0n1has indeed thebootpartition on ext4 but we don't have to deal with that. I see there are some related posts like yours here: unix.stackexchange.com/questions/315063/… Please have a look there but don't runmkfsor anything like this because this might cause data loss. Runningfsckcan help and won't harm./dev/nvme1n1: data"... no, that just meansfilecouldn't identify what the contents are. It could be garbage for all we know. It might be an encrypted volume. Nothing so far shows you have a valid filesystem there.