- Separate security updates from feature updates. Security patches can be applied automatically; version upgrades should not be.
apt list --upgradableanddnf check-updateshow you what will change before anything happens.- Take a snapshot or backup before a manual patch run. The rollback path is the part people skip and then need.
- Enable unattended-upgrades or dnf-automatic for security patches only, and read the notification emails.
- A restart of the affected service is usually enough. A full reboot is only needed for the kernel and core libraries.
How do I safely apply updates to a Linux server?
Look at what will change before you change it, patch security first, restart only what needs restarting, then verify the site still works. The order matters: most bad patch nights come from applying everything at once and finding out afterwards which change broke something.
# 1. Refresh the package lists. Changes nothing yet.
sudo apt update
# 2. See exactly what would be upgraded
apt list --upgradable
# 3. Which of those are SECURITY updates?
apt list --upgradable 2>/dev/null | grep -i security
# 4. Apply security updates only
sudo unattended-upgrade --dry-run -d # preview
sudo unattended-upgrade -d # apply
# 5. Or apply everything, once you have read step 2
sudo apt upgrade
# 6. Does anything need a reboot?
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgsapt upgrade never removes a package. apt full-upgrade will, so read its output carefully before confirming.# What is available
sudo dnf check-update
# Security updates only
sudo dnf updateinfo list security
sudo dnf update --security
# Everything
sudo dnf update
# Does anything need a restart?
sudo needs-restarting -r # 0 = no reboot needed
sudo needs-restarting -s # services running on old librariesdnf update --security has no direct apt equivalent, which makes selective patching noticeably easier on the RHEL family.apt upgrade and apt full-upgrade are not the same
apt upgrade only installs newer versions of what is already there. apt full-upgrade (formerly dist-upgrade) will remove packages when a dependency requires it, and on a server that can mean removing something a site depends on. Read the summary line before you type y.
What should I check before patching?
- 1Take a snapshot if your provider offers one. It is the only rollback that covers everything, including a kernel that will not boot. Do it before, not after.
- 2Take a database backup separately. A snapshot taken while the database is mid-write may restore into an inconsistent state. Dump the database first, then snapshot.
- 3Check free disk space. Package upgrades need room to unpack, and /boot in particular fills up with old kernels and then fails mid-upgrade, which is a genuinely awkward state to recover from.
- 4Read the changelog for anything major.
apt changelog nginxbefore upgrading a package a site depends on takes a minute and occasionally saves an evening. - 5Know how you get in if SSH breaks. Console access through your provider's panel, tested before you need it under pressure.
# Disk space, especially /boot
df -h / /var /boot
# Old kernels filling /boot (Debian / Ubuntu)
dpkg --list | grep linux-image
sudo apt autoremove --purge
# Database dump before anything else
mysqldump --single-transaction --routines --all-databases \
| gzip > /var/backups/pre-patch-$(date +%F).sql.gz
# Record current versions so you can compare afterwards
dpkg -l > /var/backups/packages-before-$(date +%F).txt
# Anything already broken? Fix it before adding changes.
systemctl --failedRun the whole session inside tmux. If SSH drops mid-upgrade, apt or dnf keeps running and you can reconnect. Without it, the connection dying part-way through a package installation leaves the package database locked and half-configured.
Should I enable automatic security updates?
Yes, for security patches. The risk of an unpatched known vulnerability sitting on an internet-facing server for weeks is far larger than the risk of a security patch breaking something. Automatic feature upgrades are a different matter and should stay off.
sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Mail "alerts@example.com";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Automatic-Reboot "false";
# Confirm it is actually running
systemctl status unattended-upgrades
sudo unattended-upgrade --dry-run -dsudo dnf install -y dnf-automatic
# /etc/dnf/automatic.conf
# upgrade_type = security
# apply_updates = yes
# emit_via = email
# email_to = alerts@example.com
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timerupgrade_type = security is the line that matters. The default is default, which applies everything.Automatic-Reboot false, always
Setting it true means a kernel security patch will restart your production server at 6am with no warning and no one watching. Leave it false, let the tool tell you a reboot is pending, and schedule it yourself. See rebooting a Linux server safely.
| Update type | Automate? | Why |
|---|---|---|
| Security patches | Yes | Backported fixes only, minimal behaviour change |
| Regular package upgrades | No | Feature changes can break configuration |
| Kernel updates | Install yes, reboot no | Needs a reboot you schedule |
| Distribution release upgrades | Never | Major change: plan, test and do it deliberately |
| Third-party repository packages | No | Nobody has tested them against your setup |
The distinction that makes automation safe is security versus everything else.
What do I do after applying updates?
# Which services are running against libraries that no longer exist?
sudo needs-restarting -s # RHEL family
sudo checkrestart # Debian, from debian-goodies
# Restart the ones that need it, individually
sudo systemctl restart nginx php8.3-fpm
# Anything failed?
systemctl --failed
sudo journalctl -p err --since '30 min ago'
# Do the versions you care about still work?
nginx -v && php -v && mysql --version
# Test the site from outside the server
curl -s -o /dev/null -w 'HTTP %{http_code} in %{time_total}s\n' https://example.com/Config file prompts need a real decision
When apt asks whether to keep your version of a config file or take the maintainer's, the safe answer is keep your version (N, the default). Then read the differences afterwards with diff /etc/nginx/nginx.conf /etc/nginx/nginx.conf.dpkg-dist and merge anything new deliberately. Accepting the package version overwrites your configuration.
# What was installed and when
grep ' install \| upgrade ' /var/log/dpkg.log | tail -30 # Debian / Ubuntu
sudo dnf history # RHEL family
# Undo an entire dnf transaction. Genuinely useful.
sudo dnf history undo 42
# Downgrade a single package on Debian / Ubuntu
apt list -a nginx
sudo apt install nginx=1.24.0-1ubuntu1
# Pin it so the next upgrade does not undo your fix
sudo apt-mark hold nginxdnf history undo has no clean apt equivalent, which is why a snapshot matters more on Debian and Ubuntu.How often should I patch a production server?
| Type | Frequency | Approach |
|---|---|---|
| Security patches | Automatically, daily | unattended-upgrades or dnf-automatic |
| Critical vulnerabilities | Within 24 hours | Manually, as soon as you hear about it |
| Regular packages | Monthly | Scheduled window, snapshot first |
| Kernel reboots | Monthly, or when required | Announced window, out of hours |
| Distribution upgrades | Before end of support | Test on a copy first, never in place on the live server |
The monthly window is where the discipline lives. Security patching should not need a window at all.
Watch the end-of-life date
When a release stops receiving security updates, running apt upgrade will keep telling you everything is fine while known vulnerabilities go unpatched. Check with hostnamectl and your distribution's support calendar, and plan the migration months ahead rather than in the last week.
Patching is one of the clearest arguments for managed hosting: it is essential, it never finishes, and the consequences of getting it wrong land on a live site. On G7Cloud the operating system, PHP and web server layers are patched centrally and rolled out in stages, with the site isolated in its own container so an update to one never reaches another. See how our platform is maintained or read WordPress security beyond plugins for the wider picture.
Frequently asked questions
What is the difference between apt upgrade and apt full-upgrade?
apt upgrade installs newer versions of installed packages and never removes anything. apt full-upgrade will remove packages when a dependency change requires it. On a production server, start with upgrade and only use full-upgrade after reading exactly what it proposes to remove.
Should I enable automatic updates on a production Linux server?
For security patches, yes. They are narrow backported fixes and the risk of leaving a known vulnerability unpatched is far greater. Restrict the configuration to the security origin only, and leave automatic reboots disabled so you decide when the server restarts.
How do I apply only security updates on Ubuntu?
Install unattended-upgrades and run sudo unattended-upgrade -d, with Allowed-Origins limited to ${distro_id}:${distro_codename}-security. There is no direct apt upgrade --security flag, which is why the tool exists. On the RHEL family it is simply dnf update --security.
Do I need to reboot after every Linux update?
No. Only kernel and core library updates need one. Check /var/run/reboot-required on Debian and Ubuntu or needs-restarting -r on the RHEL family. For everything else, restarting the affected service is enough and far less disruptive.
What should I do when apt asks about a modified config file?
Keep your version, which is the default. Then compare afterwards with diff /etc/service/conf /etc/service/conf.dpkg-dist and merge any new options deliberately. Taking the maintainer's version overwrites your configuration and is the usual cause of a service failing to start after patching.
How do I roll back a Linux update that broke something?
On the RHEL family, sudo dnf history then sudo dnf history undo <id> reverses a whole transaction. On Debian and Ubuntu there is no equivalent: downgrade individual packages with apt install package=version and hold them, which is why taking a snapshot beforehand matters more there.
About G7Cloud Engineering
Articles written by the engineers who build and run G7Cloud: UK managed hosting and the AI Website Builder. We write about what we operate every day: containers, backups, databases, and the small-business websites that run on them.
More about G7Cloud →
