Skip to content

Backup and Upgrade

A Traefik installation has almost no state, which makes this the shortest honest backup chapter in the series — provided you know which few things are the state.

What to back up

  • The static configuration (traefik.yml or your flags) — small, and the difference between a rebuild and an archaeology project.
  • The dynamic configuration — the watched folder, or wherever your providers' truths live. For Docker users that means the Compose files, including the labels; the running containers are not the record, the files are.
  • Certificates you made yourself — the local CA's key and certificate and any certificates it signed (chapter 7). Losing them is not a security event; it is every device you taught to trust the CA needing to be taught again, and every certificate reissued.
  • The ACME storage file, if you use Let's Encrypt: the account key and issued certificates live in it (a JSON file, acme.json, conventionally locked to permissions 600). Lose it and Traefik simply re-registers and re-issues at next start — a nuisance against rate limits, not a disaster — but keep it anyway; it is also, while it exists, a file containing private keys, and belongs in the backup with the same care as the CA key.

What is not state: the binary (download it again — chapter 3's checksum dance proves a fresh one), and the dashboard's contents, which are a view of the above, recomputed at every start.

A backup you have is therefore a folder of small text files and keys. Copy it whenever the configuration changes; the lab's whole estate fits in an email attachment, and a real one differs only in dignity.

Upgrading

Upgrading Traefik is replacing the binary:

  1. Read the release notes for the target version, specifically for changes to configuration you use. Major-version moves (v2 to v3) renamed and removed things; point releases within v3 are conservative by comparison — which is an observation about the project's habits, not a promise.
  2. Download and checksum the new binary exactly as in chapter 3.
  3. Stop the old, start the new, on the same configuration.
  4. Check: /api/version reports the new build, /api/overview shows zero router errors, and one real request per site you care about answers as before. Then read a screen of log — deprecation warnings announce the next upgrade's breakage while it is still optional.

Keep the old binary until step 4 has passed; rolling back is putting it back, because the configuration never moved. Two habits make this boring, which is the goal: pin versions deliberately (an install that silently follows "latest" upgrades on somebody else's schedule), and never let the version in production drift so far behind that the release notes become a trilogy.

The restore rehearsal

Because the estate is small, rehearse the whole disaster once: a spare folder, the backup copied into it, the binary run against it, the ping answered. The lab's configuration was rebuilt this way in effect at every stage — each chapter restarted from files — which is the quiet reason this guide can claim the files in examples/ are a complete description of the system they ran.