Thanks for looking. I'm trying to go the other way (which I should have specified, just tried on 6x since I have it handy):
bin/solr zk cp -r zk:/ ~/eoezk -z localhost:2181
Fails with: ERROR: Invalid path string "//configs" caused by empty node name specified 1
bin/solr zk cp -r zk:/whatever ~/eoezk -z localhost:2181
The context here was a client who'd accidentally removed the zoo_data directory on all ZKs but still had them running. We hit on the bright idea "hey, we can just dump all of the ZK data since the data is still available until we restart the ZK nodes" but ran into this when trying to copy stuff down.
So I worked out the issues with the path and got the two-way copy to work, but also noticed another issue. Since ZK nodes can have data whether leaf nodes or not, the current process is lossy since non-leaf nodes don't get their data restored.
This makes it impossible to backup the collection node and restore it since the collection can have a configset name as data. My take is that copying back and forth should restore intermediate node's data, do you (and others) concur?
My first-attempt PoC is to create a very special file name something like node_zookeeper_solr.data to put any information associated with non-leaf nodes when the data is not empty as a PoC. That feels like a hack though as there's the possibility of collisions. Hmmm, maybe
.znode.solr.data? Still possibly a collision if someone, somehow managed to have a znode with a GUID followed by .znode.solr.data I suppose, but that's seems unlikely enough that I'm not willing to worry about it. How about "erick.erickson.was.here.data"? Maybe not.