Olivier Le Moal - Fotolia
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.
Containers and containerized applications require backup, thanks to the persistent and often important nature of their data. With newer technologies, such as Kubernetes, this can be a complex process.
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.
Dig Deeper on Data storage backup tools
Related Q&A from Brien Posey
While only a small number of hardware vendors offer DPUs, the technology has significant implications for IT storage systems -- and the admins who ... Continue Reading
Microsoft 365 is a widely used service, but its many different applications make backup complicated. Watch out for these common roadblocks. Continue Reading
A ransomware attack on cloud storage can have catastrophic effects. Cloud storage is still online, which means it is susceptible to some cyberattacks... Continue Reading