The need for backup is different for identities, routers, and controllers. For all three, backup does not inherently cause it to become unavailable, e.g., database snapshot is not disruptive.
- controller is described in the backup guide and includes the database and root certificate authority, at least.
- router: it's not strictly necessary to back up a router because the same router ID can be re-enrolled by the admin if the host is lost or compromised
- identity: like routers, identities can be re-enrolled by the admin if lost or compromised, so it's not strictly necessary to back up the identity file(s).
I admit it might make sense in some cases to back up a router's or identity's files, e.g., requesting a new enrollment from the admin is inconvenient.
I mean like will the routers and identities still be enrolled and function normally to route to services they were told to or we have to redo the steps of adding routers again after backup of controller ?
I suggest that you check out the controller backup guide sections I mentioned about database snapshot and root CA (PKI).
Creating a backup (snapshot) of the controller's database makes a copy of the data on the disk that you can then move to another device for safekeeping. That way, if you lose the database, you have the option to restore the data.
Ya understood , just confirming the controller's data is about its connection and registrations made across with different routers and hence if we back it up and run on even the different machine with different IP , the existing routers will connect to the new controller and controller knows how to route traffic to them
The controller's database has the enrollments, yes, as well as all entities' state, including policies.
You can restore to a new IP address if you configured the controller address with a DNS name by changing the DNS record to the new IP address.
Changing the advertised address in the controller configuration will cause existing enrollments to stop working, so it is essential to configure a DNS name, not an IP address, as the controller address.
If we use velero we would not require to worry about the steps right ?
I don't know enough about Bolt DB to say whether it's immune to corruption. Backup systems like Velero can't guarantee database integrity, so corruption is possible if the storage is copied during a database operation.
The solution is to use the snapshot command from the backup guide and back up the snapshot files with Velero. If you restore from a snapshot then it will not be corrupted.
ya maybe snapshot resource
and velero should automate the backup and restore process
@qrkourier , if I delete /persistent/ctrl.db still the system works . Where is the controller picking the actual db from then ?
edited: Needed to restart the pod