Skip to content

Restore Mideye Fleet and Mideye Server after losing the server

The host of a Docker quickstart is gone: the disk died, the VM was deleted, the data center burned. This page brings Mideye Server and Mideye Fleet back on a new host from a backup. The Windows computers keep their enrolment and connect to the new host by themselves. Nothing is done on the computers.

Tested on 2026-10-30 with Fleet 0.26.1, Mideye Server 6.6.11 and a Windows computer with endpoint 0.24.50: the old VM was deleted, a new Ubuntu 24.04 VM was built, the backup restored. The computer checked in with the new host within seconds (same IP address) and within 4 minutes of the DNS change (new IP address).

Also see: Docker upgrade and Reset root or an admin.

A restore needs four things that must not live only on the host. Do this today:

WhatWhere it isWhat you do
The backup files/opt/mideye/backups/ on the host. A backup runs every day at 02:00. BACKUP_KEEP in .env (default 14) is how many stay.Copy them off the host every day: to a warm standby (SYNC_TARGET in .env), or with your own backup software.
The backup passphrasePrinted once by install-docker.sh. A copy is in /opt/mideye/.backup-passphrase (root only), which is lost with the host.Keep it in your password manager. Without it a backup cannot be opened by anyone, Mideye included.
The quickstart bundle of your versionThe portal’s install line always installs the newest release. A restore needs the same release as the backup.Each time you install or upgrade, also download mideye-quickstart-<version>.tar.gz from the portal (Fleet tab, Docker section) and keep it with the backups.
The DNS namePUBLIC_HOSTNAME in .env, for example mideye.example.com. The computers know Fleet by this name and trust its certificate for this name.Keep the name for good. A short TTL (5 minutes) on its DNS record makes a move to a new IP address fast.

Keep the backup files and the passphrase in different places. A backup holds .env (Mideye Server’s root password, the AD bind password, the Mideye Cloud secret) and Fleet’s keys. A backup together with its passphrase is the whole installation.

A snapshot or backup of the whole VM, from your hypervisor, is a good second layer. It does not replace mideye backup: a VM image taken while the database writes may not start cleanly, and it is as large as the disk.

KeptWhy it matters
Fleet’s certificate authorities (fleet/pki, fleet/node-ca), signing key and data keyThe computers trust Fleet’s certificate authority. The same one comes back, so they trust the new host.
The Fleet database: computers and their enrolments, groups, policies, administrators, Mideye Server records, audit trailComputers stay enrolled; no new onboarding. Root signs in with the same password and authenticator.
The Mideye Server database: users, tokens, LDAP profile, RADIUS clients, settingsUsers keep their tokens and sign in as before.
mideyeserver/ (application-prod.yml, keystore.p12)Mideye Server’s identity and the key of its data.
bootstrap/ (provisioning tokens, the setup’s “done” mark)Fleet keeps talking to Mideye Server.
.envYour settings and the image versions.

Not in it: logs, the endpoint installer copy (fetched again at start), the passphrase file, the standby sync key in .ssh/ (run sudo mideye standby-key again on the new host), the registry login, and anything you added to the host yourself (firewall rules, monitoring, an AD_CA_FILE such as /opt/mideye/ad-ca.cer: copy that file off the host too).

Lost: everything that happened after the backup. A computer enrolled after it must enrol again. A computer you revoked after it is valid again, and an administrator you disabled after it is enabled again: do those again after the restore (see step 8).

The simplest way. The new host gets the old host’s IP address and DNS name. Nothing changes for the computers.

1. Old host: if it still runs at all, stop it: cd /opt/mideye && sudo docker compose down. Two hosts with the same identity must never run at once.

2. New host: Ubuntu 24.04 LTS with the same IP address and the same requirements as the old one. Install Docker:

Terminal window
sudo apt-get install -y docker.io docker-compose-v2

3. New host: run the docker login line from the portal, as in quickstart step 3.

4. New host: install the same release as the backup, and start nothing.

  • The backup is of the release the portal offers now: the portal’s install line, as in quickstart step 4.
  • An older release: the bundle you kept. Unpack it and run its install-docker.sh with the registry, the portal and the Mideye Server version from the portal’s Docker section:
Terminal window
mkdir bundle && tar -xzf mideye-quickstart-<version>.tar.gz --strip-components=1 -C bundle
sudo MIDEYE_ACR=<registry> MIDEYE_PORTAL_URL=https://downloads.mideye.com MIDEYE_VERSION=<Mideye Server version> bash bundle/install-docker.sh

You should see Mideye quickstart written to /opt/mideye. Do not edit .env and do not run docker compose up. It printed a new backup passphrase and new setup values: ignore them, the restore brings back the old ones.

5. New host: put the old passphrase in place (from your password manager). Paste it, press Enter, then Ctrl-D:

Terminal window
sudo sh -c 'umask 077; cat > /opt/mideye/.backup-passphrase'

6. New host: copy the newest backup file into /opt/mideye/backups/, then restore and start:

Terminal window
sudo install -m 0600 mideye-backup-<host>-<time>.tar.enc /opt/mideye/backups/
sudo mideye restore latest
cd /opt/mideye && sudo docker compose up -d

Success: Restored from /opt/mideye/backups/mideye-backup-....tar.enc. After up -d, sudo docker compose ps shows db and mideyeserver healthy, fleet up, and mideye-setup exited with 0.

restore refuses, and changes nothing, when:

MessageFix
backup ... was made with other image versions (FLEET_IMAGE: ..., this host: ...)The installed release is not the backup’s. Remove /opt/mideye, install the release the message names (step 4), go on with step 5.
cannot decrypt or does not match this installation's key checkThe passphrase in /opt/mideye/.backup-passphrase is not the one of this backup. Put the right one in place (step 5).
... differs from the backup: this host is another installationThis host already runs another installation. Restore into a new install only.

7. Check that the computers are back. With the same IP address they connect at their next check, within about a minute. In Fleet, open Computers: the last contact time of each computer is new.

Fleet, Nodes after the restore: the computer is Managed and was last seen just now.

Or on the host, without signing in:

Terminal window
cd /opt/mideye && sudo docker compose exec -T db sh -c 'MYSQL_PWD="$MARIADB_ROOT_PASSWORD" mariadb -uroot -e "select hostname, state, from_unixtime(last_seen_at/1000) as last_contact from fleet.node"'

8. Fleet: end the restore hold. Fleet starts with a restore hold: the computers check in and get their policies, but they get no secrets (Mideye Server tokens, break-glass codes) until you confirm. First redo what happened after the backup: revoke again the computers you revoked, disable again the administrators you disabled, and make new onboarding tokens (the restore revoked the unused ones). Then sign in as root, open Fleet Server, and choose Confirm revocations replayed.

Fleet, Fleet Server: the restore hold notice and the button Confirm revocations replayed.

Or on the host:

Terminal window
cd /opt/mideye && sudo docker compose exec -T fleet /mideye-fleet-server confirm-restore

Success: restore hold ended: nodes get secrets again (no restart needed).

9. New host: the daily backup timer is already on (systemctl list-timers mideye-backup.timer). Set up the copy off the host again (see Before you need it). Take a backup now: sudo mideye backup.

The same steps, on a host with a new IP address, plus one DNS change. The DNS name (PUBLIC_HOSTNAME) stays the same.

  1. Steps 1 to 6 above, on the new host with its new IP address.
  2. Change the DNS A record of PUBLIC_HOSTNAME to the new IP address, in every DNS the computers use. For computers in the domain that is the AD DNS zone. A second DNS (the router’s, a split-horizon zone for computers off the network) needs the same change.
  3. Wait. Each computer finds the new host when its DNS cache expires: in the test with a TTL of 5 minutes, after 4 and 7 minutes. To speed one computer up: ipconfig /flushdns on it (not needed, not tested).
  4. Steps 7 to 9 above.

Also change what points at the old IP address by number: firewall rules, NAT or port forwards to 9443, 9444 and 8443, and RADIUS clients that send to Mideye Server by IP address.

A new DNS name is a different job. The computers know Fleet only by the name in their onboarding file and trust a certificate for that name. A dead Fleet cannot tell them a new name. With a new name, every computer has to enrol again. Keep the old name and repoint it instead. (Not tested.)

A backup you never restored is a hope, not a backup.

  • Once a year, and after each upgrade: do the steps above on a spare VM, with its network cut off from the computers (or the computers would find it). Check the Mideye Server users and the Fleet computers are there, then delete the VM.
  • Every day, automatically: a warm standby. A second host, installed with install-docker.sh --standby, receives every backup and runs mideye verify on it daily: it opens the backup with the passphrase and checks it, without starting anything. A lost primary is then steps 6 to 9 on the standby. The standby setup is in the Fleet guides in the Mideye downloads portal (login required). (Not part of the 2026-10-30 test.)