maybe without copying all the same files twice?
As far as your dd was concerned, the only files are /dev/nvmeOn1 (probably you meant /dev/nvme0n1) and /dev/sda. dd does not understand, does not analyze filesystems inside. In your case dd was copying raw content of one block device to the other. This cannot be simply "translated" to copying files from one filesystem to another.
If you have a firm clue how far your dd got then it's possible to reasonably "resume" using skip= and seek= options of dd. If not or in case of any doubts, or simply to be on the safe side, just start over. If the hardware is healthy, it should work.
Let me say this explicitly, so there is no doubt: if you want to start over, in case of the command in question there is nothing to revert, nothing to fix. Repeating the entire procedure including the command in question is a clean way to start over. The fact the same command has been run and died is irrelevant.
There may be problems if:
the content of /dev/nvme0n1 changes during the operation of (the new invocation of) dd; I assume the video you saw on YouTube provides a procedure that solves this problem (if not then it's flawed in the first place); I don't know the procedure, there may be some important preliminary steps (like unmounting filesystem(s) or mounting read-only) you should take before repeating the dd command after restarting the Steam Deck;
there is Btrfs inside (some partition(s) of) /dev/nvme0n1; the reason is cloning a Btrfs filesystem to another block device may lead to data loss; but AFAIK Steam Deck does not use Btrfs by default (at least when I'm writing this); still in general it's possible to use Btrfs with Steam Deck; this remark is mainly for future users who find this question and they know they use Btrfs;
you decide to abort and leave /dev/sda as it is; then the content of it (being only a partial copy of the other device) may cause some inconsistencies and thus problems; but you don't want to abort.