Anonymised case study based on real work. Client details are withheld; no figures are claimed beyond what the systems showed.
The situation
A business email service ran its own mail platform on a single virtual private server: an open-source, container-based mail suite (SMTP, IMAP, webmail, spam filtering, admin console) plus a small one-time-password API used by its sign-in flows. The server had pending operating system and kernel updates. Mail is noticed only when it stops, so the update had to change nothing visible.
The approach
1. Record a baseline before touching anything. We captured the list of running containers and their health status, every listening port, which services answered from the public internet, and the state of the websites on the server. Twelve containers were running, eight of them with health checks reporting healthy.
2. Confirm the restart behaviour. Every container was set to restart automatically, so a reboot should bring the stack back without manual steps. Verifying this before the reboot removed the biggest risk.
3. Update and reboot. Operating system packages and the kernel were updated, then the server was rebooted into the new kernel.
4. Compare against the baseline. After the reboot we checked that all twelve containers were running, the same eight reported healthy, the same ports were listening, the same services were reachable from outside, and the webmail and admin pages loaded and redirected to login as before.
5. Take a full backup with integrity checks. A complete archive of the mail data and system configuration was created on the server, downloaded to the owner's machine, verified with a SHA-256 checksum and only then removed from the server.
The outcome
The platform came back on the new kernel matching the pre-update baseline, with no failed services and no pending updates. The owner now has a dated, verified full backup stored off the server and a written baseline to compare against next time.
FAQ
Does a mail server need downtime for updates? A reboot causes a short interruption; with containers set to restart automatically, it is typically brief.
I take on a small number of advisory and hands-on systems engagements each quarter. Connect at virender.in.