but which of the former should I use to backup my disk?
/dev/nvme0n1
, and you will need the same target for restoration as well.
What is the purpose of having 2 devices representing the disk?
The specification for NVMe includes the concept of ‘namespaces’. Quoting directly from the official resources at https://nvmexpress.org/resource/nvme-namespaces/:
... a namespace is a collection of logical block addresses (LBA) accessible to host software. A namespace ID (NSID) is an identifier used by a controller to provide access to a namespace. A namespace is not the physical isolation of blocks, rather the isolation of logical blocks addressable by the host software.
If that sounds kind of technical, it is. From a practical perspective, you can think of NVMe namespaces as partitions that are understood and managed by the device itself instead of by the host, with the option to control some of the device’s functionality and configuration independently for each namespace.
This lets you do interesting things like use OPAL SED functionality only on part of the NVMe device, or present different slices of the device to different parts of the system without partitioning it. NVMe namespaces are also an integral part of how multipathing works with NVMe.
But the virtual block device that is a namespace is not the same thing as the NVMe controller. Because of this, for each NVMe controller in the system, Linux presents one character device for the controller (/dev/nvmeX
), which is used to issue management commands (such as those used to reconfigure namespaces), and one block device for each namespace on that controller (/dev/nvmeXnY
).
For almost all commercially shipped NVMe devices, there will be a single namespace covering the whole device (because this lets you plug in the device and use it immediately without any need for configuration unless you want to do something different with namespaces), so you’ll only see the one block device for each NVMe device.
As an aside, I strongly second the comment that you should be looking at something other than dd
for backups. It can’t do incremental backups, it can’t actually reliably do stable backups on the system being backed up, it is entirely dependent on external tooling for deduplication, compression and encryption, and it’s astronomically unlikely you need all the extra state it’s saving (nothing sane cares about block layouts on disk, almost nothing sane except backup software cares about inode numbers, the handful of extended attributes that can’t be dumped by real backup software should be regenerated manually on restore anyway, etc).
dd
as a backup solution in 2024. Unless you have very specific reasons for doing this, you might benefit from considering a different approach.