Skip to content

Quiz: Linux Data Hoarding

← Back to quiz index

9 questions

L1 (4 questions)

1. What is the core architectural difference between traditional RAID and the JBOD+mergerfs+SnapRAID approach used in data hoarding?

Show answer Each drive is an independent filesystem pooled by a union filesystem, with parity computed offline on a schedule *In the JBOD approach, each drive is formatted independently (ext4/XFS), merged into a single namespace by mergerfs, and protected by SnapRAID's snapshot parity (computed daily via cron). This allows mixed drive sizes, individual drive readability, and incremental growth.*

2. Which statement about SnapRAID parity vs backups is correct?

Show answer Parity protects against disk failure; backups protect against deletion, ransomware, fire, and theft — you need both *Parity lets you reconstruct files after a disk failure but cannot protect against rm -rf, ransomware affecting the whole pool, or physical disasters. The minimum stack is SnapRAID for parity + borg/restic to a separate drive + rclone to offsite cloud.*

3. What did Google's landmark 2007 study of 100,000+ drives reveal about SMART monitoring?

Show answer 36% of drives that failed showed zero SMART warnings beforehand *Google found that 36% of failed drives had no SMART anomalies. SMART catches gradual degradation (sector reallocation) but misses sudden failures (head crashes, PCB failures, firmware bugs). Use SMART as one layer in a defense stack, not the only one.*

4. What two fstab mount options should always be set on data drives in a hoarding array?

Show answer noatime and nofail *noatime prevents unnecessary write operations from access time updates (critical for media streaming and reducing SnapRAID sync time). nofail allows the system to boot even if a drive fails or disconnects — giving you a degraded array instead of an unbootable server.*

L2 (5 questions)

1. A data hoarder runs snapraid sync and SnapRAID reports thousands of deleted files. What is the most likely cause?

Show answer One or more data drives failed to mount, making their mount points appear empty *When a drive fails to mount, its mount point is empty. SnapRAID interprets all files on that drive as deleted. This is why snapraid-runner's deletethreshold setting is critical — it aborts sync if deletions exceed a configured limit.*

2. Why is btrfs RAID5/RAID6 considered dangerous for data storage as of 2025?

Show answer btrfs RAID5/6 has an unfixed write hole bug that can cause parity-data inconsistency after power loss, potentially making corruption worse during repair *The btrfs RAID5/6 write hole means that power loss during writes can leave parity inconsistent with data. On the next scrub, btrfs may overwrite good data with bad parity, amplifying corruption. The kernel now warns when creating these profiles. Use btrfs RAID1/RAID10 or ext4+SnapRAID instead.*

3. When choosing between BorgBackup and restic for a data hoarding backup solution, what is the key differentiator?

Show answer Restic has native multi-backend support (S3, B2, Azure, GCS) while borg requires additional tools for cloud storage *restic natively supports S3, B2, Azure, GCS, SFTP, and rclone backends. BorgBackup primarily targets local/SFTP repos and needs rclone or borgmatic for cloud integration. Both support deduplication and encryption. Choose borg for local/SFTP + max compression, restic for cloud targets.*

4. A SnapRAID array has 4 data drives (4TB, 8TB, 12TB, 16TB). What is the minimum size required for the parity drive?

Show answer 16TB (at least as large as the largest data drive) *The SnapRAID parity drive must be at least as large as the largest data drive. Since parity is computed per-block across all drives, it needs to accommodate blocks from the largest drive. With split parity (v11.0+), you can combine smaller drives to meet this requirement.*

5. What is the purpose of drive burn-in before adding a new drive to a data hoarding array?

Show answer To catch infant mortality failures by running SMART extended tests and badblocks before trusting the drive with data *New drives have a higher failure rate in their first weeks (infant mortality). Burn-in with SMART long test + badblocks catches defective drives before you put data on them. Drives that pass burn-in are statistically more reliable. Typical burn-in takes 8-24 hours.*