<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Data Hoarding on rHomelab</title><link>https://rhomelab.com/data-hoarding/</link><description>Recent content in Data Hoarding on rHomelab</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 11 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://rhomelab.com/data-hoarding/index.xml" rel="self" type="application/rss+xml"/><item><title>How Much RAID Redundancy Do You Actually Need? A Data Hoarder's Guide</title><link>https://rhomelab.com/data-hoarding/raid-redundancy-guide/</link><pubDate>Tue, 11 Aug 2026 00:00:00 +0000</pubDate><guid>https://rhomelab.com/data-hoarding/raid-redundancy-guide/</guid><description>RAID and ZFS redundancy levels explained in terms of what actually fails, how much rebuild risk you&amp;#39;re carrying, and how to size redundancy to your real data instead of a rule of thumb.</description><content:encoded><![CDATA[<p>&ldquo;RAID is not a backup&rdquo; gets repeated so often it&rsquo;s lost meaning. Here&rsquo;s the version that actually helps you pick a redundancy level instead of just feeling vaguely guilty about your array.</p>
<h2 id="what-redundancy-actually-protects-against">What redundancy actually protects against</h2>
<p>Redundancy (RAID-Z1, RAID-Z2, mirrors, whatever flavor) protects against <strong>drive failure</strong>, full stop. It does not protect against:</p>
<ul>
<li>Accidental deletion (redundancy dutifully replicates your mistake)</li>
<li>Ransomware or file corruption that writes bad data (same problem)</li>
<li>Fire, theft, flooding, or anything that takes out the whole box at once</li>
<li>Controller or power supply failure that kills multiple drives simultaneously</li>
</ul>
<p>That&rsquo;s what backups are for, and it&rsquo;s a separate problem from redundancy. This post is specifically about the &ldquo;how many drives can I lose without losing data&rdquo; question.</p>
<h2 id="the-real-risk-rebuild-time">The real risk: rebuild time</h2>
<p>The reason &ldquo;just run RAID-Z1 with one parity drive&rdquo; advice has gotten worse over time isn&rsquo;t the math — it&rsquo;s drive size. Rebuilding a failed 4TB drive from parity used to take hours. Rebuilding a failed 20TB drive can take a day or more, and during that entire window, your array has <strong>zero</strong> redundancy left. If a second drive fails — and rebuild stress is exactly when a second aging drive tends to fail — you lose the pool.</p>
<p>This is why RAID-Z1 (single parity) has fallen out of favor for anything beyond small arrays of smaller drives, and why RAID-Z2 (dual parity) has become the practical default for larger pools.</p>
<h2 id="a-sizing-framework-not-a-rule-of-thumb">A sizing framework, not a rule of thumb</h2>
<p>Instead of &ldquo;always run Z2,&rdquo; work through this:</p>
<ol>
<li><strong>How many drives are in the vdev?</strong> More drives means more chances for a second failure during a rebuild. A 4-drive vdev is a different risk profile than a 12-drive vdev.</li>
<li><strong>How big are the drives?</strong> Bigger drives mean longer rebuilds mean longer exposure windows. Scale your parity up as your drive size goes up.</li>
<li><strong>How replaceable is this data?</strong> A media library you could re-rip is a different risk tolerance than family photos or financial records that exist in exactly one place.</li>
<li><strong>Do you actually have a backup for the important subset?</strong> If yes, you can run leaner redundancy on the pool since a rebuild failure isn&rsquo;t catastrophic — it&rsquo;s an inconvenience you recover from with the backup.</li>
</ol>
<h2 id="practical-starting-points">Practical starting points</h2>
<ul>
<li><strong>Small pool (4-6 drives, ≤8TB each), backed-up critical data:</strong> RAID-Z1 is defensible. Watch your drive ages and replace proactively.</li>
<li><strong>Larger pool (8+ drives) or drives above 12TB:</strong> RAID-Z2. The rebuild window is long enough that single parity is gambling.</li>
<li><strong>Anything truly irreplaceable:</strong> mirrors (RAID-10 equivalent) or RAID-Z2 <em>and</em> an off-site backup. Redundancy buys you uptime during a drive failure; it does not buy you disaster recovery.</li>
<li><strong>Very large pools (16+ drives):</strong> consider RAID-Z3 (triple parity) or splitting into multiple smaller vdevs rather than one giant one — a single huge vdev means a single huge rebuild.</li>
</ul>
<h2 id="the-one-habit-that-matters-more-than-any-raid-level">The one habit that matters more than any RAID level</h2>
<p>Monitor drive health (SMART data, <code>zpool status</code>, scrub schedules) and replace drives showing early warning signs <em>before</em> they fail outright, not after. A proactive swap on a healthy array is a non-event. A failure during a rebuild is how pools actually get lost. Redundancy buys you a safety margin — monitoring is what tells you when you&rsquo;re about to need it.</p>
]]></content:encoded></item></channel></rss>