Olivier Le Moal - Fotolia
5 important Docker container backup best practices
With container storage a major trend, it's important to ensure data protection. These five guidelines will help you properly back up Docker containers.
Container backup best practices vary depending on which product you use. Docker Enterprise, in particular, has a laundry list of best practices that you should follow.
One Docker container backup best practice is to keep track of version numbers. Docker requires that Universal Control Plane (UCP), Docker Trusted Registry (DTR) and Engine versions all match. As such, you can cause problems if you restore a backup of an older component. For example, if you restore a DTR backup that was created when your cluster ran a different version of the software than the one in use, then the restoration introduces a version mismatch and doesn't cooperate.
Another Docker container backup best practice is to periodically back up a single manager node. Don't worry about backing up all of your manager nodes, because each one includes the same Docker Swarm and UCP data. Although you are only required to back up one manager node, you must keep track of which node it is that you are backing up. If you ever need to restore the backup, the restoration must be to a node with an IP address that matches the node you backed up.
The backup process has a visible effect on UCP. Any time that you perform either a Swarm or a UCP backup, the UCP user interface displays a warning. This occurs because the UCP manager pauses during the backup. Therefore, you must consider how the Docker container backup process affects manager availability before you begin a backup. Docker recommends that you provision clusters with five managers, so that when a manager stops as a result of the backup process, the cluster can continue to function without a disruption in service.
Back everything up separately. Docker requires that you use separate backups for each component, including Swarm, UCP and DTR. These component-level backups do not back up any application data, so you must deal with application data separately.
Finally, if you use a highly available deployment, you should only restore a node backup as an absolute last resort. If you suffer a catastrophic node failure, Docker recommends that you remove the unhealthy nodes and replace those nodes with new ones. This Docker container backup best practice enables you to return the cluster to a healthy state without performing a node-level restoration.
