PoC build for a friend, ended up saving their data

[SnickySnacks]

So, back in August or so I had a friend who was interested in setting up an Unraid build to test out VMs and stuff.

 

I'd long been championing having a server set up to store backups on and for general storage. I have a ~18TB Norco in my closet I use for media streaming that I've been using for a few years now and have come to appreciate the utility of having dedicated storage with built in docker/vm support.

 

At that time, they had an LG N2A2 NAS application set up in raid 0 format (I bet you can see where this is going) to store pictures/music and a laptop running subsonic and whatnot to handle out of home streaming.  This of course resulted in many calls back to the house to "check if the laptop is on" when subsonic stopped streaming.

I of course extolled the virtues of putting everything onto Unraid dockers with automated backups, parity checks, etc.

 

They set up a small proof of concept server with a few spare drives but ended up not really doing anything with it until a few weeks ago when their LG NAS melted down. Of course being raid 0, if they weren't able to access the data via the NAS there would be no way to get it back. They did have backups but since they were manual they were weeks out of date. Suddenly, Unraid made a lot more sense to them.

 

Cue the frantic call from my friend to come over and help rescue their data, move it to the Unraid server, and set up crashplan backups. Fortunately, we were able to get the NAS to come up sporadically so that we could pull data off it and we managed to rescue all their data to Unraid.

 

What went right:

Unraid was of course easy to set up, configure, and get working in an afternoon.

Adding functionality through dockers was super simple, despite a few hiccups.

In the end they now have a server that monitors itself, backs itself up, and is much easier to recover if it fails.

 

What went wrong:

Despite being advertised as having AMD-Vi support, the motherboard we chose for the PoC build did not work with this enabled. It would cause many weird hardware errors, lockups, and reboots and we had to eventually disable it to get things working. Once disabled, everything was smooth.

The Limetech Docker Guide never fully explained that the config for dockers had to live on an actual drive. While this may be obvious, many dockers default to like /opt/appdata, which we just took to be the correct path for configs. This directory disappeared and was recreated when we rebooted the server. Of course, it was trivial to just re-set up the docker config on the cache after that reboot, but it was a very unwelcome surprise that it wasn't made explicit anywhere that the default paths for the various docker configs wasn't "correct" out of the box. It's obvious when it came to the path for media, but not for config.

The subsonic docker reports an internal ip address in the 172.x.x.x range due to how docker hands out internal ips, which results in subsonic not working when accessed from the app at home. (https://lime-technology.com/forum/index.php?topic=40878.0). I suspect the answer is to change the docker net=bridge to net=host, but I haven't had time to mess with it, since it's otherwise working.

Purchased a $10 usb wifi adapter thinking it would allow us to hook the server up wirelessly. Realized later that Unraid doesn't have wifi support, which is a shame. Tried building the driver to support it but without rebuilding the entire kernel it was a no-go. Decided it wasn't worth the hassle.

 

Purchased hardware:

2-core A6-7400K Black Edition Boxed Processor + FM2A88M-HD+ Socket FM2+/FM2 mATX

Crucial Ballistix Sport 4GB DDR3-1600 (PC3-12800) CL9 Desktop Memory Module Kit (Two 2GB Memory Modules)

NZXT Classic Series Source 210 Mid Tower ATX Computer Case

Kingwin 120 x 120mm Long Life Bearing Case Fan

2 3gb WD Blue HDDs

8gb sandisk cruzer fit

 

Reused hardware:

Corsair 750W non-module power supply (so many wires )

 

Total hardware cost was about $160 w/o power supply + $160 for the 2 drives.

Peace of mind concerning your data's safety? Priceless.

[METDeath]

Try updating the motherboard BIOS.

 

For the docker issue, you are correct that you need to enable network bridging on the network interface page, with the array stopped. Then set the docker to use br0 and it will pull an IP from the network... or make sure the ports are mapped correctly (I don't use that docker, so can't comment further).

[ken-ji]

Try updating the motherboard BIOS.

 

For the docker issue, you are correct that you need to enable network bridging on the network interface page, with the array stopped. Then set the docker to use br0 and it will pull an IP from the network... or make sure the ports are mapped correctly (I don't use that docker, so can't comment further).

 

Docker doesn't pull an IP from the network.

But you should be able to do port mappings in the docker config which will make the ports available on the unraid IP.

However, some apps (don't use any that fall in this category) won't work/not found because they try to talk to the IP the docker has.

If you absolutely understand what that means, you can use network=host mode for that.

 

Odd, that you have a docker that tried to default to /opt/appdata - I thought they made the default to /mnt/user/appdata/<dockername>/ (Can't say nut my docker templates all have that as a default)

[SnickySnacks]

For the AMD-Vi, yeah we had updated the bios back in August when we originally set the box up (and had all the issues). In February, given that we didn't need the VMs and we were just trying to recover data, we haven't gone back and looked for new updates. I'm not even sure going forward how much we need AMD-Vi support. If it becomes an issue, probably better to just replace with server grade hardware, ECC RAM, etc...

 

Subsonic and Crashplan both defaulted to weird places. One was /opt/appdata and the other /mnt/SSD or something. Neither of which survived a reboot. Wasn't a big deal, just caught us by surprise since the instructions weren't clear about what that needed to be.

 

Subsonic falls into the category of apps that try to talk to the docker IP under one specific circumstance. When connecting via the (custom subsonic) URL to the subsonic server, if you are outside the local network you get the proper external IP. If you are internal to the local network you get the 172 (internal docker) address instead of the local network's 192 address. Next time I am over there I will play around with the network settings. I'm pretty sure network=host will fix the issue.

 

As of a day or two ago, crash plan finished backing everything up so no more worries on my friend's part.