Every Linux system boots with the help of an init system, but the one running on your server today looks nothing like the one from a decade ago. Here's what actually separates traditional SysV init from systemd, and why it matters for how you manage services.
]]>systemctl status on a fresh server and wondered why it isn't service status or some old init script, you've bumped into one of the more debated shifts in Linux history. Init and systemd both do the same basic job: they get your machine from "just powered on" to "actually usable." How they go about it, though, is almost completely different, and that difference shapes how you troubleshoot boot problems, manage services, and think about the Linux boot process in general.
This article walks through what an init system actually is, how the older SysV init worked, what systemd changed, and how you can check and manage either one on a live server.
Every Linux (and Unix) system needs a first process. When the kernel finishes loading and mounting the root filesystem, it hands off control to a single program, and that program becomes PID 1. Whatever that program is, whether it's a decades-old shell script interpreter or a modern service manager, it's called the init system.
PID 1 has a few jobs that never change no matter which init system you're running. It starts all the other system services and daemons in the right order. It becomes the parent of any process whose original parent has already exited, which means it's responsible for "reaping" those orphaned processes so they don't pile up as zombies. And it stays alive for the entire life of the system, since if PID 1 dies, the kernel panics.
Historically, "init" referred to a specific program: System V init, often shortened to SysV init. These days, "init system" is more of a general term, and systemd is simply the init system most major distributions ship with by default.
SysV init traces back to Unix System V and was, for a long time, the standard init system across most Linux distributions, including older versions of Debian, Ubuntu, Red Hat, and CentOS. It works around the idea of runlevels, numbered states (0 through 6) that each correspond to a particular system configuration. Runlevel 0 means shutdown, runlevel 1 is single-user rescue mode, runlevel 3 is a full multi-user system without a graphical interface, runlevel 5 adds a GUI, and runlevel 6 triggers a reboot.
When the system enters a runlevel, init looks in the matching /etc/rc.d (or /etc/rcX.d) directory for a set of symbolic links pointing to shell scripts, then runs them in numeric order. Each of those scripts is a genuine shell script, often bash, that starts or stops a particular service by defining its own start, stop, and status logic. If you've wondered what other types of shells could be running a script like this, this is a good example of bash doing real system work, not just interactive typing.
That flexibility came at a cost. SysV init starts services sequentially: script two doesn't run until script one finishes, whether or not they depend on each other. On a machine with a dozen or more services, that adds up to a slow boot. Worse, init had no real concept of dependencies between services. If a database needed the network up first, that ordering had to be baked into filenames and symlink numbers by hand, and different distributions handled the details slightly differently, which made scripts hard to port.
systemd was introduced by Lennart Poettering and Kay Sievers around 2010, and Fedora was the first major distribution to adopt it, in 2011. Today it's the default init system on Ubuntu, Debian, Fedora, RHEL, and their downstream relatives like Rocky Linux and AlmaLinux. It's still PID 1 and still responsible for reaping orphans, so it satisfies the same basic definition of an init system, but the mechanics underneath are quite different.
Instead of shell scripts, systemd uses unit files: plain-text configuration files that declare what a service needs rather than scripting out how to start it. A typical .service unit might just list the executable to run, which user to run it as, and which other units it depends on. systemd reads those dependencies and builds a graph, then starts services in parallel wherever it can, only serializing the ones that genuinely need to wait on each other. That's the single biggest reason systemd boots faster than SysV init on most hardware.
Runlevels are replaced by targets, which are really just units that group other units together. multi-user.target roughly corresponds to the old runlevel 3, and graphical.target corresponds to runlevel 5, but targets are more flexible since a system can activate several at once and depend on each other. systemd also bundles functionality that used to live in separate tools: journald for centralized logging, socket and timer activation so services start only when needed, and tight integration with Linux namespaces and cgroups for tracking each service's processes. That cgroup integration is why systemd can reliably kill every process belonging to a service, even ones that fork children the original script never knew about.
For backward compatibility, systemd can still parse old SysV init scripts as a fallback, and distributions maintain service and other wrapper commands so muscle memory from the SysV era mostly still works. The official systemd documentation on freedesktop.org covers the full unit file syntax and manager behavior in detail if you want to go deeper than this article does.
Not everyone was thrilled about the switch, and it's worth mentioning briefly for balance. Critics have pointed out that systemd concentrates a lot of functionality, logging, device management, network configuration helpers, and more, into one project, which cuts against the traditional Unix philosophy of small tools that each do one thing. Some sysadmins also found early versions harder to debug than a plain shell script, since understanding a boot failure now sometimes means reading unit dependency graphs instead of just reading a script top to bottom.
That pushback is part of why alternatives like OpenRC and runit still exist and see real use, particularly on distributions such as Alpine Linux, Gentoo, and Void Linux. Both aim for simpler, more transparent init systems with less built-in scope than systemd, at the cost of some of the parallelization and unit-management features systemd offers out of the box. If you're running containers or minimal images, there's a decent chance you've already encountered one of these without realizing it.
If you're not sure what a given server is using, there are a couple of quick ways to check. The most reliable is to look at what process 1 actually is:
ps -p 1
If the output shows systemd in the CMD column, you're running systemd. On an older SysV-based system, you'd typically see init instead. You can also check directly:
readlink /proc/1/exe
This resolves the actual binary backing PID 1, which will point to something like /usr/lib/systemd/systemd on a modern distribution. Another option, if the systemctl binary exists on the box at all, is simply running systemctl with no arguments; if it returns a live list of units, systemd is managing the system, since the command won't function meaningfully otherwise.
Once you know you're on a systemd-based system, a handful of systemctl commands cover the vast majority of day-to-day service management. Checking a service's current state is the one you'll reach for most:
systemctl status nginx
Starting and stopping a service is straightforward too:
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
Note that starting or stopping a service only affects its current running state; it won't survive a reboot on its own. To make a service come up automatically at boot, you enable it:
systemctl enable nginx
And to stop it from launching at boot without touching whether it's currently running, disable it:
systemctl disable nginx
For a quick sanity check across the whole system, systemctl list-units --type=service shows every loaded service unit and its state, and journalctl -u nginx pulls that service's logs straight out of the systemd journal, which is often faster than hunting through separate log files under /var/log.
Init and systemd both solve the same problem of turning a booting kernel into a working system, but they go about it in very different ways: one relies on sequential shell scripts and numbered runlevels, the other on declarative unit files, dependency graphs, and parallel startup. Knowing which one you're running, and how to check it, makes troubleshooting a stuck boot or a misbehaving service a lot less confusing.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. You can also explore IP transit, shared hosting, and general IT services for whatever your infrastructure needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
Not exactly. "Init" is a general term for whichever program becomes PID 1 and manages system startup; systemd is one specific implementation of that role, alongside older ones like SysV init and alternatives like OpenRC. On most modern distributions, systemd is the init system, so in casual conversation people often use the terms interchangeably.
Mainly for speed and consistency. SysV init's sequential, shell-script-based startup couldn't take advantage of dependency information, so boots were slower than they needed to be, and every distribution handled runlevel scripts a bit differently. systemd's unit files and parallelized startup addressed both problems, which is why Fedora, Debian, Ubuntu, and RHEL all eventually adopted it as the default.
Most of the major ones do, including Ubuntu, Debian, Fedora, RHEL, and their derivatives like Rocky Linux and AlmaLinux. It's not universal, though; distributions like Alpine Linux, Gentoo, and Void Linux use OpenRC or runit instead, often because they prioritize a smaller footprint or a simpler init model.
Generally, yes. systemd includes compatibility shims that can parse traditional SysV init scripts, and most distributions keep the service command working as a wrapper around systemctl. That said, native unit files are the preferred approach going forward, since they integrate properly with dependency resolution, logging, and cgroup tracking.
The kernel treats the loss of PID 1 as a fatal, unrecoverable event and panics rather than trying to continue, which is exactly why the init system, whichever one it is, needs to stay running and stable for as long as the machine is up.
]]>Linux namespaces and cgroups are the two kernel features that make containers possible, one hides what a process can see, the other limits what it can use. Here's how they actually work under the hood.
]]>docker ps and wondered how a container manages to feel like its own little machine, with its own process list, its own network interface, its own hostname, the answer isn't magic and it isn't a virtual machine either. It's two Linux kernel features working together: namespaces and cgroups. One decides what a process can see. The other decides what it can use. Once you understand both, containers stop feeling like a black box and start looking like a clever combination of features that have been sitting in the kernel for years.
This article covers what namespaces and cgroups actually do, how they differ, and how you can peek at both on a running system.
A namespace wraps a global kernel resource so that a process (or group of processes) inside the namespace gets its own isolated view of that resource, separate from everything else on the machine. A process inside a PID namespace, for example, might think it's process 1, when on the host it's actually process 48213. It's not lying to itself; the kernel is genuinely presenting a different, scoped-down reality.
This idea has been part of Linux for a long time. According to the kernel's own documentation, namespaces were introduced incrementally starting around the 2.4.19 kernel with mount namespaces, and grew over the following decade to cover most of the resources a process might touch. The namespaces(7) man page is the most complete single reference if you want the details for each type.
There are seven namespace types in modern Linux, and it's worth knowing what each one isolates:
Namespaces are created with the clone(), unshare(), or setns() system calls, and a process can belong to a different combination of namespaces than its parent. That's really the whole trick: a container is just a regular Linux process that's been started inside a fresh set of namespaces instead of the ones its parent used.
Namespaces solve visibility, but they don't solve resource contention. Nothing stops a process in its own PID and network namespace from consuming every CPU cycle and every byte of memory on the box. That's where control groups, better known as cgroups, come in.
cgroups were merged into the mainline kernel around version 2.6.24, and they let you organize processes into hierarchical groups and then apply limits, prioritization, and accounting to those groups as a whole. Instead of tracking resource usage per process, you can say "this group of processes gets 2 CPU cores and 512MB of RAM, total," and the kernel enforces it.
cgroups expose their controls through a virtual filesystem, typically mounted at /sys/fs/cgroup. Each controller (CPU, memory, block I/O, and others) shows up as files you can read and write directly, though in practice most people interact with cgroups through systemd or a container runtime rather than editing those files by hand. If your workflow already touches systemd unit files for service management, it's worth reading how init and systemd differ since systemd is what actually creates and manages cgroup hierarchies on most modern distributions.
There are two versions of cgroups in circulation, and it trips people up more than it should.
cgroups v1 gives each resource controller its own separate hierarchy. You could have memory limits organized one way and CPU limits organized a completely different way, which made combining them for a single application awkward and led to inconsistent naming between controllers.
cgroups v2, which the kernel documentation describes in detail, consolidates everything into a single unified hierarchy. All controllers attach to the same tree of groups, the control files are named consistently, and features like pressure stall information (a way to see how much a group is being throttled) were added along the way. Most current distributions default to cgroups v2 now, though you'll still find v1 on older systems and in some legacy container setups.
Put the two together and you get almost everything a container runtime needs. Docker, LXC, and the container layer underneath Kubernetes all follow roughly the same pattern: start a process in a fresh set of namespaces so it can't see other processes, other network interfaces, or the host filesystem, then drop that process into a cgroup so it can't starve the rest of the system of CPU or memory.
Neither piece does this alone. A process with its own namespaces but no cgroup limits is isolated but can still exhaust shared resources. A process under cgroup limits but with no namespace isolation can still see and potentially interfere with every other process on the host. Containers work because both mechanisms apply at once, and the runtime just automates the setup that you could otherwise do by hand with tools like unshare and cgcreate.
It's worth being clear that none of this is virtualization in the traditional sense. There's no hypervisor and no separate kernel; every container on a host shares that one kernel. That's a large part of why containers start in milliseconds and virtual machines take longer, but it also means a kernel-level vulnerability can, in principle, affect every container on the host. Namespaces and cgroups give strong isolation, but it's isolation within one kernel, not a hard security boundary the way a VM's hypervisor provides.
This is the part that's easy to try yourself on any Linux box, no containers required.
To see which namespaces a process belongs to, check /proc/[pid]/ns:
ls -la /proc/1/ns
That directory lists a symlink for each namespace type (pid, net, mnt, uts, ipc, user, cgroup), each pointing to an inode number. Two processes sharing the same inode number for a given namespace type are, in fact, in the same namespace; different numbers mean different namespaces.
If you'd rather see everything at once, the lsns command gives you a readable table of every namespace currently in use on the system, what type it is, how many processes belong to it, and the command that started it:
lsns
Running that on a host with a couple of Docker containers active makes the isolation concrete. You'll see one set of PID and network namespaces for the host itself, and separate ones for each container, all coexisting on the same kernel.
For cgroups, you can look at a process's current group membership through /proc/[pid]/cgroup, and browse the actual controllers and limits under /sys/fs/cgroup. On a v2 system, something like this shows you the current memory limit for a given cgroup:
cat /sys/fs/cgroup/mygroup/memory.max
If none of this is unfamiliar territory and you're comfortable poking around a shell already, you might enjoy a closer look at what Bash actually is and how it compares to the other types of shells in Linux, since the terminal commands above are really just Bash talking to the kernel through /proc and /sys.
Namespaces and cgroups are two separate kernel features solving two separate problems, isolating what a process can see and limiting what it can use, and together they're the foundation nearly every container runtime is built on. Once you can find them in /proc and /sys/fs/cgroup yourself, the whole container ecosystem stops feeling like a mystery.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. You can also explore IP transit, shared hosting, and general IT services for whatever your infrastructure needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
Not exactly. Namespaces and cgroups are kernel primitives; a container is a higher-level concept built on top of them by a runtime like Docker or LXC, which also adds things like image layers, networking configuration, and a defined filesystem root.
No. Both are built into the kernel itself. You can create namespaces with unshare and manage cgroups directly through the /sys/fs/cgroup filesystem without any container runtime at all, though runtimes make the process far more convenient.
Because each container has its own PID namespace. A process that appears as PID 1 inside a container is a normal, higher-numbered process on the host; the container just can't see the host's numbering scheme.
Generally not. Containers share a single host kernel, so a serious kernel vulnerability can affect every container on that host. Virtual machines run separate kernels under a hypervisor, which gives a stronger isolation boundary, at the cost of more overhead per instance.
cgroups v1 still works and plenty of systems run it, but it's effectively legacy at this point. cgroups v2 is the default on current major distributions and is where new kernel features are being added, so new deployments should generally target v2 unless something specific requires v1.
]]>Bash isn't the only shell on Linux. Here's a breakdown of the most common shell types, sh, bash, dash, zsh, ksh, csh/tcsh, and fish, what each is actually built for, and how to check or switch which one you're running.
]]>A shell is a command line interpreter. It's the program that sits between you and the operating system, reading the commands you type, figuring out what you mean, and asking the kernel to do the actual work. When you type ls or cd /var/log, you're not talking to the operating system directly; you're talking to the shell, and the shell translates that into system calls the kernel understands.
"A shell" is a concept, not a single piece of software, similar to how "a browser" describes a category that includes Chrome, Firefox, and Safari. Each one renders web pages, but they're built differently and behave differently in the details. Shells work the same way: each one interprets commands, but the syntax, features, and behavior can vary quite a bit from one to the next, which is exactly why it's worth knowing which one you're actually using.
sh refers to the original Bourne shell, written by Stephen Bourne at Bell Labs in the 1970s, and it's the shell the POSIX standard is modeled after. On most modern Linux systems, /bin/sh isn't literally the historical Bourne shell anymore; it's usually a symlink to a smaller, POSIX-compliant shell like dash. The name stuck around as shorthand for "the basic, portable shell," and scripts that start with #!/bin/sh are generally expected to avoid any syntax that isn't part of the POSIX spec.
Bash, short for "Bourne Again Shell," is the shell most Linux distributions have shipped as the default for decades, which is a big part of why "shell" and "bash" get used interchangeably. It was written by Brian Fox for the GNU Project as a free replacement for the Bourne shell, and according to the official GNU Bash manual, it implements the IEEE POSIX shell specification while adding its own extensions, things like command history, tab completion, associative arrays, and more capable scripting logic than the original Bourne shell offered. If you want a deeper look at bash specifically, we've covered that in more detail in our piece on what bash actually is and how it works.
Dash is a minimal, fast shell that many Debian-based distributions use as the actual target of the /bin/sh symlink, precisely because it starts up faster and uses fewer resources than bash. It sticks closely to POSIX and skips most of bash's interactive conveniences, which makes it a good fit for running system startup scripts where speed matters more than features.
Zsh builds on bash-like syntax and adds a lot of quality-of-life features on top: richer autocompletion, easier theming, and a large ecosystem of frameworks like Oh My Zsh for customizing it further. It's been the default interactive shell on macOS since Catalina, and plenty of Linux users switch to it for the same reasons, even though bash usually remains available underneath for scripts.
The Korn shell was developed at Bell Labs in the early 1980s and introduced several features that later showed up in bash, including command history and improved scripting constructs. It's less common as a default shell today, but it still turns up in some enterprise Unix environments and older scripts that were written before bash became the standard.
The C shell uses syntax that looks more like the C programming language, which some users find more intuitive and others find awkward for scripting. Tcsh is an enhanced version with better interactive features like command completion. Neither is common as a default shell on Linux today, but they still show up on some BSD systems and in certain legacy scripts.
Fish is built specifically for interactive use, with syntax highlighting, autosuggestions, and sane defaults out of the box rather than requiring a bunch of configuration to get there. The tradeoff is that it's less POSIX-compliant than the others, so scripts written for bash or sh often need adjustments to run correctly under fish.
None of these are "wrong" choices; they trade off differently between speed, interactive features, compatibility, and how closely they stick to the POSIX standard. A sysadmin writing a script meant to run on almost any Unix-like machine might deliberately target sh for portability, while a developer who lives in the terminal all day might prefer zsh or fish for the day-to-day conveniences.
This isn't just semantics. If you write a script starting with #!/bin/bash and it uses bash-specific features like arrays or [[ ]] conditional syntax, that script can break or behave unexpectedly if it's actually executed by a different shell, such as dash, which is what sh points to on many Debian-based systems. This is a genuinely common source of "it worked on my machine" bugs when moving scripts between servers or containers.
It also matters when you're troubleshooting. If a command behaves strangely, the shell you're in, along with its configuration files and environment variables, is one of the first things worth checking, well before you start suspecting the operating system itself. On a server, the shell your account launches into is often set up during initial provisioning, alongside other system-level settings that get configured when the machine boots up.
Before troubleshooting anything shell-related, it helps to know what you're actually running. There are a couple of quick ways to check.
The simplest is to run:
echo $SHELL
This prints the path to your default login shell, something like /bin/bash or /usr/bin/zsh. Keep in mind this shows your configured default, not necessarily the shell process currently running if you've launched something else on top of it.
For the shell that's actually active right now, try:
ps -p $$
This shows the process running in your current session, which is more reliable if you've switched shells temporarily. You can also check /etc/passwd for your account's assigned login shell, which is what runs by default whenever you log in.
If you decide you want to try a different shell, either just for a session or as your permanent default, both are straightforward.
To try a shell temporarily, just type its name and hit enter, like running zsh or fish directly from your current session. This starts a new shell process on top of your existing one, and typing exit drops you back to where you started.
To change your default login shell permanently, use the chsh command:
chsh -s /usr/bin/zsh
You'll need to log out and back in for the change to take effect, and the path needs to match wherever that shell is actually installed on your system, which you can confirm with which zsh or by checking /etc/shells for the list of shells your system recognizes as valid options.
| Shell | Known for | Best fit for |
|---|---|---|
| sh | The original POSIX-standard shell | Scripts that need to run portably across almost any Unix-like system |
| bash | The default interactive shell on most Linux distributions | General day-to-day use and scripts that need broad compatibility |
| dash | A minimal, fast, POSIX-compliant shell | Running system startup scripts where speed matters more than features |
| zsh | Bash-like syntax with richer autocompletion and theming | Interactive daily use, especially with frameworks like Oh My Zsh |
| ksh | An early shell that influenced many of bash's features | Enterprise or legacy Unix environments |
| csh/tcsh | C-like syntax, with tcsh adding better interactive features | Legacy scripts and some BSD systems |
| fish | Syntax highlighting and autosuggestions out of the box | Interactive use, though less POSIX-compliant for scripting |
Bash gets most of the attention, but it's one entry in a much wider family of Linux shells, each built with different priorities around speed, portability, or interactive convenience. Knowing the differences between sh, bash, dash, zsh, ksh, csh, and fish helps you pick the right one for the job and troubleshoot faster when a script behaves differently than you expect.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. You can also explore IP transit, shared hosting, and general IT services for whatever your infrastructure needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
They're not the same thing. The terminal (or terminal emulator) is the window or application that displays text and passes your keystrokes along; the shell is the program running inside it that actually interprets your commands. You could open the same terminal application and run bash, zsh, or fish inside it; the terminal itself doesn't change.
Most Linux distributions, including Ubuntu, Debian, and Fedora, use bash as the default interactive shell for user accounts, though system scripts often run under a lighter shell like dash for speed. It's worth checking your specific distribution's defaults, since some, like Kali or certain Arch-based setups, ship with zsh instead.
It depends on what you're optimizing for. Bash is the safest default for compatibility since it's available on nearly every Linux and Unix system you'll connect to, which matters a lot for scripts. Zsh or fish are worth considering if you spend a lot of time typing commands interactively and want more built-in conveniences, since neither is guaranteed to be present on a server you don't control.
Yes, and it's common. Having bash, zsh, and fish all installed at once causes no conflicts; you simply choose which one to launch interactively or set as your default login shell with chsh. Scripts also specify their own interpreter via the shebang line at the top of the file, so different scripts on the same system can rely on different shells without issue.
"Better" depends on what you're optimizing for. Zsh offers more built-in interactive features like richer autocompletion and easier customization through frameworks like Oh My Zsh, while bash has broader compatibility and is nearly guaranteed to be present on any Linux or Unix system you connect to. For scripting that needs to run reliably across many machines, bash (or plain POSIX sh) is usually the safer bet.
Bash is the command-line shell and scripting language that runs behind most Linux (and more) systems and servers. Here's what it does, where it came from, and how to start using it.
]]>Bash stands for "Bourne Again Shell," and it's both a command interpreter and a scripting language for Unix-like operating systems. When you open a terminal window and type a command like ls or cd, you're talking to Bash. It reads what you typed, figures out what you meant, and hands it off to the operating system to actually execute. In that sense, Bash acts as the middleman between you and the Linux kernel, translating human-typed commands into system calls.
It's also a full scripting language in its own right. You can string commands together, add variables, write loops, define functions, and save all of it into a file that runs on its own. That dual role, interactive command line tool and scripting language, is a big part of why Bash became so widely used.
Bash is developed as part of the GNU Project, and it's free software, which means anyone can use, study, and modify it without paying licensing fees. That openness played a real role in how far it spread.
Bash was written by Brian Fox and released in 1989 as a free replacement for the original Bourne shell, which had been the standard Unix shell since the late 1970s. The Bourne shell (often called sh) was solid, but it wasn't open source, and the Free Software Foundation wanted a shell that people could freely use, share, and improve as part of the broader GNU operating system effort.
The name itself is a pun: "Bourne Again Shell" nods to both the shell it replaced and the idea of being reborn as free software. Fox built Bash to be compatible with the Bourne shell's syntax, so existing scripts would mostly still work, while also pulling in useful features from other shells of the era like the Korn shell (ksh) and the C shell (csh). That combination of backward compatibility and added functionality is a big reason Bash caught on so quickly once Linux distributions started shipping it as the default.
Today, Bash remains the default shell on most major Linux distributions, and it was among the very first tools Linus Torvalds ported over when he started building Linux in the early 1990s.
It's worth pausing on why Bash gets described as both a shell and a language, because that distinction trips people up.
As a shell, Bash is what you interact with every time you type a command interactively. It handles things like tab completion, command history (pressing the up arrow to recall a previous command), and job control, which lets you pause, background, or kill running processes without closing your terminal. Bash is just one member of a wider family of shells though; if you want to see how it stacks up against sh, zsh, dash, and others, our piece on the different types of shells in Linux breaks that down further.
As a language, Bash lets you write scripts: plain text files full of commands, conditionals, and loops that run from top to bottom just like any other program. This is where automation lives. Instead of typing the same ten commands every time you deploy an application or back up a database, you write them once into a .sh file and run that file whenever you need it.
A few core capabilities show up again and again in day-to-day Bash use, and they're worth understanding even at a high level.
Piping and redirection let you chain commands together and control where their output goes. The pipe symbol (|) takes the output of one command and feeds it as input to the next, so you can, for example, list files and immediately filter that list for a specific name. Redirection operators (> and >>) send output to a file instead of your screen, which is handy for logging.
Variables and environment variables let scripts store and reuse values, whether that's a file path, a username, or a configuration setting. Functions let you group a set of commands under a name so you can call them repeatedly without rewriting the same lines.
Loops and conditionals (for, while, if) give Bash scripts actual logic, letting them make decisions or repeat actions based on conditions, which is what turns a list of commands into a genuine program.
Job control lets you manage multiple running processes from a single terminal session, sending tasks to the background with & or bringing them back with fg, which matters a lot when you're managing long-running processes on a remote server.
Bash isn't the only shell out there. Zsh, fish, ksh, and dash all serve similar purposes, and some distributions default to a different one depending on their goals; Debian and Ubuntu, for instance, use dash for system scripts because it's faster to start, even though Bash remains the interactive default for users. macOS switched its default interactive shell to zsh a few years back, though Bash is still available and widely used.
What keeps Bash relevant despite the competition is its near-universal availability. If a Linux system exists, there's a very good chance Bash is installed on it, which makes it a safe choice when you're writing scripts meant to run across different environments. It's also tightly connected to how the rest of a Linux system starts up and manages processes; if you're curious how a shell like Bash fits into the bigger picture of how a system boots and runs services, our article on init versus systemd is a good next read.
Before writing or running scripts, it's worth confirming which version of Bash you're working with, since some newer syntax and features only work on more recent releases. Open a terminal and run:
bash --version
This prints the version number along with some copyright information. If you just want the version number by itself, you can check the built-in variable instead:
echo $BASH_VERSION
Most modern Linux distributions ship with Bash 5.x, though older systems or minimal container images sometimes still run 4.x. If you're managing your own server or a virtual machine, checking this once at setup can save you a headache later when a script uses a feature your installed version doesn't support.
Getting started with a Bash script takes just a few steps. First, create a new text file and give it a .sh extension, something like hello.sh. At the top of the file, add what's called a shebang line, which tells the system which interpreter to use:
#!/bin/bash
echo "Hello from bash!"
That first line, #!/bin/bash, points to the location of the Bash executable so the script knows what to run it with. Below that, you can add any commands you'd normally type into the terminal.
Save the file, then make it executable with:
chmod +x hello.sh
From there, you can run it with:
./hello.sh
You should see "Hello from bash!" printed to your terminal. From that simple starting point, you can build out real scripts with variables, loops, and conditionals to automate anything from server maintenance to deployment pipelines. Bash scripting is genuinely one of those skills that pays off quickly if you're spending any real time on the command line, since even a handful of small scripts can save hours of repetitive typing.
Bash has stuck around since 1989 for good reason: it's free, it's everywhere, and it does exactly what a shell needs to do without much fuss. Whether you're running a single command or automating an entire deployment process, understanding the basics of Bash makes working on Linux systems a lot more comfortable.
Thanks for reading! If you're looking for reliable infrastructure, xTom provides enterprise-grade dedicated servers and colocation services, while V.PS offers scalable, production-ready NVMe-powered VPS hosting perfect for any workload. You can also explore IP transit, shared hosting, and general IT services for whatever your infrastructure needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
Bash stands for "Bourne Again Shell." The name is a play on words referencing the original Bourne shell it was designed to replace, and the idea of that shell being reborn as free software under the GNU Project.
No. Bash is a shell and scripting language that runs on Linux and other Unix-like systems; it isn't the operating system itself. Linux is the kernel, and Bash is one of several possible shells you can use to interact with it, though it happens to be the default on most distributions.
Not strictly, since many tasks can be done through a graphical interface. But if you're managing servers, working with cloud infrastructure, or doing anything that benefits from automation, learning basic Bash commands and scripting will make you significantly more efficient.
Bash is the interpreter itself, the program that reads and executes commands. A Bash script is a text file containing a sequence of those commands, saved so it can be run as a single program rather than typed manually each time.
Yes. Windows Subsystem for Linux (WSL) lets you run a real Linux environment, including Bash, directly on Windows. There are also standalone tools like Git Bash that provide a Bash-like environment without a full Linux installation.
]]>There's no single best place in the world to host your servers, but there is a best place for your project. Here's how location shapes speed, compliance, and reliability, and how to pick the right one.
]]>So is there a single best location for hosting? The honest answer is no, and anyone who tells you otherwise is probably trying to sell you a specific region. The more useful answer is that the right location depends on a handful of factors you can actually reason about, and once you understand them, the choice gets a lot less mysterious.
Let's walk through what location really changes, then get practical about how to choose.
The reason there's no universal best spot is simple: hosting serves wildly different goals. A game server for players in Sydney has nothing in common with a compliance-bound database for a German company, which has nothing in common with a low-latency trading box that needs to sit next to a financial exchange in Tokyo.
Each of those has a clearly correct answer. None of them is the same answer. So instead of hunting for one perfect city, you're really matching a location to the thing you're trying to do. That reframing is the whole trick.
Four things shift when you move your servers around the map. Get a feel for these and most decisions make themselves.
Latency is the delay between a request leaving your user's device and a response coming back. The biggest single factor is distance, because data still has to physically travel, and even light in a fiber cable has a speed limit. As a rough rule, signals move through fiber at around two-thirds the speed of light, which works out to roughly 1 millisecond of latency for every 100 kilometers, each way.
That sounds tiny until you stack it up. A user in London hitting a server in San Jose is looking at a round trip of well over 130 milliseconds before the server even does any work. For a static page, fine. For a chatty application that makes dozens of sequential calls, or anything real-time, that delay compounds into something users feel.
The takeaway: the closer your server sits to the people using it, the snappier everything feels. Distance is the cost you pay in milliseconds.
Here's where a lot of people get caught out. Two cities can be the same distance from your users and still deliver very different performance, because what matters isn't the straight-line distance, it's the route the traffic actually takes.
A well-connected data center sits near major Internet Exchange Points and peers directly with lots of networks, so your traffic takes a short, direct path. A poorly connected one might route your packets halfway across a continent and back before they reach their destination. This is why cities like Amsterdam, Frankfurt, Tokyo, and Singapore show up again and again in hosting maps: they're dense interconnection hubs where networks meet, so traffic in and out tends to be fast and well-peered.
If you want to see this for yourself rather than take a provider's word for it, a looking glass lets you check the real network path and round-trip time from a given location back to your part of the world. It's one of the most honest ways to compare two facilities.
Where your data physically lives decides which laws apply to it. If you handle personal data from people in the European Union, the GDPR shapes how and where you can store it, and hosting inside the EU often makes compliance simpler. Other regions have their own rules about data residency, government access, and privacy.
This is the factor people forget until it bites them. Cost and latency can be optimized later; a legal requirement to keep certain data in a certain country is not negotiable. If you operate in a regulated industry or serve a specific market, sort this out before you think about anything else.
Prices vary by region, sometimes a lot, driven by local electricity costs, real estate, taxes, and how competitive the market is. A rack in one metro can cost noticeably more than an equivalent setup elsewhere. Hardware availability and the specific services on offer also differ from one location to the next. None of this should override a hard latency or compliance need, but when two locations are otherwise close, cost is a fair tiebreaker.
With those factors in mind, here's a practical way to land on a decision without overthinking it.
Run through those five steps and you'll usually find the choice was never really about the single best city. It was about the best fit for your specific traffic, rules, and budget.
Sometimes the honest answer is that no single location works, because your users are genuinely spread across the globe or you can't afford a regional outage to take you offline.
In that case, you spread out on purpose. A common pattern is to run servers in two or three regions, say one in North America, one in Europe, and one in Asia Pacific, and route each user to the nearest one. This cuts latency for everyone and gives you redundancy, so a problem in one region doesn't take down the whole service. Content delivery networks take this idea further by caching static assets at the edge, close to users, while your core application still lives in a chosen home region.
Multi-region setups add complexity around data synchronization and cost, so they're not the default for every project. But for global audiences or services that can't go dark, distributing across locations beats trying to crown one winner.
There's no single best location for hosting, and chasing one is a distraction. The better move is to match a location to your project: host near your users, respect the laws that apply to your data, favor well-connected facilities, and spread across regions when one site can't cover everyone. Decide in that order and the "best" location reveals itself.
Picking the right region only pays off if the infrastructure underneath it is solid. xTom runs facilities across Asia Pacific, North America, and Europe, with dedicated servers and colocation in major interconnection hubs, scalable NVMe-powered KVM VPS through V.PS, IP transit for networks that want their own routing, shared hosting for simpler projects, and a range of general IT services to round it out.
Ready to discuss your infrastructure needs? Contact our team to explore the right location and setup for your project.
Yes. The farther data has to travel between your server and your users, the higher the latency, and the slower pages feel. Network quality and peering matter too, but for most sites, hosting closer to your main audience is one of the easiest performance wins available.
In most cases, near your users, because distance is the biggest driver of latency. That said, a location close to a major interconnection hub often gives you both, since those hubs tend to sit in or near large population centers and offer excellent peering. When forced to choose, prioritize proximity to your audience.
Data sovereignty means the data you store is subject to the laws of the country it physically sits in. If you handle regulated or personal data, rules like the GDPR may require you to keep it within a specific region. Sort out these requirements before optimizing for speed or cost, since legal obligations aren't something you can engineer around later.
If your users are spread across multiple continents, or you can't tolerate a regional outage, then yes, a multi-region setup lowers latency for everyone and adds redundancy. For a project with a single regional audience, one well-chosen location is usually simpler and plenty.
There's no single winner, but cities like Amsterdam, Frankfurt, Tokyo, Singapore, and the major US metros are known for dense interconnection and strong peering. The practical way to compare is to test real round-trip times from your users' networks rather than relying on reputation alone.
]]>Getting your own IP addresses can mean going straight to a Regional Internet Registry for next to nothing, or paying to lease or buy space on the open market. Here's how each route works, what it costs, and which one actually fits your situation.
]]>It's a fair question, and the honest answer is that there's more than one path. You can go straight to the source and request space directly, which costs almost nothing but tends to take a while. Or you can pay for it on the open market, either by leasing addresses month to month or buying them outright. Each route trades off cost, speed, and how much control you walk away with.
Let's walk through all three, starting with the free and patient option, then moving into the paid routes.
Before picking a route, it helps to know who hands these things out. No single company owns the internet's address space. At the top sits IANA, the Internet Assigned Numbers Authority, which carves the global pool into large chunks and distributes them to five regional bodies called Regional Internet Registries, or RIRs.
Those five registries each cover a part of the world: ARIN for North America, RIPE NCC for Europe, the Middle East, and parts of Central Asia, APNIC for the Asia-Pacific region, LACNIC for Latin America, and AFRINIC for Africa. If you want a deeper look at how this whole system is structured, we've covered it in our guide to what a Regional Internet Registry is.
Which registry matters to you depends on where your organization is legally based. That's the front door for the free route, so let's start there.
The cheapest way to get your own addresses is to request them directly from your registry. There's a twist, though: this route behaves completely differently for IPv6 than it does for IPv4.
This is where the "free" part really holds up. To get space directly, your organization usually becomes a member of its RIR. In the RIPE region that membership makes you a Local Internet Registry, or LIR. It isn't literally free; RIPE NCC charges a one-time sign-up fee plus an annual service fee, which in 2026 works out to roughly €1,000 to join and €1,800 a year. But once you're in, your first IPv6 allocation, typically a /32, comes at no extra charge and with very little paperwork. RIPE generally just wants a simple statement that you plan to deploy it within the next year.
If full membership feels like overkill, end users can also get provider-independent IPv6 space through a sponsoring LIR, which is lighter and cheaper than running your own registry account.
The reason IPv6 is so painless is supply. There's an almost unimaginable number of IPv6 addresses, so registries are happy to hand them out. The catch is adoption: plenty of the internet still leans on IPv4, so IPv6-only deployments can hit compatibility gaps. If you're weighing the two, our breakdown of IPv4 vs IPv6 goes through the practical differences.
IPv4 is a different story. The world ran out of fresh IPv4 addresses years ago. ARIN's free pool ran dry back in September 2015, and the other registries followed. So you can't simply ask for a brand-new block and get one.
What you can do is join the IPv4 waiting list. When addresses get returned, reclaimed, or revoked for non-payment, registries redistribute them to organizations waiting in line. It costs nothing beyond your membership fees, but the constraints are real. The wait is long; at RIPE, members typically sit on the list somewhere between 12 and 24 months. The block is small, too: RIPE hands out a single /24, which is 256 addresses, while ARIN's waitlist tops out at a /22 and lets you elect a smaller size down to a /24. Eligibility is limited as well, since ARIN won't add you to the list if you already hold a /20 or more. And there's a holding period: addresses from ARIN's waitlist can't be transferred to anyone else for five years.
So the free route is genuinely cheap, but it rewards patience and suits organizations that can plan months ahead. If you need addresses now, you're looking at the paid market.
There are two flavors of paying for IPv4: renting it or owning it. Both pull from what's called the secondary market, since registries no longer sell from a fresh pool.
One thing both routes share is that getting the addresses is only half the job. To actually use them on the public internet, the routes to your block have to be announced using BGP, the protocol that tells the rest of the internet where your addresses live. That usually means having your own Autonomous System Number, or ASN, plus an upstream provider willing to carry your announcements through IP transit. If you lease through a hosting provider that already announces the space for you, this part is handled on your behalf.
Leasing means renting address space: you pay a monthly fee while someone else keeps ownership. It's the faster, lower-commitment option, which makes it popular with startups, short-term projects, and anyone bridging toward IPv6.
Lease rates have stayed steadier than purchase prices over the years. As of 2026, most blocks in the RIPE and ARIN regions lease for roughly $0.30 to $0.50 per IP per month, with APNIC space running higher, often above $0.60, because supply there is tighter. A /24 of 256 addresses tends to land somewhere in the rough neighborhood of $80 to $150 a month, though the exact figure depends on block size, region, and the reputation of the addresses.
Marketplaces like IPXO and IPv4.Global connect holders of unused space with people who want to lease it. Reputation matters more than people expect here; if a block was previously used by a spammer and landed on blocklists, your mail and traffic can suffer, so it's worth checking a block's history before you commit. You can look up who a block is registered to and its current status using an RDAP lookup, and we built a free RDAP client for exactly that.
The downside of leasing is that you never own the asset. Stop paying and the addresses go back. For a lot of businesses that's a perfectly fine trade for the flexibility.
Buying gives you the addresses outright. Since registries don't sell from a fresh pool anymore, a purchase is really a transfer: ownership of an existing block moves from the seller to you, recorded officially through your RIR's transfer process, such as ARIN's section 8.3 transfer.
In 2026, IPv4 sells for roughly $20 to $45 per address depending on block size and region. Larger blocks like a /16 have actually dropped below $20 per IP, while smaller and more in-demand /24s sit at the higher end. Buying a single /24 outright, then, runs somewhere in the rough range of $9,000 to $12,000 as a one-time cost.
What you get for that is permanent control, no recurring lease fees, and an asset you can resell or even lease out yourself later. What you take on is a significant upfront cost, responsibility for the block's reputation, and a transfer process where you'll need to meet your registry's policies and justify the need. Brokers handle the paperwork and escrow for a cut, which is worth it for most first-time buyers.
Buying makes the most sense when you have long-term, stable address needs and you'd rather own the space than carry an ongoing bill.
Pulling it all together, here's a sensible way to approach it.
Start by figuring out what you actually need. How many addresses, and IPv4, IPv6, or both? A handful of IPv6 addresses for a modern deployment is a very different ask from a /22 of IPv4 for a hosting fleet. Be honest about your timeline too, because that single factor often decides the route for you.
If you can wait and you mostly need IPv6, go straight to your RIR. Identify your region's registry, become a member or work through a sponsoring LIR, and request your allocation. You'll have IPv6 quickly, and you can park yourself on the IPv4 waiting list at the same time.
If you need IPv4 soon and want flexibility, lease it. Pick a reputable marketplace, or a hosting provider that includes address space, check the reputation of any block before you commit, and confirm how the addresses will be announced.
If you need IPv4 for the long haul and want to own it, buy through a broker or directly from a seller, and budget for the transfer process through your RIR.
Whichever route you take, make sure you can actually route the space. That means sorting out your ASN, BGP, and an upstream willing to carry your announcements before the addresses are any use. If you're getting the space bundled with hosting or transit, your provider usually takes care of all of that.
Obtaining your own IP addresses comes down to a trade between time and money. The free route through a Regional Internet Registry costs little beyond membership and gets you IPv6 quickly, but IPv4 means a long wait for a small block. Leasing gets you IPv4 fast without a big upfront spend, at the cost of ongoing fees and no ownership. Buying hands you permanent control and resale value, but it asks for real money up front and a bit of paperwork. None of them wins across the board; the right one depends on your timeline, your budget, and how much you want to own.
If you'd rather skip the registry queues and routing headaches altogether, xTom can provide the infrastructure with address space already sorted. We offer enterprise-grade dedicated servers and colocation, scalable NVMe-powered KVM VPS through V.PS, IP transit to carry your announcements, shared hosting, and a full range of general IT services to round things out.
Ready to discuss your infrastructure needs? Contact our team to find the right setup for your project.
More or less, for IPv6. Once you're a member of your Regional Internet Registry, your first IPv6 allocation comes at no extra charge beyond membership fees. IPv4 is harder; you can join your registry's waiting list at no extra cost, but you'll wait a year or two for a small block. Truly free IPv4 on the open market no longer exists.
As of 2026, most blocks in the RIPE and ARIN regions lease for roughly $0.30 to $0.50 per IP per month, with APNIC space running higher. A /24 of 256 addresses lands around $80 to $150 a month, depending on block size, region, and the reputation of the addresses.
About $20 to $45 per address in 2026, depending on block size and region. Larger blocks cost less per IP, while smaller /24s cost more. A single /24 works out to roughly $9,000 to $12,000 as a one-time purchase.
If you want to announce the space yourself on the public internet, then yes, you'll generally need your own ASN and a BGP setup, along with an upstream provider to carry your announcements. If you lease addresses through a hosting provider that announces them for you, you don't need your own ASN.
Leasing is renting: lower upfront cost, monthly fees, no ownership, and easy to scale up or down. Buying is owning: high upfront cost, no recurring fees, full control, and the option to resell later. Leasing suits short-term or uncertain needs; buying suits long-term, stable ones.
Look up its registration and history first. An RDAP lookup shows who a block is registered to and its status, and you can check whether the addresses appear on any blocklists.
The one covering where your organization is legally based: ARIN for North America, RIPE NCC for Europe and the Middle East, APNIC for the Asia-Pacific region, LACNIC for Latin America, and AFRINIC for Africa.
]]>IPv4 prices went through one of the sharpest corrections on record in 2025, and 2026 is showing the first real signs of a turnaround. Here's what the latest market data says an IP address actually costs this year, and what's driving the numbers.
]]>When people talk about paying for IP addresses, they're almost always talking about IPv4. IPv6 is so abundant that registries effectively give it away; once you're a member of your registry, an IPv6 allocation usually comes at no extra charge. There's no meaningful resale market because there's no scarcity. If you want the background on why the two protocols behave so differently, our explainer on IPv4 vs IPv6 covers it.
IPv4 is the opposite. There are only about 4.3 billion addresses, the free pools at the registries are exhausted, and roughly 3.9 million unallocated addresses are left worldwide, mostly sitting in the APNIC and AFRINIC regions. Practically speaking, the only way to get IPv4 now is the secondary market: buying or leasing existing space from whoever already holds it. That scarcity is the whole reason a price exists at all. So for the rest of this article, "IP address prices" means IPv4 prices.
Pricing depends heavily on the size of the block you're after, the region it's registered in, and the reputation of the addresses. As a rough guide, here's where the market sits in 2026 based on data from IPv4.Global, the largest IPv4 marketplace, alongside lease figures tracked by platforms like IPXO.
| Block size | Addresses | Approx. purchase price per IP | Approx. lease per IP / month |
|---|---|---|---|
| /24 | 256 | $28 to $40 | $0.38 to $0.50 |
| /22 | 1,024 | $22 to $30 | $0.38 to $0.48 |
| /20 | 4,096 | $21 to $30 | $0.35 to $0.45 |
| /16 | 65,536 | $13 to $22 | $0.30 to $0.40 |
A couple of things stand out. First, the per-address price drops as blocks get larger, which is normal, but the gap has stretched to an unusual degree (more on that in a moment). Second, leasing has stayed remarkably stable while purchase prices swung wildly.
To put that in real money: buying a single /24 outright runs somewhere around $7,000 to $9,000 as a one-time cost, while leasing the same block lands near $100 to $130 a month. A /20 leases for roughly $1,500 to $1,800 a month. If the slash notation is unfamiliar, our guide to IPv4 vs IPv6 block sizes breaks down how many addresses each prefix holds.
Region matters too. ARIN-registered space has historically commanded a 5 to 15% premium over RIPE addresses, mostly because of where buyers want their traffic to appear, while APNIC purchase prices tend to run lower. Leasing flips that for APNIC, where tight supply pushes lease rates above $0.60 per IP per month. The differences come down to which Regional Internet Registry governs the block.
The 2026 numbers only make sense against the backdrop of what just happened, and it's a genuinely dramatic arc.
Rewind to late 2023. At that point, big blocks were the expensive ones. IPv4.Global data showed /16 and larger blocks trading near $52 per address, while smaller /20 to /24 blocks changed hands closer to $36. That 44% premium for large blocks was historically odd, and the reason was specific: hyperscale cloud operators were hoarding large, contiguous blocks to expand their infrastructure, and their appetite dragged prices up to levels that couldn't last.
That demand held until around July 2024, then the floor gave way. By the second half of 2024, the premium had evaporated entirely and blocks of every size were trading at roughly the same $33 per address. The convergence surprised plenty of people who'd treated the large-block premium as permanent.
It didn't stop at convergence. Through 2025, large blocks fell off a cliff. A /16 that started the year near $33 per address dropped below $13 by the fourth quarter, with some bulk deals clearing under $10. That's a contraction of more than 60% in a single year, and a ten-year low. In May 2025, the /16 slipped under $20 per address for the first time since 2019, which became the headline marker of how far things had fallen. Mid-size blocks followed the slide, with /17 to /19 ending the year near $16 and /20 to /21 near $21.
Here's the part that matters most, though: demand never actually broke. Transaction volume stayed strong throughout the decline. In July 2025, IPv4.Global recorded 98 transactions in the month against a typical average of 73, a 32% jump, even as prices were sinking. When price falls but volume rises, that's not a market collapsing. It's a market repricing to a new level, with a broader base of buyers stepping in.
Small blocks, the /22 to /24 range, told a completely different story through all of this. They dipped, but only modestly, and by mid-2025 they were trading at more than double the per-address rate of /16s. The old pattern, where buying big got you a steep discount, didn't just narrow; it reversed into an extreme.
The reason is who's buying. Small blocks have a wide, steady, practical buyer base: regional ISPs, hosting providers, and businesses that need a targeted slice of addresses for a specific project. That demand shows up month after month regardless of what the giant blocks are doing. On top of that, cloud platforms like AWS and Azure now charge for IPv4 usage, which pushes companies to buy their own space on the secondary market and bring it to the cloud through BYOIP programs. That's a structural floor under small-block prices that simply doesn't exist for /16s.
One of the clearest lessons in the 2025 data is how differently leasing and buying behaved. While purchase prices for large blocks were losing 60% of their value, lease rates barely moved, holding in a $0.38 to $0.50 per IP per month band across most RIPE and ARIN blocks. That stability is exactly why a lot of businesses treat leasing as the lower-risk option.
The trade-off is straightforward. Leasing means predictable monthly costs, no big upfront spend, and the freedom to scale up or down, but you never own the asset. Buying means a large one-time cost and responsibility for the block's reputation, in exchange for permanent control and an asset you could resell or lease out later. The wild swings on the purchase side are precisely what make leasing feel safe, and the steadiness of leasing is part of what puts a floor under small-block purchase prices.
Whichever way you go, owning or leasing the addresses is only useful if you can route them. That means having an Autonomous System Number, announcing the space with BGP, and an upstream provider carrying your routes through IP transit, unless you're getting the space bundled with hosting that handles all of that for you.
A handful of forces are shaping the numbers this year. On the supply side, legacy holders like universities, telecoms, and restructured companies spent 2024 and 2025 monetizing address space they weren't using, which flooded the large-block market and drove those prices down. At the same time, the hyperscale cloud buyers who'd propped up large-block pricing largely stepped back.
On the demand side, a new category showed up: AI infrastructure. GPU clusters and the data centers behind them need IPv4 for management networks, API endpoints, and customer-facing services, and that demand barely existed during the last big buying cycle. Broadband buildouts are adding pressure too; the US BEAD program, a roughly $42 billion push to expand rural coverage, is expected to lift IPv4 demand by 10 to 20% as providers build the networks that deliver those connections. Reputation also moves prices at the margins, with clean, well-documented blocks commanding a 10 to 15% premium over space with a spotty history. Before you commit to any block, it's worth checking its registration and reputation, which you can do with an RDAP lookup.
Hanging over all of it is IPv6. Adoption keeps creeping forward, and every network that goes IPv6-native is one that needs a little less IPv4. That doesn't crater prices overnight, but it does cap how high they can realistically climb over the long run.
Based on the first four months of 2026, the market looks like it found its floor. January brought record transaction volume and a wave of new buyers. February held steady and even ticked up for some block sizes. March delivered a measurable price increase across the board, and April confirmed it with broad demand spread across block sizes rather than concentrated in one corner.
IPv4.Global's own projection, published in June 2026, expects a gradual recovery through year-end: large /16+ blocks climbing from their $10 to $13 lows toward $15 to $22 per address, medium blocks landing in the $18 to $30 range depending on size, and small /22 to /24 blocks holding firm around $30 to $36, with ARIN space at the higher end. None of that is a return to the 2022 peak, and it's a projection rather than a promise, but the direction has clearly shifted from "how far will it fall" to "how fast will it recover." If AI infrastructure demand accelerates, the recovery could move faster than those figures suggest.
IPv4 prices in 2026 are best understood as a market coming out of a steep correction. Large blocks lost more than 60% of their value in 2025 before bottoming out near ten-year lows, small blocks held firm and now cost more per address than the big ones, and leasing stayed steady through all of it at roughly $0.40 per IP per month. Early 2026 data points to a measured recovery, driven by steady operational demand, a new wave of AI infrastructure buyers, and tightening supply. For anyone budgeting for address space this year, the headline is that timing and block size matter more than they have in a long while.
If you'd rather not navigate the secondary market and registry transfers yourself, xTom can provide the infrastructure with address space already handled. We offer enterprise-grade dedicated servers and colocation, scalable NVMe-powered KVM VPS through V.PS, IP transit to carry your announcements, shared hosting, and a full range of general IT services to round things out.
Ready to discuss your infrastructure needs? Contact our team to find the right setup for your project.
It depends on block size and region, but as a rough guide, expect roughly $28 to $40 per address for a small /24 block and $13 to $22 for a large /16. Per-address prices fall as blocks get bigger. A single /24 of 256 addresses works out to somewhere around $7,000 to $9,000 to buy outright, or about $100 to $130 a month to lease.
Large blocks fell more than 60% over the year, mainly because legacy holders started selling off unused address space at the same time that hyperscale cloud operators, who had been the biggest buyers of large blocks, stepped back from the market. More supply plus less demand at the top end pushed prices to ten-year lows.
Small blocks have a broad, steady base of buyers, including hosting providers and businesses bringing their own addresses to cloud platforms, so demand stays consistent. Large blocks depend on a much smaller set of big buyers, and when those buyers stepped back, large-block prices fell faster. By mid-2025, small blocks were trading at more than double the per-address rate of the largest blocks.
It depends on your time horizon. Leasing costs roughly $0.38 to $0.50 per IP per month and avoids a big upfront spend, which suits short-term or variable needs. Buying costs more up front but has no recurring fees and gives you a resellable asset, which suits long-term, stable requirements. Lease rates stayed steady even while purchase prices swung sharply, so leasing is often the lower-risk choice.
Yes. ARIN-registered addresses typically carry a 5 to 15% premium over RIPE space on purchases, while APNIC purchase prices tend to run lower. For leasing, APNIC often costs more, above $0.60 per IP per month, because supply there is tighter.
The early 2026 data suggests prices have bottomed out and begun a gradual recovery, helped by strong demand and new buyers from AI infrastructure. Most market observers expect modest increases through year-end rather than a sharp spike, though projections are not guarantees and prices vary widely by block.
No. IPv6 is plentiful enough that there's no real resale market, and a first IPv6 allocation usually comes at no extra cost beyond your registry membership fees. The pricing pressure that affects IPv4 simply doesn't apply to IPv6.
]]>A point of presence (PoP) is the physical spot where one network meets another and hands off traffic, and it quietly shapes how fast your sites and apps feel. Here's what a PoP actually is, what lives inside one, and how to check a provider's PoP footprint before you commit.
]]>PoPs are everywhere in networking, and they shape real things like latency, reliability, and how close your servers can get to the people using them. But the term gets used loosely, so it helps to slow down and look at what a PoP really is, what sits inside one, and why it matters when you're choosing where to host. Let's break it down.
At its simplest, a point of presence is a physical location where a network connects to other networks and to the wider internet. It's the spot where traffic gets handed off between different parties. If you connect to the internet through an ISP, the place where your traffic enters that ISP's network is a PoP. If a provider sells you transit or colocation, the facility where their routers live and interconnect with everyone else is also a PoP.
The term goes back further than the internet as we know it. After the court-ordered breakup of the Bell telephone system in the United States, a point of presence was the location where a long-distance carrier could hand traffic off into the local phone network. The core idea stuck around: a PoP is a boundary, a meeting point where one network ends and another begins. The technology underneath has changed a lot since the days of phone switches, but the concept has aged well.
These days, when a hosting or transit provider talks about their PoPs, they usually mean the cities and facilities where they have networking gear installed and connected. A provider with PoPs in Frankfurt, Tokyo, and San Jose has a physical footprint in all three, with equipment ready to carry your traffic and exchange it with other networks nearby.
A PoP isn't a single machine; it's a collection of networking hardware living inside a data center, often in leased rack space. The exact contents vary, but most PoPs share a similar cast of equipment.
You'll typically find routers, which are the devices that decide where traffic goes next and speak BGP to the rest of the internet. There are switches that move traffic around locally within the facility. There's cabling and cross connects, the physical links that join a provider's gear to other networks in the same building, including internet exchange points where many networks meet to swap traffic directly. And depending on the operator, there may be servers too, whether for caching, DNS, monitoring, or actual customer workloads.
The data center wrapped around all of this supplies the boring but important stuff: power, cooling, physical security, and fire suppression. A PoP only works because the facility keeps the lights on and the temperature steady around the clock.
One thing worth clearing up early: a PoP and a data center aren't quite the same thing. A data center is the building. A PoP is a network's presence inside that building. A single large facility can host PoPs for dozens of different networks, all sitting in their own cages and cabinets, interconnecting with each other. So when xTom announced its point of presence at Global Switch in Singapore, that meant installing networking equipment inside that facility and lighting up connectivity there, not building the data center itself.
To see why PoPs matter, it helps to picture how your data travels. When you load a page, your request leaves your device, reaches your ISP's nearest PoP, and from there hops across one or more networks until it arrives at the server holding the content. Each of those hops adds a little time. The fewer and shorter the hops, the snappier everything feels.
This is where a provider's PoP footprint starts to matter for you directly. If a network has PoPs close to your users, traffic can stay local instead of taking a long detour across continents. Networks that interconnect at a lot of locations can also lean on peering and IP transit to find efficient routes, which tends to mean lower latency and fewer surprises during congestion.
It's the same logic that makes a content delivery network (CDN) effective. A CDN spreads cached copies of your content across many PoPs, often called edge locations, so a visitor in Sydney gets served from somewhere nearby rather than from an origin server on the other side of the world. The PoP is the building block that makes that closeness possible.
PoPs also feed into redundancy. A network with presence in multiple cities can keep traffic flowing if one site or one upstream link has trouble, because there are other paths available. A single PoP is a single point of failure; several well-connected PoPs are a safety net.
If you're picking where to host servers or buy transit, the PoP question is worth a few minutes of homework. Here's a practical way to go about it.
Start by finding out where the provider's PoPs actually are. Most serious operators publish a list of their locations, and you want those locations to line up with where your users or your other infrastructure live. A provider with great coverage in Europe doesn't help much if your audience is in Southeast Asia.
Next, check the provider in PeeringDB, a free public directory that lists networks, the facilities they're present in, and the internet exchanges they connect to. It's one of the most honest signals you'll find, because networks maintain their own records there and other operators rely on them. A network that peers at well-known exchanges like DE-CIX in Frankfurt, AMS-IX in Amsterdam, or LINX in London is interconnecting where a lot of traffic already flows.
Then test the path yourself. A quick traceroute (or tracert on Windows) from your location to the provider's network shows you the hops your traffic takes and roughly how long each leg adds. Many providers also run a public looking glass, a web tool that lets you run pings and traceroutes from their PoPs back toward you, so you can measure latency from the other direction before you sign up.
Finally, think about redundancy and not just raw speed. Ask whether the provider has more than one PoP in the regions you care about, and whether they buy transit from multiple upstreams. Multihoming across providers is standard practice for anything you can't afford to have go dark.
Put those steps together and you get a clear picture: where the network lives, who it connects to, how fast it reaches you, and how well it holds up when something breaks.
A point of presence is a small idea with a big footprint. It's just the spot where networks meet, but those meeting points decide how close your infrastructure can get to your users, how many hops your traffic takes, and how gracefully things hold up when a link fails. Once you start noticing PoPs, you start seeing them behind almost every conversation about latency, transit, and reach.
If you're choosing where to put your infrastructure, having a provider with a well-connected PoP footprint makes a real difference. xTom offers enterprise-grade dedicated servers and colocation across global data centers, along with IP transit for networks that need direct, well-peered connectivity. For scalable compute, V.PS provides NVMe-powered KVM VPS hosting built for production workloads, and if you want to get started quickly there's shared hosting too. You can browse the full range of xTom services to see what fits.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
A data center is the physical building that supplies power, cooling, and security. A point of presence is a particular network's gear and connectivity inside that building. One data center can hold PoPs for many different networks at once, so the two terms describe different layers of the same setup.
More or less, yes. A CDN edge location is a point of presence where the CDN caches content close to users. The wider term PoP covers any network meeting point, while edge location is the CDN-specific flavor of the same idea.
A PoP close to your visitors shortens the physical distance their traffic has to travel and reduces the number of network hops along the way. Both of those cut latency, so pages and apps feel faster. A provider with PoPs near your audience, and good peering at those PoPs, will generally outperform one that routes everything through a distant hub.
Most providers publish a list of their locations on their site, and you can cross-check that against PeeringDB to see which facilities and internet exchanges they connect to. Running a traceroute to their network, or using their public looking glass, lets you measure the actual latency and routing from your own location before committing.
It depends on your reach and your tolerance for downtime. A single PoP can be plenty for a regional project on a budget, but if your users are spread across regions, or you can't afford outages, presence in multiple well-connected locations gives you both lower latency for distant users and a fallback path when something fails.
]]>Losing data on a Linux server is painful, and it's almost always preventable. This guide walks you through setting up automatic Linux backups using tools like rsync, cron, and tar, so your data is protected without you having to think about it.
]]>rm -rf, a failed drive — any of these can wipe out hours, days, or even months of work in seconds. The fix isn't complicated, though: a well-designed automatic backup strategy means that when something goes wrong (and eventually, something will), you're restoring from last night's backup rather than starting from scratch.
This guide covers how to set up automated Linux backups using tools that come standard on most distros. No paid software required, no vendor lock-in, just solid, time-tested methods you can set up in an afternoon.
The problem with manual backups is simple: people forget to do them. Or they do them inconsistently. Or they back up the wrong directories. Automation removes the human element from a task that really shouldn't depend on humans remembering to do it.
Beyond just running the backup, automation also lets you schedule backups during off-peak hours, rotate old backups to save disk space, and get notified if something fails. That's a lot harder to pull off reliably if you're doing it by hand.
Before jumping into scripts, it helps to know which tools you're working with and why they're suited for the job.
rsync is probably the most widely used backup tool on Linux. It copies files efficiently by only transferring what has changed since the last run, which makes incremental backups fast even over a network. It supports SSH out of the box, so you can back up to a remote server securely without any extra setup.
tar is the traditional Unix archiver. It bundles files and directories into a single archive (usually compressed with gzip or bzip2), which makes it easy to move backups around or store them as snapshots. Unlike rsync, tar creates a complete copy of everything in one file rather than a mirrored directory structure.
cron is the Linux job scheduler. It's what ties everything together by running your backup scripts on a schedule, whether that's nightly, hourly, or weekly.
Duplicati and BorgBackup are worth mentioning as well. Both are open-source tools that handle deduplication, encryption, and remote storage more elegantly than raw rsync or tar scripts. If you want a more feature-complete solution, either of these is worth exploring. But for this guide, we'll focus on the built-in tools since they work everywhere.
Here's a practical rsync command that backs up a directory to a remote server over SSH:
rsync -avz --delete /var/www/ user@backup-server:/backups/www/
Breaking that down: -a enables archive mode, which preserves permissions, timestamps, symlinks, and ownership. -v is verbose output so you can see what's happening. -z compresses data during transfer. --delete removes files on the destination that no longer exist on the source, keeping the backup in sync.
If you're backing up locally (for example, to a second drive mounted at /mnt/backup), just swap the destination:
rsync -av --delete /var/www/ /mnt/backup/www/
For remote backups, it's worth setting up SSH key authentication so the script can connect without prompting for a password. Without that, automated scripts will fail silently.
Rather than running rsync directly from cron, it's cleaner to write a shell script that handles the logic, logging, and any error handling you want.
Here's a starting point:
#!/bin/bash
# Configuration
SOURCE="/var/www /etc /home"
DEST="user@backup-server:/backups/$(hostname)"
LOG="/var/log/backup.log"
DATE=$(date +"%Y-%m-%d %H:%M:%S")
echo "[$DATE] Backup started" >> "$LOG"
for DIR in $SOURCE; do
rsync -az --delete "$DIR" "$DEST" >> "$LOG" 2>&1
if [ $? -ne 0 ]; then
echo "[$DATE] ERROR: Failed to back up $DIR" >> "$LOG"
fi
done
echo "[$DATE] Backup complete" >> "$LOG"
Save this as something like /usr/local/bin/backup.sh and make it executable:
chmod +x /usr/local/bin/backup.sh
Test it manually before adding it to cron:
/usr/local/bin/backup.sh
Check the log file afterward to make sure everything ran correctly.
Once your script is working, cron handles the scheduling.
Open the crontab editor as root:
crontab -e
To run the backup every night at 2 AM, add:
0 2 * * * /usr/local/bin/backup.sh
Cron syntax follows the format: minute, hour, day of month, month, day of week. The asterisk means "every" for that field. If you want to run it more frequently, say every six hours, you'd write:
0 */6 * * * /usr/local/bin/backup.sh
Crontab Guru is a handy tool for generating and verifying cron expressions if you're not confident in the syntax.
Running the same rsync command every night works, but you'll eventually end up with only one copy of your data, and it'll always reflect the most recent state. If a file gets corrupted or accidentally deleted and you don't notice for a few days, your backup will be corrupted too.
Backup rotation solves this by keeping multiple dated snapshots. Here's an approach using tar to create timestamped archives alongside your rsync backup:
#!/bin/bash
BACKUP_DIR="/mnt/backup"
SOURCE="/var/www"
DATE=$(date +"%Y-%m-%d")
ARCHIVE="$BACKUP_DIR/www-$DATE.tar.gz"
# Create a compressed archive
tar -czf "$ARCHIVE" "$SOURCE"
# Delete archives older than 30 days
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +30 -delete
The find command at the end handles cleanup automatically. You can adjust +30 to however many days of history you want to retain, keeping in mind the disk space implications.
File backups alone aren't enough if you're running a database. MySQL/MariaDB and PostgreSQL both need to be dumped properly to get a consistent, restorable backup.
For MySQL/MariaDB:
mysqldump -u root -p"$DB_PASSWORD" --all-databases | gzip > /backups/mysql-$(date +%F).sql.gz
For PostgreSQL:
pg_dumpall -U postgres | gzip > /backups/postgres-$(date +%F).sql.gz
These commands can be added to the same backup script and scheduled via cron alongside your file backups. Store the database password securely, ideally in a restricted file with chmod 600, rather than hardcoding it in the script.
Knowing a backup ran is as important as actually running it. You can configure cron to email you on failure by adding a MAILTO variable at the top of your crontab:
MAILTO=you@yourdomain.com
0 2 * * * /usr/local/bin/backup.sh
This only works if your server has a mail transfer agent configured (like Postfix). For a simpler approach, you can add a curl call inside your backup script to hit a webhook service like Healthchecks.io, which will alert you if a scheduled job stops checking in.
Keeping backups on the same server you're backing up isn't a real backup strategy; if the server fails, you lose both. At minimum, backups should go to a separate machine, a different location, or a cloud storage bucket.
rsync works great over SSH to a remote server. If you want to push to cloud storage, tools like rclone act as a bridge between your Linux server and services like AWS S3, Backblaze B2, or even SFTP destinations, using the same rsync-style syntax you're already familiar with.
A common pattern is the 3-2-1 rule: keep three copies of your data, on two different media types, with one copy offsite. It's a good target to work toward as your backup setup matures.
A backup that you've never restored from is just a backup you hope works. Schedule regular test restorations, even if it's just restoring a single file to verify the archive isn't corrupted. For tar archives:
tar -tzf /backups/www-2025-06-01.tar.gz | head -20
This lists the contents without extracting, letting you confirm the archive is intact. For a full test, restore to a temporary directory:
tar -xzf /backups/www-2025-06-01.tar.gz -C /tmp/restore-test/
Doing this even once a month will save you from the unpleasant surprise of discovering your backups were quietly failing for weeks.
Automated backups don't have to be complicated. With rsync, tar, and cron, you can have a working backup system in place within an hour, one that runs silently in the background and gives you real peace of mind. Start simple, test your restores, and add rotation and offsite storage as you go.
Whether you're running a small project or managing production infrastructure, xTom has the right solution to keep your workloads running reliably. We offer enterprise-grade dedicated servers, colocation services, IP transit, shared hosting, and a full range of IT services and solutions. For fast, scalable VPS hosting with NVMe storage, V.PS is a great fit for any workload, from dev environments to production deployments.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
There's no single answer, but rsync is a great default for most use cases because it's fast, handles incremental transfers well, and works over SSH without any additional software. For more advanced needs like deduplication and encryption, BorgBackup is worth considering.
It depends on how much data you can afford to lose. For production servers, nightly backups are a reasonable baseline; for databases or frequently changing files, hourly or even more frequent snapshots might make sense. The key is matching your backup frequency to your recovery point objective (RPO).
Yes, and it's a good idea. Using rsync over SSH, you can push backups from your VPS to any remote server you have SSH access to. Just set up SSH key authentication first so the process can run unattended.
At minimum, back up /home, /etc, /var/www (or wherever your web files live), and your database dumps. The /etc directory is especially important since it holds your system and application configuration. You generally don't need to back up /tmp, /proc, /sys, or /dev.
Check your log files after each run and, more importantly, do test restores regularly. Listing the contents of a tar archive or restoring a file to a temporary directory confirms the backup is intact and restorable, not just present on disk.
Use backup rotation: automatically delete archives older than a set number of days using a find command with -mtime. Combine this with rsync for live mirrors and tar for point-in-time snapshots, and you'll keep storage manageable while retaining meaningful history.
A content delivery network (CDN) is a globally distributed system of servers that delivers web content to users faster by serving it from a location close to them. This article explains what CDNs are, how they work under the hood, and when you actually need one.
]]>CDNs are one of those foundational pieces of internet infrastructure that most people interact with dozens of times a day without realizing it. If you've ever streamed a video, downloaded a software update, or loaded a news article quickly from the other side of the world, you've almost certainly been served by a CDN. Understanding how they work isn't just useful trivia; it's practical knowledge for anyone building or managing anything on the web.
A CDN is a geographically distributed network of servers that work together to deliver internet content, such as web pages, images, videos, JavaScript files, and stylesheets, to users more efficiently.
The core idea is simple: instead of every visitor fetching content from a single origin server (say, one located in Dallas), a CDN places copies of that content on servers spread across many locations worldwide. When someone in Tokyo requests your website, they get it from a server in Tokyo, not one in Dallas. That cuts down the physical distance the data has to travel, which directly reduces latency and improves load times.
Those distributed servers are called edge servers or Points of Presence (PoPs). The closer a PoP is to the end user, the faster the content arrives.
The main mechanism behind a CDN is caching. When a user requests a piece of content, the CDN checks whether it already has a cached copy on the nearest edge server. If it does, it serves that copy directly. If it doesn't, the edge server fetches the content from the origin server, caches it locally, and then delivers it to the user. Subsequent requests for the same content from nearby users get served from the cache, without touching the origin server at all.
This is controlled by cache headers, specifically Cache-Control and Expires headers sent by your origin server. These tell the CDN how long to hold onto a cached copy before refreshing it from the source.
CDNs use intelligent routing to direct users to the best available edge server. The two most common methods are:
Anycast routing assigns the same IP address to multiple servers in different locations. When a user makes a request, the network automatically routes them to the topologically closest server. This is how many large CDN and DNS providers operate.
DNS-based routing uses the CDN's own DNS resolver to return different IP addresses depending on where the user is located. When your browser looks up a domain, the CDN's DNS responds with the IP of the nearest PoP.
CDNs are excellent at serving static content, which includes anything that doesn't change between users: images, fonts, CSS files, JavaScript bundles, videos, and downloadable files. These can be cached indefinitely (or until you update them) and served at full speed from the edge.
Dynamic content is trickier. Personalized pages, API responses, and anything generated on the fly can't simply be cached and reused. Modern CDNs have evolved to handle this through techniques like edge computing, where lightweight logic runs directly on the CDN's edge servers to handle some dynamic requests without going all the way back to your origin.
One underappreciated benefit of a CDN is how much traffic it absorbs before it ever reaches your origin server. If your site gets a spike in traffic, or even a DDoS-style flood of requests, the CDN's edge layer takes the brunt of it. Your origin server only needs to handle cache misses and dynamic requests, not every single page view.
When a CDN sits in front of your site, it handles the TLS handshake at the edge. This means the encryption and decryption overhead happens close to the user, reducing connection setup time, especially for visitors far from your origin.
Most CDNs support modern protocols like HTTP/2 and HTTP/3 (QUIC), even if your origin server only speaks HTTP/1.1. This translates to multiplexed requests, header compression, and faster connection establishment for end users.
CDNs act as a shield between the public internet and your origin. Because they're built to handle enormous volumes of traffic across many servers, they can absorb and filter out distributed denial-of-service attacks more effectively than a single server ever could. This isn't their only purpose, but it's a significant operational benefit.
Many CDN providers bundle WAF capabilities, allowing you to filter malicious traffic, block known attack patterns, and enforce rate limits before requests reach your application.
Getting started with a CDN doesn't require deep infrastructure changes. Here's how the process generally works:
1. Choose a CDN provider. Major options include Cloudflare, Fastly, Amazon CloudFront, and Bunny.net, among others. Each has different pricing models, PoP coverage, and feature sets.
2. Point your DNS to the CDN. You'll update your domain's DNS records to route traffic through the CDN's network. With some providers this is as simple as changing your nameservers; with others you add a CNAME record pointing to the CDN's hostname.
3. Configure your cache rules. Tell the CDN what to cache, for how long, and what to pass through to your origin. Most providers have sensible defaults, but you'll want to tune these for your specific application, especially if you have a mix of static assets and dynamic pages.
4. Set cache-control headers on your origin. The CDN reads these to know how long cached content is valid. For static assets that rarely change, a long max-age (days or weeks) is fine. For HTML pages, a shorter TTL or conditional caching might make more sense.
5. Invalidate the cache when you deploy. When you push a new version of your site or update static files, you need to tell the CDN to clear its cached copies. Most providers offer instant cache purging via API or dashboard.
Not every project needs one on day one, but there are clear signals that it's time to consider adding a CDN to your stack.
You should think about a CDN if your users are geographically spread out and you're seeing latency complaints from certain regions. If your site serves a lot of large static assets, the bandwidth savings alone can justify the cost. If you're running a site that gets irregular traffic spikes (e-commerce launches, media coverage, etc.), the offload protection is genuinely valuable. And if uptime is a priority, a CDN adds a redundancy layer that helps absorb failures at the origin.
On the other hand, if you're running a small internal tool used by people in a single city, or a prototype not yet in production, a CDN is probably overkill at that stage.
A CDN doesn't replace a well-configured origin server; it complements one. How your underlying infrastructure is set up still matters a great deal. A slow, underpowered origin will still cause slowdowns on cache misses and for any dynamic content that bypasses the cache entirely.
This is where your hosting foundation comes in. Whether you're running a VPS, a dedicated server, or a colocated setup, the performance characteristics of your origin directly affect the user experience that your CDN delivers. A CDN can dramatically reduce how often users hit your origin, but when they do, you want that origin to be fast.
It's also worth noting how CDNs interact with IP transit. CDN providers maintain their own high-capacity network backbones and private peering agreements. When you use a CDN, your content often travels across private networks rather than the public internet, which contributes to the speed and reliability improvements users experience. Understanding IP transit can help you reason about why this matters if you're building infrastructure at scale.
Third-party CDN services are the default choice for most teams, and for good reason: they're quick to set up, managed for you, and backed by global infrastructure that took years and serious capital to build. But there's a subset of use cases where running your own CDN-like infrastructure makes sense, and it's worth understanding what that actually involves.
If you're running a large platform with significant, predictable traffic, the per-bandwidth costs of commercial CDN providers can add up fast. At scale, owning your delivery infrastructure can be more economical. Similarly, if you have strict data sovereignty requirements, specific compliance needs, or want full control over how your content is cached and routed, a self-hosted setup gives you options that a third-party provider might not.
Media companies, large SaaS platforms, game distribution networks, and telecommunications providers often operate their own CDN infrastructure for exactly these reasons.
Building a CDN-like system from scratch means assembling several components yourself. At a high level you need:
Geographically distributed servers. The whole point is edge proximity, so you need servers (or VMs) in multiple regions. This typically means either leasing space in data centers around the world or using a colocation provider with a footprint in your target regions.
A caching layer. Software like Varnish Cache or Nginx with its proxy caching module are the most common choices for handling caching at the edge. Both are well-documented and widely used in production.
A routing mechanism. You need a way to send users to their nearest edge node. Anycast routing (which requires BGP and your own IP address space) is the cleanest approach, but it has real operational complexity. A simpler alternative is GeoDNS, where your authoritative DNS server returns different records depending on the user's location. Services like PowerDNS support this natively.
An origin pull mechanism. Your edge nodes need to know how to fetch content from your origin when they don't have a cached copy, and how long to hold onto it.
Cache invalidation and management. When content changes, you need a way to purge cached copies across all your edge nodes. This is usually handled via an API call that triggers a purge across your fleet.
Monitoring and health checks. A CDN that silently fails at an edge node and routes users to a cold origin defeats the purpose. You need visibility into cache hit rates, node health, and latency across locations.
Running your own CDN isn't just a one-time setup task; it's ongoing infrastructure you're responsible for. That means patching, monitoring, capacity planning, and dealing with edge node failures. You also won't have the same global PoP coverage as a major commercial provider unless you're willing to invest significantly in server deployments across many regions.
For most teams, the answer is to use a commercial CDN and focus engineering effort elsewhere. But for the teams where cost, control, or compliance make self-hosting worth it, the tooling is mature and the path is well-trodden. Starting with a handful of strategically placed edge nodes in your highest-traffic regions, rather than trying to match a commercial provider's footprint from day one, is usually the pragmatic way to approach it.
Web hosting is where your actual website files and application logic live, typically on an origin server. A CDN is a separate layer that sits between your origin and your users, caching and delivering content from edge locations closer to them. Most sites use both; hosting provides the origin, the CDN accelerates delivery.
Yes, with some nuance. Static assets on a dynamic site (images, CSS, JS) are still cached and served efficiently by a CDN. Truly dynamic, user-specific content usually can't be cached, though modern CDNs offer edge computing features that can handle some dynamic logic at the edge without reaching the origin.
Indirectly, yes. Google uses page speed as a ranking signal, and CDNs can significantly reduce load times, particularly for users far from your origin server. Faster pages also reduce bounce rates, which matters for engagement metrics.
Most CDN providers are built for high availability across many redundant edge nodes. A failure at one PoP typically fails over to another automatically. However, if a provider has a major outage (it happens), traffic can fall back to your origin, which may become overwhelmed if it isn't sized to handle the full load. This is worth factoring into your architecture planning.
They overlap but aren't the same. A reverse proxy sits in front of your origin server and forwards requests to it, optionally caching responses. A CDN is essentially a globally distributed reverse proxy network. All CDNs act as reverse proxies, but not all reverse proxies are CDNs.
Yes, and some organizations do exactly that. The typical approach involves deploying caching servers (usually Nginx or Varnish) in multiple geographic locations, using GeoDNS or Anycast routing to direct users to the nearest node, and building a cache invalidation mechanism to push updates across the fleet. The tradeoff is operational overhead: you're taking on the responsibility of managing, patching, and monitoring that infrastructure yourself. It tends to make sense for large platforms with high, predictable traffic volumes where per-bandwidth CDN costs are significant, or where data sovereignty or compliance requirements make third-party providers a poor fit.
Cache invalidation is one of the genuinely tricky parts of CDN management. When you update content on your origin, cached copies on edge servers don't automatically refresh until their TTL expires. Most CDN providers offer cache purge APIs so you can manually invalidate specific URLs or entire directories immediately after deploying changes. For static assets, a common pattern is to append a version hash to filenames (e.g., app.a3f4bc2.js) so each new version is treated as a completely new file and the old one expires naturally.
CDNs are one of the most practical tools in modern web infrastructure. They reduce latency for users around the world, take load off your origin servers, improve resilience under traffic spikes, and add a useful security layer in front of your application. Understanding how they work, from edge caching to request routing to TLS termination, helps you configure them properly and make smarter decisions about your overall stack. And if you're at the scale where building your own CDN infrastructure starts to make sense, the same principles apply; you're just operating the edge nodes yourself.
If you're building out infrastructure to support a CDN-backed architecture, or exploring self-hosted edge caching with servers in multiple regions, xTom has you covered. xTom offers enterprise-grade dedicated servers, colocation services, and IP transit for teams that need serious network performance and control. For scalable, NVMe-powered VPS hosting, V.PS is built for production workloads of all sizes. If you need shared hosting to get started quickly, that's available too at vps.hosting. You can browse the full range of xTom services here.
Ready to discuss your infrastructure needs? Contact the xTom team to explore the right solution for your projects.
]]>Regional Internet Registries are the organizations responsible for allocating IP addresses and Autonomous System Numbers across the globe. Understanding how they work is useful for anyone managing infrastructure, requesting IP space, or thinking about internet routing.
]]>Whether you're a network engineer, a sysadmin spinning up infrastructure, or just someone curious about how IP addresses are handed out, understanding RIRs gives you a clearer picture of the internet as a system, not just a service you plug into.
The internet runs on addresses. Every device that communicates online needs a unique IP address, and someone has to be responsible for making sure those addresses are handed out in an orderly, non-overlapping way.
That responsibility ultimately sits with IANA, the Internet Assigned Numbers Authority, which is operated by ICANN. IANA manages the global pool of IP address space, but it doesn't deal directly with individual organizations or networks. Instead, it delegates large blocks of addresses to a tier of regional bodies: the Regional Internet Registries.
From there, RIRs distribute address space to Local Internet Registries (LIRs), such as ISPs and hosting providers, who then allocate it further to their customers or use it internally.
Think of it as a hierarchy: IANA at the top, RIRs in the middle, and LIRs and end users at the bottom.
There are five RIRs in total, each serving a specific part of the world.
ARIN (American Registry for Internet Numbers) covers the United States, Canada, and many parts of the Caribbean. It's one of the older registries and manages a large portion of the IPv4 space that was allocated during the early commercial internet era.
RIPE NCC serves Europe, the Middle East, and parts of Central Asia. RIPE is short for Réseaux IP Européens, and its NCC (Network Coordination Centre) is headquartered in Amsterdam. It's also one of the most active registries in terms of policy development.
APNIC covers the Asia-Pacific region, which includes a massive and fast-growing portion of the world's internet users. Given the size of that footprint, APNIC was actually the first RIR to exhaust its IPv4 free pool, back in 2011.
LACNIC handles Latin America and the Caribbean (the parts not covered by ARIN). It's headquartered in Montevideo, Uruguay.
AFRINIC manages IP resources for Africa. It's the newest of the five RIRs, having been founded in 2004, and it still holds some of the remaining IPv4 address space in the global pool, though allocations continue to tighten.
RIRs don't just hand out IPv4 and IPv6 addresses. They manage a few key internet resources:
IPv4 address blocks. These are the classic 32-bit addresses (like 192.0.2.0) that most people picture when they think of an IP address. The global free pool of IPv4 space is largely exhausted, which has pushed organizations to either transfer addresses, move to IPv6, or use both.
IPv6 address blocks. IPv6 uses 128-bit addresses, which gives an astronomically larger pool. RIRs actively encourage and facilitate IPv6 adoption, and getting IPv6 space is generally much more straightforward than fighting over legacy IPv4 blocks.
Autonomous System Numbers (ASNs). An ASN is a unique identifier assigned to a network that runs the Border Gateway Protocol (BGP). If you want to announce your own IP prefixes on the internet, you'll need an ASN. Networks with ASNs are called Autonomous Systems, and BGP is how they exchange routing information with each other. If you're interested in a deeper look at how that works, you'll want to read this article.
WHOIS and route registry data. RIRs maintain public databases where you can look up who holds a given IP range or ASN. This is useful for troubleshooting, abuse reporting, and verifying route origins. The RIPE Database and ARIN's WHOIS tool are commonly used examples.
The path from the global pool to your server rack follows a fairly consistent process.
IANA allocates large blocks, typically /8s or similar, to RIRs. The RIR then breaks those down and allocates smaller chunks to LIRs, which are usually ISPs or hosting providers who are members of the registry. Those LIRs can then either use the addresses themselves or sub-allocate them to their customers.
When a business or operator wants address space directly from an RIR, they typically need to justify their request with documentation showing current usage and projected need. The specific policies vary between registries, but most require that you demonstrate you have a plan for the address space rather than just sitting on it.
For most companies, the practical path is to work with a provider that's already an LIR and can either assign addresses from their own allocation or help sponsor a direct assignment from the RIR.
IPv4 exhaustion is one of the most significant practical consequences of how IP addressing has developed. With only about 4.3 billion possible IPv4 addresses, and the internet growing far beyond what its designers anticipated, regional free pools started running dry starting around 2011.
Today, most RIRs operate under what's called "final /8 policy" or similar restrictions, meaning they can only issue very small allocations from whatever remains. ARIN, for example, moved to its IPv4 Waiting List for new requests, where applicants wait for returned or revoked space to become available.
This scarcity has driven a secondary market for IPv4 transfers, where organizations that hold address blocks they no longer need can sell or transfer them to others, subject to each RIR's transfer policies. Prices for IPv4 space have risen significantly over the past decade as a result.
IPv6 is the long-term answer to this, and RIRs have made it progressively easier to get IPv6 allocations. The challenge has been adoption, since getting IPv6 space is one thing; getting every network, device, and application in the ecosystem to support it is another.
If you're at the point where you need your own address space or want to run your own ASN, here's a general picture of how that works.
Working through an LIR. For most organizations, the simplest path is working with an ISP or hosting provider that's already an LIR member of the relevant RIR. They can sponsor a PI (Provider Independent) assignment, which means the addresses are assigned to you and don't disappear if you change providers.
Becoming an LIR. Larger organizations, especially those managing multiple networks or operating at scale, sometimes apply to become LIRs themselves. This requires becoming a member of the relevant RIR, paying annual fees, and agreeing to their policies. In return, you get a direct allocation and more flexibility in how you distribute and use the space.
Getting an ASN. If you want to run BGP and announce your own prefixes, you'll need an ASN. Applications go through your regional RIR and typically require that you have at least two BGP peers and a legitimate reason to operate an Autonomous System. The process varies by registry but isn't particularly complicated for qualifying networks.
IP transfers. If you need IPv4 space quickly and can't wait, the transfer market is an option. RIRs have defined transfer policies that allow address blocks to move between organizations, sometimes within the same region, sometimes across regions. This usually involves a broker and can be expensive depending on the size of the block.
For companies running internet infrastructure, being an LIR or working closely with one has real operational implications. Provider Independent (PI) space means your addresses are yours regardless of which upstream provider carries your traffic. That matters a lot for multihoming, where you're connected to multiple transit providers for redundancy, and for portability if you change providers.
Having your own ASN also lets you participate directly in the routing ecosystem, giving you more control over how your traffic is routed and making it easier to implement things like BGP communities or traffic engineering policies.
For organizations with significant traffic or complex routing requirements, these aren't just technical details; they directly affect performance, resilience, and cost.
An RIR is a policy and administrative body that allocates internet resources like IP addresses and ASNs to networks within its region. An ISP is a commercial company that provides internet connectivity to customers. ISPs often become LIR members of an RIR so they can receive address allocations and assign them to their customers.
It's possible, but most small organizations work through an ISP or hosting provider instead. Getting space directly from an RIR typically requires becoming a member, paying fees, and meeting minimum size thresholds. For most use cases, working through a provider is simpler and more cost-effective.
A WHOIS lookup queries a registry's database to find out who is responsible for a given IP address or domain. RIRs maintain these databases for the IP space and ASNs they manage. They're commonly used for network troubleshooting and abuse reporting.
Yes, the free pool of unallocated IPv4 space at the global IANA level was exhausted in 2011. Regional pools have followed suit at different times since then. IPv4 addresses are still available through transfers on the secondary market, but they come at a cost. IPv6 adoption is the long-term path forward.
Provider Independent (PI) space is assigned directly to your organization, meaning it belongs to you regardless of which ISPs or providers carry your traffic. This is in contrast to Provider Aggregatable (PA) space, which comes from your ISP's allocation and would typically need to be returned if you change providers.
Each RIR develops its own policies through a community-driven process, so there are differences between them. However, they all operate within the broader framework set by IANA and ICANN, and they coordinate through a group called the Number Resource Organization (NRO).
An IP address block is a range of addresses used to identify devices on the internet. An ASN (Autonomous System Number) is a unique identifier for a network that uses BGP to exchange routing information. You need an ASN if you want to announce your own IP prefixes to other networks, but having IP addresses doesn't automatically mean you need an ASN.
Regional Internet Registries are an often-overlooked but foundational part of how the internet operates. They're the organizations that make sure IP address space and routing identifiers are distributed in a way that keeps the global network functioning, and understanding how they work is genuinely useful if you're managing any kind of infrastructure at scale.
Whether you're thinking about getting your own IP space, running BGP, or just want to understand how your provider's addresses are sourced, the RIR system is worth knowing.
At xTom, we operate as a registered LIR with allocations from multiple RIRs, which means we can offer IP transit with real network depth, alongside dedicated servers, colocation, and scalable NVMe KVM VPS through V.PS. We also offer shared hosting for simpler workloads, and you can see the full range of what we do at our services page.
Ready to talk infrastructure? Get in touch with our team and let's find the right setup for your network.
]]>GeoDNS lets you route users to the server closest to them based on their location, cutting latency and improving reliability. Here's how it works and when you should use it.
]]>This article breaks down what GeoDNS is, how it works under the hood, and when it makes sense to use it for your own infrastructure.
Before getting into GeoDNS specifically, it helps to understand what the Domain Name System (DNS) actually does. In short, DNS is the system that translates human-readable domain names like example.com into IP addresses that computers use to connect to each other. Every time you type a URL into your browser, a DNS query happens behind the scenes.
Standard DNS is essentially location-blind. When someone queries your domain, your DNS server returns the same IP address regardless of where that person is located in the world. That works fine when you have a single server or when your audience is geographically concentrated, but it starts to become a problem when you're serving users across continents.
Network latency, the time it takes for data to travel from point A to point B, is directly affected by physical distance. A server in Amsterdam can respond to a user in the Netherlands almost instantly, but that same server might add 150 to 200 milliseconds of latency for a user in Sydney. For some applications, that delay barely matters. For others, like real-time platforms, APIs, or latency-sensitive games, it's a meaningful degradation in experience.
This is the problem GeoDNS was built to solve.
GeoDNS, sometimes called geographic DNS or geo-routing DNS, is a method of returning different DNS responses based on the geographic location of the person making the query. Instead of giving everyone the same IP address, your DNS resolver checks where the query is coming from and returns the IP address of the server that's geographically closest, or most appropriate, to that user.
Here's a simplified version of the flow:
A user in Singapore queries api.example.com. The GeoDNS resolver identifies that the query originates from Southeast Asia and returns the IP of your Singapore-region server. A user in Dallas queries the same domain, and the resolver returns the IP of your North American server instead. Both users think they're connecting to api.example.com, but they're actually hitting different physical servers tailored to their location.
The geographic identification typically relies on IP geolocation databases, which map IP address ranges to approximate locations. These databases aren't perfect, especially for users on VPNs or certain mobile networks, but they're accurate enough for the vast majority of real-world traffic.
GeoDNS is often mentioned alongside IP Anycast, and they're frequently confused or treated as interchangeable. They're not quite the same thing, though they sometimes work toward similar goals.
With Anycast, multiple servers around the world share the same IP address. Routing is handled at the network layer by BGP, and traffic is naturally directed to the topologically nearest node. DNS doesn't need to do anything clever; the routing happens in the network fabric itself. Anycast is actually what many large DNS providers use to make their own DNS resolvers fast and resilient.
With GeoDNS, the routing decision happens at the DNS layer. Different IP addresses are returned based on the origin of the DNS query. The servers themselves can have completely different IPs; the intelligence lives in the DNS configuration.
In practice, you can use both together. Many CDN and DNS providers layer GeoDNS policies on top of Anycast infrastructure to get the benefits of both approaches.
GeoDNS isn't just for massive companies with data centers on every continent. There are several practical scenarios where even mid-sized deployments benefit from it.
Traffic distribution across multiple data centers. If you run servers in two or more regions, GeoDNS lets you direct users to the most appropriate region automatically, rather than relying on a single origin and hoping latency is acceptable everywhere.
Compliance and data sovereignty. Some regulations require that certain user data stay within specific geographic boundaries. GeoDNS can help ensure that users from the EU, for example, always hit your EU-hosted infrastructure rather than being routed elsewhere.
Failover and disaster recovery. GeoDNS can be configured with health checks so that if your primary server in a region goes down, traffic fails over to a backup location automatically. This pairs well with a solid redundant hosting setup where you have standby capacity ready.
Content localization. If you're serving region-specific content, different languages, pricing, or product catalogs, GeoDNS gives you a clean way to route users to the server or application stack configured for their market.
Reducing bandwidth costs. Routing users to a geographically closer server often means fewer hops through expensive transit networks, which can reduce your bandwidth bills over time, especially at scale.
The specifics depend on which DNS provider or authoritative nameserver software you're using, but the general approach follows the same pattern.
Not every DNS host supports geographic routing out of the box. You'll need a provider or authoritative DNS server that supports geo-based record sets. Two popular options are AWS Route 53 and Cloudflare, but plenty of alternatives exist. If you're running your own nameserver infrastructure, software like PowerDNS supports geo-routing through its GeoIP backend.
GeoDNS only helps if you actually have infrastructure in the regions you want to serve. This might mean setting up dedicated servers or VPS instances in each target region, or it could mean leaning on an existing multi-region setup.
Once your provider supports it, you'll create multiple A (or AAAA for IPv6) records for the same hostname, each mapped to a different IP, and each associated with a geographic region. The exact interface varies by provider, but conceptually you're saying "return this IP for users in Europe, this one for Asia, and this one for North America."
Always configure a default record for users that don't match any specific region. This could be your largest server, your most central location, or simply your primary origin. Without a default, queries from unrecognized locations may fail entirely.
Use tools like DNSChecker.org or command-line tools like dig with specific DNS resolvers to verify your records are resolving correctly from different regions. Some providers also offer built-in health check and monitoring features you should enable to catch routing issues early.
Once you're live, pay attention to your traffic distribution. You may find certain regions are misclassified due to IP geolocation inaccuracies, or that your TTL (time to live) values need adjusting to balance DNS caching with failover speed. A shorter TTL, say 30 to 60 seconds, allows faster failover but increases the number of DNS queries hitting your nameservers.
GeoDNS isn't a silver bullet. A few things worth keeping in mind:
IP geolocation isn't perfect. VPN users, corporate proxies, and some ISPs can cause users to be routed to an unexpected region. In most cases this is a minor inconvenience, but it's worth factoring in if geographic precision is a compliance requirement rather than just a performance optimization.
DNS caching can delay routing changes. Resolvers and clients cache DNS responses for the duration of the TTL, so changes to your GeoDNS records don't take effect instantaneously everywhere. Plan for this during maintenance or failover events.
It adds DNS infrastructure complexity. More moving parts mean more things to monitor and maintain. Make sure your team has visibility into whether geo-routing is working as expected, not just whether your servers are up.
A Content Delivery Network (CDN) and GeoDNS both help reduce latency, but they work at different layers. A CDN caches and serves content from edge nodes distributed globally, handling the actual HTTP traffic. GeoDNS operates at the DNS layer and determines which IP address a user's browser connects to. They're complementary; many CDN setups use GeoDNS internally to direct users to the nearest CDN edge node.
Yes. GeoDNS works with AAAA records for IPv6 just as it does with A records for IPv4. If your infrastructure is dual-stack, you can configure geo-routing for both record types independently.
Absolutely, and this is one of its most practical uses. When combined with health checks, GeoDNS can automatically remove an unhealthy server from the rotation and route traffic to a healthy one in another region. The speed of failover depends on your TTL settings and how quickly your DNS provider detects the failure.
This is a balance. Lower TTLs like 30 to 60 seconds allow faster failover and quicker propagation of routing changes, but they mean more DNS queries hitting your nameservers. Higher TTLs reduce DNS query volume but slow down your ability to react to outages. For latency-sensitive or high-availability setups, a TTL of 60 seconds is a common starting point.
Not exactly. Traditional load balancing distributes traffic across multiple servers, often within the same data center or region, for redundancy and capacity reasons. GeoDNS is more about directing users to the right region first. That said, you can combine both: GeoDNS routes a user to the correct regional cluster, and then a load balancer within that cluster distributes requests across individual servers.
IP geolocation databases are generally accurate at the country or broad regional level, but less reliable for city-level precision. For most GeoDNS use cases, country or continent-level routing is sufficient. If you need finer-grained control or have compliance requirements that demand precise geographic enforcement, you may need to supplement with other methods or accept that a small percentage of users will be misclassified.
GeoDNS is a relatively straightforward concept once you understand how DNS and IP routing work, but its impact on latency, availability, and user experience can be significant. If you're running infrastructure in more than one region, or planning to expand to new markets, it's worth adding to your toolkit.
At xTom, we provide the infrastructure that makes multi-region setups like these practical to deploy and manage. Whether you need dedicated servers in specific locations, colocation for your own hardware, IP transit for your network, or flexible NVMe-powered VPS hosting through V.PS, we have options designed for teams that take performance seriously. We also offer shared hosting for lighter workloads, along with a full range of IT services to support your stack.
Ready to discuss your infrastructure needs? Contact our team to find the right solution for your setup.
]]>Git is the standard version control system for developers and sysadmins alike, and getting it running on Linux takes just a few minutes. This guide walks you through installation, basic configuration, and the everyday commands you'll actually use.
]]>Whether you're a developer pushing code to GitHub, a sysadmin versioning your server configs, or someone just getting started with Linux, learning Git is one of those things that pays off pretty quickly.
This guide will cover how to install Git on the most common Linux distributions, how to configure it for the first time, and how to use it day-to-day. No prior experience required.
Git is a distributed version control system originally created by Linus Torvalds in 2005 to manage the Linux kernel's source code. Instead of saving a single file that gets overwritten, Git keeps a full history of every change ever made to your project, who made it, and when.
What makes Git "distributed" is that every person working on a project has a complete copy of the entire history on their own machine. There's no single point of failure, and you can work offline just fine.
You might also hear Git mentioned alongside platforms like GitHub, GitLab, or Bitbucket. Those are hosting services built on top of Git, not Git itself. Git is the tool; those platforms are where you store and share your repositories remotely.
Git is available in the default package repositories of virtually every major Linux distribution, so installation is straightforward.
sudo apt update
sudo apt install git
sudo dnf install git
sudo pacman -S git
Once it's installed, verify it worked:
git --version
You should see something like git version 2.43.0. The exact version will vary depending on your distribution.
Before you start using Git, you need to tell it who you are. Git attaches your name and email address to every commit you make, so this matters even if you're only working locally.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
You can also set your preferred text editor. By default, Git often falls back to Vim, which can be a surprise if you're not expecting it. If you'd rather use Nano:
git config --global core.editor nano
To check your current configuration at any time:
git config --list
These settings are stored in ~/.gitconfig in your home directory.
Before jumping into commands, it helps to understand a few key terms.
A repository (or "repo") is just a directory that Git is tracking. It contains your project files plus a hidden .git folder that stores all the version history.
A commit is a saved snapshot of your project at a specific point in time. Each commit has a unique ID, a message describing what changed, and metadata about who made it.
A branch is an independent line of development. You can create branches to work on features or fixes without touching the main codebase, then merge them back when ready.
The staging area (also called the index) is a middle step between your working files and a commit. You explicitly add files to the staging area before committing, which gives you fine-grained control over what goes into each snapshot.
To start tracking a project with Git, navigate to the project directory and run:
git init
This creates a .git folder and turns the directory into a Git repository. Nothing is committed yet; you've just initialized it.
If you want to download a copy of an existing project, use git clone:
git clone https://github.com/username/repository.git
This creates a new directory with the project name, downloads all the files, and pulls in the full commit history.
One of the most used commands you'll run is:
git status
It tells you which files have been modified, which are staged for the next commit, and which are untracked. Run it often, it's your sanity check.
Once you've made some changes, you need to stage them before committing. To stage a specific file:
git add filename.txt
To stage everything that's changed:
git add .
Then commit with a message:
git commit -m "Add initial configuration file"
Write commit messages that are brief but descriptive. Future you (and anyone else reading the history) will thank you.
To see a log of all commits:
git log
For a more compact view:
git log --oneline
This shows each commit on a single line with its short ID and message, which is a lot easier to scan through.
To create a new branch:
git branch feature-login
To switch to it:
git checkout feature-login
Or, combine both steps into one:
git checkout -b feature-login
When you're done with the feature and want to merge it back into your main branch:
git checkout main
git merge feature-login
To see all branches:
git branch
If you're working with a remote repository (say, on GitHub or a self-hosted GitLab instance), you'll need to push your local commits up and pull down changes from others.
First, add a remote if you haven't already:
git remote add origin https://github.com/username/repository.git
Push your commits:
git push origin main
Pull down changes:
git pull origin main
Git gives you several ways to backtrack.
To unstage a file you accidentally staged:
git restore --staged filename.txt
To discard uncommitted changes to a file and restore it to the last committed state:
git restore filename.txt
To undo the last commit but keep your changes staged:
git reset --soft HEAD~1
To undo the last commit and discard the changes entirely (use with care):
git reset --hard HEAD~1
Not everything in your project directory should be tracked. Log files, compiled binaries, environment files with secrets, and editor-specific folders are all things you'll typically want Git to ignore.
Create a .gitignore file in the root of your repository and list patterns for files and folders to exclude:
*.log
node_modules/
.env
__pycache__/
Git will then skip those files when staging and committing. GitHub maintains a collection of useful .gitignore templates for common languages and frameworks.
If you're frequently pushing to GitHub or GitLab, typing your password every time gets old fast. SSH key authentication solves this.
Generate a key pair if you don't already have one:
ssh-keygen -t ed25519 -C "you@example.com"
Then print your public key:
cat ~/.ssh/id_ed25519.pub
Copy the output and add it to your GitHub or GitLab account under Settings > SSH Keys. After that, use the SSH URL when cloning:
git clone git@github.com:username/repository.git
For a broader look at SSH and how it works on Linux, check out xTom's SSH guide.
Git itself doesn't require an internet connection or a third-party platform. You can use it entirely locally, or push to a server you control. If you want full ownership of your code and history, self-hosting GitLab is a solid option and it's more approachable to set up than you might expect.
Git is the version control software that runs on your local machine. GitHub is a cloud platform where you can host Git repositories online, collaborate with others, and manage projects. You can use Git without GitHub entirely, and there are several alternatives like GitLab and Gitea if you'd rather self-host.
Not necessarily, but in practice you'll almost always end up using it. Most projects you'll deploy via Docker are distributed as Git repositories, and versioning your configuration files with Git is widely considered a best practice for server management.
Absolutely, and it's a great habit. Tracking files like your Nginx configs, Docker Compose files, or /etc settings in a Git repo means you always have a history of what changed and can roll back if something breaks.
git pull and git fetch?git fetch downloads changes from the remote but doesn't apply them to your working branch. git pull does both; it fetches and then merges. Using git fetch first lets you review what's coming before integrating it.
To delete a local branch: git branch -d branch-name. To delete the remote branch as well: git push origin --delete branch-name.
No. Once something is committed to a Git repository and pushed to a remote, it's very difficult to fully remove. Never commit passwords, API keys, private keys, or other secrets. Use a .gitignore to exclude sensitive files and consider tools like git-secrets to catch accidental leaks.
Git is one of those tools that's worth investing time in early. Once the basic workflow clicks, version control starts to feel natural, and going back to working without it is genuinely uncomfortable.
Whether you're managing a single project or collaborating across a whole team, Git gives you a reliable record of your work and the freedom to experiment without fear.
Thanks for reading! If you're looking for reliable infrastructure to host your projects, xTom provides enterprise-grade dedicated servers and colocation services, along with IP transit and shared hosting options. V.PS offers scalable, production-ready NVMe-powered VPS hosting that's a great fit for anything from a personal Git server to a full GitLab instance. You can browse all available services here.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>IP address blocks are the backbone of how networks are organized and routed across the internet, but the differences between IPv4 and IPv6 allocations can be confusing. This guide breaks down block sizes, CIDR notation, and what it all means in practice.
]]>This article covers how block sizes work in both IPv4 and IPv6, what CIDR notation means, and how the two protocols compare when it comes to address space and allocation.
Before getting into blocks, it helps to quickly recap what an IP address actually is.
An IPv4 address is a 32-bit number, typically written in dotted decimal notation like 192.168.1.1. That 32-bit structure gives IPv4 a theoretical maximum of about 4.3 billion addresses, which sounds like a lot until you consider that essentially every device on earth needs one.
An IPv6 address is a 128-bit number, written in hexadecimal groups like 2001:db8::1. The address space is so large it's almost hard to conceptualize, roughly 340 undecillion addresses (that's 3.4 × 10³⁸). For practical purposes, it's inexhaustible.
Both IPv4 and IPv6 use CIDR (Classless Inter-Domain Routing) notation to describe blocks of addresses. You'll see it written as an IP address followed by a slash and a number, like 10.0.0.0/8 or 2001:db8::/32.
The number after the slash is called the prefix length. It tells you how many bits are fixed (the network portion), with the remaining bits available for hosts or sub-allocation.
So in 192.168.1.0/24:
Smaller prefix numbers mean larger blocks. A /8 is vastly larger than a /24. This trips people up at first because it feels backward, but think of it this way: the prefix length is the number of bits that are locked in, so fewer locked bits means more room for addresses.
IPv4's 32-bit address space means blocks range from a single /32 (one address) all the way up to /0 (the entire internet). Here's a practical reference for common block sizes:
| CIDR | Total addresses | Common use |
|---|---|---|
| /32 | 1 | Single host, loopback |
| /31 | 2 | Point-to-point links |
| /30 | 4 | Small point-to-point (2 usable) |
| /29 | 8 | Small subnet (6 usable) |
| /28 | 16 | Small LAN (14 usable) |
| /27 | 32 | 30 usable hosts |
| /26 | 64 | 62 usable hosts |
| /25 | 128 | Half a /24 |
| /24 | 256 | Standard "class C" equivalent |
| /23 | 512 | Two /24s combined |
| /22 | 1,024 | Common ISP allocation |
| /21 | 2,048 | Larger ISP block |
| /20 | 4,096 | Regional allocation minimum |
| /19 | 8,192 | — |
| /18 | 16,384 | — |
| /17 | 32,768 | Half a /16 |
| /16 | 65,536 | "Class B" equivalent |
| /8 | 16,777,216 | "Class A" equivalent |
The /24 is by far the most common unit you'll encounter in practice. It's the smallest block that most internet exchange points and transit providers will accept as a BGP announcement, which is why it's become the de facto standard building block of IPv4 routing.
When an organization announces IP space to the internet via BGP, they're telling every router in the world "I have these addresses, route traffic here." The global BGP routing table currently has hundreds of thousands of prefixes, and to keep it manageable, most networks filter announcements more specific than a /24. If you announce a /25 or smaller, there's a good chance many networks won't accept it and your addresses will be unreachable from parts of the internet.
This is why even small hosting providers that only need a few dozen IPs will typically receive or purchase at least a /24.
The IANA exhausted its free IPv4 pool back in 2011, and regional registries like ARIN, RIPE NCC, and APNIC have since run out of most of their general-pool allocations as well. Today, organizations that need IPv4 space typically get it one of two ways: leasing it from a provider, or purchasing it on the transfer market, where a /24 (256 addresses) can go for several thousand dollars depending on the registry region and market conditions.
IPv6 uses the same CIDR notation, but the numbers have a very different feel because the address space is so much larger. The smallest allocation a typical end-user organization would receive is a /48, which contains 2⁸⁰ addresses. That's more addresses than exist in the entire IPv4 internet, given to a single organization.
Here's how the hierarchy typically works in IPv6:
| CIDR | Size description | Typical use |
|---|---|---|
| /128 | Single address | One interface/host |
| /127 | 2 addresses | Point-to-point links |
| /64 | 18.4 quintillion addresses | Standard subnet (one LAN) |
| /56 | 256 × /64 subnets | Some ISPs give to home users |
| /48 | 65,536 × /64 subnets | Standard end-site allocation |
| /32 | 65,536 × /48 blocks | Minimum ISP allocation |
| /29 | 8 × /32 blocks | Larger ISP/LIR allocation |
| /23 and larger | Regional allocations | RIR assignments to ISPs |
In IPv6, the /64 plays a similar role to the /24 in IPv4, but at the subnet level rather than the routing level. The IETF strongly recommends using /64 for all point-to-multipoint links (which covers virtually every normal LAN). This is because some IPv6 features, particularly SLAAC (Stateless Address Autoconfiguration), only work correctly on /64 subnets. With SLAAC, devices can automatically configure their own IPv6 address from the prefix without needing a DHCP server.
This might seem wasteful since a /64 contains 18.4 quintillion addresses, but given the overall size of IPv6, it's not a concern.
If you're running servers or infrastructure, here's roughly what you'd expect to receive:
From a VPS or cloud provider: Usually a single /128 per server, sometimes a /64 if you ask or pay for it.
From a colocation or dedicated server provider: Typically a /64 or /48 per customer, depending on their policies and your stated needs.
From an ISP or transit provider (for your own AS): At minimum a /48, and in many regions you can justify a /32 or larger by documenting your planned usage.
For home internet: Most ISPs that support IPv6 assign either a /64 or a /56 to the customer's router. A /56 allows you to create 256 separate /64 subnets at home, which is useful if you want separate network segments for different VLANs or IoT devices.
It helps to put the two protocols side by side when thinking about relative sizes:
| IPv4 | IPv6 equivalent (approx.) | Notes |
|---|---|---|
| /32 (single host) | /128 | Both are single addresses |
| /24 (256 addrs) | /120 | Rarely used in IPv6 |
| /24 | /48 (end-site) | Conceptually similar as "org allocation" |
| /20 | /32 (ISP minimum) | Conceptually similar as "provider block" |
| Entire IPv4 internet | /8 in IPv6 | IPv6 dwarfs all of IPv4 many times over |
One key takeaway: in IPv6, address space is not scarce, so the conventions around allocation are more generous and the hierarchy is more structured. Rather than squeezing subnets down to /30s and /29s to conserve space, the standard practice is to use /64 everywhere and hand out /48s freely to end sites.
Subnetting is the practice of dividing a larger block into smaller ones. The math works the same way in both IPv4 and IPv6.
Each bit you add to the prefix length cuts the block in half. So a /24 split into /25s gives you two equal halves. A /24 split into /26s gives you four quarters. And so on.
For example, the block 192.168.1.0/24 can be split like this:
192.168.1.0/25 (addresses .0 through .127)192.168.1.128/25 (addresses .128 through .255)Or into four /26s:
192.168.1.0/26192.168.1.64/26192.168.1.128/26192.168.1.192/26In IPv6, the same principle applies. A /48 allocated to your organization is typically divided into /64 subnets for individual network segments. Since a /48 contains 65,536 possible /64 subnets, you'll likely never run out.
Tools like IP Calculator / IP Subnetting are handy for working out subnet math quickly without doing it by hand.
Not all IP blocks are routable on the public internet. Both protocols have reserved ranges for private use.
IPv4 private ranges (RFC 1918):
10.0.0.0/8172.16.0.0/12192.168.0.0/16These are used heavily in home networks, corporate LANs, and data center environments. Traffic from these ranges doesn't route across the public internet; it stays within the local network or is translated via NAT.
IPv6 private equivalent (ULA, RFC 4193):
fc00::/7 (commonly fd00::/8 for locally assigned ULA space)ULA (Unique Local Addresses) serve a similar purpose to RFC 1918 in IPv4. They're not routable on the public internet but are stable and unique enough for internal use without the risk of collisions that comes with using 10.x.x.x everywhere.
There's also fe80::/10, which is the link-local range in IPv6. Every IPv6-enabled interface automatically assigns itself a link-local address, used for neighbor discovery and other on-link communication. These addresses are never routed beyond the local link.
For a deeper look at how IPv4 and IPv6 differ beyond just addressing, the xTom guide on IPv4 vs. IPv6 covers the protocol differences in more detail.
If you're planning to run your own Autonomous System (AS) and announce your own IP space, minimum prefix sizes matter a lot.
For IPv4, the general internet consensus is:
/24 is the smallest prefix most networks will accept/25, /26, etc.) may be filtered by many providersFor IPv6, the commonly accepted minimum is a /48 for end-site announcements, though many networks also accept /32 and shorter prefixes from ISPs and transit providers.
If you need IP transit to carry your announcements, the prefix you announce needs to fall within these accepted norms or your traffic simply won't reach parts of the internet. This is worth verifying with your upstream provider before purchasing or leasing address space.
For more on how IP transit works, read our article What Is IP Transit and How Does It Work.
Understanding IP block sizes isn't just academic. It affects how you plan subnets, whether your BGP announcements will be accepted, how much address space you need to request, and how efficiently you can organize a network. IPv4's scarcity has made block sizing a careful exercise in conservation, while IPv6's abundance shifts the focus toward clean, hierarchical design.
Whether you're managing a single server or building out an infrastructure with dozens of nodes, knowing the difference between a /24 and a /48 will save you confusion down the road.
xTom offers dedicated servers, colocation, and IP transit for organizations that need reliable, well-connected infrastructure. V.PS provides NVMe-powered scalable KVM VPS hosting if you're looking for a flexible place to run your workloads. For smaller-scale needs, shared hosting is also available. You can browse all available services at here.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
A /24 is an IPv4 block containing 256 addresses, and it's the standard minimum allocation for routing on the public internet. A /48 is an IPv6 block containing 65,536 possible /64 subnets, and it's the standard minimum allocation for an end-site organization in IPv6. They serve conceptually similar roles in their respective protocols, but the scale is completely different.
The number after the slash is the prefix length. It tells you how many bits of the address are fixed as the network identifier. The remaining bits are available for hosts or sub-allocation. A longer prefix (higher number) means a smaller block; a shorter prefix (lower number) means a larger block.
Most networks filter BGP announcements more specific than a /24 to keep routing tables manageable. A /25 is "more specific" than a /24, meaning it's a smaller block carved out of a larger one. Many internet routers will simply drop the announcement, making your addresses unreachable from those networks. If you need to route a block publicly, make sure it's at least a /24.
A /24 contains 256 total addresses. In IPv4, two are reserved: the network address (the first) and the broadcast address (the last). That leaves 254 usable host addresses. In IPv6, the concept of broadcast doesn't exist, so technically all addresses in a /64 subnet are usable, though /128 is used for individual host assignments.
For a single server or interface, you'd receive a /128. For a subnet, the standard is a /64. An end-site organization (like a business or a home customer) typically gets a /48 or /56 from their ISP, though this varies by provider. For your own BGP-routable block, you'd typically need at least a /48.
The /64 boundary in IPv6 is largely defined by SLAAC (Stateless Address Autoconfiguration), which allows devices to automatically generate their own addresses using the network's prefix plus a host identifier derived from the interface's MAC address. SLAAC requires exactly a /64 prefix to work correctly. Because SLAAC is a widely used and important feature, the IETF standardized /64 as the normal subnet size for IPv6, even though the address space would technically allow for much smaller subnets.
In IPv4, a /32 is a single host address. In IPv6, a /32 is a massive block containing 65,536 /48 sub-allocations, and it's considered the minimum allocation for an ISP or large organization. The same notation means very different things depending on which protocol you're working with.
Linux desktop market share is climbing fast, with fresh data from StatCounter, the Steam Hardware Survey, and Stack Overflow painting a clearer picture than ever. Here's what the numbers say halfway through 2026.
]]>Let’s break down what the latest data actually shows.
Before getting into the stats, a quick note: Linux isn’t technically a full operating system. It’s a kernel, the core layer that manages hardware and system resources. What most people call “Linux” is actually a Linux distribution (or distro), like Ubuntu, Fedora, or Arch Linux, which bundles the kernel with a desktop environment, package manager, and user-facing tools.
That distinction matters when looking at market share. The numbers below represent all Linux-based desktop systems combined, not any single distro.
No single source has a definitive read on Linux market share. The three most commonly cited are StatCounter, Valve's monthly Steam Hardware Survey, and the annual Stack Overflow Developer Survey. Each collects data differently, which is why the numbers vary so much between them.
Each measures a different audience:
None is a complete picture, but together they show clear directional trends.
According to StatCounter’s March 2026 desktop OS data, Linux holds 3.16% of the global desktop market.
For context:
The inclusion of a large “Unknown” category is important—it suggests actual Linux share may be slightly undercounted depending on detection methods.
Even with that caveat, Linux has steadily climbed from sub-3% levels just a few years ago, continuing a slow but consistent upward trend.
This is where things get genuinely interesting.
The March 2026 Steam Hardware Survey puts Linux at 5.33% of Steam users—the highest ever recorded.
This marks the first time Linux has crossed the 5% threshold in Steam’s data.
Within Linux:
However, its relative share is shrinking. Two years ago, Steam Deck users made up roughly 42% of Linux gamers on Steam. By March 2026, that dropped to ~24%, indicating that organic desktop Linux gaming adoption is growing beyond just handheld users.
There was some sampling noise in February due to regional effects (like Chinese New Year), but the broader upward trend predates that.
The 2025 Stack Overflow survey gives a much deeper look at how developers actually use operating systems.
Personal use:
Professional use:
Notably, Android slightly surpassed Ubuntu for personal use (29% vs 28%), but Ubuntu remains the dominant Linux-based desktop OS in both personal and professional environments.
Across Linux environments:
The key takeaway: Linux usage among developers is far higher than general consumer stats suggest, especially when including WSL.
The Steam data is outpacing general desktop adoption for a reason.
Compatibility used to be Linux’s biggest weakness. That’s changed dramatically with Proton.
That gap has effectively closed for most users.
On top of that, Valve’s continued investment in SteamOS and potential future hardware (like rumored living-room systems) could push adoption even further.
Linux desktop share has grown steadily over the past few years, with global estimates ranging from ~3% (strict web tracking) to ~4–5% (broader modeling including developers and enthusiasts).
Some regional highlights:
On servers, Linux is dominant. For example, according to W3Techs, 61.1% of websites with identifiable OS run on Linux (with more being identified as Unix).
If you’re considering Linux, the distro you pick matters more than people expect:
Most distributions can be tested via a live USB without installing anything.
Yes. Growth has been steady, with gaming adoption accelerating faster than general desktop usage.
Ubuntu leads in developer surveys and general usage. SteamOS is significant in gaming but declining as a percentage of Linux users.
Stability, flexibility, and zero licensing costs make it ideal for infrastructure. Desktop adoption has historically lagged due to software compatibility, though that gap is closing.
Not natively, but tools like Wine and Proton make many applications and games usable on Linux.
Most distributions are free and open source. Enterprise versions (like Red Hat) offer paid support.
Linux has gone from a niche choice for developers and server admins to a legitimately competitive desktop and gaming platform, and the data backs that up. Whether you're tracking it for curiosity or making infrastructure decisions based on it, the trajectory is clear.
If you're running Linux in production, or thinking about it, xTom provides enterprise-grade dedicated servers and colocation services built for serious workloads. V.PS offers scalable, NVMe-powered KVM VPS hosting that pairs well with any Linux stack. xTom also offers IP transit, shared hosting, and a full range of IT services to keep your infrastructure running.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>Grep is one of the most useful command-line tools in Linux, letting you search through files and output for exactly the text you're looking for. This guide covers what it does, how it works, and the most practical ways to use it.
]]>grep mentioned somewhere, whether in a tutorial, a Stack Overflow answer, or piped at the end of some command you copy-pasted. It's one of those tools that shows up everywhere, and for good reason.
At its core, grep does one thing: it searches for text. But the way it does that, and how flexible it is, is what makes it so indispensable for anyone working on the command line.
grep stands for Global Regular Expression Print. It was originally written by Ken Thompson in 1974 as part of Unix, and it's been a staple of Unix-like systems ever since.
The basic idea is simple: you give grep a pattern and a file (or some input), and it prints every line that matches. That's it. But when you combine it with regular expressions, pipes, and various flags, it becomes something you'll reach for constantly.
The general structure of a grep command looks like this:
grep [options] pattern [file...]
So a simple, real-world example would be:
grep "error" /var/log/syslog
This searches the file /var/log/syslog and prints every line that contains the word "error." Case-sensitive by default, so "Error" or "ERROR" wouldn't match unless you tell it otherwise.
The most common use for grep is searching inside one or more files. Say you have a config file and you want to find a specific setting:
grep "listen" /etc/nginx/nginx.conf
You can also search across multiple files at once:
grep "listen" /etc/nginx/*.conf
Or search an entire directory recursively with -r:
grep -r "listen" /etc/nginx/
The -r flag is especially useful when you're digging through a project directory or a folder full of config files and you're not sure which file contains what you're looking for.
There are a lot of flags available for grep, but here are the ones that come up most often.
-i — case-insensitive search
grep -i "error" /var/log/syslog
This matches "error", "Error", "ERROR", and anything in between.
-n — show line numbers
grep -n "error" /var/log/syslog
Prints the line number alongside each match, which is handy when you need to jump to a specific line in an editor.
-c — count matches
grep -c "error" /var/log/syslog
Instead of printing the matching lines, this just tells you how many lines matched. Useful for a quick sanity check.
-v — invert the match
grep -v "error" /var/log/syslog
This prints every line that does not match. Great for filtering out noise.
-l — list matching files
grep -rl "listen" /etc/nginx/
With -l, grep just prints the names of files that contain a match rather than the lines themselves. Useful when you're searching many files and just want to know which ones are relevant.
-A, -B, -C — show context
Sometimes you don't just want the matching line, you want to see what's around it.
-A 3 shows 3 lines after the match-B 3 shows 3 lines before the match-C 3 shows 3 lines before and after (context)grep -C 3 "error" /var/log/syslog
-w — match whole words only
grep -w "fail" /var/log/auth.log
Without -w, searching for "fail" would also match "failure" or "failed." This flag restricts it to exact whole-word matches.
--color — highlight matches
grep --color "error" /var/log/syslog
Many distros enable this by default through an alias, but if yours doesn't, it highlights the matching text in color, which makes scanning output much easier.
One of the most practical ways to use grep is alongside other commands. Because Linux tools are built to pass output to each other, you can filter the output of almost anything with grep.
For example, if you want to see which processes are running that involve nginx:
ps aux | grep nginx
Or check if a specific package is installed on a Debian-based system:
dpkg -l | grep "nginx"
You can read more about how to list installed packages in Linux if you want to dig deeper into that.
Or search your command history for something specific:
history | grep "docker"
Piping grep into other grep commands is also valid if you want to narrow things down further:
cat /var/log/syslog | grep "error" | grep -v "trivial"
grep supports regular expressions (regex), which is where things get interesting. You don't need to be a regex expert to get value out of this, but knowing a few basics helps.
. — match any single character
grep "err.r" file.txt
Matches "error", "errxr", "err5r", etc.
^ — match start of line
grep "^error" file.txt
Only matches lines that start with "error."
$ — match end of line
grep "error$" file.txt
Only matches lines that end with "error."
.* — match anything
grep "error.*failed" file.txt
Matches any line containing "error" followed by anything and then "failed."
For more advanced patterns, you can use grep -E (or egrep) to enable extended regular expressions, which adds support for things like +, ?, |, and grouping with ().
grep -E "error|warning|critical" /var/log/syslog
This matches lines containing any of those three words, which is a quick way to scan logs for anything worth investigating.
You might come across egrep and fgrep as well, especially in older scripts or documentation.
egrep is equivalent to grep -E, enabling extended regular expressions. fgrep is equivalent to grep -F, which treats the pattern as a fixed string rather than a regex. This makes fgrep faster when you're searching for a literal string with no special characters, since there's no regex engine involved.
In modern Linux systems, both egrep and fgrep are technically deprecated in favor of grep -E and grep -F, but they still work and you'll still see them used.
If you're working with compressed log files, like the .gz archives that log rotation creates, regular grep won't work directly on them. That's where zgrep comes in. It works just like grep but handles gzip-compressed files transparently:
zgrep "error" /var/log/syslog.2.gz
It's a small thing, but it saves you from having to decompress files just to search them.
One common real-world scenario is troubleshooting failed login attempts on a Linux server. The auth log keeps track of all authentication events, and grep makes it easy to filter for what you care about.
grep "Failed password" /var/log/auth.log
You could also combine it with -c to get a count:
grep -c "Failed password" /var/log/auth.log
Or check for a specific IP address:
grep "Failed password" /var/log/auth.log | grep "192.168.1.100"
If you want to go further with protecting your server from brute force attempts, it's worth reading about securing SSH on a Linux server and setting up Fail2Ban.
Grep stands for Global Regular Expression Print. The name comes from a command in the ed text editor (g/re/p), which performed a similar "find and print" operation across a file.
Yes. By default, grep treats searches as case-sensitive. To make a search case-insensitive, use the -i flag.
grep searches for text within files. find searches for files themselves based on name, type, size, modification date, and similar attributes. They serve different purposes, though you can combine them, for example, using find to locate files and piping them into grep to search their contents.
Yes. You can pass multiple file paths to grep, use wildcards like *.log, or use the -r flag to search recursively through an entire directory.
grep -E enables extended regular expressions, which adds support for additional metacharacters like +, ?, |, and grouping. It's the modern equivalent of the older egrep command.
When grep encounters a binary file (like a compiled program or image), it doesn't print the matching lines and instead just notes that a match was found. If you want to force it to treat binary files as text, you can use the -a flag.
Strings that start with - can confuse grep because it might interpret them as flags. To work around this, use -- before the pattern to signal the end of options:
grep -- "-option" file.txt
For anyone working with Linux, whether you're a developer, a sysadmin, or just someone who self-hosts a few services, grep is a command worth knowing well. It's one of those tools that starts simple and reveals more usefulness the more you use it.
Thanks for reading! If you're looking for reliable infrastructure to run your Linux workloads, xTom offers enterprise-grade dedicated servers, colocation, IP transit, shared hosting, and a full range of IT services. For scalable, NVMe-powered VPS hosting, V.PS has you covered for any workload.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
]]>RDAP has taken over as the modern way to look up registration data for domains, IP ranges, and autonomous system numbers. xTom’s open source Rust client wraps that protocol in a fast CLI with readable output, smart query detection, and flexible JSON support. Learn more about it in this article.
]]>whois and thought, “this works, but it really feels like it belongs to another era,” RDAP is the answer.
RDAP, short for Registration Data Access Protocol, is the structured successor to WHOIS. It gives users a standard way to query registration data for domains, IP addresses, CIDR ranges, autonomous system numbers, nameservers, and entities, while also supporting machine-readable JSON, better HTTP semantics, and more predictable responses. ICANN has also moved generic TLD registration lookups over to RDAP, with WHOIS sunset for gTLDs on January 28, 2025.
That shift matters for sysadmins, network operators, security teams, and developers. It also explains why a good RDAP client is worth having on hand.
And that's exactly why we created our open source xtomcom/rdap project. It's a Rust-based RDAP client built for the command line, and it’s meant to make those lookups faster, cleaner, and easier to work with than the old habits many Linux users still rely on.
WHOIS was always a bit messy. Output formats varied, registries handled responses differently, and parsing the results for scripts often turned into a mess of brittle text processing.
RDAP improves that by using HTTP and JSON, along with a standard model for responses. It also supports bootstrap-based service discovery, which means a client can figure out the authoritative RDAP service for a given domain, IP block, or ASN instead of relying on a pile of hardcoded guesses. That bootstrap model is part of the RDAP standards and is tied to IANA’s published registries.
In practice, that means RDAP is better suited to both terminal use and automation.
A good RDAP client should help with a few things:
That’s exactly where this Rust client fits in.
The xtomcom/rdap project is a fork of Akaere-NetWorks/rdap, extended with more features and bug fixes. It’s written in Rust and can be used both as a CLI tool and as a library in Rust projects.
At a high level, it supports:
That already makes it more flexible than the way many people still use whois, which often means jumping between different services or manually changing syntax depending on what they want to inspect.
What stands out here is that the tool isn’t only about returning raw data. It also tries to make RDAP pleasant to use from a terminal. The default text output is colorized and formatted for readability, while JSON and pretty JSON output are there when you want to pipe results into another tool or service.
Rust is a good fit for networking utilities that need to be fast, efficient, and dependable.
This project uses asynchronous I/O with Tokio, efficient HTTP handling, and Serde for JSON parsing. That matters because RDAP is an HTTP-based protocol, and even simple lookups can involve redirects, referrals, bootstrap discovery, cache reads, and multiple remote queries.
For a CLI tool, the result is straightforward: fast startup, low overhead, and a small binary that’s easy to ship around.
For developers, the library side is just as useful. You can query RDAP programmatically, detect object types automatically, serialize responses to JSON, and build services on top of it without writing your own RDAP stack from scratch.
A lot of RDAP clients can fetch data. Fewer of them make the experience smooth.
This project adds a handful of practical features that matter in real use.
You can pass a value like a domain, IP, CIDR block, or AS number, and the client will detect the query type automatically. That makes the CLI feel natural:
rdap example.com
rdap 8.8.8.8
rdap 8.8.8.0/24
rdap AS15169
For day-to-day use, that’s exactly how most people want a lookup tool to behave.
One of the more useful additions is multi-layer RDAP querying for domains.
For domain names, registry-level data and registrar-level data can differ in presentation and detail. This client can follow registrar referrals, so you can inspect both layers rather than stopping at the first answer. That’s handy when you want a fuller picture of status codes, registrar details, nameservers, abuse contacts, and redacted registrant information.
RDAP discovery is better than the old WHOIS approach, but real-world naming infrastructure still has edge cases. The tool includes configurable TLD overrides for ccTLDs that may not behave exactly how users expect through the normal bootstrap flow.
It also supports a local configuration model with updateable downloaded files and persistent local override files. In other words, you can update the general config without wiping your own custom settings.
That is a small feature, but a very practical one.
For IP and ASN work, showing abuse contacts quickly is genuinely useful.
If you’re investigating suspicious traffic, checking ownership of an IP block, or trying to find the right point of contact for a network issue, having abuse details surfaced directly in the output saves time.
Some tools lean too hard in one direction. They’re either nice for humans and annoying for automation, or good for JSON workflows and miserable to read in a terminal.
This one handles both use cases well. You can use the default text mode when you’re working interactively, then switch to:
rdap -f json example.com
rdap -f json-pretty example.com
That makes it a decent fit for shell pipelines, dashboards, web services, and internal tooling.
The project supports a few different installation paths.
You can build it from source with Cargo:
git clone https://github.com/xtomcom/rdap.git
cd rdap
cargo build --release
sudo cp target/release/rdap /usr/local/bin/
There are also package options for Debian and Ubuntu, RPM-based distributions, and macOS through Homebrew. That matters because network tools are most useful when they’re easy to install on the systems where people already work.
For Linux admins, packaging support is always a plus. It means you can get the tool onto a workstation, jump box, or admin VM without treating it like a one-off experiment.
Debian (via extrepo):
sudo apt update && sudo apt install extrepo -y
sudo extrepo enable xtom
sudo apt update && sudo apt install rdap -y
One-Line Style:
sudo apt install -y lsb-release ca-certificates apt-transport-https curl gnupg dpkg
# Add xTom repository
curl -fsSL https://repo.xtom.com/xtom.key | bash -c 'gpg --dearmor > /usr/share/keyrings/xtom.gpg'
echo "deb [signed-by=/usr/share/keyrings/xtom.gpg] https://repo.xtom.com/deb stable main" | sudo tee /etc/apt/sources.list.d/xtom.list
sudo apt update
sudo apt install rdap
DEB822:
sudo apt install -y lsb-release ca-certificates apt-transport-https curl gnupg dpkg
curl -fsSL https://repo.xtom.com/xtom.key | bash -c 'gpg --dearmor > /usr/share/keyrings/xtom.gpg'
sudo bash -c 'cat > /etc/apt/sources.list.d/xtom.sources << EOF
Components: main
Architectures: $(dpkg --print-architecture)
Suites: stable
Types: deb
Uris: https://repo.xtom.com/deb
Signed-By: /usr/share/keyrings/xtom.gpg
EOF'
sudo apt update
sudo apt install rdap -y
# Add xTom repository
sudo curl -o /etc/yum.repos.d/xtom.repo https://repo.xtom.com/rpm/xtom.repo
sudo dnf install rdap
# Install Homebrew https://brew.sh/
brew tap xtomcom/brew
brew install xtomcom/brew/rdap
The nice thing about this client is that the basic usage is simple.
A domain lookup:
rdap example.com
An IP lookup:
rdap 192.0.2.1
A CIDR lookup:
rdap 8.8.8.0/24
An ASN lookup:
rdap AS8888
Verbose output:
rdap -v AS8888
And if you need to force a query type or server, you can:
rdap -t domain example.com
rdap -s https://rdap.verisign.com/com/v1 example.com
That mix of convenience and explicit control is what makes a CLI tool stick.
This isn’t just a neat GitHub project for protocol enthusiasts. There are real day-to-day use cases for it.
If you’re a sysadmin, it helps when you need to inspect domain registration data, IP ownership, or ASN details without relying on random web lookup sites.
If you work in abuse handling or incident response, it gives you a quicker path to network details and abuse contacts.
If you’re a developer, the Rust library means you can build RDAP lookups into your own services, customer tooling, dashboards, or automation scripts.
And if you work in hosting or network operations, it’s the kind of utility that ends up in your standard toolbox because you keep finding reasons to use it.
The CLI is only half the story.
Because the project is also a Rust library, you can add it directly to Cargo.toml and query RDAP from your own applications. That opens up a lot of possibilities:
The examples in the repository show how to create a client, auto-detect query types, work with domain and IP models, and serialize responses. There’s even an integration example using Axum for a simple web service.
That makes the project useful beyond the terminal. It can be the base layer for higher-level tooling.
The configuration system is one of the smarter parts of the project.
It uses a layered priority model, with local user overrides above downloaded configs, system-wide configs, and finally built-in defaults. That means you can have a usable zero-config experience out of the box, while still being able to customize behavior when needed.
The rdap --update command updates config files from GitHub and refreshes the IANA TLD list, while keeping *.local.json files intact. That split is a good design choice because it avoids the usual problem where an update stomps on local changes.
For people managing odd TLD edge cases or internal lookup workflows, that flexibility matters more than it might seem at first glance.
A lot of admins still default to whois because it’s familiar.
That isn’t irrational, but the internet’s registration data ecosystem has moved on. RDAP is now the standard path for structured registration data, especially for gTLDs, and its use of JSON, HTTP, referrals, and standardized responses makes it a better long-term fit for both human use and automation.
Compared with older habits, this client gives you:
That’s a meaningful upgrade.
This tool makes the most sense for:
sysadmins who want a better replacement for scattered whois usage, network engineers who need fast ASN and IP ownership lookups, developers building network-aware tooling in Rust, and security teams that need readable registration and abuse contact data.
It’s also a nice fit for anyone who wants a small open source CLI tool that feels modern instead of patched together.
RDAP is no longer the “next” protocol for registration lookups, it’s the current one. With WHOIS sunset for gTLD registration data and the broader move toward structured, machine-readable responses, having a good RDAP client is becoming less of a nice extra and more of a practical necessity.
The xtomcom/rdap project is a solid example of what that client should look like. It’s fast, readable, scriptable, flexible enough for real-world use, and useful both as a CLI and as a Rust library.
For teams running their own infrastructure, that kind of utility fits naturally alongside reliable dedicated servers, colocation, NVMe-powered scalable KVM VPS through V.PS, IP transit, shared hosting, and other IT services. xTom would love to help!
Ready to discuss your infrastructure needs? Contact the team to explore the right solution for your projects.
RDAP stands for Registration Data Access Protocol. It is the standards-based successor to WHOIS for looking up registration data related to domain names, IP addresses, autonomous system numbers, and related internet resources. RDAP uses HTTP and structured responses, usually JSON, instead of the loose text formatting common in WHOIS.
For generic top-level domains, yes. ICANN announced the WHOIS sunset for gTLD registration data on January 28, 2025, making RDAP the definitive protocol in that area.
It supports domain queries, TLD queries, IP address lookups, CIDR ranges, AS numbers, entity lookups, nameserver queries, and search queries based on the project documentation you provided.
Yes. The project works as both a command-line tool and a Rust library. It supports JSON output for scripting and includes examples for integrating it into Rust applications and web services.
A local RDAP client is faster to work with, easier to automate, and better suited to shell workflows, incident response, and internal tooling. It also lets you control output format, timeouts, referrals, and server selection directly from the command line.
Yes. It supports compact JSON and pretty-printed JSON, which makes it useful for scripts, APIs, dashboards, and data processing workflows.
The biggest strengths are the Rust implementation, auto-detection of query types, readable terminal output, multi-layer domain lookups, abuse contact display, configurable overrides, and the ability to use it as a reusable library instead of only as a CLI.
]]>GRE tunnels encapsulate one packet inside another so traffic can move between remote systems or networks over an IP path. In this article, we'll explain more about them.
]]>That simple concept makes GRE useful in several real-world scenarios. It can connect remote private networks, carry routing traffic between servers or routers, and forward traffic from a DDoS-protected edge network to backend infrastructure hosted somewhere else. GRE has been around for a long time, but it still matters because it solves a specific problem cleanly.
GRE stands for Generic Routing Encapsulation. It is a tunneling protocol defined in RFC 2784. GRE creates a virtual point-to-point link between two endpoints by encapsulating an original packet inside a new outer IP packet.
The intermediate network only needs to route the outer packet to the far end of the tunnel. Once it arrives, the receiving endpoint removes the outer packet and forwards the original traffic normally.
In simple terms, GRE makes two remote systems or networks behave more like they are directly connected, even when the real path between them crosses the public internet or another unrelated IP network.
A GRE tunnel has two endpoints. One endpoint encapsulates the original traffic, and the other decapsulates it.
At the sending side, the original packet is wrapped with a GRE header and a new outer IP header. The outer source and destination addresses belong to the real tunnel endpoints. The original packet stays intact inside the new packet.
At the receiving side, the outer IP header and GRE header are removed, and the original packet is forwarded on to its destination.
A simple way to picture it looks like this:
Original packet: [Inner IP header][Payload]
GRE tunnel packet: [Outer IP header][GRE header][Inner IP header][Payload]
That extra encapsulation is what allows traffic to move across networks that otherwise would not carry it in the same way.
GRE remains widely used because it is flexible and relatively simple. It is not trying to be a security suite or an application delivery platform. Its main role is moving traffic between two endpoints in a useful way.
One of the most common GRE tunnel use cases is connecting one private subnet to another over an IP network. This can be useful when infrastructure is spread across two data centers, two providers, or two geographic regions.
Instead of redesigning the whole network, a GRE tunnel can create a virtual link between the two sides. Once routes are added, the remote networks can communicate as though there is a more direct path between them.
GRE is also useful for carrying routed traffic between remote systems. It can make remote endpoints act more like directly connected peers, which is one reason it appears so often in routing-heavy environments.
For more background on related topics, see xTom’s guides on what BGP is and how it works and what IP transit is and how it works.
GRE tunnels are also used in some hosting and DDoS mitigation setups.
In this type of design, traffic first reaches a DDoS-protected provider or protected network edge. After filtering or scrubbing, that traffic is forwarded through a GRE tunnel to a backend server or backend subnet hosted elsewhere, sometimes at a provider without the same level of DDoS protection.
This lets the backend infrastructure benefit from the protected edge without requiring the full application stack to be moved there. It is a common approach when the origin server is already deployed somewhere else, when infrastructure is split across providers, or when a business wants to keep compute and storage in one location while using another network for protected ingress.
That said, GRE does not automatically hide or secure the backend. If the origin is still publicly reachable, attackers may be able to bypass the protected edge entirely. Proper firewall rules, routing policy, and origin lockdown are what make this setup effective.
GRE tunnels are often confused with VPNs, but they are not the same thing.
GRE is an encapsulation protocol. It wraps traffic and transports it between two endpoints. By itself, it does not provide encryption, authentication, or confidentiality.
VPN technologies such as IPsec are designed to secure traffic. That is why GRE is often paired with IPsec in real deployments. GRE handles the flexible tunnel and routing behavior, while IPsec adds encryption and authentication.
This distinction matters because a tunnel does not automatically mean privacy. A plain GRE tunnel should be treated as transport, not security.
GRE is one of several tunneling methods available.
IP-in-IP is simpler, but generally less flexible. IPsec focuses on secure transport. WireGuard is a more modern choice for encrypted point-to-point networking. VXLAN is more common in virtualized and data center overlay environments.
GRE still makes sense when the main goal is routing flexibility, packet encapsulation, or forwarding traffic between remote systems without needing GRE itself to provide encryption.
GRE remains useful because it offers a few practical advantages.
It is relatively easy to understand once the basic concept clicks. It is flexible enough for a variety of Layer 3 networking scenarios. It is also widely supported across Linux, routers, and network appliances.
On Linux, GRE tunnels can be configured with standard tools such as iproute2, which makes them approachable for many sysadmins and network operators.
GRE also comes with tradeoffs.
The biggest limitation is that GRE does not encrypt traffic on its own. For anything sensitive crossing an untrusted network, GRE usually needs to be paired with something secure.
There is also packet overhead. Because GRE adds extra headers, the effective MTU drops. If that is not accounted for, fragmentation and inconsistent traffic behavior can show up.
GRE also depends on correct routing and firewall configuration. A tunnel may look correct in configuration, but still fail if the endpoints are not reachable, if intermediate devices block GRE, or if the right routes are not in place.
One common mistake is assuming GRE uses a normal TCP or UDP port. It does not. GRE is IP protocol 47, which is handled differently by firewalls and security policies.
The exact setup depends on the Linux distribution and the network management stack in use, but the basic workflow is usually the same.
Assume this example:
203.0.113.10198.51.100.2010.10.10.1/3010.10.10.2/30On Server A:
ip tunnel add gre1 mode gre local 203.0.113.10 remote 198.51.100.20 ttl 255
ip addr add 10.10.10.1/30 dev gre1
ip link set gre1 up
On Server B:
ip tunnel add gre1 mode gre local 198.51.100.20 remote 203.0.113.10 ttl 255
ip addr add 10.10.10.2/30 dev gre1
ip link set gre1 up
Then routes are added so traffic for each remote subnet goes through the tunnel.
For example, if Server A needs to reach 10.20.0.0/24 behind Server B:
ip route add 10.20.0.0/24 via 10.10.10.2 dev gre1
And if Server B needs to reach 10.30.0.0/24 behind Server A:
ip route add 10.30.0.0/24 via 10.10.10.1 dev gre1
At that point, traffic for those remote subnets is sent through the GRE interface instead of the normal path.
For related Linux setup and troubleshooting, these xTom guides may also help: how to diagnose network issues using ping, traceroute, and MTR and how to set up UFW on Debian.
A GRE tunnel only works if the network path between endpoints supports it.
The public IP addresses of both tunnel endpoints must be reachable. Any firewall or filtering layer in front of them must allow GRE traffic. Routes on both sides must point the correct remote networks into the tunnel.
In protected edge to backend designs, the backend often needs to be restricted so that only the protected edge or approved sources can reach it. Otherwise, the backend may still be directly exposed even though GRE forwarding is in place.
Packet size is one of the most common GRE tunnel issues.
Because GRE adds encapsulation overhead, the usable MTU becomes smaller. If MTU is not adjusted, traffic may fragment or fail unpredictably, especially under real application load.
That is why many GRE deployments lower the MTU on the tunnel interface. The exact value depends on the rest of the network path and whether GRE is combined with additional encapsulation or encryption.
GRE tunnels are sometimes mentioned alongside proxying, especially in protected edge and backend origin setups, but GRE is not the same thing as a reverse proxy.
A reverse proxy works at the application layer, usually handling HTTP or HTTPS requests. GRE works at the network layer and tunnels packets themselves.
So while GRE can forward traffic from a protected edge network to backend servers, it is not terminating and reissuing web requests the way an application-layer reverse proxy would.
For readers looking at application-layer traffic handling, xTom also has a guide on setting up NGINX as a reverse proxy for Apache on Debian and Ubuntu.
GRE is a good fit when a deployment needs a simple virtual link between two endpoints, site-to-site routing between remote networks, or traffic forwarding from a protected network edge to backend infrastructure hosted elsewhere.
It is less suitable when the main requirement is encrypted transport with minimal additional configuration. In those cases, technologies such as IPsec or WireGuard may be a better fit.
GRE is still relevant because it handles a specific networking job well, especially in routing-focused and hosting-focused environments.
GRE tunnels are a straightforward way to move traffic between remote endpoints by encapsulating one packet inside another. That makes them useful for site-to-site networking, routed links between remote systems, and protected edge-to-origin forwarding when a DDoS-protected provider is sitting in front of backend infrastructure hosted elsewhere.
The key thing to remember is that GRE is about transport and flexibility, not encryption. When security matters, GRE should be paired with the right tools, and the rest of the deployment, including routing, MTU, firewall rules, and origin protection, needs to be planned carefully.
Thanks for reading! If infrastructure is needed for routing, tunneling, hosting, or broader network deployments, xTom offers dedicated servers, colocation, IP transit, shared hosting, and general IT services. For scalable NVMe-powered KVM VPS hosting, V.PS is available for production workloads, testing environments, and edge deployments.
Ready to discuss infrastructure needs? Contact the team to explore the right solution for any project.
A GRE tunnel is used to encapsulate traffic and move it between remote endpoints over an IP network. Common use cases include site-to-site connectivity, routed links between servers or routers, and forwarding traffic from a protected network edge to backend infrastructure.
No. GRE tunnels do not provide encryption on their own. If confidentiality and secure transport are needed, GRE is often paired with IPsec or replaced with another secure tunneling option.
Yes. GRE tunnels are sometimes used to send traffic from a DDoS-protected provider or protected edge network to backend servers hosted at another provider. This can help keep the backend behind a filtered ingress path, as long as the origin is properly locked down.
GRE does not use a TCP or UDP port. It uses IP protocol 47, which means firewall rules need to specifically allow GRE traffic.
Yes. Linux supports GRE tunneling through built-in networking features and standard tools such as iproute2, which makes GRE practical for many server and infrastructure setups.
GRE is mainly for encapsulation and routing flexibility. IPsec is mainly for security. In many deployments, GRE and IPsec are used together so GRE handles the tunnel behavior and IPsec secures the traffic.
Yes. GRE adds overhead to packets, which reduces the effective MTU. If MTU is not adjusted properly, fragmentation or unreliable connectivity can occur.
Yes. GRE tunnels are still used in routing-heavy environments, site-to-site network designs, and protected edge-to-origin hosting setups where straightforward packet encapsulation is needed.
]]>RAID can improve uptime, performance, and fault tolerance, but it doesn't magically make data safe from every kind of loss. Here's what RAID actually does, how each RAID level works, and where ZFS, software RAID, and hardware RAID fit in.
]]>RAID can help keep a system online when a drive fails, and in some setups it can also improve storage performance. What it can't do is protect you from every kind of data loss. If files are deleted, corrupted, encrypted by ransomware, or overwritten by mistake, RAID usually won't save you. That's why it's important to understand what RAID is actually for, what each RAID level does, and how it compares to things like ZFS, software RAID, hardware RAID, and backups.
In this guide, we'll break down RAID in plain English, compare the main RAID levels, explain when each one makes sense, and cover where ZFS fits into the conversation.
RAID stands for Redundant Array of Independent Disks. The idea is simple: instead of treating each drive as a separate device, RAID combines multiple drives into one logical storage unit.
Depending on the RAID level, the array may spread data across drives for speed, duplicate data for redundancy, or store parity information so the array can survive one or more failed disks.
That means RAID is usually built around one or both of these goals:
Performance, by splitting reads and writes across multiple drives
Fault tolerance, by keeping enough duplicate or parity information to recover from a failed drive
Different RAID levels make different tradeoffs. Some focus almost entirely on speed. Others focus more on redundancy. Some do a bit of both, but with more complexity.
RAID protects data by reducing the chance that a single drive failure takes down the entire system.
For example, if you use a mirrored setup and one disk dies, the other disk still has the same data. If you use a parity-based RAID setup, the array can rebuild the missing data from the remaining drives and parity information.
This matters for servers, virtualization hosts, databases, and storage systems where uptime matters. A failed drive doesn't have to mean immediate downtime or emergency recovery from scratch.
Still, this protection has limits.
RAID does not replace backups. It doesn't protect against accidental deletion, file corruption, malware, controller failure in some setups, fire, theft, or a bad command run by a human. If bad data gets written to the array, RAID usually protects that bad write just as faithfully as it would a good one.
So the better way to think about RAID is this: RAID helps with drive failure and availability. Backups help with actual disaster recovery.
This is the most important distinction in the whole article.
RAID is about keeping storage available when hardware fails. Backups are about restoring data after something goes wrong.
If a drive dies in a RAID 1 mirror, the server can keep running. Great. But if someone deletes a client folder and that deletion syncs instantly across the array, RAID has done exactly what it was supposed to do, and your files are still gone.
A real data protection strategy usually includes both:
RAID for uptime and drive failure tolerance
Backups for recovery from deletion, corruption, ransomware, and larger disasters
That combination is much safer than relying on either one alone.
RAID works through a few core techniques: striping, mirroring, and parity.
Striping means splitting data across multiple disks. This can improve performance because multiple drives can read or write parts of the same workload at the same time.
Mirroring means storing identical copies of data on more than one disk. This gives you redundancy, but reduces usable capacity because the same data is written multiple times.
Parity means storing calculated data that can be used to reconstruct missing information if a disk fails. This is more space-efficient than full mirroring, but it adds complexity and can slow down writes.
Every RAID level is basically a different combination of these ideas.
Not every RAID level is common in modern deployments, but it's still useful to understand the full landscape.
RAID 0 uses striping only. Data is split across two or more drives, which can improve read and write performance.
The catch is that RAID 0 has no redundancy at all. If one drive fails, the entire array is lost because parts of the data were stored across all disks.
RAID 0 gives you the full combined capacity of all drives. Two 2 TB drives in RAID 0 give you 4 TB usable. That's attractive for speed and space, but it's risky.
RAID 0 is best for temporary data, scratch space, or workloads where performance matters more than fault tolerance. It is not a good choice for important data.
RAID 1 uses mirroring. Every write is copied to at least two drives.
This means if one drive fails, the other drive still contains the full dataset. RAID 1 is simple, reliable, and easy to understand. It doesn't give you the same capacity efficiency as parity-based RAID, but it is a common choice for operating system volumes, boot drives, and smaller servers.
The tradeoff is usable space. Two 2 TB drives in RAID 1 give you only 2 TB usable, because one drive is effectively the mirror of the other.
RAID 1 is a good fit when simplicity and redundancy matter more than raw capacity.
RAID 2 is largely historical and almost never used in modern systems. It used bit-level striping and special error correction methods across multiple disks.
You usually won't see RAID 2 offered in real-world server deployments today.
RAID 3 uses byte-level striping with a dedicated parity disk. It can tolerate a single drive failure, but the dedicated parity disk becomes a bottleneck, especially for writes.
Like RAID 2, RAID 3 is mostly of historical interest now.
RAID 4 uses block-level striping with a dedicated parity disk. It improved on some of the limitations of RAID 3, but it still suffers from that dedicated parity bottleneck.
Modern systems generally prefer RAID 5 or RAID 6 instead.
RAID 5 uses block-level striping with distributed parity. Instead of storing parity on one dedicated disk, parity data is spread across all drives in the array.
This avoids the single parity-disk bottleneck found in RAID 4 and allows the array to survive one disk failure.
RAID 5 needs at least three drives. Usable capacity is roughly the total capacity minus one drive's worth. For example, four 2 TB drives in RAID 5 give you about 6 TB usable.
RAID 5 became very popular because it offers a decent balance of performance, redundancy, and space efficiency. But it has real downsides on larger arrays and bigger disks. Rebuilds can take a long time, and during that period the array is vulnerable. If a second drive fails before rebuild finishes, the array is gone.
For modern large-capacity disks, many admins are much more cautious about RAID 5 than they used to be.
RAID 6 is similar to RAID 5, but it stores double distributed parity instead of single parity. That means the array can survive two drive failures instead of one.
It requires at least four drives, and usable capacity is roughly total capacity minus two drives' worth. Four 2 TB drives in RAID 6 give you about 4 TB usable.
RAID 6 is often preferred over RAID 5 for larger arrays because the added protection is worth the extra capacity cost. The tradeoff is slower writes and less usable storage.
If you're working with big SATA drives and want parity-based redundancy, RAID 6 is often the safer choice.
RAID 10, sometimes written as RAID 1+0, combines mirroring and striping. It stripes data across mirrored pairs of drives.
This gives you strong read and write performance, along with better redundancy than RAID 0 and usually faster rebuild behavior than parity-based RAID. It requires at least four drives.
With four 2 TB drives in RAID 10, you get about 4 TB usable. Like RAID 1, half of the raw capacity is used for redundancy.
RAID 10 is widely used for virtualization hosts, databases, and production systems where performance and resilience both matter. The main downside is capacity efficiency. You give up more usable space than with RAID 5 or RAID 6.
RAID 50 combines multiple RAID 5 groups with striping across them. It can improve performance and fault tolerance compared to a single RAID 5 set, but it's more complex and usually found in larger enterprise storage setups.
It still inherits RAID 5's parity and rebuild concerns, just in a more layered design.
RAID 60 combines multiple RAID 6 groups with striping across them. Like RAID 50, it is generally used in larger storage environments where you want more scale and more fault tolerance.
This can survive multiple drive failures depending on where the failures occur, but complexity and overhead both increase.
| RAID level | Minimum drives | Fault tolerance | Performance | Usable capacity |
|---|---|---|---|---|
| RAID 0 | 2 | None | High | 100% |
| RAID 1 | 2 | 1 drive per mirror | Good reads, decent writes | 50% |
| RAID 2 | Varies | Historical | Historical | Rarely used |
| RAID 3 | 3 | 1 drive | Good sequential, limited by parity disk | Total minus 1 disk |
| RAID 4 | 3 | 1 drive | Better than RAID 3 in some cases, still parity bottleneck | Total minus 1 disk |
| RAID 5 | 3 | 1 drive | Good reads, slower writes | Total minus 1 disk |
| RAID 6 | 4 | 2 drives | Good reads, slower writes than RAID 5 | Total minus 2 disks |
| RAID 10 | 4 | Depends on which drives fail | Very good | 50% |
| RAID 50 | 6+ | Varies by subgroup | High | Better than RAID 10, less than RAID 0 |
| RAID 60 | 8+ | Higher than RAID 50 | High | Lower than RAID 50 |
One of the biggest practical questions is whether to use software RAID or hardware RAID.
Software RAID is managed by the operating system. On Linux, this is often done with tools like mdadm or with filesystems and volume managers that include RAID-like features.
The main advantage is flexibility. Software RAID is often easier to inspect, migrate, automate, and recover, especially in Linux environments. It also avoids dependence on a specific RAID controller model. Modern CPUs are usually more than capable of handling the overhead for many workloads.
Software RAID is also often cheaper because you don't need a dedicated RAID card.
Hardware RAID uses a dedicated controller card or onboard RAID chipset to manage the array independently of the OS.
This used to be much more appealing when CPU overhead mattered more and dedicated RAID cards brought features like battery-backed cache. In some enterprise environments, hardware RAID is still used for specific workflows and vendor-supported storage stacks.
But hardware RAID has downsides too. If the RAID controller fails, recovery may depend on finding a compatible replacement. Management can also be more opaque compared to software RAID, and lower-end "fake RAID" implementations can create more confusion than value.
For many modern Linux servers, software RAID is the more practical choice. It's transparent, portable, and usually easier to troubleshoot.
Hardware RAID can still make sense in some enterprise setups, especially where a specific platform is already standardized around it, or where controller-based caching and vendor support are part of the design.
In other words, this isn't about one option always being better. It's about choosing the simpler and more maintainable tool for the environment you're running.
ZFS is not traditional RAID, but it often comes up in the same conversation because it can do many of the things people want from RAID, while also adding filesystem-level features.
OpenZFS combines storage management and the filesystem in a way that lets it handle redundancy, snapshots, checksums, and data integrity together. Instead of thinking only about RAID levels, ZFS users often think in terms of vdevs and storage pools.
Common ZFS layouts include mirrors, RAIDZ1, RAIDZ2, and RAIDZ3.
RAIDZ1 is roughly comparable to RAID 5 in that it can tolerate one disk failure
RAIDZ2 is roughly comparable to RAID 6 and can tolerate two disk failures
RAIDZ3 can tolerate three disk failures
Where ZFS stands out is data integrity. ZFS checksums data and metadata, and it can detect silent corruption, often called bit rot. In redundant configurations, it can often repair corrupted data automatically by reading a good copy elsewhere in the pool.
That's a major reason people choose ZFS for storage servers, backup systems, and environments where data correctness matters as much as uptime.
Still, ZFS isn't automatically the right answer for every system. It has its own memory expectations, operational habits, and design choices. It also doesn't remove the need for backups. Snapshots are helpful, but snapshots are not the same thing as off-system backups.
RAID and ZFS are often discussed as if they are direct competitors, but that oversimplifies things.
Traditional RAID is usually focused on block device redundancy and performance. ZFS is a filesystem and volume manager with integrated redundancy options.
If you want a simple mirrored boot volume or an mdadm RAID 10 for a Linux host, traditional software RAID may be the straightforward option.
If you want end-to-end checksumming, snapshots, pooled storage, and self-healing behavior in redundant configurations, ZFS may be the better fit.
A lot depends on the workload, the operating system, your team's familiarity with the platform, and how much complexity you want to manage.
The right RAID level depends on what you're optimizing for.
If you care most about speed and don't care about redundancy, RAID 0 is the obvious answer, though it should be used very carefully.
If you want simple redundancy for a smaller setup or boot volume, RAID 1 is often enough.
If you want a good balance of capacity and protection for larger storage, RAID 6 is often safer than RAID 5.
If you want strong performance and fault tolerance for production workloads, RAID 10 is a common favorite.
If you're building a storage server and care about data integrity features beyond classic RAID, ZFS deserves a serious look.
The biggest mistake is choosing based on raw usable capacity alone. Saving extra space isn't very helpful if rebuild times, failure risk, or recovery complexity become a problem later.
The exact steps depend on your OS, controller, and storage stack, but the general process looks similar across most environments.
First, decide what problem you're solving. Are you trying to keep a hypervisor online after a drive failure? Improve database IOPS? Build a storage server? The answer affects whether RAID 1, RAID 6, RAID 10, or ZFS makes the most sense.
Next, use matching drives whenever possible. Mixing capacities and performance levels usually leads to wasted space or uneven behavior.
Then, decide whether you want software RAID, hardware RAID, or ZFS. For many Linux servers, software RAID is the cleaner option. For storage-focused setups, ZFS may be worth the extra planning.
After that, monitor drive health. RAID is not something you set once and forget forever. You want SMART monitoring, alerts, and a plan for replacing failed disks quickly.
And finally, back everything up anyway. This is the part people skip until they regret it.
One of the biggest myths is that RAID is a backup. It isn't.
Another common myth is that RAID 5 is always enough. It used to be the default recommendation for a lot of arrays, but today's larger disks and longer rebuild times make that more questionable in many scenarios.
It's also a mistake to assume hardware RAID is always better than software RAID. On modern Linux systems, software RAID is often easier to manage and recover.
And while ZFS has a strong reputation for data integrity, it still isn't magic. You still need sound backups, monitoring, and operational discipline.
RAID is one of those storage topics that sounds more complicated than it really is once you break it down. At its core, it's just a way to combine drives for better performance, redundancy, or both.
The important thing is knowing what kind of protection you're actually getting. RAID can help a server stay online when a disk fails, but it doesn't replace backups, and it doesn't protect against every kind of data loss. For many workloads, RAID 1, RAID 6, and RAID 10 are the most practical traditional choices, while ZFS is worth considering when data integrity and filesystem-level features matter just as much as redundancy.
If you're planning infrastructure for storage-heavy applications, virtualization, backups, or production hosting, the right setup depends on your workload, your recovery goals, and how much complexity you want to manage. xTom provides dedicated servers, colocation, IP transit, shared hosting, and general IT services for a wide range of projects, while V.PS offers scalable NVMe-powered KVM VPS hosting for lighter deployments and flexible cloud workloads.
Ready to discuss your infrastructure needs? Contact the team to explore the right solution for your projects.
RAID is a way to combine multiple drives into one storage setup to improve performance, add redundancy, or both. Different RAID levels handle that in different ways.
RAID helps protect against drive failure, but not all data loss. It usually won't protect against accidental deletion, ransomware, corruption, or site-level disasters. That's why you still need backups.
There isn't one best RAID level for everything. RAID 1 is simple and reliable, RAID 6 is often better for larger parity-based arrays, and RAID 10 is a strong choice when you want both performance and redundancy.
RAID 5 can still make sense in some smaller arrays, but many admins are more cautious about it now because rebuild times on large disks can be long, and the array only tolerates one drive failure.
For many production workloads, RAID 10 is often preferred because it offers better write performance and usually less stressful rebuild behavior. RAID 5 is more space-efficient, though, so it depends on whether performance or usable capacity matters more.
Not always, but software RAID is often the simpler and more flexible option on modern Linux servers. Hardware RAID can still make sense in some enterprise environments, especially where a specific controller platform is already part of the design.
ZFS isn't just a RAID alternative, it's a filesystem and volume manager with integrated redundancy options. It can be a better fit when you want snapshots, checksumming, pooled storage, and protection against silent corruption, but it still requires planning and it still doesn't replace backups.
No. RAID helps with uptime after disk failure. Backups help you recover data after deletion, corruption, malware, or larger disasters. You usually want both.
]]>Debian and Ubuntu are closely related, but they don't feel the same once you start running real workloads. Here's what actually changes, and when those differences matter.
]]>The answer is yes, there is, but it's not as dramatic as some people make it sound.
At a glance, Debian and Ubuntu share a lot. They both use .deb packages, both rely heavily on APT for package management, and both can make excellent choices for servers, cloud instances, development boxes, and self-hosted apps. That shared foundation is exactly why the comparison comes up so often.
But once you get past the package format and basic command-line similarity, the differences start to matter. Release cadence, software freshness, default behavior, commercial backing, package extras like Snap, and how much hand-holding you want all change the day-to-day experience. Debian maintains separate stable, testing, and unstable branches, while Ubuntu ships regular releases every six months and LTS releases every two years.
So, is there any real difference between Debian and Ubuntu?
Yes, there is. The better question is whether those differences matter for what you're trying to do.
Debian is usually the more conservative option. It leans toward stability, long-term consistency, and fewer surprises.
Ubuntu takes Debian's foundation and adds its own packaging decisions, release schedule, hardware support focus, cloud image ecosystem, and commercial support model through Canonical. Ubuntu also includes Snap as part of its software story, alongside traditional Debian packages managed through APT.
That means Debian often feels cleaner and a bit more minimal, while Ubuntu often feels more convenient out of the box.
Neither approach is automatically better. It depends on whether you care more about a steady base or newer defaults and a more opinionated experience.
Ubuntu is derived from Debian, so they start from a shared family tree.
That similarity shows up immediately in things like:
apt updateapt install.deb packagesIf you know your way around Debian, Ubuntu won't feel foreign. If you know Ubuntu, Debian won't feel alien either.
This is why many tutorials work across both, especially for common services like NGINX, Apache, MariaDB, PostgreSQL, Docker, SSH hardening, and basic firewall setup. In fact, if you're working through tasks like securing SSH or configuring a firewall, a lot of the same concepts apply across both systems. For related reading, xTom has guides on setting up UFW on Debian and securing SSH on a Linux server.
Still, similar isn't the same thing.
This is one of the biggest practical differences.
Debian Stable is known for being careful and predictable. Packages are usually older than what you'll see on Ubuntu, but that's by design. The point is to avoid unnecessary churn and keep a dependable base for long-running systems. Debian explicitly recommends Stable for production use.
Ubuntu moves faster. Its regular releases arrive every six months, and its LTS releases arrive every two years. Ubuntu 24.04 LTS is supported for five years under standard maintenance, with longer support available through Ubuntu Pro options from Canonical.
What does that mean in plain English?
On Debian, you're more likely to get older, well-settled software versions.
On Ubuntu, you're more likely to get newer kernels, newer packages, and newer platform features without doing as much work yourself.
For a server, that can matter a lot. If you're deploying something that values consistency over novelty, Debian is often attractive. If you need newer support for hardware, newer app dependencies, or a more current cloud-first experience, Ubuntu often gets there faster.
Debian tends to ask for less trust and give you more control.
Ubuntu tends to make more decisions for you.
That's not an insult to Ubuntu. In many cases it's the whole point. Ubuntu is often designed to get more users, including newer Linux users and enterprise teams, up and running quickly. Debian is more likely to say, in effect, "Here's a clean system, now build what you want."
That philosophical difference can shape how the system feels over time.
Debian often feels leaner and less opinionated.
Ubuntu often feels more pre-integrated.
If you like a distro that stays out of your way, Debian has a strong appeal. If you like a distro that smooths over rough edges and ships more ready-made choices, Ubuntu may feel easier.
This is another area where people notice a real difference.
Debian is centered around its package repositories and long-established packaging policies. Ubuntu also uses APT and .deb packages, but Canonical has made Snap a major part of the Ubuntu ecosystem, especially for some types of software distribution. Ubuntu's own server documentation describes software management in Ubuntu as involving both Debian packages and snaps.
Some admins like Snap because it can simplify packaging and distribution across environments.
Others don't like it because it adds another layer, another package format, and another set of defaults to think about.
On many servers, this won't be a deal-breaker either way. But it is a real difference, and for some Linux users it's one of the first things they point to when comparing Debian and Ubuntu.
Debian is community-driven.
Ubuntu is backed by Canonical, which gives it a commercial support path and a big enterprise footprint. Canonical also offers products and services around Ubuntu, including long-term security maintenance options.
For some businesses, that matters. A company may prefer Ubuntu because it fits better with vendor support expectations, cloud marketplace images, and established enterprise workflows.
For others, Debian's community-driven model is a plus, not a minus. Debian has a long-standing reputation for careful governance, strong documentation, and a stable production track.
On paper, both work well in hosting environments.
In practice, Ubuntu often gets first-class treatment from cloud providers, container ecosystems, and third-party software vendors. That's partly because Ubuntu is widely used in public cloud environments and has a very visible server presence.
Debian is also widely available and widely trusted, especially for VPS deployments, self-hosting, and classic Linux server roles. It just tends to feel a bit less commercial and a bit more stripped back.
If all you need is a clean Linux base for web hosting, reverse proxying, databases, or self-hosted apps, either can be a solid fit.
Both Debian and Ubuntu take security seriously, but they don't package and maintain things in exactly the same way.
Debian Stable is conservative about what changes after release. Security fixes and selected updates are handled with care, and the project documents that stable updates are reviewed case by case rather than treating a stable release like a rolling target.
Ubuntu also provides security maintenance, especially on LTS releases, while layering on Canonical's support model and longer optional support programs.
For most admins, the real takeaway is simple: both can be secure, but Debian usually changes less, and Ubuntu usually offers more structured commercial support around the base system.
For most people, Ubuntu is easier at first.
That's especially true if you're newer to Linux, using newer hardware, or following vendor documentation that explicitly targets Ubuntu.
Ubuntu usually has a more guided feel. Debian is more of a "know what you want and build it" experience.
That doesn't mean Debian is hard. It just tends to assume a little more comfort with Linux, especially if you want to tune the system beyond the basics.
If you're running a headless server and you're already comfortable with the shell, the ease gap gets much smaller.
A lot of Linux admins would say yes, but only with context.
Debian is often a great server OS because it's steady, lightweight in feel, and avoids unnecessary churn. That can make it especially appealing for web servers, databases, container hosts, internal services, VPN endpoints, and other systems where boring is a feature.
Ubuntu is also a very common server OS, especially in cloud environments. There are plenty of good reasons to use it, including fresher packages, strong cloud availability, and a wide support ecosystem.
So it isn't really "Debian for servers, Ubuntu for desktops." That's too simplistic.
A better way to say it is this:
Debian is often chosen when the admin wants maximum predictability.
Ubuntu is often chosen when the admin wants convenience, broader vendor alignment, or newer defaults.
That's a decent shorthand, but it leaves out too much.
Ubuntu starts from Debian, but it isn't just Debian with a new wallpaper.
Ubuntu has its own release engineering, repositories, support lifecycle, packaging choices, defaults, and ecosystem priorities. Canonical also develops Ubuntu-specific tooling, publishes release notes and support timelines, and maintains services around the platform.
So yes, Ubuntu comes from Debian.
No, that doesn't make them interchangeable in every real-world scenario.
If you're deciding what to deploy on a VPS or dedicated server, start with the workload, not the distro debate.
Ask yourself:
Do you want the steadiest possible base with fewer moving parts?
Debian is probably the better fit.
Do you want newer packages, broader out-of-the-box cloud familiarity, and a distro many vendors actively target?
Ubuntu may be the easier call.
Do you care about avoiding Snap in your workflow?
Debian will likely be more appealing.
Do you want a large ecosystem of Ubuntu-focused tutorials and commercial support options?
Ubuntu has an edge there.
For services like web hosting, reverse proxying, self-hosted apps, and common Linux infrastructure, either one can do the job well. What changes is how much updating, tweaking, and distro-specific decision-making you want to deal with over time.
Before you pick one, it helps to think through the setup you actually need.
Some apps are happy on older, stable packages.
Others need newer runtimes, kernels, or dependencies.
If the software stack needs newer components right away, Ubuntu may save time. If not, Debian may give you a cleaner long-term base.
Some software vendors document Ubuntu first.
That doesn't always mean Debian won't work, but it can mean less friction if you stick with the documented path.
This matters more than people admit.
If you like a distro that stays close to a minimal, stable core, Debian may simply feel better to manage.
If you prefer convenience and broader out-of-the-box compatibility, Ubuntu may be more comfortable.
Your Linux distro doesn't live in isolation.
If you're also deciding between web server stacks, database setups, or firewall tooling, it helps to choose a base that matches your comfort level. For example, if you're planning a web stack build, these xTom guides on NGINX vs. Apache and protecting a Linux server with Fail2Ban pair naturally with either Debian or Ubuntu.
Yes, there is a real difference, but it mostly shows up in philosophy and operations, not in basic Linux commands.
Debian is usually the calmer, more conservative choice.
Ubuntu is usually the more guided, faster-moving choice.
That means the difference is very real if you care about package freshness, default behavior, enterprise support paths, or Snap. If you just need a Linux server that can run common services well, the difference may feel smaller day to day.
In other words, Debian and Ubuntu are close relatives, but not twins.
Generally, yes. Debian Stable is specifically known for prioritizing a steady production base and careful updates. Ubuntu LTS is also stable, but Debian usually takes the more conservative path on package versions and change rate.
Not automatically. For many server workloads, performance differences are small. The more noticeable difference is usually package age, default services, and how much extra tooling is included rather than raw speed.
Yes. Ubuntu uses Debian-style .deb packages and APT, but it also supports snaps as part of its software ecosystem.
Either can be a good VPS operating system. Debian is a strong choice if you want a steady base with fewer moving parts. Ubuntu is a strong choice if you want newer packages, wider vendor targeting, or a more guided setup experience.
Usually because Debian feels less opinionated and more predictable over time. Many admins like the idea of installing a clean base system and adding only what they need.
Usually, yes. Ubuntu tends to be easier for newer Linux users because of its defaults, documentation footprint, and broader beginner-oriented ecosystem.
If you're trying to choose between Debian and Ubuntu, the good news is that there isn't really a wrong answer, at least not for most common hosting and server tasks.
Both are mature, widely used Linux distributions with a shared foundation. Debian tends to appeal to people who want a steady and minimal base system, while Ubuntu tends to appeal to people who want newer defaults, wider ecosystem support, and a more guided experience. The better choice depends less on distro loyalty and more on how you like to run your systems.
Thanks for reading! If you're planning your next deployment, xTom offers dedicated servers, colocation, IP transit, shared hosting, and general IT services. For smaller projects or scalable virtual infrastructure, V.PS provides NVMe-powered KVM VPS hosting that works well for Linux workloads, including both Debian and Ubuntu.
Ready to discuss your infrastructure needs? Contact the xTom team to explore the right solution for your projects.
]]>