My Unraid NAS Backup Solution

[Pauven]

Whoohoo! It's working!

It was quite a bit more effort to modify that mirror.sh bash script, I had tons of typos and mistakes. But I finally figured out the correct syntax.

Additionally, I had to add one more IF clause to evaluate how deep the directory is before overriding where it is created. If the directory depth is 5, then it will be overridden from my Frankenstore MergerFS mount point to one of the FS# mount points. I only do this for depth of 5 as my Unraid share name is depth 4, i.e.

/DEPTH1/DEPTH2/DEPTH3/DEPTH4/DEPTH5
/mnt/disks/Frankenstore/Blu-rays/DEPTH5

So by overriding only depth 5 directories, I override where the movie folder is written, but not the subfolders. This was important for folder rips, which have a ton of subfolders. What I was finding is that the parent movie folder might get created on FS1, but as data was written then future subdirectories got split over to FS2 because FS1 was too low on free space.

But since I already had plenty of buffer free space, I didn't want those subdirectories to split off like that. So by not overriding the subdirectories, they get written to the Frankenstore mount point, which lets MergerFS decide where to write them, and it will keep them in the original parent's directory.

For example on Bullet Train, I override the main folder but not the subfolders. Here's what that looks like:

mkdir /mnt/disks/FS1/Blu-Rays/Bullet Train
mkdir /mnt/disks/Frankenstore/Blu-Rays/Bullet Train/BDMV
mkdir /mnt/disks/Frankenstore/Blu-Rays/Bullet Train/BDMV/META
mkdir /mnt/disks/Frankenstore/Blu-Rays/Bullet Train/BDMV/PLAYLIST
mkdir /mnt/disks/Frankenstore/Blu-Rays/Bullet Train/BDMV/STREAM

So all subfolders were created on Frankenstore, which wrote to the existing path inside Bullet Train which was created on FS1.

EDIT: Unfortunately, I just had a minor failure on this new logic. I had a folder inside an otherwise empty folder, so instead of being 5 layers deep it was 6 directories deep:

/mnt/disks/Frankenstore/Blu-Rays/Butch Cassidy and the Sundance Kid/47030325_BUTCH_SUNDANCE

That 6th folder is the folder rip. So in this case, the logic thought it was creating the 6th folder, but the 5th folder didn't exist yet and it didn't know this, so it allowed the 6th folder to be created in Frankenstore, which put it on FS1, bypassing my new logic to put it on the next drive.

So I just added a new check, to see if the parent folder exists when the directory level is 6 deep. If the parent folder is missing, then it will still trigger the new override logic to create the folder on one of the FS# drives.

EDIT 2: The new-new logic appears to be working as desired. My Butch Cassidy folder was correctly created on FS2 instead of FS1. I updated the revised mirror.sh code in the previous post to reflect this change.

At this point, my backup is running on it's own. I'll continue to monitor, though it looks like it really is correctly filling up each backup drive, one-by-one, and not erroring/crashing on drive transitioning.

[Pauven]

Progress update - it's still working. Though there have been a couple very minor hiccups.

For the most part, data has been written exactly as I hoped, progressively filling up each drive in order, FS1, then FS2, then FS3, then FS4, and now it's working on FS5.

I have the Star Trek Startdate Collection, ripped to folder, and grouped together in a collection folder. So instead of a folder rip being 6 directories deep, this collection is 7 deep before any files are found. Because of this, the logic I added to handle 6-layer deep folder rips didn't kick in, and instead the backup script allowed MergerFS to decide where to create the directories, and it decided to put them on FS6. For the most part, I think I'm okay with this, as that drive had the most free space, and had the highest guarantee of backup success for a large movie collection like this.

Had my logic worked for this collection, it would have been backed up to FS5, which happens to have plenty of space available, but it only missed being on FS4 by a few movies, so that would have been a problem if it had happened just slightly earlier. So even though this was an unexpected event, I'm happy it went this way. I did foresee this type of event happening with TV series, which are 7 or more directories deep, and I felt it best to let MergerFS decide where to put those as well.

The problem here is that, upon closer inspection, MergerFS decided to create the Star Trek Stardate Collection folders on FS1, and filled up the remaining 70 GB of space until only 180 MB remained, and only then did it start writing to FS6. While all this happened without error, it's certainly not quite as clean as I would have liked. I will likely move the 3 movies that snuck onto FS1 over to FS6 after the backup completes.

Perhaps I should change the MergerFS creation logic, from EPFF (existing path, first found), which is what caused the Star Trek Stardate Collection to fill up FS1, to EPMFS (existing path, most free space). After all, my backup solution is creating 99% of all paths automatically according to my wishes, so these exception cases like larger movie collections might work best if they always go to the most free space drive.

The only other hiccup is one ISO getting written to the wrong drive. For Sling Blade, my script created the directory on FS4, but the ISO got copied onto FS6 (or moved there) likely by MergerFS auto-logic. It wasn't a space issue, though the drive was nearly full at the time, there's still room for another ISO or two. Oddly, the Sling Blade metadata files did get copied to FS4, as expected, and there's nothing in the log to explain why the ISO ended up separated on FS6. I plan to move the ISO manually to the FS4 spot after the backup finishes.

After the Star Trek Stardate Collection finishes on FS6, the backup should revert to writing data onto FS5, which still has about 14TB free. Based upon what's left to backup, I'm thinking it should finish sometime tomorrow night.

EDIT: The Sling Blade ISO being on FS6 was due to a space issue on FS4, though I'm still confused by this. I attempted to move it from FS6 to FS4, and it errored with an out of space error. The odd thing is that FS4 has 69.2 GB free, and the ISO is only 49.4 GB, so it should fit with 20 GB to spare. I thought I had started the MergerFS with a 4GB min free space parameter, though perhaps I accidentally set it to 40 GB - that's the only reason I can see this failing.

Another clue, the movie after Sling Blade, Slumdog Millionaire, was copied successfully. That's a 39.3 GB ISO, 11.1 GB smaller than Sling Blade. Doing a bit of math, had Sling Blade copied successfully, free space remaining would have been 11.1 GB less than 69.2, so 58.1 GB. That's still comfortably above 40 GB, so perhaps I somehow have the min free space limit somewhere around 60 or 65 GB. Those values don't seem familiar to me, but I do remember editing the value on the fly as I entered it on the command line. Maybe there was a 6 in front of the 4 GB limit I though I was setting, and I accidentally set it to 64 GB.

I've yet to figure out how to query an existing MergerFS to see what parameters were used - that would be super helpful.

[Pauven]

My movie collection backup has completed, and I'm very happy. The first 5 drives are filled sequentially to the brim, utilizing about 99.5% of available space on each drive, and I have almost 14 TB of free space on the 6th drive, FS6.

image.png (218.77 KiB) Viewed 9232 times

None of my backed-up data is striped or split across any drives, so worst case if I lose a drive is I only lose the backed-up data on just that drive.

While it looks like I have enough room for a couple more movies on each drive, I'm not sure that space is actually accessible. FS4, which has 69.2 GB free, errors every time I try to copy another ISO to it, as soon as the free space drops below 65 GB. This is the issue I first noticed with the Sling Blade ISO erroring while writing to FS4, but I mistakenly attributed this issue to MergerFS. I've now determined that this is not a MergerFS issue. Without MergerFS even running, I can interact with all 6 drives individually, FS1 to FS6, and it is via direct access that FS4 errors anytime I go below 65 GB free.

I have seen one of the other drives, FS2, drop as low as 12 GB free during some of the backup activity, so I'm not sure why FS4 is behaving this way. But ultimately, I'm hesitant to try and utilize that last half-percent of free space, I'd rather leave it unused for future backup activity to sync changes.

I created a bash script to mount my MergerFS virtual pool. For anyone else using this script, the main things you would change is the mount point name (mfs_name="Frankenstore"), and the branches being mounted (mfs_dsks=...):

Code: Select all

#!/bin/bash

mfs_name="Frankenstore"
mfs_opts="cache.files=off,dropcacheonclose=true,category.create=epmfs,minfreespace=4G,moveonenospc=true,fsname=${fs_name}"
mfs_dsks="/mnt/disks/FS1:/mnt/disks/FS2:/mnt/disks/FS3:/mnt/disks/FS4:/mnt/disks/FS5:/mnt/disks/FS6"
mfs_trgt="/mnt/disks/${mfs_name}"

if [ ! -d "${mfs_trgt}" ]; then
	mkdir ${mfs_trgt}
	chown nobody:users ${mfs_trgt}
fi

mergerfs -o ${mfs_opts} ${mfs_dsks} ${mfs_trgt}

When you're done using it, just unmount the MergerFS filesystem using "umount" and the path to the mounted filesystem, i.e. "unmount /mnt/disks/Frankenstore".