Planning Your Data Protection
SHIELD can perform etcd backups in a few different ways, depending on your network throughput, access control, and personal preferences.
The simplest method is to run the SHIELD agent on the same box as
etcd, and connect to it over the loopback address,
127.0.0.1. Keep in mind, however, that this does not
work if your local etcd instance is offline or otherwise non-functional.
You can also run the SHIELD agent somewhere else, and configure your backup jobs to connect to the etcd endpoints across the network, using either their public IPs, or (if you have configured them) internal Linode IPs.
This can be useful if you'd rather not load additional software on your cluster. You can also reuse the external agent to protect multiple etcd clusters, since your backup jobs will specify the URL endpoints of each cluster.
SHIELD uses the etcd HTTP REST/JSON API for both snapshots and restoration, so there is no dependency on other installed software.
Configuring Backup Jobs
It's entirely up to you.
This plugin supports three different methods of authenticating to your etcd cluster:
- Role-based (username and password) authentication
- Certificate-based authentication
- Both role- and certificate-based authentication
Which method is used is governed by the Authentication parameter.
Under Role-Based Authentication, the plugin will connect to the etcd cluster and present the given Username and Password parameter values. No client certificates will be presented, even if they are configured.
Under Certificate-Based Authentication, the plugin uses the specified Client Certificate during its TLS handshake with the etcd cluster. This generally only works if the remote etcd nodes are expecting mutual TLS.
If you specify Both for your Authentication method, then the plugin sends the client certificate and the username and password. It's a belt-and-suspenders proposition.
Backing up All Keys
The default configuration of the etcd backup plugin is to protect all keys and values found.
You dont' have to do anything — just make sure to leave the Prefix parameter blank (its default value)!
Backing up Some Keys
If you only want to back up a subset of the etcd key-value hierarchy, specify the uppermost root your are interested in via the Prefix parameter. This will cause the etcd plugin to only traverse that part of the hierarchy.
Note: this parameter has no bearing on restores; SHIELD will restore all keys found in the snapshot archive, regardless of what you set for Prefix.
Restoring etcd from a Snapshot
etcd SHIELD snapshots consist of serialized key-value records, a format that is specific to this plugin. These are read in and replayed during restore operations.
It is worth noting that this plugin will restore whatever keys are in the snapshot! If you snapshot all of the keys (via an empty Prefix), and then reconfigure the data system to specify a key prefix, the archive created Before the reconfiguration will still have all keys.
This section details all available configuration parameters for the etcd data protection plugin.
- The client URL(s) of the etcd cluster.
- Connection Timeout
- The timeout for failing to establish a connection. Enter time in seconds.
- Type of authentication for accessing the cluster. No authentication is done if left blank.
- Username for role based authentication.
- Password for role based authentication.
- Client Certificate
- Certificate issued by the CA in pem format for the client connecting to the cluster.
- Client Private Key
- Key issued by the CA in pem format for the client connecting to the cluster.
- CA Certificate
- CA certificate in pem format that issued the client cert and key.
- If this is enabled, only keys mentioned in the 'Prefix' field will be deleted. The values will be restored using the backup archive.
- This is the input string for prefix based backup-restore.