Bad magic number in super-block after clone

I wanted to experiment with lvm and debian. So I installed debian on a LVM on my home nas using a cheap Sandisk Cruzier (16GB). I was quite happy with the setup so I purchased a faster Sandisk Extreme (32 GB, 100+ MB/s).

Now I expected I could do a simply clone using dd if=/dev/sda of=/dev/sdh bs=1M

Everything appears to work but when I check the file system:

#fsck.ext4 -nf /dev/sda1 e2fsck 1.42.12 (29-Aug-2014) Warning! /dev/sda1 is mounted. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda1: 328/62248 files (23.5% non-contiguous), 41381/248832 blocks # fsck.ext4 -nf /dev/sda2 e2fsck 1.42.12 (29-Aug-2014) fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda2 Could this be a zero-length partition? # fsck.ext4 -nf /dev/sda5 e2fsck 1.42.12 (29-Aug-2014) Warning! /dev/sda5 is in use. ext2fs_open2: Bad magic number in super-block fsck.ext4: Superblock invalid, trying backup blocks... fsck.ext4: Bad magic number in super-block while trying to open /dev/sda5 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> 

Although everything appears to be functioning fine this does not sound promising. Any suggestions on how to repair the LVM? Or is this output "normal" for LVM?

edit:

So it appears on LVM you have to fsck the volume not the partition:

fsck -nf /dev/bugattidebian-vg/root fsck from util-linux 2.25.2 e2fsck 1.42.12 (29-Aug-2014) Warning! /dev/mapper/bugattidebian--vg-root is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Deleted inode 1857 has zero dtime. Fix? no Inodes that were part of a corrupted orphan linked list found. Fix? no Inode 1859 was part of the orphaned inode list. IGNORED. Inode 1863 was part of the orphaned inode list. IGNORED. Inode 1864 was part of the orphaned inode list. IGNORED. Inode 1865 was part of the orphaned inode list. IGNORED. Inode 261082 was part of the orphaned inode list. IGNORED. Inode 526205 was part of the orphaned inode list. IGNORED. Inode 526206 was part of the orphaned inode list. IGNORED. Inode 528192 was part of the orphaned inode list. IGNORED. Inode 656572 was part of the orphaned inode list. IGNORED. Inode 805735 was part of the orphaned inode list. IGNORED. Inode 805736 was part of the orphaned inode list. IGNORED. Inode 805738 was part of the orphaned inode list. IGNORED. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: -(95232--95629) -(114854--115453) -(499941--500298) -(558488--558526) -(3203436--3203440) -3203448 Fix? no Free blocks count wrong (2528802, counted=2515671). Fix? no Inode bitmap differences: -1857 -1859 -(1863--1865) -261082 -(526205--526206) -528192 -656572 -(805735--805736) -805738 Fix? no Free inodes count wrong (771106, counted=771776). Fix? no /dev/mapper/bugattidebian--vg-root: ********** WARNING: Filesystem still has errors ********** /dev/mapper/bugattidebian--vg-root: 132878/903984 files (0.4% non-contiguous), 1084894/3613696 blocks 

So I guess the situation is less troublesome then I thought based on the initial report!