Ubuntu Server on KnightLi Blog

Choosing a Linux Server Distribution in 2026: Debian, Rocky Linux, AlmaLinux, and Ubuntu Server Compared

Thu, 07 May 2026 21:03:12 +0800

When choosing a Linux server distribution in 2026, the key question is not “which one is best,” but “which one fits your operations model.”

If you need the most stable community distribution, Debian remains one of the best choices. If you need the RHEL-compatible ecosystem but do not want to buy RHEL directly, Rocky Linux and AlmaLinux are the most natural CentOS successors. If you care most about cloud images, documentation, fast deployment, and newer packages, Ubuntu Server is still the easiest path.

Below is a practical comparison from a server perspective.

Quick Conclusion

Distribution	Best For	Main Strengths	Main Notes
Debian	Long-term stability, self-hosting, basic services	Stable, clean, strong community, deep free-software tradition	Default packages are conservative; enterprise commercial support is less explicit than RHEL/Ubuntu
Rocky Linux	RHEL-compatible production environments	Close to RHEL habits, suitable for enterprise CentOS migration	Conservative package cadence; desktop and new-tech experience are not the focus
AlmaLinux	RHEL-compatible production, cloud, enterprise replacement	RHEL compatible, active community, clear lifecycle	Still has some differences from RHEL; read release notes
Ubuntu Server	Cloud servers, containers, development deployment	Strong cloud support, rich docs, fast deployment, long LTS lifecycle	Snap, HWE kernels, and PPAs need team-wide rules

In one sentence:

Safest general-purpose choice: Debian.
Enterprise RHEL ecosystem replacement: Rocky Linux / AlmaLinux.
Cloud and development efficiency first: Ubuntu Server.

Debian: Rock-Solid Stability

As of May 2026, the current Debian stable release is Debian 13 trixie. Debian 12 bookworm has moved into oldstable and still receives security and LTS support, but new server deployments should generally start with Debian 13.

Debian’s characteristics have always been clear:

conservative default package selection;
clean system structure;
no strong commercial-vendor binding;
mature community governance;
well suited to long-running basic services.

Debian is comfortable if your servers mainly run:

Nginx / Apache;
PostgreSQL / MariaDB / Redis;
Docker / Podman;
WireGuard / Tailscale;
file services, backup services, monitoring services;
small self-hosted applications.

Debian’s advantage is not being “the newest,” but requiring less fuss. Many servers can run for years with normal security updates and minor maintenance.

Debian is suitable when:

you want the system to stay simple and not be too affected by vendor strategy;
you are familiar with apt, systemd, and Debian file layout;
you can accept software versions that are not the newest;
you care more about stability, security updates, and predictable upgrades.

Debian is less suitable when:

a vendor only certifies RHEL or Ubuntu;
you need enterprise commercial support with an SLA;
you depend on the newest kernel, GPU stack, or new hardware support;
your team has already built operations standards around the RHEL ecosystem.

My take: for personal servers, self-hosting, lightweight SaaS, and small-team infrastructure, Debian remains an excellent first choice.

Rocky Linux: A Steady CentOS Successor

Rocky Linux has a clear position: it serves users who need the RHEL-compatible ecosystem and continues the role that CentOS Linux played in enterprise production environments.

In 2026, both Rocky Linux 9 and Rocky Linux 10 are within their support periods. Rocky Linux 9 fits more conservative production environments, while Rocky Linux 10 is better for new projects, newer hardware, and a longer future runway.

Rocky Linux fits scenarios such as:

enterprise environments that previously ran CentOS 7 / CentOS 8;
RHEL-style directory structure, package names, and operations habits;
reliance on dnf, RPM, SELinux, and firewalld;
software vendors that explicitly support RHEL-compatible distributions;
internal automation scripts written around Enterprise Linux.

Its advantage is low migration friction. Many teams have years of CentOS-based Ansible playbooks, monitoring rules, audit scripts, and security baselines. Moving to Rocky Linux is mentally much easier than moving to Debian or Ubuntu.

Things to note about Rocky Linux:

packages are conservative by design; this is a feature of Enterprise Linux, not a flaw;
very new user-space components may require EPEL, third-party repositories, or containers;
RHEL compatibility does not mean every commercial software vendor automatically offers formal support, so check certification lists;
Rocky Linux 10 has new hardware baselines and ecosystem requirements, so validate before production.

My take: if your server environment is already CentOS / RHEL based, Rocky Linux is a very natural replacement, especially for stable production environments and internal enterprise services.

AlmaLinux: A More Proactive RHEL-Compatible Route

AlmaLinux is another important CentOS successor. It is also enterprise-grade, long-term supported, and RHEL compatible.

It shares many traits with Rocky Linux:

both target the RHEL-compatible ecosystem;
both fit server production environments;
both have long-term 8, 9, and 10 release lines;
both are suitable for CentOS migration;
both can use a large set of Enterprise Linux ecosystem tools.

The difference is that AlmaLinux is more proactive in documenting and handling upstream differences while remaining RHEL compatible. For example, AlmaLinux 10 provides an x86-64-v2 architecture option for older hardware and clearly documents differences from RHEL in release notes.

This is useful for some users: they want to stay in the RHEL ecosystem but also want a community distribution with more flexibility around hardware support, package builds, and EPEL compatibility.

AlmaLinux is suitable when:

you need RHEL compatibility but do not want to be fully constrained by RHEL release strategy;
you value community governance and transparent release notes;
you need a stable base system for cloud platforms, container images, and enterprise workloads;
you want a smooth migration from CentOS or older Enterprise Linux.

The key caution: AlmaLinux is not “identical to RHEL with your eyes closed.” For strict compliance, vendor certification, database certification, or hardware certification scenarios, check whether the software vendor explicitly supports AlmaLinux.

My take: both Rocky Linux and AlmaLinux can replace CentOS. If you prefer a more conservative and traditional CentOS-style story, look at Rocky. If you value community transparency and a more flexible compatibility route, look at AlmaLinux.

Ubuntu Server: Best Cloud Support and Deployment Efficiency

Ubuntu Server’s advantage is practical: cloud platforms, documentation, community tutorials, images, automation tools, and developer ecosystem are all strong.

For new server deployments in 2026, the main choice is still Ubuntu 24.04 LTS. Ubuntu LTS usually has 5 years of standard support and can be extended through ESM. For cloud servers, container hosts, development environments, and CI/CD nodes, Ubuntu Server is often the fastest to get working.

Ubuntu Server fits:

AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and other cloud servers;
Docker, Kubernetes, GitLab Runner, CI/CD;
AI / GPU / CUDA development environments;
teams that need abundant tutorials and community recipes;
environments where development and production should stay similar.

Ubuntu’s strengths:

high-quality cloud images;
lots of official and third-party documentation;
often more active new hardware support;
clear LTS cadence;
convenient developer toolchain updates;
many commercial software vendors provide Ubuntu installation instructions first.

Things to watch:

not every team likes Snap on servers, so decide your policy in advance;
PPAs are convenient, but overusing them in production increases maintenance risk;
choose clearly between HWE kernel, cloud kernel, and standard kernel;
for minimal-stability purists, Ubuntu’s default system feels busier than Debian.

My take: if you mainly run cloud servers, containers, development deployment, or AI toolchains, Ubuntu Server is usually the most efficient choice. It is not the most “pure” distribution, but it reduces lookup time and friction for many tasks.

How to Choose Among the Four

Personal VPS / Self-Hosting

Debian or Ubuntu Server first.

If you want stability, low maintenance, and less fuss, choose Debian. If you often follow tutorials to deploy new projects or need a newer software stack, choose Ubuntu Server.

Enterprise Production

Rocky Linux, AlmaLinux, or RHEL first.

If the company used CentOS before, migration to Rocky / Alma is the cheapest path. If commercial databases, hardware certification, security compliance, or vendor support are involved, check certification lists first.

Cloud Native and Container Hosts

Ubuntu Server, Debian, and Rocky / Alma can all work.

If the team values development efficiency, choose Ubuntu Server. If you want minimal stability, choose Debian. If the enterprise standard is RHEL-based, choose Rocky / Alma.

AI / GPU Servers

Look at Ubuntu Server first, then Rocky / Alma.

The reason is simple: NVIDIA, CUDA, PyTorch, TensorFlow, driver installation tutorials, and community experience are usually richest on Ubuntu. Enterprise GPU clusters built around the RHEL ecosystem can choose Rocky / Alma, but drivers, CUDA, container runtime, and monitoring tools should be validated in advance.

Traditional Business Systems

Rocky Linux / AlmaLinux first.

Traditional Java, databases, middleware, commercial software, auditing, and operations standards often lean toward the RHEL ecosystem. In that case, Rocky / Alma fits existing systems more easily than Debian / Ubuntu.

What to Check Before Choosing

Do not choose only by distribution name. For server selection, judge by these questions:

Lifecycle: until which year is this version maintained?
Upgrade path: is major-version upgrade mature? Is smooth migration supported?
Software sources: do you rely on third-party repositories? Who maintains them?
Security updates: are security advisories, patch cadence, and CVE handling clear?
Hardware support: have CPU, NIC, RAID, GPU, and storage controllers been validated?
Team experience: is the team more familiar with apt or dnf? Debian-style or RHEL-style systems?
Vendor certification: does the business software explicitly support this distribution?
Automation assets: can existing Ansible, Terraform, and image-building scripts be reused?

The real cost is often not the installation ISO. It is upgrades, audits, troubleshooting, and handover over the next five years.

My Default Recommendations

If I had to give a default 2026 server selection guide:

Scenario	Recommendation
Personal VPS, self-hosting	Debian 13
Cloud server, fast deployment	Ubuntu Server 24.04 LTS
CentOS migration	Rocky Linux 9 / AlmaLinux 9
New enterprise project	Rocky Linux 10 / AlmaLinux 10, after ecosystem validation
AI / GPU development	Ubuntu Server 24.04 LTS
Strict-compliance commercial production	RHEL, or Rocky / Alma after vendor support is confirmed

Short Conclusion

Debian’s keywords are stability, simplicity, community, and free-software tradition. It is suitable for long-running base servers.

Rocky Linux and AlmaLinux are about RHEL compatibility, enterprise production, and CentOS replacement. They fit teams that already have Enterprise Linux operations systems.

Ubuntu Server is about cloud, documentation, development efficiency, and ecosystem completeness. It fits fast deployment, containers, AI/GPU, and cloud servers.

There is no forever-correct distribution. There is only the distribution that best matches your team, business, hardware, and lifecycle. The best server choice is usually not the hottest one, but the one you will still be willing to maintain five years later.

Debian Releases: https://www.debian.org/releases/
Ubuntu Releases: https://releases.ubuntu.com/
Rocky Linux Release and Version Guide: https://wiki.rockylinux.org/rocky/version/
AlmaLinux Release Notes: https://wiki.almalinux.org/release-notes/

Hard Drive Prices Are Soaring: Do Not Expand Your NAS Yet, Try a $200 TerraMaster + HC620 Cold Data Setup

Mon, 04 May 2026 11:46:53 +0800

When hard drive prices rise sharply, a full NAS does not always need an immediate drive upgrade. If the main NAS is still working normally and only running out of capacity, it is often better to separate data by access frequency: keep frequently used hot data on the original NAS, and move rarely used cold data and backups to a separate cold-storage disk.

This article records a low-cost approach: use large HC620 drives for cold data, then use an inexpensive TerraMaster F2-220, F2-221, or F4 as the migration and mount node. It does not aim for high performance. It solves one practical problem: during a period when upgrading disks is not cost-effective, first free up space on the main NAS.

Idea

Sort data by access frequency first:

Hot data: photos, work files, recent downloads, frequently watched videos. Keep these on the main NAS.
Cold data: old media libraries, archived materials, large files that rarely change. Move these to HC620.
Backup data: data that only needs periodic writes and occasional reads. This can also be stored on HC620.

For HC620 usage scenarios, see the site article: Misunderstandings and Correct Usage of Western Digital HC620 SMR Drives. It is better suited to sequential writes, long-term storage, and random reads. It is not suitable for workloads with frequent deletes and repeated writes.

If the goal is simply to free up space on the main NAS, I do not recommend replacing the main NAS disks on a large scale while hard drive prices are high. Move rarely used data out first, and let the main NAS continue handling hot data. This is usually more cost-effective.

Why Use an Old TerraMaster

The problem with HC620 is not capacity, but convenience. It has requirements for the operating system, interface, and usage pattern, so putting it directly into a USB hard drive enclosure is not a good fit.

An old TerraMaster F2-220, F2-221, or some F4 models can be used as a low-cost cold-data node. The advantages are straightforward:

Cheap. A used F2-220 is often under 200 RMB.
Small footprint and acceptable power consumption.
The system can be installed on a USB drive, so it does not occupy a drive bay.
Two or more SATA bays are available, making it suitable for HC620 archive disks.

These old machines are not powerful, but they are enough for cold-data migration, CIFS mounting, and background copying. Although the F2-220 only has older SATA 3G ports, HC620 can still reach around 200MB/s in outer-track disk-to-disk copies in testing. For cold-data migration, this is not slow. The bottleneck is often the network, the source disk condition, or the number of files.

If the onboard gigabit network is not fast enough, you can also add a USB 2.5G network adapter. A cold-data node does not need complicated modification. As long as the system recognizes the adapter, and both the switch and main NAS support 2.5G, the network bottleneck can be raised noticeably.

Prepare Video Output

If the machine has no HDMI port, you need VGA for system installation. The F2-220 has an internal VGA header. You can use a motherboard internal 12-pin VGA adapter cable: one end connects to the internal header, and the other end exposes a standard VGA connector for a monitor.

For VGA adapter specifications and notes, see: Installing fnOS on TerraMaster F2-220: VGA Output. In short, search terms include “12Pin VGA adapter cable”, “motherboard 12-pin VGA cable”, and “2.0mm 12Pin to VGA”. Before buying, check pitch, direction, and pinout.

Install Ubuntu Server to a USB Drive

Install Ubuntu Server to a USB drive so all hard drive bays remain available for data disks.

The F2-220 is relatively weak, so installing directly on it can be slow. A more efficient method is to plug the USB drive into a faster computer, complete the Ubuntu Server installation there, then move the USB drive back to the TerraMaster. As long as the boot mode is compatible, it usually works directly.

After installation, check the network configuration carefully. Otherwise, the machine may boot but have no network connection, making SSH management impossible.

Configure Networking

After entering the system, check the network interface name first:

`1`	`lshw -c network`

The sample output shows the logical name:

  *-network
       description: Ethernet interface
       product: RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 07
       serial: 6c:bf:b5:00:63:ab
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=6.8.0-111-generic duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.8.205 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:17 ioport:e000(size=256) memory:d0604000-d0604fff memory:d0600000-d0603fff

Here the interface name is enp2s0. Then edit the netplan configuration:

`1`	`sudo more /etc/netplan/01-install-config.yaml`

If the file does not exist, create it with this content:

network:
  version: 2
  ethernets:
    enp2s0:
      dhcp4: true

Replace enp2s0 with the actual interface name on your machine. Save the file and apply it:

`1`	`sudo netplan apply`

After the network is restored, you can SSH into the TerraMaster and continue without keeping a monitor connected.

Format HC620 as btrfs

If the HC620 is new, or if all data on it has been confirmed unnecessary, format it as btrfs first. The following operations erase the target drive. Confirm the disk device before running them. Do not format the main NAS share or the system USB drive by mistake.

List current disks:

`1`	`lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS`

You can also check stable disk paths:

`1`	`ls -l /dev/disk/by-id/`

After confirming which device is the HC620, unmount any existing mount point:

1
2

sudo umount /dev/sda 2>/dev/null
sudo umount /dev/sda1 2>/dev/null

If you want to create btrfs directly on the whole disk:

`1`	`sudo mkfs.btrfs -f -O zoned -d single -m single -L HC620_01 /dev/sda`

Parameter notes:

-f: force file-system creation, avoiding old signatures blocking the format.
-O zoned: enable the zoned feature, suitable for drives like HC620 that need zone-aware sequential writes.
-d single -m single: use single-disk mode for both data and metadata.
-L HC620_01: set a label for easier identification.

If your system or kernel does not handle zoned btrfs well, continue with the earlier test notes: Is a New WD HC620 14T Drive for About 600 RMB Worth Buying?. Compatibility for this type of drive depends on kernel version, SATA controller, and file-system support. Do not import real data until the setup behaves normally.

After formatting, test with a temporary mount:

1
2
3

sudo mkdir -p /mnt/disk1
sudo mount /dev/sda /mnt/disk1
df -h

After confirming it mounts correctly, write /etc/fstab for automatic mounting. For long-term use, prefer /dev/disk/by-id/ instead of /dev/sda to avoid device-name changes after reboot.

Configure Mounts

This cold-data node usually needs to mount two types of paths:

The main NAS share, used to read data that needs to be migrated.
The local HC620 data disks, used to store cold data and backups.

Create mount directories first:

`1`	`sudo mkdir -p /mnt/xxxxx /mnt/disk1 /mnt/disk2`

If you need to mount CIFS/SMB shares, install the tools:

1
2

sudo apt update
sudo apt install cifs-utils

Then edit /etc/fstab and add lines like these:

1
2
3

//192.168.x.xxx/xxxxx   /mnt/xxxxx cifs auto,username=xxxxx,password=xxxxx,uid=997,gid=997,file_mode=0777,dir_mode=0777,nofail 0 0
/dev/sda  /mnt/disk1  auto  defaults,nofail  0  0
/dev/sdb  /mnt/disk2  auto  defaults,nofail  0  0

The first line mounts the main NAS share. The next two lines mount local disks.

In real use, prefer stable paths such as /dev/disk/by-id/ for data disks to avoid /dev/sda and /dev/sdb changing order after reboot. HC620 formatting and mounting notes are also covered in the earlier record: Is a New WD HC620 14T Drive for About 600 RMB Worth Buying?.

Test the mount after editing:

1
2

sudo mount -a
df -h

After confirming that both the main NAS share and local data disks appear, start migrating data.

Copy Files in the Background

For large data migrations, do not run plain cp directly in the SSH foreground. The preferred setup here is screen + mc: screen keeps the session alive after SSH disconnects, while mc provides a clearer two-pane file-management interface.

mc is well suited to manually organizing cold data. Open the main NAS mount on the left, open the HC620 data disk on the right, select files, and press F5 to copy. During copying, it shows both current-file progress and total progress, which is much easier to read than raw command-line output when moving many files.

The image above illustrates the copy-progress window. The Midnight Commander manual also notes that copy, move, and delete operations show a file-operation dialog in verbose mode, with current-file and total progress available.

Install the tools:

`1`	`sudo apt install screen mc rsync`

Start a background session:

`1`	`screen -S cold-data`

Run mc inside screen:

mc

The usual workflow is to open the source directory and target directory in the two panels, then operate with shortcuts:

Tab: switch between panels.
Insert: select multiple files or directories.
F5: copy to the other panel.
F6: move or rename.
F8: delete, use carefully.

If you need a more scriptable and repeatable sync task, use rsync instead:

`1`	`rsync -avh --progress /mnt/xxxxx/old-data/ /mnt/disk1/old-data/`

Even if SSH disconnects during copying, the screen session remains alive. Reconnect and run:

`1`	`screen -r cold-data`

You will return to the original copy task.

Usage Advice

This setup is for cold data and backups. Do not use HC620 as a high-frequency write disk. Suggested usage:

Keep hot data and daily services on the main NAS.
Store large long-term files, media libraries, and archive materials on HC620.
Migrate mainly by sequential writes; avoid frequent deletes and repeated small-file writes.
Keep at least two copies of important data. Do not keep the only copy on a single disk.
After migration, sample-check files and confirm that directory and file counts look normal.

If hard drive prices fall later, upgrading the main NAS array can still be considered. For now, using a low-cost node to relieve capacity pressure keeps both risk and spending more controllable.

Summary

When NAS space is full, buying new drives immediately is not the only answer. Treat the main NAS as the hot-data device, treat HC620 as cold-data and backup storage, and use a cheap TerraMaster F2-220, F2-221, or F4 as the mount and copy node. This is a low-cost and practical transitional setup.

The key is not performance, but division of responsibility: the main NAS keeps the daily experience smooth, while cold data is stored separately. This frees up space and avoids a large upgrade cost during a period of high hard drive prices.