The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The safe sequence for routine Ubuntu maintenance is sudo apt update followed by sudo apt upgrade, run from a tested SSH session while your VPS provider’s web console or rescue path remains available. Back up or snapshot the server first, read the complete transaction, plan any reboot, and verify SSH, the kernel, services, ports, logs, and application health afterward. A major Ubuntu release change is different: use sudo do-release-upgrade only after a separate backup, compatibility, and recovery plan.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What you are updating: packages or the Ubuntu release
“Updating Ubuntu” can describe two operations with very different risk profiles. Routine package maintenance installs fixes inside the Ubuntu release already on the VPS. A release upgrade moves the operating system to a newer release and changes a much larger set of packages, repositories, defaults, and configuration files.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Operation | Command | What changes | Typical interruption | When to use it |
|---|---|---|---|---|
| Refresh package indexes | sudo apt update |
Downloads current metadata from configured repositories; it does not install packages. | None by itself. | Before every package installation or upgrade. |
| Routine package upgrade | sudo apt upgrade |
Installs available updates within the currently installed Ubuntu release. | Some services may need restarting; a kernel update can require a reboot. | Regular maintenance and security patching. |
| Major release upgrade | sudo do-release-upgrade |
Transitions the VPS to the next supported Ubuntu release and rewrites the package set. | Planned downtime and a required reboot. | Moving between Ubuntu releases, not ordinary patching. |
Ubuntu recommends LTS releases for servers. Current Ubuntu documentation describes five years of standard support for an LTS release and nine months for an interim release (Ubuntu documentation, 2026). LTS-to-LTS upgrades are sequential: you must move through each intervening LTS rather than skipping directly to a later one.
Before touching a production VPS
A reliable update starts with recovery preparation, not with the first APT command. Perform these checks during a planned maintenance window.
#1 Best Overall
- Test SSH before maintenance. Open a fresh session, authenticate successfully, and confirm that you can use the account with
sudo. Keep the original session open as a safety line until the update is complete. - Keep an out-of-band path ready. Confirm that the provider’s web console, serial console, rescue environment, or equivalent recovery path is enabled and that you know how to reach it if SSH stops responding.
- Create or verify a backup. Use a current, restorable backup. A provider snapshot is useful for rolling back a staged change, but it is not a substitute for an independent copy of important data or a tested restore procedure.
- Check disk space. Package downloads, unpacked archives, new kernels, and temporary files all consume storage. Free space in the root filesystem and in any separate boot filesystem before beginning.
- Record the current state. Note the Ubuntu release, running kernel, public IP address, listening services, application versions, and any unusual configuration. This gives you a before-and-after reference if a service behaves differently.
- Choose a maintenance window. Schedule a period in which a service restart or reboot is acceptable. Tell anyone operating a game server, web service, database, or scheduled job that connections may be interrupted.
- Review repository changes. List third-party repositories and PPAs. They are outside Ubuntu’s standard archive and can introduce dependency conflicts; they are disabled during a release upgrade.
Ubuntu’s release-upgrade guidance specifically calls for backups, sufficient disk space, release-note review, and an understanding that third-party repositories are disabled during the transition. Ubuntu’s snapshot service can pin APT operations to a known package state on supported versions, which is useful when you need repeatable, staged changes.
Routine package updates: the safe SSH procedure
- Open a second, tested SSH connection. Do not begin with the only shell you have. If the first connection is interrupted, the second gives you a way to distinguish a client problem from a server problem.
- Start a persistent terminal session when appropriate. A terminal multiplexer such as
tmuxorscreencan preserve the shell if your local network drops. This does not protect the VPS from a reboot, but it protects the interactive command from a brief laptop or Wi-Fi failure. - Refresh package metadata.
sudo apt update - Read every warning and error. A successful-looking summary is not enough if a repository could not be reached, a signature could not be verified, or a package list was ignored. Resolve repository and dependency errors before installing updates.
- Install updates within the current release.
sudo apt upgrade - Watch configuration-file prompts. A package may ask whether to keep a locally modified file or install the maintainer’s version. Pause and inspect the difference when possible; do not choose blindly on a production server.
- Let the transaction finish. Do not close SSH while packages are being unpacked, configured, or while trigger scripts are running. Wait for the shell prompt and confirm that the command exits successfully.
- Run a second pass.
sudo apt upgradeA second run should report no remaining upgrades. If packages are still pending, investigate why instead of declaring maintenance complete.
apt update only refreshes the indexes that tell APT what versions are available. apt upgrade uses those indexes to install eligible updates without changing the Ubuntu release. Running only the first command leaves the installed packages unchanged; running only the second can use stale metadata.
How to read common APT outcomes
Repository or signature errors
Messages about unreachable mirrors, invalid signatures, missing release files, or malformed source entries mean APT does not have a trustworthy, complete package view. Check the affected source, network access, DNS, and repository key configuration. Do not bypass signature verification merely to make the command continue. Third-party sources deserve special scrutiny because they are not covered by Ubuntu’s archive guarantees.
Dependency or configuration failures
If APT reports unresolved dependencies or a package configuration error, stop and capture the complete output. Identify the package named in the error, determine whether a third-party source supplied it, and correct the underlying repository or package state before retrying. Rebooting over an unfinished transaction can leave a service or package database in a less recoverable state.
Packages marked “kept back”
APT phased updates can intentionally hold a package while Ubuntu evaluates rollout safety. Ubuntu states that security updates are never phased, so a kept-back package is not automatically an ignored security fix. Inspect the package’s candidate version, dependencies, repository origin, and any hold or third-party source before deciding what to do. Do not force every kept-back package into the transaction without understanding the reason.
A clean second pass
When the second apt upgrade reports no remaining upgrades, that confirms the eligible routine updates have been applied. It does not prove that every application is healthy or that a reboot is unnecessary; those are separate checks.
Service restarts and deciding whether to reboot
Many updates replace files that a running process has already loaded. Ubuntu’s automatic-updates documentation states: “Many updates do not require a full reboot, but do require services that use the updated files to be restarted before the change takes effect.” A package transaction can therefore complete successfully while an old process continues running.
Ubuntu documents /run/reboot-required as a manual indicator. Check it after routine updates:
if [ -e /run/reboot-required ]; then
echo "A reboot is required"
else
echo "No reboot flag is present"
fiThe flag is a planning signal, not a substitute for judgment. If a kernel update installed a newer kernel, a full reboot is normally needed to run it. If only a daemon was updated, restart that daemon during the maintenance window when the package or service documentation calls for it. Automatic tools may request or schedule a reboot, so understand your unattended-upgrades policy before assuming that the server will remain online indefinitely.
For a production VPS, choose a deliberate reboot time. Warn connected users, stop or drain workloads where the application supports it, and keep the provider console open. Never close your only recovery-capable session immediately before restarting.
Recommended Free Tools
Post-update and post-reboot verification
Verification is part of the update, not an optional cleanup step. Perform checks in this order so that a basic connectivity failure is found before you investigate application symptoms.
- Confirm SSH. From a new client session, connect using the normal hostname or IP and authenticate with the usual account.
- Confirm the running kernel. Compare
uname -rwith the kernel version installed during the transaction. A new kernel package is not active until the VPS has rebooted. - Check failed units and expected services. Review the service manager’s failed-unit list and inspect the status of each critical service. A successful package command does not guarantee that a daemon restarted successfully.
- Check listening ports. Verify that the ports required by your applications are listening on the intended addresses and that firewall rules still permit the expected traffic.
- Read logs around the maintenance time. Look for startup failures, permission errors, database migrations, certificate problems, and repeated crash loops in the system and application logs.
- Run application health checks. Test the public endpoint, an authenticated request, a database operation, or the game-server connection path that matters to your users. Local process status alone is not an end-to-end test.
- Check scheduled work. Confirm that timers, cron jobs, backups, monitoring agents, and log rotation resumed after the restart.
- Keep the snapshot until acceptance. Do not immediately delete your recovery point. Retain it until the VPS has passed normal traffic and monitoring for the period your rollback policy requires.
Upgrading to the next Ubuntu release
A release upgrade is an interactive migration, not a larger version of apt upgrade. Start it only after the backup, console, disk-space, repository, and maintenance-window checks are complete.
- Confirm the supported path. LTS upgrades are sequential. If the VPS is on an older LTS, plan each supported intermediate LTS rather than attempting a skip-level jump.
- Apply current routine updates first. Bring the installed release to a consistent, fully updated state and resolve all APT errors before changing releases.
- Review release notes and application compatibility. Check runtime versions, database support, kernel behavior, firewall rules, and any vendor-specific instructions for software that your VPS hosts.
- Disable or plan for third-party sources. Ubuntu disables third-party repositories during the release upgrade because they are a common source of conflicts. Know which packages came from those sources and how you will restore compatible repositories afterward.
- Launch the upgrader from a persistent session.
sudo do-release-upgrade - Stay available for prompts. The upgrader may ask about services, obsolete packages, and locally modified configuration files. Read each prompt, record your choices, and preserve custom settings only when you understand the resulting file.
- Do not disconnect until completion. Keep the SSH session and provider console available. A network drop is particularly risky while packages are being configured, so use a persistent terminal session and an out-of-band path.
- Reboot when requested. Ubuntu’s guidance treats the system as not upgraded until the required reboot has occurred. Do not report success merely because the upgrader reached its final prompt.
- Repeat the full verification process. Recheck SSH, the active kernel, services, ports, logs, application health, scheduled tasks, and repository configuration. Re-enable only third-party sources that explicitly support the new release.
Expect more configuration decisions and a longer outage window than for routine package maintenance. If the VPS hosts a stateful game service, database, or custom networking stack, test the release upgrade on a disposable clone first whenever your provider and workflow allow it.
Automatic security updates: useful, but not hands-off
Current Ubuntu Server installations include unattended-upgrades by default in Ubuntu’s documentation. It normally runs daily, records detailed activity under /var/log/unattended-upgrades, and can be configured to reboot automatically. Ubuntu security documentation says security updates are installed after about 24 hours by default, while normal updates are delayed about seven days (Ubuntu documentation, 2026).
Automatic updates apply only to the archive origins allowed by the configuration. Third-party repositories and PPAs require explicit allowed-origins settings; they are not automatically covered merely because APT can reach them. Review the policy and logs rather than assuming that every installed package receives unattended maintenance.
- Check the log after a maintenance cycle. Confirm what was downloaded, installed, held back, or unable to configure.
- Decide who owns reboot timing. An automatic reboot can reduce exposure after a kernel fix but can also interrupt a live service at an unexpected time. If automatic reboot is enabled, align it with your availability plan.
- Test service behavior. A package can install automatically while a dependent daemon needs a restart or a later manual check.
- Keep backups and console access. Automation does not remove the need for rollback and recovery.
Ubuntu also documents Canonical Livepatch: “The Canonical Livepatch service provides security fixes for most major kernel security issues without requiring a reboot.” Livepatch reduces reboot pressure for supported kernel fixes; it does not replace ordinary package updates, application testing, backups, or a recovery plan.
Snapshots, rollback, and staged maintenance
A snapshot gives you a point-in-time recovery option before a risky transaction. Verify what the provider snapshot actually includes, how long it takes to restore, whether it captures attached volumes, and whether restoring changes the public IP or disk identifiers. A snapshot that cannot be restored within your outage budget is not a complete rollback plan.
For higher-risk work, clone the VPS or restore the snapshot into an isolated test instance. Apply the update there, start the application, exercise its health checks, and compare configuration and logs with the production baseline. Then schedule production maintenance with the same command sequence and a clearly defined rollback trigger.
Rank #4
Ubuntu’s snapshot service can pin APT operations to a known package state on supported versions. That makes staged or repeatable changes easier, but it still requires you to test the application and retain independent backups.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Routine update versus release upgrade: choosing the right path
| Decision factor | Routine package update | Major release upgrade |
|---|---|---|
| Command | sudo apt update, then sudo apt upgrade |
sudo do-release-upgrade |
| Scope | Eligible packages inside the installed Ubuntu release. | Operating-system release, package set, defaults, and configuration. |
| Repository risk | Configured sources can affect dependency resolution. | Third-party repositories are disabled and must be reviewed afterward. |
| Connection handling | Keep SSH open until the transaction exits successfully. | Use a persistent session and recovery console; do not disconnect until the migration completes. |
| Reboot expectation | Only when a kernel or other update requires it, or when services need planned restarting. | Required before the system is considered upgraded. |
| Rollback preparation | Backup or provider snapshot recommended for production. | Backup, restorable snapshot, release-note review, and a tested recovery path are essential. |
| Verification effort | Check package completion, service restarts, kernel state, and application health. | Perform all routine checks plus repository restoration, compatibility checks, and configuration review. |
Keeping game and application services online
For a VPS hosting a multiplayer game server or another latency-sensitive application, the most disruptive events are usually service restarts, kernel reboots, and changed firewall or networking behavior—not the index refresh itself. Announce the window, save or gracefully stop the application according to its own procedure, and make sure automated startup is configured before rebooting.
- Record the service’s bind address and ports before maintenance, then verify them after the update.
- Drain players or active sessions when the application supports a graceful shutdown.
- Check that firewall rules, dedicated data volumes, and file ownership are unchanged.
- Watch CPU, memory, disk, and network metrics after startup; a service can be reachable while performing poorly because of a migration or configuration change.
- Keep the previous snapshot until users have reconnected successfully and monitoring is quiet.
Do not treat a successful SSH login as proof that the hosted application is healthy. The application-level health check is the acceptance test for the maintenance.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteTroubleshooting by symptom
SSH disconnects during an update
Do not immediately start a second package transaction. Try the provider console or rescue path, then determine whether the VPS is still booted, whether networking is responding, and whether APT is still running. If the machine is reachable, reconnect and inspect the transaction output and package state before taking further action.
The VPS comes back, but the service is down
Check the service status and logs first, then verify configuration-file changes, permissions, ports, and dependent services. If the package transaction completed but the service was not restarted, perform the documented restart during the maintenance window and repeat the end-to-end health check.
A reboot flag appears unexpectedly
Review which packages changed and schedule the reboot rather than allowing an unplanned outage. Keep the recovery console available and perform the post-reboot kernel, service, port, log, and application checks.
Best Value
APT repeatedly keeps a package back
Inspect whether the package is in a phased rollout, has unmet dependencies, is explicitly held, or is tied to a third-party source. Security updates are not phased according to Ubuntu’s documentation, so distinguish a phased normal update from a repository or dependency problem before choosing an action.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsThe release upgrader reports third-party repository problems
Follow the upgrader’s instructions, record which sources were disabled, and identify replacement repositories that support the target Ubuntu release. Do not re-enable an old-release source simply to make the prompt disappear; it can reintroduce incompatible packages.
A practical maintenance policy
For a small VPS, a simple written policy prevents rushed decisions:
- Apply routine updates on a predictable schedule, with daily unattended security updates reviewed through their logs.
- Take a provider snapshot and verify the recovery console before production maintenance.
- Use a maintenance window for any service restart or reboot.
- Run the two-command routine sequence, read all output, and repeat
apt upgradeuntil no eligible upgrades remain. - Record configuration-file decisions, held-back packages, and any repository changes.
- Run the post-update health checklist and retain the rollback point until acceptance is complete.
- Plan release upgrades separately, test them on a clone when possible, and move sequentially between LTS releases.
This process keeps routine patching small and reversible while reserving the heavier release migration for a deliberate project with its own compatibility and rollback plan.
Final safety rule
Never equate a command that returned to a shell prompt with a completed, safe maintenance event. Safe Ubuntu VPS updates combine the correct APT sequence, a tested SSH and console path, a restorable backup or snapshot, controlled service interruptions, careful handling of repositories and prompts, and explicit post-update verification. Use apt update plus apt upgrade for routine maintenance; reserve do-release-upgrade for a planned, sequential release transition that ends with a verified reboot.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
