dd is indeed faster than cp and even rsync ... The reason is dd doesn't process directories and files, while cp and rsync do ... dd just reads and writes (although it can process data in other usage cases) ... But, cp and rsync are more manageable and more fixable and stopable in case of a mistake while dd is NOT. ... dd will DESTROY the destination disk as soon as you hit the Enter key.
Big Dangerous Ugly Warning (disk names do change)
Disk names(and partition names as a result) under /dev/ can and will change depending on their connection order i.e. the first connected disk gets the first available letter in the order /dev/sda then the next one will be named /dev/sdb then the third one /dev/sdc/ and so on … So if two disks get disconnected and then connected again in a different order, their previously assigned names might get swapped and your source disk might suddenly become the destination for dd and it will be DESTROYED … The same goes for all types of disks e.g. NVMEs, SSDs … etc. … So unless you are an experienced user, DO NOT use dd.
Notice: Clonezilla as discussed in this answer is a bit safer and should give the same performance as dd.
Warnings made clear? ... If true; then continue.
What you are doing with dd is called partition/disk imaging and you can do it in a few ways.
First way(disk to disk)
In this way you copy raw disk(overlooking partitions but including them) data as an image to another disk ... This will make the destination disk an exact image of the source disk ... Extra space however on the destination disk is not utilized as the image will only occupy a size identical to the total size of the readable area on the source disk ... Any data, partitions and images on the destination disk will be DESTROYED ... Filesystems i.e. partitions must not be mounted during the imaging process on both source and destination … This way can be done with something like this(where /dev/sdb is the source and /dev/sdc is the destination):
dd if=/dev/sdb of=/dev/sdc
Second way(partition to disk)
In this way you copy a partition as an image to another disk ... This will make the destination disk contain an identical partition(with filesystem and data) to the source partition ... Extra space however on the destination disk is not utilized as the image will only occupy a size identical to the total size of the source partition ... Any data, partitions and images on the destination disk will be DESTROYED ... Filesystems i.e. partitions must not be mounted during the imaging process on both source and destination … This way can be done with something like this(where /dev/sdb1 is the source partition and /dev/sdc is the destination disk):
dd if=/dev/sdb1 of=/dev/sdc
Third way(disk/partition to a file)
In this way you copy a disk or a partition as an image to a file on a mounted filesystem ... This will make the destination file contain an identical image of the source partition/disk ... The destination file is an image that can be mounted in-place, moved, copied and restored ... Filesystems i.e. partitions must not be mounted during the imaging process on the source … This way can be done with something like this(where /dev/sdb and /dev/sdb1 are the source disk/partition and /mnt/backup is the destination mount-point of a supported filesystem and file.img is a suggested filename for the image file):
dd if=/dev/sdb of=/mnt/backup/file.img
or(to image a partition instead):
dd if=/dev/sdb1 of=/mnt/backup/file.img
Remarks
If you are an advanced user, then you know your ways ... But if you are a normal user willing to save your data and time, then this part is for you.
dd is best suitable for copying/imaging physical disks in raw data mode i.e. raw disk data blocks … these are different from data manipulation/processing that happen on the LV/partition(logical devices/disks) and the filesystem(data structure implemented and used by your OS to control how data is stored and retrieved) … to copy on the LV/partition level and especially on the filesystem level, don’t use dd … use filesystem level tools like partclone or cp or rsync or even tar.
You might find on the internet instructions on using dd to "copy" disk partitions and they'll tell you to do it by copying the source partition to the destination partition(without enough explanation of what else you need to care for when using this method) e.g. just like this(not advised):
dd if=/dev/sdb1 of=/dev/sdc1
That might go wrong on many levels as the destination partition, if it exists, is merely a logical boundary i.e. a logical(not real) device/disk created and identified with software ... So you would be imaging the source partition /dev/sdb1 with its area being read by dd on the disk raw level into /dev/sdc1 which is a logical disk that depends on identifiers by software to be correctly utilized by the OS ... Those identifiers might not remain valid after that imaging process as e.g. the filesystem might change ... If, on the other hand, the destination partition e.g. /dev/sdc1 doesn't exist, then what's the point of attempting to create a partition on /dev/sdc the wrong way(dd is not a disk partitioning tool) as although(if the imaging operation succeeds by pure luck and a 50/50 chance) the destination /dev/sdc1 will contain the a filesystem(copied from the source i.e./dev/sdb1) it will not really be a partition and the destination desk /dev/sdc will not contain a partition table identifying /dev/sdc1 as a partition ... But, you most likely(50% of the time if we are being optimistic) will not see this not advised approach yield any expected result and you will end up in a loop not knowing what went wrong like these e.g. (To name just a few ... The list is long):
Furthermore, partitioning is a disk specific(for one unique geometry of a certain distinct physical disk) procedure ... Correctly created partitions are deeply rooted into that disk's partition table with their purposes/types, filesystems, flags and geometry set ... They shouldn't be selectively copied(using low level tools like dd) to another disk with a different partition table and be expected to simply magically work! ... And even worse things could happen, if dd is used to copy a partition from one disk into a partition in another disk destroying its filesystem, causing un-allocated space on the partition level and probably mangling it's logical boundaries ... If correctly cloning a partition is what you want then use other partition cloning tools that will do it right and not dd ... If you must do it with dd, then at least protect the integrity of your valuable data(assuming preserving data is your goal) and do it partition to physical disk and not to a logical device that might get mangled very badly during the process ... Yes, physical disks can hold a filesystem and data without partitioning(read and write speeds might be a bit slower though) and it should be safer than imaging partition to partition as far as data concerned.
Please go through this example of How to create swap partition in Linux as it illustrates how a partition is really created and set covering some of the underlying deep roots of a partition.
A good and easy reading resource on this matter is File System - Partition / Volume (Logical Disk Partition)
ddis faster thancp?dd, it is rather inefficient compared to copying only the used drive space, and you can do that either byrsync, which often is quite efficient, or by Clonezilla, which is a good alternative todd, when the file system is recognized by Partclone (which is used by Clonezilla).