Looking for suggestions - your views opinion on etcd restore when you are not on master/controlplane node?
Would be interesting to hear about that.
All the labs and exercises I have done are all done from controlplane node.
I would assume that if you had to do it from outside of the cluster, you would need to have the same certificates etcd is using available locally, in order to talk with etcd.
In that case, backup is trivial.
The restore however, sounds like it would be trickier.
You have to specify a
--data-dir which points to a local directory…. Im not really sure how I would proceed.
@OE any thoughts on that?
or maybe @Tej_Singh_Rana?
@Michael Cuffaro There are a # of threads related to this. Restoring from the controlplane node isn’t really different from any other node (or even your local machine) except you can take some shortcuts in terms of the parameters you have to specify (again, search for previous threads on this). You can copy the certs over if you don’t have them locally if you want and use them. Make sure to use the same version of etcdctl and etcd as I’ve run into failed restores due to this (I wrote a thread about this as well). You’d still typically have to ssh to the control plane to modify the etcd.yaml file to point to the new --data-dir
so essentially - if you are restoring from any other place apart (lets assume local for the sake of simplicity) from the controlplane then you need to have correct etcd address (assuming you have the backup and certs your local.
You always have to have the correct etcd address. Restoring from the controlplane just lets you not specify it because it defaults to 127.0.0.1:2379 which is accessible from controlplane
But because etcd restore can bork your setup, I’d recommend taking a backup. I covered how to do this in a thread using volume backups so you can easily get a working cluster again if something goes wrong
by correct address I meant the one for the correct etcd.I would still prefer to backup and restore from the controlplane node.