ddrescue might be a good change for you, in particular specifying to not retry (because you're going to come back later) and to specify the 'log' file that's actually a map of every sector on the source drive and whether it's been successfully imaged.
I don't think I've ever imaged an SSD, but for HDDs your ideal is a single pass through with no retries on bad blocks, possibly skipping ahead if you hit a bad block, and a log file writing to the destination drive where you're also storing the image in a file (NOT doing direct output of the input disk). This gets you everything you can get with minimal disruption of the source.
After that first run you'll specify the same log file for every time you run it, and (on HDDs) you can tell it to do things like trying to read the higher-numbered sectors first (so if you got an error on block 10,000 and told it to skip 100 on errors, now you start at 10,099 and work backwards, perhaps getting down to 10,005 before you get another error. Basically, get the dropped fruit, then the low-hanging fruit, then work harder for anything remaining.
Before you do those followup runs though, it's a good idea to look at things with the 'ddrutility' tools to see if you even need to bother. ddru_findbad will let you use the image file and 'log' file to identify what files might have pieces missing so you can decide if you need to progress further; ddru_ntfsfindbad does basically the same thing for NTFS volumes. It's always nice to determine that 1) yes there's a chunk of bad blocks and 2) we don't have to care because they're all in the Hibernation file so we can restore that image to a new drive, boot, disable and re-enable hibernation just to be cautious, and have no concerns about lost data on the old drive without having to beat the crap out of the drive hoping that on the 1000th attempt it's finally going to read that one failing sector.
sorry if the latter part of that got preachy, I've seen some bad advice in the past on imaging failing drives and it's made me sensitive....
I recently had the pleasure to work with ddrescue. Unfortunately the SSD disappeared on encountering read errors and could only be brought back by power cycling (at least as far as I found out in the time allotted) :/, so it went to my 'defect hardware' pile.
I don't think I've ever imaged an SSD, but for HDDs your ideal is a single pass through with no retries on bad blocks, possibly skipping ahead if you hit a bad block, and a log file writing to the destination drive where you're also storing the image in a file (NOT doing direct output of the input disk). This gets you everything you can get with minimal disruption of the source.
After that first run you'll specify the same log file for every time you run it, and (on HDDs) you can tell it to do things like trying to read the higher-numbered sectors first (so if you got an error on block 10,000 and told it to skip 100 on errors, now you start at 10,099 and work backwards, perhaps getting down to 10,005 before you get another error. Basically, get the dropped fruit, then the low-hanging fruit, then work harder for anything remaining.
Before you do those followup runs though, it's a good idea to look at things with the 'ddrutility' tools to see if you even need to bother. ddru_findbad will let you use the image file and 'log' file to identify what files might have pieces missing so you can decide if you need to progress further; ddru_ntfsfindbad does basically the same thing for NTFS volumes. It's always nice to determine that 1) yes there's a chunk of bad blocks and 2) we don't have to care because they're all in the Hibernation file so we can restore that image to a new drive, boot, disable and re-enable hibernation just to be cautious, and have no concerns about lost data on the old drive without having to beat the crap out of the drive hoping that on the 1000th attempt it's finally going to read that one failing sector.
sorry if the latter part of that got preachy, I've seen some bad advice in the past on imaging failing drives and it's made me sensitive....