i may have shot myself in the foot by adding a dedup device to my pool without understanding what i was doing. now i can’t seem to remove it, even though it’s unused. (no data set has deduplication enabled.)
# zpool remove data db77679e-6cb5-4b56-a9d0-96acf88bd034
cannot remove db77679e-6cb5-4b56-a9d0-96acf88bd034: invalid config; all top-level vdevs must have the same sector size and not be raidz.
again, though the pool has the deduplication feature, no data set has it enabled. i’d like to have this spurious NVME dedup device removed from the pool before i actually try to use deduplication, if possible. help?
You lose the pool.
I am not aware of any way of going back unless you made a checkpoint. That might be able to help. But if you didn’t manually make one (in the CLI) there won’t be one to go back to.
well damn, i’ve really shot myself in the foot here, then. i guess i’ll have to back up my data to some other storage, delete the pool, and recreate everything from scratch. that’s gonna hurt…
i’ll have to go searching for any way to back up the NAS configuration that would not also back up the pool structure, so that i can rebuild the datasets and shares and suchlike without automagically painting myself back into this same corner. you wouldn’t happen to know of such a feature, would you?
Sorry, I am not aware of a way to “save” the dataset configuration specifically. There’s the TrueNAS config of course, but that’s not quite what you’re after here.
While I haven’t tried it myself - shares appear to reference data using basic paths. So presumably you could disable the shares before the transfer process. If you name your new pool the same, the shares “should” just work. You will however likely need to redo your dataset ACLs.
There really really really need to be some “You are about to add a DEDUP vDev to your ‘data’ pool. THIS WILL BE PERMANENT AND CANNOT LATER BE REMOVED. Are you sure?” messages in TrueNAS.
so, backing up my data to a different device then deleting / recreating the pool seems to be the thing to do.
of course, i don’t have another five terabytes of networked RAID just lying around unused. but i DO have a USB disk large enough, and for a temporary procedure it’d do.
now how do i get TrueNAS to recognize i have a 12TB disk plugged into a USB port? no sign of it shows up in the web UI.
this was precisely my plan, but for some reason it isn’t seeing the USB disk.
and the TrueNAS box is running headless, so it’s a slight pain to diagnose. i may have to connect the USB disk to another machine on the net and run an rsyncd to receive the data. such a bother.
after resolving an ID10T error relating to the disk itself, sure enough, it was recognized. after that, setting up the replication task was a simple matter of trying and failing enough times to make me read the fine manual. then fine-tuning the task after i got it set up, so that it’d target the periodic snapshot task i already had existing instead of the new one it redundantly created. seems to be running now.
the lesson i learned was to read the documentation before making assumptions and acting on them. my first error was assuming that a dedup device was something analogous to a log or cache device; if the UI had given me a hint or two to go read the documentation that told me otherwise, that might’ve saved me this embarrassment. but fundamentally, the fault was mine.
Mind that deduplication is a resource hog, requires at least 64 GB RAM as a start, and is generally not worth it for home use.
But if you’re still decided to give it a try, also mind that the dedup vdev is absolutely critical and should be redundant. So the other way out of your misery would be to add further drives to make the dedup vdev a mirror, preferably 3-way to match the resiliency of a raidz2.
But backup, destroy and restore, without dedup, is the best way.
