I set up a little home‑lab server last year and wanted a way to snap my home directory every night without tying the job to a terminal. The old nohup trick works, but it leaves orphaned processes and you end up chasing logs in the dark. Systemd user units give a cleaner, more reliable solution that plays nicely with the rest of the system.
When you’re running a small site or a homelab server, the access log is the first place you look for clues about what’s happening. A quick glance at the most frequent status codes can tell you whether a recent change broke something, if a bot is hammering your API, or if a mis‑configured rewrite is returning 404s for legitimate pages.
Below is a practical, one‑liner‑heavy walk‑through that shows how to extract the top ten status codes from a standard Nginx log using only awk. It covers common pitfalls, performance tricks, and a few security‑related notes that fit naturally into a daily‑use workflow.
As someone who’s run a homelab for years, I’ve learned that managing disk space is key to keeping my servers running smoothly. One of the most effective ways to keep disk usage under control is by using btrfs snapshots. I’ve seen this go wrong when people don’t have a solid backup strategy, and btrfs snapshots have been a lifesaver for me. The real trick is to use them in conjunction with a solid backup plan.
[Read More]I’ve been self-hosting various services at home for a while now, and one thing that’s always been a pain point is managing SSL certificates. With multiple services running on different machines, each requiring its own certificate, it’s easy to lose track of which ones are due for renewal. I’ve seen this go wrong when a certificate expires unexpectedly, taking down a service with it. To avoid this, I’ve implemented a centralized certificate management system, which I’ll outline in this article.
[Read More]I’ve seen this go wrong when you least expect it - a misconfigured system file, a failed update, or an accidental deletion of a critical file can leave your Linux system in a borked state. Whether you’re working on a desktop, server, or in a homelab setup, having a reliable method to rescue and restore your system is invaluable. In my experience, rsync combined with temporary snapshots is one of the most effective tools for this purpose.
I’ve been there - stuck in dependency hell, trying to figure out why a package won’t install or update. It’s frustrating, especially when you’re just trying to get some work done. On Debian-based systems like Ubuntu, tools like apt-mark and pinning can be lifesavers. In this article, I’ll walk you through how to use these tools to manage dependencies and keep your system running smoothly.
apt-mark is a command-line tool that lets you mark packages as automatically or manually installed. This is super useful for preventing unwanted package removals or upgrades. For example, if you’ve installed a package manually, you can mark it as manually installed using the following command:
I’ve seen this go wrong when you least expect it - a small Linux server, whether in a homelab or for self-hosting, suddenly runs out of disk space. This can happen due to misconfigured log rotation, unexpected data growth, or simply underestimating storage needs. When it does, acting quickly and making informed decisions is crucial to prevent data loss and service downtime.
The real trick is to identify the cause of the issue quickly. I usually start with df -h to get an overview of the disk space usage, or du -sh /path/to/directory to check the size of specific directories. For a more detailed analysis, tools like ncdu are invaluable - they provide an interactive way to browse through the directory tree and identify large files or directories. This is where people usually get burned, not realizing that a single large file or directory is consuming all their disk space.
I’ve been using Borg Backup for years, and it’s been a reliable tool in my homelab setup. However, like any complex system, it’s not perfect, and I recently had to deal with a failed repository. This experience taught me a lot about the recovery process, and I’d like to share my findings with you.
Before we dive into recovery, it’s crucial to understand how Borg Backup repositories work. A repository is essentially a storage location for your backups, and it can be hosted locally or remotely. Borg uses archives to store individual backups within the repository, and each archive contains a snapshot of your data at a particular point in time. I’ve seen this go wrong when the repository becomes inconsistent, so it’s essential to understand the basics.
[Read More]I’ve learned the hard way that managing disk space is crucial for a healthy and efficient home server. It’s easy to let disk space consumption get out of hand, especially with the amount of data we generate these days. I’ve seen this go wrong when I didn’t keep a close eye on my server’s disk usage - it was growing at an alarming rate. To get back on track, I’ve implemented a quarterly rsync snapshot and log rotation strategy. The real trick is to find a balance between keeping enough data for backups and not letting logs consume too much disk space.
[Read More]I’ve been working with Btrfs for a while now, and I have to say, its send and receive functionality is one of my favorite features. It makes efficient backups and data replication across systems a breeze. However, like any complex operation, things can go wrong, and you’re left with incomplete or corrupted data. That’s where having a safety net like rsync comes in handy.
[Read More]