Cannot mount new hard disk after using dd command to copy old hard disk

Question

I wanted to create a backup copy of my external HDD (/dev/sda) to new HDD (/dev/sdb). Initially, old HDD had one ext4 partition and new HDD had one exfat partition. I did the following.

$ sudo dd if=/dev/sda of=/dev/sdb status=progress
1500292583936 bytes (1.5 TB, 1.4 TiB) copied, 13878 s, 108 MB/s   
2930277167+0 records in
2930277167+0 records out
1500301909504 bytes (1.5 TB, 1.4 TiB) copied, 13878.1 s, 108 MB/s

As I understand it, this makes an exact copy of the first disks, block by block. Both disks have equal blocks as identified from fdisk utility. But I'm not able to mount the new disk.

$ sudo mount /dev/sdb1  /media/darth_vader124/Expansion/
FUSE exfat 1.2.3
ERROR: invalid VBR checksum 0x180000 (expected 0xef00f1d9).
$ sudo mount -t ext4 /dev/sdb1  /media/darth_vader124/Expansion/
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
$ dmesg | tail
[35260.595816] sd 5:0:0:0: Attached scsi generic sg0 type 0
[35264.291591] sd 5:0:0:0: [sdb] 2930277167 512-byte logical blocks: (1.50 TB/1.36 TiB)
[35264.291596] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[35264.291771] sd 5:0:0:0: [sdb] Write Protect is off
[35264.291774] sd 5:0:0:0: [sdb] Mode Sense: 53 00 00 08
[35264.292084] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[35264.292374] sd 5:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[35264.380436]  sdb: sdb1
[35264.382173] sd 5:0:0:0: [sdb] Attached SCSI disk
[35994.146335] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem

I see that mount doesn't recognize the new disk as ext4. So, dd probably didn't copy all the blocks.

Edit: I hadn't run partprobe after dd

$ sudo partprobe -s
/dev/sda: gpt partitions 1
/dev/sdb: gpt partitions 1
$ sudo fdisk -l
Disk /dev/sda: 1.4 TiB, 1500301909504 bytes, 2930277167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: BE916BAF-9FFC-4D88-8E8C-B8DD0072B234

Device     Start        End    Sectors  Size Type
/dev/sda1   2048 2930276351 2930274304  1.4T Linux filesystem


Disk /dev/sdb: 1.4 TiB, 1500301909504 bytes, 2930277167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: BE916BAF-9FFC-4D88-8E8C-B8DD0072B234

Device     Start        End    Sectors  Size Type
/dev/sdb1   2048 2930276351 2930274304  1.4T Linux filesystem

Edit2:

$ sudo cat /dev/sda1 | file -
/dev/stdin: Linux rev 1.0 ext4 filesystem data, UUID=61852e31-2c29-41fc-acbd-2a146f7d0d51, volume name "darth_vader124" (extents) (large files) (huge files)
$ sudo cat /dev/sdb1 | file -
/dev/stdin: DOS/MBR boot sector
$ sudo cmp /dev/sda /dev/sdb
/dev/sda /dev/sdb differ: byte 1048577, line 1
$ sudo cmp /dev/sda1 /dev/sdb1 
/dev/sda1 /dev/sdb1 differ: byte 1, line 1

So, it looks like dd didn't copy all the blocks correctly. cmp shows huge number of differences (atleast a total of 1000 non matching bytes) starting from sector 2048 (start of partition).

I tried dd for 1 million 512-sized blocks from sda to sdb just for sanity check using cmp. I compared first 512 million bytes (~489MB) again. Now they match. Surprisingly I am also able to mount sdb now and able to see all other files. I'm not sure what caused the non-mountability of sdb and data difference between sda and sdb the first time. When I ran dd the first time, both disks were mounted (most likely, not exactly sure), but I wasn't using any file. My guess would be some conflict between raw data access and file system caching done by host OS on which dd was run.

Answer 1

As discussed in the comments, this was most likely due to new hard disk being mounted while dd was being performed. After dd completed, new hard disk was unmounted. This might have caused superblock on the new hdd to be overwritten.