<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Self-Hosting on Linux Café</title>
    <link>https://mrtomlinux.org/tags/self-hosting/</link>
    <description>Recent content in Self-Hosting on Linux Café</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Thu, 13 Aug 2026 08:06:36 +0200</lastBuildDate>
    <atom:link href="https://mrtomlinux.org/tags/self-hosting/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Taming Disk Usage with btrfs Snapshots and Automatic Pruning on My Homelab Server</title>
      <link>https://mrtomlinux.org/post/2026-08-13-taming-disk-usage-with-btrfs-snapshots-and-au/</link>
      <pubDate>Thu, 13 Aug 2026 08:06:36 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-08-13-taming-disk-usage-with-btrfs-snapshots-and-au/</guid>
      <description>&lt;h2 id=&#34;introduction-to-btrfs-snapshots&#34;&gt;Introduction to btrfs Snapshots&lt;/h2&gt;&#xA;&lt;p&gt;As someone who&amp;rsquo;s run a homelab for years, I&amp;rsquo;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&amp;rsquo;ve seen this go wrong when people don&amp;rsquo;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming My Self-Hosted Chaos: Managing SSL Certificates Across Multiple Home Services</title>
      <link>https://mrtomlinux.org/post/2026-08-06-taming-my-self-hosted-chaos-managing-ssl-cert/</link>
      <pubDate>Thu, 06 Aug 2026 10:23:14 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-08-06-taming-my-self-hosted-chaos-managing-ssl-cert/</guid>
      <description>&lt;h2 id=&#34;introduction-to-self-hosted-chaos&#34;&gt;Introduction to Self-Hosted Chaos&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been self-hosting various services at home for a while now, and one thing that&amp;rsquo;s always been a pain point is managing SSL certificates. With multiple services running on different machines, each requiring its own certificate, it&amp;rsquo;s easy to lose track of which ones are due for renewal. I&amp;rsquo;ve seen this go wrong when a certificate expires unexpectedly, taking down a service with it. To avoid this, I&amp;rsquo;ve implemented a centralized certificate management system, which I&amp;rsquo;ll outline in this article.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Rescuing a Borked Linux System with Rsync and Temporary Snapshots</title>
      <link>https://mrtomlinux.org/post/2026-08-01-rescuing-a-borked-linux-system-with-rsync-and/</link>
      <pubDate>Sat, 01 Aug 2026 09:30:14 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-08-01-rescuing-a-borked-linux-system-with-rsync-and/</guid>
      <description>&lt;h2 id=&#34;introduction-to-rescuing-borked-linux-systems&#34;&gt;Introduction to Rescuing Borked Linux Systems&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;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&amp;rsquo;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, &lt;code&gt;rsync&lt;/code&gt; combined with temporary snapshots is one of the most effective tools for this purpose.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming Dependency Hell with apt-mark and Pinning on Debian-Based Systems</title>
      <link>https://mrtomlinux.org/post/2026-07-26-taming-dependency-hell-with-apt-mark-and-pinn/</link>
      <pubDate>Sun, 26 Jul 2026 09:50:39 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-26-taming-dependency-hell-with-apt-mark-and-pinn/</guid>
      <description>&lt;h2 id=&#34;introduction-to-dependency-hell&#34;&gt;Introduction to Dependency Hell&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been there - stuck in dependency hell, trying to figure out why a package won&amp;rsquo;t install or update. It&amp;rsquo;s frustrating, especially when you&amp;rsquo;re just trying to get some work done. On Debian-based systems like Ubuntu, tools like &lt;code&gt;apt-mark&lt;/code&gt; and pinning can be lifesavers. In this article, I&amp;rsquo;ll walk you through how to use these tools to manage dependencies and keep your system running smoothly.&lt;/p&gt;&#xA;&lt;h2 id=&#34;understanding-apt-mark&#34;&gt;Understanding apt-mark&lt;/h2&gt;&#xA;&lt;p&gt;&lt;code&gt;apt-mark&lt;/code&gt; 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&amp;rsquo;ve installed a package manually, you can mark it as manually installed using the following command:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dealing with Disk Space Emergencies on Small Linux Servers</title>
      <link>https://mrtomlinux.org/post/2026-07-25-dealing-with-disk-space-emergencies-on-small-/</link>
      <pubDate>Sat, 25 Jul 2026 11:20:26 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-25-dealing-with-disk-space-emergencies-on-small-/</guid>
      <description>&lt;h2 id=&#34;dealing-with-disk-space-emergencies&#34;&gt;Dealing with Disk Space Emergencies&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;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.&lt;/p&gt;&#xA;&lt;h2 id=&#34;identifying-the-issue&#34;&gt;Identifying the Issue&lt;/h2&gt;&#xA;&lt;p&gt;The real trick is to identify the cause of the issue quickly. I usually start with &lt;code&gt;df -h&lt;/code&gt; to get an overview of the disk space usage, or &lt;code&gt;du -sh /path/to/directory&lt;/code&gt; to check the size of specific directories. For a more detailed analysis, tools like &lt;code&gt;ncdu&lt;/code&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Recovering from a Failed Borg Backup Repository: Lessons from a Homelab Mishap</title>
      <link>https://mrtomlinux.org/post/2026-07-22-recovering-from-a-failed-borg-backup-reposito/</link>
      <pubDate>Wed, 22 Jul 2026 10:35:16 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-22-recovering-from-a-failed-borg-backup-reposito/</guid>
      <description>&lt;h2 id=&#34;introduction-to-borg-backup&#34;&gt;Introduction to Borg Backup&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been using Borg Backup for years, and it&amp;rsquo;s been a reliable tool in my homelab setup. However, like any complex system, it&amp;rsquo;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&amp;rsquo;d like to share my findings with you.&lt;/p&gt;&#xA;&lt;h2 id=&#34;understanding-borg-backup-repositories&#34;&gt;Understanding Borg Backup Repositories&lt;/h2&gt;&#xA;&lt;p&gt;Before we dive into recovery, it&amp;rsquo;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&amp;rsquo;ve seen this go wrong when the repository becomes inconsistent, so it&amp;rsquo;s essential to understand the basics.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming Disk Space Consumption on My Home Server with Quarterly rsync Snapshots and a Dash of Log Rotation</title>
      <link>https://mrtomlinux.org/post/2026-07-21-taming-disk-space-consumption-on-my-home-serv/</link>
      <pubDate>Tue, 21 Jul 2026 11:03:41 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-21-taming-disk-space-consumption-on-my-home-serv/</guid>
      <description>&lt;h2 id=&#34;introduction-to-disk-space-management&#34;&gt;Introduction to Disk Space Management&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve learned the hard way that managing disk space is crucial for a healthy and efficient home server. It&amp;rsquo;s easy to let disk space consumption get out of hand, especially with the amount of data we generate these days. I&amp;rsquo;ve seen this go wrong when I didn&amp;rsquo;t keep a close eye on my server&amp;rsquo;s disk usage - it was growing at an alarming rate. To get back on track, I&amp;rsquo;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Recovering from a Failed Btrfs Send Receive Operation with Rsync as a Safety Net</title>
      <link>https://mrtomlinux.org/post/2026-07-12-recovering-from-a-failed-btrfs-send-receive-o/</link>
      <pubDate>Sun, 12 Jul 2026 08:52:53 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-12-recovering-from-a-failed-btrfs-send-receive-o/</guid>
      <description>&lt;h2 id=&#34;introduction-to-btrfs-send-and-receive&#34;&gt;Introduction to Btrfs Send and Receive&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;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&amp;rsquo;re left with incomplete or corrupted data. That&amp;rsquo;s where having a safety net like rsync comes in handy.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming Disk Space Usage on My Homelab Server with btrfs Snapshots and Quotas</title>
      <link>https://mrtomlinux.org/post/2026-07-09-taming-disk-space-usage-on-my-homelab-server-/</link>
      <pubDate>Thu, 09 Jul 2026 08:16:36 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-09-taming-disk-space-usage-on-my-homelab-server-/</guid>
      <description>&lt;h2 id=&#34;introduction-to-disk-space-management&#34;&gt;Introduction to Disk Space Management&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been running a homelab server for a while now, and one thing that&amp;rsquo;s always been a challenge is managing disk space. With multiple services and projects running on my server, it&amp;rsquo;s easy to lose track of disk usage. I&amp;rsquo;ve seen this go wrong when you&amp;rsquo;re not paying attention, and suddenly you&amp;rsquo;re scrambling to free up space. Recently, I started exploring ways to better manage my disk space, and I stumbled upon btrfs snapshots and quotas. In practice, these features have been a game-changer for me.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming Disk Space Hogs with btrfs Snapshots and Automatic Pruning</title>
      <link>https://mrtomlinux.org/post/2026-07-03-taming-disk-space-hogs-with-btrfs-snapshots-a/</link>
      <pubDate>Fri, 03 Jul 2026 09:12:54 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-07-03-taming-disk-space-hogs-with-btrfs-snapshots-a/</guid>
      <description>&lt;h2 id=&#34;introduction-to-btrfs-snapshots&#34;&gt;Introduction to btrfs Snapshots&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been running Linux for years, and one thing I&amp;rsquo;ve learned is the importance of managing disk space effectively. btrfs has been a game-changer for me - its snapshotting and automatic pruning features have saved me from more than a few headaches. In this article, I&amp;rsquo;ll share my experience with using btrfs snapshots to keep my systems running smoothly.&lt;/p&gt;&#xA;&lt;h2 id=&#34;what-are-btrfs-snapshots&#34;&gt;What are btrfs Snapshots?&lt;/h2&gt;&#xA;&lt;p&gt;btrfs snapshots are essentially temporary copies of a subvolume, which can be used to roll back changes or recover data if something goes wrong. I&amp;rsquo;ve seen this go wrong when I&amp;rsquo;ve accidentally overwritten important files or filled up my disk with unnecessary data. With btrfs snapshots, you can create a snapshot of your system, make changes, and then delete the snapshot if everything works out. The real trick is to use them consistently and make them a part of your workflow.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming the Beast: Getting borg Backup to Respect My Limited Laptop Disk Space</title>
      <link>https://mrtomlinux.org/post/2026-06-27-taming-the-beast-getting-borg-backup-to-respe/</link>
      <pubDate>Sat, 27 Jun 2026 10:49:30 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-06-27-taming-the-beast-getting-borg-backup-to-respe/</guid>
      <description>&lt;h2 id=&#34;introduction-to-borg-backup&#34;&gt;Introduction to Borg Backup&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been on the hunt for a reliable backup solution that can handle my laptop&amp;rsquo;s limited disk space for ages. When I stumbled upon Borg Backup in 2025, I thought I&amp;rsquo;d finally found the answer. This deduplicating backup program has been a game-changer, but I soon realized that its default settings weren&amp;rsquo;t exactly optimized for my laptop&amp;rsquo;s storage constraints. So, I set out to tame the beast and get Borg Backup to respect my laptop&amp;rsquo;s limited disk space.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming Background Tasks with Nohup and Systemd: A Homelab Lesson Learned</title>
      <link>https://mrtomlinux.org/post/2026-06-22-taming-background-tasks-with-nohup-and-system/</link>
      <pubDate>Mon, 22 Jun 2026 09:09:19 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-06-22-taming-background-tasks-with-nohup-and-system/</guid>
      <description>&lt;h2 id=&#34;introduction-to-background-tasks&#34;&gt;Introduction to Background Tasks&lt;/h2&gt;&#xA;&lt;p&gt;As someone who&amp;rsquo;s spent years running a homelab, I&amp;rsquo;ve found that managing background tasks is crucial. These tasks need to keep running even after I&amp;rsquo;ve logged out of my system, and they&amp;rsquo;re essential for things like backups, system monitoring, and maintenance scripts. I used to rely on &lt;code&gt;screen&lt;/code&gt; and &lt;code&gt;tmux&lt;/code&gt; to keep these tasks running, but I&amp;rsquo;ve recently switched to using &lt;code&gt;nohup&lt;/code&gt; and &lt;code&gt;systemd&lt;/code&gt;. In this article, I&amp;rsquo;ll share my experience with these tools and provide some practical examples.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming rsync: My Backup Scripts and the Quest for Consistent Snapshot Rotation</title>
      <link>https://mrtomlinux.org/post/2026-06-09-taming-rsync-my-backup-scripts-and-the-quest-/</link>
      <pubDate>Tue, 09 Jun 2026 09:07:15 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-06-09-taming-rsync-my-backup-scripts-and-the-quest-/</guid>
      <description>&lt;h2 id=&#34;introduction-to-backup-scripts&#34;&gt;Introduction to Backup Scripts&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve been running my own homelab for years, and I&amp;rsquo;ve learned the hard way that a solid backup strategy is crucial. After trying out various backup tools in 2025, I kept coming back to &lt;code&gt;rsync&lt;/code&gt; due to its flexibility and reliability. This year, I&amp;rsquo;ve been focused on fine-tuning my backup scripts to achieve consistent snapshot rotation. Don&amp;rsquo;t bother with overly complex backup solutions - &lt;code&gt;rsync&lt;/code&gt; is a powerful tool that can get the job done.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Recovering from a Failed Borg Backup Repository: Lessons Learned from a Homelab Mishap</title>
      <link>https://mrtomlinux.org/post/2026-05-26-recovering-from-a-failed-borg-backup-reposito/</link>
      <pubDate>Tue, 26 May 2026 08:10:41 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-05-26-recovering-from-a-failed-borg-backup-reposito/</guid>
      <description>&lt;h2 id=&#34;introduction-to-borg-backup&#34;&gt;Introduction to Borg Backup&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve learned the hard way that having a reliable backup system is crucial for any homelab setup. Borg Backup has been my go-to tool for deduplicating backups, and it&amp;rsquo;s served me well - until I recently encountered a failed repository. This experience taught me some valuable lessons about recovery and prevention.&lt;/p&gt;&#xA;&lt;h2 id=&#34;understanding-borg-backup-repositories&#34;&gt;Understanding Borg Backup Repositories&lt;/h2&gt;&#xA;&lt;p&gt;Before diving into the recovery process, it&amp;rsquo;s essential to grasp how Borg Backup repositories work. A repository is the central storage location for all your backups, where Borg stores deduplicated data. When you create a repository, Borg initializes it with a unique ID, ensuring data integrity. I&amp;rsquo;ve seen this go wrong when the repository index gets corrupted, so it&amp;rsquo;s crucial to understand how it works.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Taming CPU Usage Spikes with `systemd` and `ps` in My Home Server Setup</title>
      <link>https://mrtomlinux.org/post/2026-05-17-taming-cpu-usage-spikes-with-systemd-and-ps-i/</link>
      <pubDate>Sun, 17 May 2026 10:15:48 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-05-17-taming-cpu-usage-spikes-with-systemd-and-ps-i/</guid>
      <description>&lt;h2 id=&#34;introduction-to-cpu-usage-spikes&#34;&gt;Introduction to CPU Usage Spikes&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve had my fair share of CPU usage spikes on my home server, and I&amp;rsquo;ve learned that they can be caused by a variety of factors, including resource-intensive applications, misconfigured services, or even malware. The real trick is to identify the root cause of the spike and take corrective action. In my experience, using &lt;code&gt;systemd&lt;/code&gt; and &lt;code&gt;ps&lt;/code&gt; can be a powerful way to manage CPU usage spikes.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What I Would Actually Self-Host Again on Linux</title>
      <link>https://mrtomlinux.org/post/2026-05-07-what-i-would-actually-self-host-again-on-linu/</link>
      <pubDate>Thu, 07 May 2026 03:04:34 +0200</pubDate>
      <guid>https://mrtomlinux.org/post/2026-05-07-what-i-would-actually-self-host-again-on-linu/</guid>
      <description>&lt;h2 id=&#34;introduction-to-self-hosting&#34;&gt;Introduction to Self-Hosting&lt;/h2&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve spent years running my own Linux servers, and over time, I&amp;rsquo;ve experimented with a bunch of self-hosted services. Recently, I decided to take a step back and simplify my setup. This involved figuring out what actually works for me and what I&amp;rsquo;d self-host again on Linux.&lt;/p&gt;&#xA;&lt;h2 id=&#34;choosing-the-right-services&#34;&gt;Choosing the Right Services&lt;/h2&gt;&#xA;&lt;p&gt;It&amp;rsquo;s easy to get carried away with all the services available for self-hosting. I&amp;rsquo;ve seen this go wrong when people try to host too many services at once. The real trick is to prioritize what&amp;rsquo;s truly necessary. For me, that includes a personal wiki, a photo gallery, and a Git server. These services are crucial for my daily workflow and personal projects.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
