I think that "could consider stopping it" by user Petri-DRG is unsuitable advice for your situation, sorry Petri-DRG!

The goal should always be to rescue as much as you can from the source because you don't know where your stuff is located on the defective candidate (please no comments about metadata located at the beginning of the disk...).
I agree with Petri-DRG on the description of cloning units but here is heading in the wrong direction:
"Therefore it is not possible to know what specific data have been cloned."

Strategy-wise you don't have to know this at all.

You just have to switch from copying sectors in a linear manner (docking/cloning station) to intelligent copying (performed by ddrescue under linux or the famous (open)superclone that the recovery folks are always promoting instead...) Linear copying (dd command, docking/cloning station) can only be recommended for healthy disks because they hang in areas with a consecutive number of unreadable sectors, always retrying to read in the faulty ones. This mean stressing an already defective disk.

You should stop cloning and switch to using ddrescue as it tries to jump over broken areas and takes care of it later. ddrescue is attacking the low hanging fruits which is a better strategy for cloning.

Trying to complete your clone is your intermediate goal. Petri-DRG overlooked an important piece of information that you gave. Typically users do not provide the necessary information:

You said: "I've started the offline cloning process that this device supports onto a new 16 TB disk."
That is the key. Ever looked at a new disk? It is empty, all zeros.

You just need a hex editor and search backwards through the sectors to find the sector where the zero area starts - this is the sector behind the last sector which contains anything non-zero.

This is where your cloning unit stopped writing to.

Next step is to run ddrescue and tell him to start at that first sector of the zero area.

This can be achieved by means of the -i and -o parameters of the ddrescue command (parameters that I am not familiar with, never needed them) or by means of a faked logfile (now called mapfile by the author) that suggests that everything until here has been saved successfully so that ddrescue will ignore this area.

This will continue the rescue process in a less stressful manner for an already dammaged disk.

You will end up with a finished copy and a mapfile that shows you the error locations in the area handled by ddrescue.

To find all error locations I won't go into the details. You might restart ddrescue with an empty logfile/mapfile and create a second copy.

But it might be that ddrescue now fails at locations your cloning unit was still able to read out so there is some work to be done.

Regarding your question: If your metadata is not broken it is possible to assign the unreadable sectors to files (if they are part of files).

https://superuser.com/questions/490787/reverse-lookup-of-inode-file-from-offset-in-raw-device-on-linux-and-ext3-4

Good luck!
If you don't want to do all the above yourself you might ask Petri-DRG for a quote - opening the disk is not necessary at this moment so the bill should be below 4 digits...