Short answer: Don't do it.
No, it moves them from the general pool devices to a vdev. RAM is volatile and anything updated there needs to be committed to disk, whether it's general capacity vdevs or dedicated DDT vdevs.
The DDT gets cached into RAM for performance reasons, which is why running out of RAM and having your DDT reads hitting spinning disks is so punishing. It's not so much "saves RAM" but rather "makes the consequences of running out less catastrophic." Having to do a bunch of random reads against an SSD that isn't doing anything other than handling DDT lookups/updates is far better than having to interleave those random reads with your regular data I/O against the capacity vdevs; but both are still much, much slower than going through RAM.
Regarding redundancy, "special" vdevs of any type in OpenZFS are considered root vdevs of the pool - losing them results in either inaccessible data (for things like a small_blocks vdev) or a total pool failure (metadata/ddt) so you should be looking at two-way mirrors at a minimum; three-way mirror wouldn't be unreasonable.
For your setup, at an average indexing cost of 5G/1T (assuming 64K records) your 60T of data is going to be looking for 300G of RAM just to hold DDTs. (That's not accounting for RAM needed for other metadata or actual ARC for MRU/MFU.) Even if you devoted 3/4 of your RAM (192G) to hold DDTs, you'd still have 108G of potential lookups that would hit the SSD rather than RAM. If you're unlucky and your recordsize is smaller, you could use significantly more RAM - halving your average recordsize doubles your RAM footprint.
Could it be tolerable if you use an SSD as a dedup vdev? Possibly. But you're going to lose a lot of performance for only 25% space savings, not just from giving up 192G or so of your potential ARC to do housekeeping, but needing to scan through that size of table to check for duplicate hits when you flush transaction groups to disk. Worst case scenario is when writing unique data (which is 75% of your data) - you check the whole table, get no results, and then you have to write the new data to the pool, the metadata for the new data, and a new record to the DDT (so you can dedup against it in the future)
GREAT advice!!
So, after begging a friend said he was going to help me setup a FreeNAS build -- he stopped helping (after I'd ordered equipment, etc) ... because for the 1st time in perhaps his entire life he managed to get a modicum of vagina. As a consequence, I screwed up in EXACTLY the way you're discussing above (willy-nilly using dedupe bc FN 10 I think ... had no warnings about the performance and there were so many damned config choices that looking up each one would've taken an eternity.
Anyway, now I have probably 30GB of my data deduped, and even disabling dedupe (as you know) doesn't stop the pain.
Thing is -- my ARC (RAM) is 48GB ... and it wasn't even using half (according to the overview -- but maybe that's lying or misleading, etc) ...
I'd be ELATED to throw an array of NVMe SSDs and probably have 128GB (if not more I can put in the computer) -- at LEAST to get my goddamned data out of freaking JAIL! We're talking 1MB/s to Read any of the data that was written while DeDupe was enabled -- if not in the kb !!!!
I also have a piece of SHIT CPU in this machine -- bc uh ... you know ... QNAPs use hamsters for their compute power!!! How was I supposed to know!?
I have a POS CPU! in the 4x Dell T320
E5-2403v2 which is a 1.8GHz 4c (NO HYPERTHREADING! NO TURBO!) lol
I'm GOING to replace them ... unless it's not even going to help at all.
Was going to get the E5-2450v2 or E5-2470v2 ...
E5-2450v2 2.5GHZ (3.3 GHz) 8c (16 threads)
(which cost all of about $55)
... or, if cores would be better than an extra 100MHz (and worth paying 2x for them)
E5-2450v2 2.4GHZ (3.2 GHz) 10c (20 threads)
I also have a Radian RMS-200/8G
and still know that both of those things will do VERY LITTLE if ANYTHING to mitigate my issue ...
I'm hoping I can find an optane which my DDT (dedupe table) ...which I spell out not for you but others...
Might be able to swing a pair of 905P
... which I could use as a pair for special vDevs and dedicate to 4k files after my dedup project...?