How to update Proxmox safely
Typing apt full-upgrade and hoping is not a strategy. What matters is knowing which package restarts a service and which one wants a reboot, and having a way back prepared before the update. This page covers two things: a safe update routine that works on any Proxmox host, and how Atlas turns that routine into a single flow.
Why Proxmox updates feel risky
Kernel updates want a reboot, and a reboot takes every VM and container down with it. An update applied at the wrong hour is an unplanned outage.
A full-upgrade can restart network or storage services in the middle of the day. The apt output does not say which package will trigger what.
If boot breaks, the only way in is the console. Without a snapshot or a backup there is no way back either.
A safe update routine
With or without Atlas, this order works on every Proxmox host:
List pending packages and skim the release notes; plan major version jumps separately.
Classify the effect of each update: no interruption, restarts a service, or requires a reboot.
Take a snapshot or backup first: a ZFS/Btrfs snapshot takes seconds; a PBS backup is even better.
Dry-run first when possible; see what changes before applying anything.
Batch reboot-requiring updates into a maintenance window; watch the first boot.
Verify afterwards: VMs up, storage pools healthy, network in place.
Atlas turns this routine into one flow
Every step above is built into the product:
Three effect groups
Every package arrives labeled with one of three groups: No interruption, Restarts service, Requires reboot. The cost of each click is known in advance.
Dry-run preview
See the change in a dry run before applying it; surprises happen on screen, not on the server.
Snapshot first
The flow takes a restore point before updating; if something goes wrong, the way back is already there.
Boot guard
Kernel pinning and boot guard: a known-good kernel is kept at hand against the unbootable-system scenario.
An update brain
The advisor says what can wait and what should go first; the list arrives ordered to make the decision easy.
Watch keeps an eye on it
Atlas Watch monitors host health continuously; if something critical happens after an update, word arrives at once.
Frequently asked questions
- Is unattended-upgrades safe on Proxmox?
- For security patches, yes. Leaving kernel and Proxmox packages on automatic is risky: a reboot-requiring package can take the VMs down unplanned. Automating the security repo and updating the rest by hand, in a window, is the balanced path.
- Does every Proxmox update require a reboot?
- No. Most packages are non-disruptive; some only restart their own service. Reboots are usually needed for kernel, systemd and microcode updates. What matters is knowing which is which before applying.
- apt upgrade vs apt full-upgrade: what is the difference?
- upgrade never installs new dependencies or removes packages; full-upgrade does both when needed. Proxmox officially expects full-upgrade (or pveupgrade); plain upgrade can leave mixed, half-applied states.
- How do I roll back a broken update?
- With a ZFS/Btrfs snapshot or a PBS backup taken before updating, recovery takes minutes. Without one, it means picking an older kernel in GRUB and downgrading packages by hand. That is why the restore point comes before the update.
- How often should I update Proxmox?
- Do not delay security patches; batch feature updates into weekly or monthly windows. When a critical CVE lands, do not wait for the window.
- Is a major version upgrade (say 8 to 9) different?
- Yes. A major upgrade is its own procedure: the official upgrade guide, a pre-check tool like pve8to9, and a full backup are mandatory. Do not mix it into the routine update flow.
- What are the best practices for Proxmox updates?
- Proxmox update best practices come down to a few things: read what is about to change, snapshot the machines that matter, plan the packages that require a reboot separately, and confirm the system really comes back up after a kernel update. Atlas takes that order on: it classifies what effect each package has, takes the snapshot beforehand, and keeps the way back to the previous kernel open with boot guard.
Related entries
- Before you press update: which update stops what What people who have not updated for months are afraid of is not the update, it is not knowing what will stop. Updates are not one kind of thing and their effects are nothing alike.
- Repositories and the subscription notice: the first surprise after installing On a fresh install the update fails with an authentication error and nothing is broken: the default repository is the paid one. This entry covers the repositories, the real difference between them, and the dangerous one-liner circulating on forums.
- Kernel updates: why the most dangerous update is the quietest one The kernel installs, nothing happens, everything looks normal. The danger arrives at the next boot, and that boot may be weeks away. Weeks come between cause and effect.
- Something broke after the update: "after" and "because of" are not the same A reboot is the first honest test of everything done since the last reboot. Some of what breaks was not introduced by the update, it was already there and had never been exercised.