Currently if a dedupe partition goes offline, you can recover the data happily. However while backups can still run (redundantly = good) they don't run exactly the same as if the offline partition was still available (I'd describe that as *fully* redundant
Backups or DASH copies targeting the partition have to write a lot more data, basically re-baselining all data on the offline partition onto the existing partition. This is particulary important if the partition is offline for an extended period of time eg. stuck pruning 300 million pending deletes before allowing the parition back online - which can take a weekend..
For larger partitions this can quite easily blow through your available space (I've seen 30tb+ over a weekend) and then you have to accomodate the excess usage until the data ages and really hope it's not the end of month fulls doing extended retention or you'll be waiting months to get that space back.
Shared lun disks in clustered is probably out as SAN SSD wasn't fast enough for us, local SSD is the best thing for larger stores (~1PB).
A secondary copy of each MA paritions DDB may do the trick, you could probably use slower speed disk as you'd still be doing remote lookups via network just keeping a copy of the other MA partitions DDB locally. Even copying this once or twice a day as a sync task would probably suffice to prevent 95% of re-baselining. You could keep the secondary DDB in a read-only state as the reconstruct DDB job would take the offline partition back to that state.
Note - this is assuming the following setting is enabled.
If the Allow jobs to run to this copy while at least [ ] partition(s) are available option is enabled, and if one of the partitions goes offline, sealing and start of a new DDB is prevented, and the backups continue to other active partitions.