<?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>Tue, 09 Jun 2026 09:07:15 +0200</lastBuildDate>
    <atom:link href="https://mrtomlinux.org/tags/self-hosting/index.xml" rel="self" type="application/rss+xml" />
    <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>
