Ubuntu Server Administration Guide 2026: UFW, Logs, Disk & Monitoring

Key Takeaways

• Five daily admin commands: df -h, free -h, systemctl status, journalctl -p err, ufw status.
• btop for real-time monitoring: Better than top/htop — shows CPU, memory, disk I/O, and network in one view.
• logrotate is automatic: Check /etc/logrotate.d/ to understand rotation — modify only when defaults aren’t right.
• Swap is not RAM: Swap prevents OOM kills but is much slower than RAM. Add it; don’t rely on it.

---

Introduction

Direct Answer: What are the essential Ubuntu 24.04 server administration tasks and commands in 2026?

Daily: df -h (disk space), free -h (memory), systemctl --state=failed (failed services), journalctl -p err --since today (errors). Weekly: sudo apt-get update && sudo apt-get upgrade -y (patches), review access logs. Setup: sudo apt-get install -y btop (monitoring), ensure unattended-upgrades is active (systemctl status unattended-upgrades), create swap if < 2GB RAM (fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile). Log management: journalctl for system logs, /var/log/nginx/ for Nginx, logrotate handles rotation automatically.

---

Part 1: Daily Health Check Commands

# Comprehensive server health check (run daily)
echo "=== DISK USAGE ==="
df -h | grep -v "tmpfs\|udev"

echo ""
echo "=== MEMORY ==="
free -h

echo ""
echo "=== SYSTEM LOAD ==="
uptime

echo ""
echo "=== FAILED SERVICES ==="
systemctl --state=failed --no-pager 2>/dev/null | head -10

echo ""
echo "=== RECENT ERRORS (last hour) ==="
journalctl -p err --since "1 hour ago" --no-pager | tail -10

echo ""
echo "=== DISK USAGE TOP 10 DIRS ==="
du -sh /var/log/* /var/lib/* /home/* 2>/dev/null | sort -h | tail -10

---

Part 2: btop — Real-Time Monitoring

sudo apt-get install -y btop

# Run btop
btop

# Key shortcuts:
# q     = quit
# f     = filter processes
# e     = show extended memory
# m     = toggle memory graph
# p     = toggle CPU per-core

For non-interactive monitoring: vmstat 5 (every 5 seconds), iostat -x 5 (disk I/O), ss -tlnp (open ports).

---

Part 3: Disk Management

# Find large files (over 100MB)
find / -size +100M -type f 2>/dev/null | sort -k5 -rn 2>/dev/null | head -10

# Identify disk usage by directory
du -sh /var/log /var/lib /home /opt /tmp 2>/dev/null | sort -h

# Clean up safely
# ── APT cache (safe) ──────────────────────────────────────────────────────
sudo apt-get clean               # Remove downloaded .deb files
sudo apt-get autoremove          # Remove unneeded packages

# ── Journal size limit ────────────────────────────────────────────────────
sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500M   # Keep only last 500MB of logs

# ── Docker cleanup (if Docker is installed) ───────────────────────────────
docker system prune -f            # Remove stopped containers, dangling images

---

Part 4: Swap Configuration

# Check current swap
swapon --show
free -h | grep Swap

# Create a 2GB swapfile
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Persist across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Reduce swappiness (0-100, default 60 — lower = use RAM longer)
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl vm.swappiness=10

# Verify
swapon --show

Expected output:

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

---

Part 5: Log Management

# View logs by priority
journalctl -p emerg       # System unusable
journalctl -p alert       # Action must be taken immediately
journalctl -p crit        # Critical conditions
journalctl -p err         # Error conditions
journalctl -p warning     # Warning conditions

# Useful filters
journalctl -u nginx --since today            # Nginx logs today
journalctl -u postgresql --since "2 days ago"  # PostgreSQL last 2 days
journalctl --grep "failed\|error" -i         # Case-insensitive keyword search
journalctl -k                                 # Kernel messages (like dmesg)

# logrotate configuration
ls /etc/logrotate.d/                         # Per-package rotation configs
sudo logrotate -d /etc/logrotate.conf        # Preview (dry run)
sudo logrotate -f /etc/logrotate.conf        # Force rotate now

---

Conclusion

Ubuntu 24.04 server administration is built on five pillars: disk monitoring (df/du), process monitoring (btop/systemctl), log review (journalctl), automated patching (unattended-upgrades), and firewall verification (ufw status). Running the daily health check script gives a complete server state overview in under 10 seconds.

---

People Also Ask

How do I find what’s using all my disk space on Ubuntu?

Use du -sh /* 2>/dev/null | sort -h to find the top-level directories by size. Then drill down: du -sh /var/* | sort -h to identify the offending subdirectory. Common culprits: /var/log (logs not rotating), /var/lib/docker (Docker images and volumes), /var/backups (old backups), and /home (user files). After identifying the directory, find /path -size +50M -type f | head -20 finds the specific large files.

---

Part 4: Patch Management and Security Updates

Ubuntu 24.04 is a long-term support release, but it still needs regular patching. Use unattended-upgrades for routine security updates, and keep a maintenance window for kernel and service upgrades.

4.1 Enable unattended upgrades

sudo apt-get install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Review the configuration in /etc/apt/apt.conf.d/50unattended-upgrades. Enable upgrades for UbuntuESM or proposed only in a controlled environment.

4.2 Scheduled patch review

Add a weekly review step to your admin checklist:

sudo apt-get update
sudo apt-get upgrade --dry-run
sudo apt-get install -y --only-upgrade gnupg openssh-server

Keep a changelog of package versions before and after patching, especially for network-facing services such as SSH, Nginx, and PostgreSQL.

Part 5: Firewall Policies with UFW

UFW is the simplest firewall on Ubuntu, but it is powerful when used correctly.

5.1 Default deny and explicit allow

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

For a server that should only accept SSH from a management subnet:

sudo ufw allow from 10.0.0.0/24 to any port 22 proto tcp
sudo ufw deny 22

5.2 Application profiles

UFW supports application profiles in /etc/ufw/applications.d. Use them for services such as Nginx Full instead of raw port rules.

sudo ufw allow 'Nginx Full'

5.3 Firewall status and logging

sudo ufw status verbose
sudo ufw show added
sudo tail -n 20 /var/log/ufw.log

Logging can be noisy, but it is useful after an onboarding or when you suspect unauthorized access attempts.

Part 6: System Logs and Journal Management

Ubuntu now relies on systemd-journald. Learn how to keep journal logs manageable and usable.

6.1 Disk usage and rotation

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=1G
sudo journalctl --vacuum-time=7d

This keeps the journal from consuming the entire boot disk while preserving enough history for troubleshooting.

6.2 Service-specific logs

sudo journalctl -u nginx --since '2026-05-20' --no-pager
sudo journalctl -u ssh --priority=warning --since '2 hours ago'

6.3 Persistent journal

Enable persistent journaling so logs survive reboots:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

This is essential for a sovereign server because it keeps your logs under your control and available after a reboot.

Part 7: Disk Health and Filesystem Monitoring

Check disk health with smartctl and monitor filesystem usage.

sudo apt-get install -y smartmontools
sudo smartctl -H /dev/sda
sudo smartctl -A /dev/sda | grep -E 'Reallocated_Sector|Pending_Sector'

For filesystems, use df -h and find:

df -hT / /var /home
sudo find /var/log -type f -size +100M -exec ls -lh {} \;

Use tune2fs -l /dev/sda1 to inspect ext4 mount options and enable journaling if needed. A hardened server should have consistent mount options such as noexec on /tmp and nodev on non-executable filesystems if your workload allows it.

Part 8: Service Management and Recovery

Use systemctl to inspect and control services.

sudo systemctl status nginx
sudo systemctl restart nginx
sudo systemctl daemon-reload
sudo systemctl enable --now fail2ban

If a service fails, the first step is always the logs:

sudo journalctl -u nginx --since '1 hour ago'

If you need to recover from a misconfigured service, keep the last working config snapshot. On Ubuntu, maintain /etc/nginx/sites-available/default.bak or similar backups so you can roll back quickly.

Part 9: Monitoring and Alerting

A sovereign server should self-report health. Use local monitoring tools and simple alerting scripts.

9.1 btop and htop

btop provides a rich terminal dashboard. Install and use it for interactive investigation.

sudo apt-get install -y btop
btop

9.2 Endpoint health checks

A simple shell script can check disk usage, CPU, and service status, then email or webhook alerts if thresholds are exceeded.

#!/usr/bin/env bash
set -e
if df -h / | awk 'NR==2 {print int($5)}' | grep -qE '^[8-9][0-9]?$|^100$'; then
  echo 'Disk usage over 80%' >&2
fi

Keep the alerting logic local to avoid dependence on external SaaS.

Part 10: Backup and Snapshot Practices

Backing up the server state is part of administration. For Ubuntu servers, backup configuration and critical data separately.

10.1 Config backup

sudo tar czf /var/backups/etc-$(date +%F).tar.gz /etc/nginx /etc/ufw /etc/ssh /etc/systemd

10.2 Data backup

For application data, use rsync or borg to copy files to another local volume or a private backup host.

borg create --compression lz4 /backups::$(date +%F) /var/www /etc/nginx

Schedule backups with cron or systemd timers and verify restoration periodically.

Part 11: Basic Security Hardening

Harden SSH, remove unused packages, and lock down user accounts.

11.1 SSH hardening

Edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers ubuntu admin
PermitEmptyPasswords no

# Optional: limit to specific ciphers and MACs
Ciphers [email protected],[email protected]
MACs [email protected]

Restart SSH with sudo systemctl restart ssh.

11.2 Remove unnecessary packages

sudo apt-get purge -y snapd lxd lxd-client cloud-init
sudo apt-get autoremove -y

A smaller attack surface is easier to secure and audit.

Part 12: Admission and Access Control

Maintain local access control by using dedicated admin accounts and restricting login shells.

sudo adduser admin
sudo usermod -aG sudo admin
sudo chsh -s /usr/sbin/nologin guest

Use sudo logs and /var/log/auth.log to audit access events. If an account is no longer needed, lock it immediately.

Part 13: Documentation and Runbooks

Keep an admin runbook with the daily checklist, patch procedures, firewall rules, and recovery steps. Store it in the same repository as your server configurations or in a private wiki.

A minimal runbook should include:

• how to access the server
• backup locations
• patch window schedule
• emergency SSH and console access
• service restart commands
• recovery procedure for full disk failure

This documentation is part of the server itself. Treat it as a first-class operational asset.

Part 14: Local Development Workflows for Administration

A good admin workflow is repeatable. Use shell aliases, reusable scripts, and configuration templates.

Example .bashrc aliases:

alias dfh='df -h'
alias jerr="journalctl -p err --since '1 hour ago' --no-pager"
alias ufws='sudo ufw status verbose'
alias sng='sudo systemctl status nginx'

Store these aliases in a shared admin dotfiles repository if you manage multiple servers.

Part 15: Advanced Disk and Filesystem Tips

For large server installs, use xfs_quota or lvm to manage disk allocations. On Ubuntu 24.04, zfs is also an option if you need copy-on-write snapshots and data integrity checks.

Example lvcreate for LVM:

sudo pvcreate /dev/sdb
sudo vgcreate vgdata /dev/sdb
sudo lvcreate -L 100G -n data vgdata
sudo mkfs.ext4 /dev/vgdata/data
sudo mount /dev/vgdata/data /mnt/data

A properly designed filesystem layout makes server administration easier and more resilient.

---

Part 16: Further Reading

Part 17: High Availability and Failover

For critical Ubuntu servers, plan a failover strategy. Even in a local environment, having at least one standby machine or a snapshot-based recovery target is valuable.

17.1 Standby server readiness

Keep a standby host configured with the same Ubuntu image and packages. Use configuration management or scripted provisioning so the standby can be brought online quickly.

17.2 NFS and shared storage considerations

If you use shared storage, keep it isolated on a separate network and restrict access. Avoid exposing NFS to untrusted networks.

Part 18: Hardened SSH and Bastion Access

Use a bastion host for remote administration and restrict SSH access to that host.

sudo ufw allow from 10.0.0.5 to any port 22 proto tcp
sudo ufw deny 22

On the bastion:

ssh -J [email protected] admin@target

This pattern confines administrative access and keeps the target host off the public edge.

Part 19: Kernel and Bootloader Management

Keep the kernel up to date on your Ubuntu server and manage boot entries carefully.

sudo apt-get install --install-recommends linux-generic-hwe-24.04
sudo update-grub

When changing kernel parameters, document the reason and keep a rollback entry in GRUB.

Part 20: AppArmor and Runtime Confinement

Ubuntu uses AppArmor for application confinement. Enable and enforce profiles for services such as Nginx, MySQL, and custom daemons.

sudo apt-get install -y apparmor apparmor-utils
sudo aa-status

Use aa-complain and aa-enforce to tune profiles.

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Audit the resulting audit.log entries to refine policies.

Part 21: Time Synchronization and Clock Health

A consistent clock is essential for logs, certificates, and backup timestamps.

sudo timedatectl set-ntp true
sudo timedatectl status

If your host is air-gapped, use a local NTP server or a GPS-based time source.

Part 22: Local Container Administration

If the server runs containers, keep the container runtime patched and the host footprint small. Use Podman for rootless containers or Docker with user namespaces.

For Podman:

sudo apt-get install -y podman buildah skopeo
podman info

Keep container data under /var/lib/containers and monitor disk use with podman system df.

Part 23: Backup Strategy for System State

In addition to application backups, back up system state and configuration. A simple snapshot strategy uses tar archives and encryption.

sudo tar czf /var/backups/system-etc-$(date +%F).tar.gz /etc

Encrypt the archive before moving it off the host.

Part 24: Local Package Cache and Offline Updates

If the server needs to operate in a restricted or air-gapped environment, maintain a local apt cache or mirror.

Install apt-cacher-ng and configure clients to use it:

sudo apt-get install -y apt-cacher-ng

On the client host:

Acquire::http::Proxy "http://cache.local:3142";

This keeps package installs fast and reduces dependence on external repositories.

Part 25: Security Notifications and Local Alerts

Install a local alerting mechanism for security events, such as ossec, fail2ban, or simple shell scripts. The goal is to know when the server experiences suspicious activity without relying on cloud monitoring.

25.1 Fail2Ban example

sudo apt-get install -y fail2ban
sudo tee /etc/fail2ban/jail.d/ssh.conf <<'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
EOF
sudo systemctl restart fail2ban

This blocks repeated unauthorized SSH attempts automatically.

Part 26: Local Audit Trail and Change Control

Track administrative changes in a local change log or an ops Git repository. Each change should record:

• what was changed
• why the change was made
• who made it
• when it was applied

This practice turns everyday server administration into a governed process.

Part 27: Recovery and Rebuild Procedures

If the entire server is compromised or fails, a rebuild procedure should exist. Script the provisioning process with shell scripts, cloud-init, or a configuration management tool.

27.1 Minimal rebuild steps

1. install Ubuntu 24.04
2. apply base hardening and user setup
3. restore /etc config from backup
4. restore application data and service definitions
5. verify service health

A quick rebuild is a sign of good administration.

Part 28: Final Ubuntu Server Admin Checklist

• daily health checks are documented and run
• firewall rules are default deny/incoming allow
• logs are rotated and audited
• patch management is scheduled and tracked
• swap is configured appropriately
• SSH is hardened and bastion access is used
• backups of configs and data are stored securely
• AppArmor is enabled for key services
• time synchronization is configured
• local monitoring and alerts exist
• service recovery procedures are documented

---

Part 29: Network Segmentation and Zero Trust Principles

Segment your network so management traffic is separated from service traffic. Apply zero trust principles by requiring authentication and authorization at every host boundary.

29.1 Private network zones

Use VLANs or separate physical interfaces to isolate management, database, application, and backup traffic. This reduces lateral movement risk.

29.2 Host-based restrictions

Even on a protected network, use host-level rules such as ufw and iptables to enforce access policies. Never assume the network alone provides complete security.

Part 30: Certificate Management and TLS

Use locally issued certificates or a private PKI for internal encrypted traffic.

openssl req -newkey rsa:4096 -nodes -keyout nginx.key -x509 -days 365 -out nginx.crt

Configure Nginx or the application service to use the certificate and enforce TLS 1.3 where possible.

Part 31: Audit and Incident Response

Prepare an incident response plan for the Ubuntu server. The plan should include:

• how to contain the incident
• how to preserve volatile evidence
• how to restore service safely
• post-mortem steps

Document the contact points, the escalation path, and the criteria for invoking the incident plan.

Part 32: Immutable Infrastructure and Reproducibility

Where practical, treat server configuration as code. Use shell scripts, Nix, or configuration management to reproduce the server state from scratch.

A reproducible server can be rebuilt quickly after a compromise or hardware failure.

Part 33: Health Checks and Self-Healing

Implement local health checks for critical services and optionally automatic restarts.

For systemd services, use Restart=on-failure and StartLimitBurst settings.

[Service]
Restart=on-failure
StartLimitIntervalSec=10
StartLimitBurst=3

This is not a substitute for root cause analysis, but it can improve availability.

Part 34: Operator Training and Handover

If multiple administrators will manage the server, create a handover package. Include:

• access details
• backup locations
• troubleshooting commands
• service restart steps

A well-documented handover reduces the risk of operational errors.

Part 35: Local Backup Verification and Restore Testing

Backups are only valuable if they can be restored. Periodically perform a restore test to a separate host.

35.1 Restore process

1. provision a test host
2. restore the configuration backup
3. restore application data
4. verify the service starts correctly

Document the restore steps and timing.

Part 36: Final Ubuntu Operations Checklist

• network segmentation is enforced
• TLS is configured for services
• logs are audited and retained
• incident response plan exists
• infrastructure is reproducible
• health checks are configured
• operator handover documentation is current
• backup restore tests are conducted regularly

---

Part 37: Backup Retention and Rotation Policies

Define a retention policy for backups and old snapshots. Retention should balance storage cost, recovery requirements, and regulatory needs.

Example policy:

• daily backups retained for 14 days
• weekly backups retained for 12 weeks
• monthly backups retained for 12 months

Implement rotation in your backup scripts and verify that older backups can still be restored.

Part 38: Secure Shell and Key Management

Rotate SSH keys periodically and remove stale public keys from ~/.ssh/authorized_keys. Maintain a record of active keys and their owners.

Use key comments to identify users and issue dates:

ssh-rsa AAAAB3... alice@workstation 2026-05-22

Regular key audits keep administrative access secure.

Part 39: Local Service Dependency Mapping

Document the dependencies between services on the server. A dependency map helps you understand the blast radius of a service failure.

For example, an Nginx reverse proxy may depend on:

• backend application service
• database service
• TLS certificate files

Keep this map updated and use it during incident response.

Part 40: Security Testing and Penetration Exercises

Even for local servers, perform periodic security exercises. Use local tools such as nmap, lynis, and osquery to scan for misconfigurations.

A simple nmap command:

sudo nmap -sS -sV -O 127.0.0.1

Use the results to harden open ports and remove unnecessary services.

Part 41: Performance Tuning and Capacity Planning

Monitor CPU, memory, and I/O over time and use those metrics to plan capacity. Adjust service limits, thread pools, and cache sizes based on actual load.

A host under sustained high load may need a separate application node or additional resources.

Part 42: Final Operational Review

Review the server configuration and operational practices quarterly. Confirm that the update schedule, backup validation, and security controls are still effective.

This review should include a brief written summary to capture changes and remaining risks.

---

Part 43: Maintenance Windows and Change Windows

Document regular maintenance windows and communicate them to stakeholders. A predictable maintenance window reduces surprises and ensures that upgrades happen when the impact is lowest.

43.1 Change approval process

Use a simple local change approval process for non-trivial changes. This can be a shared document or a ticket where you record:

• the planned change
• risk assessment
• rollback plan
• responsible operator

A local change process is not a heavy burden; it is a practical way to avoid accidental outages.

43.2 Post-maintenance validation

After updating or restarting services, validate the key endpoints and check logs for errors. Use a small post-maintenance checklist such as:

• verify SSH access
• verify application health checks
• verify backups still complete
• verify disk and memory usage

This ensures that the server is healthy after any administrative operation.

---

Part 44: Review and Continuous Improvement

Treat server administration as a continuous improvement process. After each incident or upgrade, capture what worked, what did not, and what should change in the next cycle.

A brief retrospective note can make future administration faster and safer, especially when multiple operators share responsibility.

---

Further Reading

• UFW Firewall Tutorial 2026 — detailed UFW configuration
• Linux systemd Service Management 2026 — systemctl and journalctl reference
• Linux Package Management 2026 — apt and unattended-upgrades

Tested on: Ubuntu 24.04 LTS (Hetzner CX22). Last verified: April 30, 2026.