Backups

Docker Manager backs up your stacks (their folder and volumes), your other volumes and its own state, Docker Manager State: its database and settings. Backups are encrypted and stored in a repository on S3-compatible storage. The owner adds the first repository; after that, people with the “Manage Backup Repositories” permission can add more. Only the owner handles the Recovery Key. People with permission choose what is backed up.

1. Add a repositoryCopy Anchor Link

1. Open Backups and press Add Repository.
2. Enter a Name, the Endpoint, Bucket, Access Key ID and Secret Access Key. Any S3-compatible storage works, such as AWS S3, Backblaze B2 or MinIO on your network, but not loopback or link-local addresses such as localhost. Pick storage away from Docker Manager's server, such as a cloud bucket: if you lose that server, you lose its backups too.
3. Choose the Compression. Automatic suits most data.
4. Press Save and Continue. Docker Manager tests the connection right away. If the test fails, press Back, correct the details and press Save and Continue again.
5. Press Next. The first time, Docker Manager shows your Recovery Key. Copy or download it, store it outside Docker Manager, check I stored the Recovery Key somewhere safe and press Continue.
6. Paste the key, check I Saved the Recovery Key Outside Docker Manager and press Confirm Recovery Key. Later repositories use the same key and ask you to type it again.

If you leave with details you haven't saved, or before you stored the Recovery Key (step 5), Docker Manager asks first. Until the key is confirmed, nothing is stored in the repository. Open the repository to confirm the key, to change its endpoint, bucket or prefix (More Actions (⋯) → Edit Repository), or to press Generate New Key if you didn't save the first one.

2. Choose what to back upCopy Anchor Link

1. On Backups, press Edit Backups.
2. What to Back Up: every environment, stack and volume is included, also the ones you add later. Uncheck what to leave out. A long list has a filter: type part of a name, then Exclude Shown leaves out every match. Docker Manager State is always backed up.
3. Stop Containers During Backups is on: each stack stops while it is backed up and starts again right after, one stack at a time. Containers outside stacks keep running. Turn it off to keep everything running; databases copied live may not restore cleanly. If a stack does not start again, the next stacks are backed up without stopping them until it runs again.
4. Repositories: every backup goes to the Primary Repository (the first one you added), and a second, independent copy to the Secondary Repository if you pick one.
5. Schedule: turn on Back Up Automatically and pick when.
6. Retention: how many backups to keep; 7 Daily, 4 Weekly, 12 Monthly (Recommended) is a good start. The newest complete backup of each stack and volume is kept, also when newer backups were only partly saved. Turn on Remove Backups of Deleted Stacks and Volumes to remove their backups the number of days under Remove Them After after Docker Manager notices the deletion; the newest backup of a volume that still exists stays. On an environment whose Docker Agent is older than Docker Manager, the newest backups stay only as the rules decide until you upgrade its Docker Agent.
7. To check, press Preview What Gets Backed Up (Preview What Gets Backed Up and Stopped while containers stop): each stack and volume with its estimated size, why each path is included or left out, the volumes under Not Backed Up, and which containers stop.
8. Press Save Changes.

Every volume is backed up once: with the stack that uses it, or on its own. Volumes of Compose projects Docker Manager doesn't manage, and volumes kept after you deleted a stack, are backed up on their own (except a volume that stores a backup repository: see What is not backed up). A volume two stacks use is backed up with one of them, never with one you left out. A stack's folder is backed up as it is, also with changes not deployed yet, files with errors, or when it was never deployed; a stack's folder inside another one is backed up only with its own stack. On an environment whose Docker Agent is older than Docker Manager:

• a stack's volume that none of its containers use (for example while the stack is down) is backed up on its own;
• a volume a stack's Compose file names as external, while another stack uses it or it is backed up on its own, can be backed up twice when that stack also uses a named volume created outside it, or when the server has more than 256 volumes;
• a volume you uncheck can still be backed up with a running stack whose Compose file names it while none of the stack's containers use it, when that stack also uses a named volume created outside it;
• a stack whose Compose file can't be read isn't backed up until you upgrade the environment's Docker Agent;
• a stack that serves the storage of a backup repository is still copied into it, and a stack serving another repository may be stopped.

If a stack's folder is missing, its volumes are still backed up and it shows Partly Backed Up; with nothing else to back up, its backup fails. A stack's or volume's Backups tab and the stack's Settings tab say whether it is covered, why not, and how its last backup went (the worse result when it goes to two repositories). While its server can't be asked, they decide from the backup settings and say so.

On Backups:

• Back Up Now runs a backup right away; Retry Missing backs up only what failed. A volume that became part of a stack after the run can't be added by Retry Missing when the run already backed up that stack: the run names it, and the next backup holds it with its stack. A volume that left a stack after the run is backed up on its own when Retry Missing backs that stack up again.
• Running Now shows each running backup with the stack or volume it is on, that item's progress and time left. To stop one, press Cancel on its line, then Cancel Backup. What it already backed up is kept, the rest waits for Retry Missing, and containers it stopped start again. Each server's backup is cancelled on its own.
• Last Complete Run is the newest run that backed up everything, also when the runs after it were partial. A run's size is the data it backed up, counted once although it goes to two repositories, also when only the Secondary repository got a copy. With access to only some of a run's backups, it counts those.
• Stored and Storage show what the repositories hold after deduplication and compression, measured after every backup and retention; they say how old the oldest measurement is and how many locations aren't measured yet (those aren't counted). Storage two repositories reach at different addresses counts once.
• All Backups and a stack's or volume's Backups tab list up to the newest 10,000 backups; All Backups groups them by run and leaves out a run whose older backups didn't fit.
• Details on a run under Recent Runs shows what failed and why, then each stack and volume with the repositories it is stored in, whether it is a Live Copy or Containers Stopped, and why it was copied live. Partly Backed Up means some of its data was left out; the notes below it say what. All Runs lists every run in Jobs; Partial or Failed Runs opens the ones that went wrong, also runs in which a stack or volume was only partly backed up.
• To clean up now, choose More Backup Actions (⋯) → Apply Retention Now, check which backups go and confirm with Remove N Backups. If you cancel it under Running Now, backups it already removed stay removed and the next retention frees the rest of the space; Docker Manager doesn't go on with the rest after a cancel. If it can't start for one environment, the others still run. One run removes at most 1,000 backups per repository and environment (or Docker Manager State); Docker Manager goes on with the rest right after. If that environment's Docker Agent is older than Docker Manager, a retention with more than that to remove there removes nothing until you upgrade Docker Agent, and the check before you confirm keeps all of its backups.
• After Docker Manager was restored from a backup, Backups Paused After the Restore shows until you press Resume Backups: no backup, retention or verification runs meanwhile, Back Up Now, Retry Missing, Apply Retention Now and a backup's Verify aren't offered until then, and Next Run says Paused, as do the backup and verification schedules under Schedules (their details list the Next Runs Once Resumed), and a stack's Backups card on Settings says the backups are paused. Only a restore you start still backs up the data it replaces first, unless you turn off Back Up the Current Data First.

Good to know:

• To change the roles, choose Make Primary, Make Secondary or Stop Using as Secondary in the menu (⋯) of a repository's row under Repositories, or on its page. Making the Secondary the Primary swaps the two. Docker Manager asks first when a choice leaves another repository without a role. While backups are on, a repository takes a role only once its Recovery Key is confirmed. While no repository is the Primary, Backups says Backups Paused, with a button that makes the only ready repository the Primary (or Edit Backups to choose one), a repository's page offers Make Primary at the top, and an empty list of backups offers Edit Backups.
• Each repository needs its own storage: Docker Manager refuses a repository at the same address, bucket and prefix as another one, and a Secondary on the Primary's storage, which would be no independent copy. It can't tell the same storage reached at another address (another host name, or its IP address) from a copy of it: when backups are then no longer found, the alert says the other repository holds the same backups. If it is the same storage, keep only one of the two.
• To check a repository for damage, open it, press Edit Schedule and turn on Verify Automatically (Sundays at 04:23 UTC unless you change it). Its page shows Last Verified; under Advanced, each location shows whether its check read data (Data Read) or only the structure (Structure Checked). Backups wait while a repository is verified.
• A backup that a check (a verification or a retention) doesn't find in its repository, for example after a bucket rule deleted it, shows Not Found at Last Check: a restore of it may fail, and the current data then stays. If the next check doesn't find it either, it is removed from the list, and an alert says how many backups of which environment and repository were removed.
• When a check doesn't find most backups of an environment in a repository (more than 20 and more than half), the repository may point at the wrong storage, so nothing is removed from the list: those backups show Not Found at Last Check, the repository's page says many backups were not found, and an alert asks you to check the repository's endpoint, bucket and prefix and the bucket's rules. Backups that are still not found two weeks later are removed from the list, and the alert about removed backups counts them. The alert ends once a later check no longer misses most of them.
• Backups of an archived or removed environment are still verified with their repository and follow retention, but never count as deleted.
• Removing the Primary repository makes the Secondary the Primary. Without a Secondary, backups pause and an alert says so until you make another repository the Primary.
• Backups in a repository that is no longer the Primary or Secondary stay: you can still browse and restore them, and Apply Retention Now covers them too.
• Back Up Now by someone other than the owner leaves Docker Manager State out; scheduled backups always include it.
• With Stop Containers During Backups on, each container gets at least a minute to stop, paused containers are paused again afterwards, and with a Secondary repository each stack stops once for each copy. A stack that serves the storage of any of your backup repositories (such as MinIO on the same server) and Docker Manager's own stack keep running and are copied live. If a stack can't be started again right after its backup, the Docker Agent tries again at the end of the run, and keeps trying for 7 days. The run says what was started then and names any service it left as it is because it was started, stopped or removed since. A run whose stacks all start again before it ends is not shown as failed; one with a stack that still can't be started then is, even if a later try starts it. It stops only containers it starts again, never starts a container someone started or stopped since, waits while Docker Manager restores, moves or exports that stack, and stopping, starting or taking down the stack, one of its services or one of its containers in Docker Manager ends it for what that covers. If the containers that ran when a stack's backup began were replaced or stopped since, it stops nothing and copies the stack as it is. If the Docker Agent stops while a container is still stopping, it waits for that stop to finish before it starts the stack again.
• An environment that is offline when a backup starts gets an hour to come back, one that goes offline during the backup six hours; time Docker Manager itself isn't running doesn't count for either. After that its part fails and Retry Missing backs it up. If its previous backup is still running, it is backed up with the next run.

What is not backed upCopy Anchor Link

• Docker Manager's own data: its database is in Docker Manager State.
• Folders and secret or config files a stack mounts from outside its own folder, such as /srv/media:/media, unless you allow them. With Back Up Allowed Folders Outside Stacks on, those of a stack that has no containers and that the Docker Agent never saw deployed or running (such as one never deployed, or one taken down before the Docker Agent was upgraded) can't be known until you deploy or start it again; its backups say so.
• Data that stores a backup repository, such as the folder or volume MinIO keeps its data in on the same server, is not copied into that repository, or every backup would copy the repository into itself. Only your other repositories, if any, hold it; without one, nothing does. Docker Manager leaves out exactly what that storage writes to, whichever stack, docker run container or other Compose project it belongs to. The rest of the stack, with its Compose files and other data, is still backed up; a stack that serves the repository is never stopped. When that storage covers everything a stack holds (for example a broad folder it mounts), nothing of the stack is copied into that repository, and its Backups tab says so. Docker Manager leaves data out only when it is sure: the repository's address names the container (its name, network alias, service or address), or the container publishes the repository's port there and the address is localhost, a loopback address, host.docker.internal or the one address it publishes the port on; a folder or volume holds the repository's bucket, as MinIO keeps it; or the storage went away while the stack was stopped for a backup (that backup of the stack fails once, and Retry Missing backs it up). Preview What Gets Backed Up in Edit Backups shows what is left out and why (a stack's path as Left Out of the Primary Repository, a volume under Not Backed Up). The volume list of Edit Backups and the volume's Backups tab say which repository leaves a volume out, or Not Backed Up when no repository backs it up; the stack's Backups and Settings tabs say which repository its data is left out of. Check there that your storage is recognized. Leaving it out is no failure: the backup's result lists it as left out without turning into a warning, and it never counts as a missed complete backup.
• A stack or volume whose containers only publish the repository's port while the address is another address of your network, such as a reverse proxy, is backed up as usual, and backups never stop such a stack. Its backups and the preview carry a note that it may serve the repository; it is never marked as left out.
• Anonymous volumes (Docker names them with 64 hexadecimal characters), unless you turn on Back Up Anonymous Volumes. With it on, a stopped stack's anonymous volumes are backed up too.
• buildx builder volumes, unless you turn on Back Up buildx Builder Volumes.
• GitLab Runner cache volumes (labels com.gitlab.gitlab-runner.managed=true and com.gitlab.gitlab-runner.type=cache), unless you turn on Back Up GitLab Runner Cache Volumes.
• Volumes with the label docker-manager.backup.exclude=true, and the volumes of a container with that label, also while its stack is down.
• Volumes a migration is still copying, until it has finished.
• Volumes that keep their data in memory (tmpfs).
• Volumes Docker Manager can't read: those of other drivers or on remote storage such as NFS, and those Docker mounts from a device. They show as Can't Be Backed Up. A volume that keeps its data in a server folder (o=bind) is backed up from that folder once you allow the folder on the agent (step 1 of Back up folders outside a stack). A folder inside the stacks folder needs no allowing. A volume whose folder lies in its own stack's folder is backed up with that folder. Such a volume shows Can't Be Backed Up when its folder overlaps another stack's folder or another volume's folder, or, with Back Up Allowed Folders Outside Stacks on, a folder outside a stack that a stack uses; the reason says why. When a folder that is backed up holds it, its files are still in that folder's backup. This also applies to a volume you uncheck, or that has the exclude label, whose server folder is its stack's folder itself. The volume's Backups tab and its (i) in Edit Backups then name the stack whose backups hold its files. A volume that can't be backed up is named in the run, and every backup of its stack ends Partly Backed Up (every backup run, for a volume no stack uses), until you uncheck it in Edit Backups.

In Edit Backups, volumes with the label, volumes a migration is still copying and volumes kept in memory show unchecked and can't be checked; the (i) next to them says why. A volume that can't be backed up shows checked, its (i) saying why: uncheck it to leave it out.

Docker never changes the labels of a volume that already exists. If you add the label to a volume in a stack's compose.yaml later, deploy the stack: its backups then leave the volume out, although Docker still shows the volume without the label. Set the label to "false" to back it up again.

Back up folders outside a stackCopy Anchor Link

A stack can mount a folder of the server from outside its own folder, such as /srv/media, or use a secret or config file from there. To back it up:

1. Allow the folder on that server's agent: mount it at the same path and list it in DOCKER_AGENT_BACKUP_EXTERNAL_ALLOWLIST (several folders separated by commas).

   Copy Text

   services:
     docker-agent:
       environment:
         # ...keep the existing lines...
         DOCKER_AGENT_BACKUP_EXTERNAL_ALLOWLIST: /srv/media
       volumes:
         # ...keep the existing lines...
         - /srv/media:/srv/media

2. On Backups, press Edit Backups and turn on Back Up Allowed Folders Outside Stacks.

System folders such as /proc or /dev and everything inside them, Docker's own data folder, and folders that contain it, the stacks folder or the Docker Agent's data are never backed up. A folder you allow but didn't mount shows "not mounted into the Docker Agent" in the preview.

RestoreCopy Anchor Link

Restore from a stack's or volume's Backups tab, from a backup run, or from a backup's page. Restores need the environment to be online and its Docker Agent at Docker Manager's version. Containers that use the data stop during the restore; those that were running start again afterwards. While a stack is being restored, it shows Restoring From a Backup and offers no deploy, start or stop, also not in its file editor. Until the restore ends, the file manager can't change files of a volume being restored or of a stack the restore uses (also when it restores only one of the stack's volumes, or data the stack uses), and Restore to Disk on the stack's revisions is refused. A restore doesn't start while the file manager is still saving or uploading into what it restores: wait until that finishes, then restore again. The data is restored next to the original first; if anything fails before it is in place, the original data is put back.

Every restore offers Back Up the Current Data First (on by default): the data the restore replaces is backed up into the same repository first, so Undo Restore can put it back. The containers stay stopped a little longer. That backup is kept for 1 day, or as many days (up to 90) as you set under Undo Restore → Keep Them For in Edit Backups; a change applies to those already taken too. Once its time is up it is removed within the hour, also when retention is off; while backups are paused after Docker Manager was restored, within the hour after you press Resume Backups. It shows as Before Restore, with the date it is kept until (Removed soon once that date has passed, or Removed After Resume while backups are paused), on the stack's or volume's Backups tab and on its own page, and never counts as a backup run. When nothing is there yet to back up (for example a volume that was removed since), nothing is backed up first, and the restore shows that it can't be undone before you confirm.

On a stack's or volume's Backups tab, each backup is listed once for every repository it is stored in (Stored In); pick either.

• Restore Everything puts back everything the backup holds: for a stack, its folder, all its volumes and its folders outside the stack. Leave Deploy … Afterwards on to deploy the stack from the restored files, type the name and press Restore Everything.
• Choose Files restores only the files or folders you pick. A folder you pick is made exactly like it was in the backup: newer files in it are removed.

To restore from a backup run:

1. Open Backups → Backups and press Restore on the run (or in its Details).
2. Search for the stack or volume and, if it is stored in more than one repository, pick one. A copy that the last check didn't find says Not Found at Last Check; a copy that was found is picked first.
3. Press Choose Files or Restore Everything on its line. For one volume of a stack, press Restore on that volume's line, or pick its files with the stack's Choose Files. A stack that was deleted has Restore instead, which opens its backup's restore page with Restore Into.

Restore from a backup's pageCopy Anchor Link

A backup's page has Choose Files, as above, and Restore:

1. Open a backup by its date and press Restore.
2. Choose Everything, Choose Parts or Chosen Files.
   • Choose Parts: check what to put back: Stack Folder, each volume, each folder outside the stack, in any combination.
   • Chosen Files: press Choose Files, check the files and folders and press Choose Files, or type the path of one file into Or Type the Path of One File.
   • When the backup's stack was deleted, choose the stack to restore into under Restore Into, or press Create Stack first. Chosen files of its folder need it too; its volumes alone don't. If you come back while such a restore runs, choose the same stack again to follow it. A stack moved to another environment since is restored where it is now.
3. Leave Deploy … Afterwards on to deploy the stack from the restored folder. It starts the services that were running before and that the restored Compose file still runs; the result names the ones it left out. A stack that was not running, or none of whose running services the restored file still runs, is deployed whole. If the stack's files in the backup were never deployed as they are, check Deploy Them Anyway to deploy them, or turn the switch off.
4. Press Review, then Next, type the name and press Restore Now.

The result says what happened: restored (and what became of deploying the stack afterwards), restored but some containers may not have started again, or not restored. If Docker Manager can't find out whether the restored or the original data is in place, it says Result Unknown: check the data before you use it. Undo Restore puts back the data the restore replaced, as long as its Before Restore backup is kept. After a restore of chosen files it puts back only those files and folders; one the restore created where there was none stays, so remove it in the file manager. If nothing was changed, Open Job shows what went wrong and Start Over goes back to the first step with your choices kept. You can also press Undo Restore on the restore's job page.

Good to know:

• Cancelling a restore stops it only before the restored data is in place. After that the restore finishes; use Undo Restore instead.
• If a folder the restore was going to create appears while it prepares (for example a folder you create during a long restore), the restore stops before changing anything, so what appeared is never deleted. Check it and restore again.
• Archiving an environment while a restore runs there stops the restore. If nothing was changed yet, the result says Restore Stopped and the stack isn't deployed afterwards.
• If you start another restore of the same stack that puts back its folder or files in it (such as Undo Restore) before the first one deployed the stack, the first restore waits for it. If the later restore put the files back (or may have changed them), the first one no longer deploys the stack, and its result says so. A later restore of volumes only, or one that was cancelled or changed nothing, doesn't stop the deploy.
• A restore needs the permissions to stop and start every stack and container it stops.
• A restore never stops a stack that serves the storage of one of your backup repositories (such as MinIO on the same server), recognized as for backups: the review names it and the restore can't start. The same holds for a container started on its own (docker run). Stop it yourself first, then restore from a repository it doesn't serve. A stack that only may serve it, such as a reverse proxy, is stopped as usual and the review warns. If it serves the storage of the repository you restore from, the restore fails and puts everything back as it was. If it serves another repository's storage, the restore goes on, but backups and restores that use that repository may fail while the stack is stopped.
• A restore never writes into the storage of the repository it restores from: a folder or volume that lies there can't be restored from that repository (restore it from another one), and such storage inside what you restore is kept as it is; the review says so.
• While a restore runs, other stacks that use the restored data can't be started, restarted or deployed either, even when they are stopped or Down.
• A backup Docker Manager found in the repository without its record lists no volumes: Everything leaves them out (the review lists them under Not Restored); restore their files with Chosen Files. A Before Restore backup found that way lists the volumes whose whole data it holds. A Before Restore backup that holds only chosen files offers only Chosen Files.
• Anonymous volumes are restored into the ones the stack's containers use now: deploy the stack first if it has none.
• Folders of other stacks inside the stack's folder stay as they are in every restore of it, also when you choose a folder that holds one (the review shows them as Kept as it is). Restore files inside them from those stacks' own backups. So do folders that hold a Compose project the backup doesn't have (for example a stack created or renamed there since, or a Compose project that has containers, whatever its Compose file is called) and folders where a failed restore left the original data. A Compose project not imported as a stack is part of the stack's backups and is restored with its folder.
• Two parts of a backup that would go into the same volume or folder can't both be restored: choose one of them. A part that would go inside another one must be restored on its own.
• A backup that could not read some files when it was taken doesn't hold them, so a restore removes their current copies (the review counts them as removed). Keep Back Up the Current Data First on to be able to undo it. Everything lists the parts a backup left out (a volume that couldn't be backed up, a missing stack folder) under Not Restored. A volume that couldn't be backed up on its own isn't restored as a volume; when its files lie in the stack's folder or a folder outside it, the review says whether they come back with that folder or are kept as they are.
• Folders outside the stack are restored only where the Docker Agent still allows them (see Back up folders outside a stack), and never through a symlink: a folder outside the stack, a volume's server folder, the stack's folder, or a volume's data folder that now leads somewhere else through a link can't be restored. A folder outside the stack that was deleted is created again, as long as a folder above it, inside the allowed folder, is still on a folder mounted into the Docker Agent. A file outside the stack (such as a config file the stack mounts) is restored too, when its folder is allowed.
• A folder with another filesystem mounted inside it (a network share or a second disk) can't be restored whole: restore the files beside it with Chosen Files (for a folder outside the stack, download them instead), or unmount it first. Files that lie inside such a mount can't be restored into it either: download them instead.
• A volume that keeps its data in a server folder (o=bind) is restored into that folder, where the Docker Agent may read it for backups. When that folder lies in the stack's folder, the volume is restored with the stack's folder, also when the volume was removed since (for example with the stack): deploy the stack to create it again. Undo Restore puts it back with the folder. When you restore the stack's folder without such a volume and its folder no longer exists, the review says the folder comes back without that volume's data. When you restore the stack's folder without such a volume, or a volume that lies there without being the stack's own, its folder stays as it is (the review shows it as Kept as it is), also for a volume created after the backup. A volume that holds another volume's folder or a stack's folder (also the folder of a stack that is down) can't be restored whole: restore the files beside them with Chosen Files. A folder outside the stack keeps such folders as they are (Kept as it is). The exception is the folder of a volume shown as Can't Be Backed Up because it lies in that folder outside the stack: that volume's data is only in this backup, so it is restored with the folder, the review names it and its containers stop, unless its folder now lies in a folder the restore keeps as it is: then the review lists it under Not Restored. Restoring it needs the “Restore Backups” permission on that volume too. Such a volume can't be restored on its own. A volume whose folder now lies in a folder the stack's restore keeps as it is (another stack's folder, another volume's folder, or a Compose project created there since) can't be restored together with the stack's folder: restore it on its own, or leave it out. A backup made by an older Docker Agent can't restore such a volume: restore it from a newer backup.
• Other volumes that keep their data elsewhere through driver options can't be restored: download their files from the backup instead.
• A container started with --rm that uses the data must be stopped first.
• If a failed restore can't put the original data back, its containers stay stopped and an alert is raised; the restore's job says where the original data is.
• If a restore was interrupted before Docker Manager learned its result, Undo Restore is offered only once the Docker Agent confirms that its Before Restore backup read every file. A Before Restore backup found in the repository without that confirmation shows May Be Incomplete, and restoring it removes the current copies of files it lacks. So does one a failed or cancelled restore left behind, once a verification of its repository finds it; like every Before Restore backup it is removed once its keep time is up. Until a verification finds it, it stays in the repository: with Verify Automatically off, press Verify on a backup of the same environment in that repository to find it (once backups aren't paused after a restore of Docker Manager).

Recover Docker ManagerCopy Anchor Link

If you lost Docker Manager's server, you can bring Docker Manager back from a backup of Docker Manager State. It is restored only this way, on a new Docker Manager, never over a running one. You need the repository's details and your Recovery Key.

1. Install Docker Manager again as in the Quickstart.
2. On the setup page, press Import From Backup instead of creating an account.
3. Enter where the backups are and your Recovery Key, and press Check Access.
4. Press Show Backups, pick one and press Next.
5. Check Replace Docker Manager's state with the backup and restart and press Import and Restart.
6. Sign in with your old owner account.
7. Re-attach each environment, then press Resume Backups on Backups. Backups stay paused until you do, so this copy doesn't back up, apply retention or verify in the same repositories as an old Docker Manager that may still run. A restore you start meanwhile still backs up the data it replaces there first, unless you turn off Back Up the Current Data First.

Create new API tokens: the old ones were revoked. Invite links, password reset links and install commands from before the restore stop working too.

Good to know:

• The newest Recovery Key opens older backups too, unless Docker Manager's secret key file was replaced since; then also enter the key that was current when the backup was taken, under Previous Recovery Key.
• A backup whose run record is missing can still be chosen: its environments' backups are listed from their repositories.
• Charts history comes back if Include the Metrics Database was on. If its metrics database can't be used, the alert about the paused backups says why.
• Jobs and migrations that were still running when the backup was taken have ended; the restored Docker Manager doesn't continue them. If a Docker Agent still runs a job when you re-attach its environment, also one the old Docker Manager started after the backup, Docker Manager stops it. What the job did is recorded on the job, or in the audit log for a job the backup doesn't know.
• If the restart can't apply the backup, Docker Manager starts without it and tries again at the next restart, but not once you have created an account instead.
• If you set DOCKER_MANAGER_SECRET_KEY_FILE to a file mounted on its own or read-only, mount its folder writable instead: the import replaces that file.