Aran

I was looking at the SMART self-test results of my hard drives and noticed they're now about 4.5 years old. (I bought my first Unraid license back in 2020.) The SMART values still look good, and it made me realize that during all that time I've never really had a major issue with Unraid software itself. The GUI has always been reliable, updates have gone smoothly and worked on the first try, and the rollout of Unraid Connect went pretty well too. The only thing I struggled with a bit was the KVM/QEMU virtualization stack, but that's probably not entirely under Unraid's control. Now, six years later, we know exactly what we need, and we've ended up with a true "sit and forget" server. For those who are curious, the Docker containers we run include Nextcloud (the basic setup without Photos, Office, etc.), Immich, Jellyfin, Music Assistant, and Vaultwarden. Those are the core services that allow us to stay as independent as possible from the big tech companies. As for VMs, I only have a Clonezilla VM configured, and it's powered on only when I actually need it. There were a couple of issues with the Nextcloud and Immich databases over the years that required me to recreate those containers. Fortunately, thanks to the User Scripts plugin, restoring everything from backup was quick and easy. I highly recommend the User Scripts plugin as part of any backup strategy. It's a simple, no-nonsense tool (basically a gui on top of cron) with a surprising amount of functionality. Personally, I prefer using the plugin instead of running yet another Docker container. Writing the scripts was a bit challenging at first, but there are plenty of tutorials and examples on the Unraid forums and elsewhere on the internet. These days I stick to the KISS principle, although I have to admit it wasn't always like that. During the first two years I probably installed a new Docker container almost every weekend and rearranged my hard drives every three months or so. Honestly, I'd recommend anyone doing that too. That's how I learned Unraid inside and out, discovered what it could do, and figured out what our actual needs were. That was four years ago. Today, the server just quietly sits in the basement doing its job without anyone paying much attention to it. About twice a year I open the case to blow out the dust, and that's about it. I still check the GUI weekly—sometimes even daily—to see if there are updates, but that's pretty much the extent of it. There are weekends when I catch myself wondering if I should try something new with the server, but there's a golden rule: if it ain't broke, don't fix it. I still enjoy experimenting, and Unraid made that easy up to the point where the server became part of our home's infrastructure. I don't need to put a spoiler on a classic car, so to speak. A few times I've considered switching to plain Debian with Cockpit and Docker, but at the end of the day Unraid is first and foremost a NAS for file storage—and that's exactly what I need. So yes, Unraid has become boring. And that's a good thing. Thanks to the entire Unraid team.

The same IP as your unraid server and port 53 (unless you changed the port number).

I don't know what your home network looks like, but Pi-hole and AdGuard Home can also work without a dedicated IP address, using Bridge mode. A dedicated IP is not a requirement. For Immich, Redis, and PostgreSQL, it's generally a good idea to create a custom Docker network (for example, immich) and place your entire Immich stack on that network so those containers are isolated from the rest. For reference, I run 18 Docker containers. Only 3 of them have a static IP address, one uses the Host network, and all the others use Bridge mode. That said, I'm not an expert when it comes to Docker networking, and I'm not claiming this is the only correct way to do it. Others here can probably provide more in-depth advice.

No hard feelings 👍 But remember. You won't get SMART data from your ssd's so unraid cannot monitor the disks health and cannot warn you for any disk-issues. Also, i think you cannot use the full potential of your ssd's in an array (speed-wise) but since you use USB that won't matter anyway. My advice is to upgrade your Lenovo to a desktop model (lenovo or any other brand will do fine) that has more sata ports. I don't know where you live but you can get s1151 xeon desktops basicly for free in Belgium. (i have one in our basement and you can have it for free) They are surpisingly energy efficient. DO NOT focus on TDP wattage only.

One of the main reasons is because the array doesn't support TRIM. No, the general rule of thumb is NOT to use SSD's in the array. Yes, the default unraid array is more flexible if you want to expand later. ZFS has better overal performance and does a better job with data integrity. BUT what MowMdown wanted to say (i think) is that you should create a POOL instead of an ARRAY. Those are two different configurations in unraid. Pools support TRIM while an array does not. This is not by choice but more a 'side-effect' because of the way a pool or unraid-array works. Whether you choose btrfs of zfs is up to you. This is fine for an USB backup-drive. Use the user-scripts plugin to create a backup script. Are you talking about SSD's attached over USB?? If so, then this won't work. [edit] what docker containers do you use? What is your use case?

I stopped using Nextcloud about 5 years ago because it was indeed always a hassle with updates and fixing issues. After that, I switched to Resilio (works completely different, i know), but it wasn’t exactly what I was looking for. A few months ago, I installed Nextcloud again, but this time without the office suite, chat, etc. That makes maintenance a lot simpler. In fact, it works properly and I’m not experiencing the problems I had 5 years ago. We use Nextcloud only for synchronizing files between our different devices, and it’s also convenient to create a shared link to use within the family, for example. That’s something that was a bit less smooth with Resilio (in my experience). Nextcloud is running behind a reverse proxy and I only use Authentik for logging in. Logging in via username/password is not possible, not even for other (family) users. Although I have to admit that my knowledge of Authentik is very limited. I’ve often searched for an alternative to Nextcloud, but for one reason or another I always ended up coming back to it. One advantage is that with Nextcloud I only have to maintain a single Docker container. I’m currently looking into rejetto/hfs, but it seems that it doesn’t synchronize between different devices... Anyway, the search continues…

@bmartino1 i saw your post in another topic and didn't want to hijack it so i started a new one. I'm interested because nextcloud is what i use but i want to get rid of it. I did not install the AIO-container but just the file-sharing service without chat, agenda, etc... Anyway, i'm interested in what 'different set of dockers' you mean?

We should consolidate all backup topics ... Anyway, it's always interesting to read someone else's backup strategy. Here's mine: We only need to backup 3 devices: 2 phones and an unraid server. We also have a linux laptop but there's no data stored on it so if there is something wrong with it i just reinstall my linux-distro. (and i have an excuse to try another distro ) Phones -> immich -> Main server -> rsync ->Backup server Laptop <-> nextcloud <-> Main server -> rsync -> Backup server I use rsync because it rarely fails and you don't need to maintain another container. @ConnerVT i'm interested in your appdata backup script. I make weekly backups of all my immich-related appdata but i have other docker-containers too that are currently not backed up. Care to share our script?

How is your mounted flash-drive formatted? If it is formatted in exFat or FAT then (i think) 'chown' won't work. I too use immich and i make a backup of all my immich-containers: postresql, redis, immich-appdata and immich-userdata. It is best to stop the containers when making a backup otherwise the immich database can become corrupted. I use this script to backup my immich instance: #!/bin/bash # ========================================================== # Immich Backup Script voor Unraid met logging + rotatie # ========================================================== # Configuratie MAC_ADDRESS="macadressofbackuppc" INTERFACE="eth0" REMOTE_IP="ipadressofbackuppc" MAX_WAIT=15 LOGDIR="/var/log" LOGFILE="$LOGDIR/immich_backup.log" CONTAINERS=("immich" "PostgreSQL_Immich" "redis") # ---------------------------------------------------------- # Logrotatie: houd max. 2 logs (immich_backup.log en .1) # ---------------------------------------------------------- mkdir -p "$LOGDIR" if [ -f "$LOGFILE" ]; then if [ -f "$LOGFILE.1" ]; then rm -f "$LOGFILE.1" fi mv "$LOGFILE" "$LOGFILE.1" fi # ---------------------------------------------------------- # Logging functie # ---------------------------------------------------------- log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOGFILE" } log "==================== START BACKUP ====================" log "Wakker maken van remote server ($MAC_ADDRESS)..." etherwake -i "$INTERFACE" -b "$MAC_ADDRESS" | tee -a "$LOGFILE" log "Wachten tot de server online komt..." WAITED=0 while ! ping -c 1 -W 1 "$REMOTE_IP" > /dev/null 2>&1; do sleep 1 WAITED=$((WAITED + 1)) if [ "$WAITED" -ge "$MAX_WAIT" ]; then log "FOUT: Server is niet online gekomen binnen $MAX_WAIT seconden." exit 1 fi done log "Server is online!" # ---------------------------------------------------------- # Containers stoppen # ---------------------------------------------------------- log "Containers stoppen..." for NAME in "${CONTAINERS[@]}"; do log "Stop container: $NAME" docker stop "$NAME" >> "$LOGFILE" 2>&1 sleep 5 done # ---------------------------------------------------------- # Back-ups uitvoeren # ---------------------------------------------------------- log "Start Immich backup..." rsync -avh --delete /mnt/user/appdata/immich/ root@$REMOTE_IP:/mnt/user/backup/appdata/immich/ | tee -a "$LOGFILE" rsync -avh --delete /mnt/user/appdata/PostgreSQL_Immich/ root@$REMOTE_IP:/mnt/user/backup/appdata/PostgreSQL_Immich/ | tee -a "$LOGFILE" rsync -avh --delete /mnt/user/appdata/redis/ root@$REMOTE_IP:/mnt/user/backup/appdata/redis/ | tee -a "$LOGFILE" rsync -avh --delete /mnt/user/immich/ root@$REMOTE_IP:/mnt/user/backup/immich/ | tee -a "$LOGFILE" log "Backup van Immich voltooid." # ---------------------------------------------------------- # Containers opnieuw starten (omgekeerde volgorde) # ---------------------------------------------------------- log "Containers opnieuw starten..." for (( idx=${#CONTAINERS[@]}-1 ; idx>=0 ; idx-- )) ; do NAME="${CONTAINERS[idx]}" log "Start container: $NAME" docker start "$NAME" >> "$LOGFILE" 2>&1 sleep 15 done log "Containers succesvol opgestart." log "==================== BACKUP KLAAR ====================" Wakes up the backup-server and checks if it is online. All containers are stopped in a specific order (immich, postgresql, redis). Then the actual backup is made. Containers are restarted in the reverse order (redis, postgresql, immich). Logs are /var/logs/... This script can probabely be improved but it works for me.

I'm sorry, i didn't mean 'copied'. I should have said 'moved'. The files are MOVED to the array at 9AM. So, no. When the mover moves the files at 9AM from your primary storage (cache) to your secondary storage (array) the files wil ONLY be stored on that secondary storage. The files are moved to the secondary storage even when there is plenty of free storage on your primary.(note: i'm not 100% sure that this is correct. The 'prefer' option was removed) If your primary storage is full or above the minimum free space setting, then it will write directly to the secondary storage.

No, one reason is to prevent unnecessary spinup of your hard disks. This video will give you some insights. The array disks are protected by parity, spin up and down, are much slower for random I/O The cache pool (SSD) is very fast (low latency, high IOPS), is always online and is not slowed down by parity writes. The three shares i mentioned are high-I/O, latency-sensitive, and constantly accessed, which makes them poor candidates for the parity-protected array. Lets say you want to copy a large file from your desktop to your server. If your share is set to 'primary cache' and 'secondary array' the the file will be copied to the cahce first -> it is faster (ssd) and your hard drives won't have to spin up. In you case the file will be copied to the array at 9AM. This is ok for your bulk data like media etc. But your 'appdata' conains config files, databases, thumbnails, metadata etc. from your container apps. Those are constantly accessed and need fast read/write speeds. You don't want these on your array. FYI, i don't use the mover at all. I have appdata, domains and system set to cache only and have weekly backups to a second server. You can backup to your array but the mover is NOT a backup function.

In short: (I assume you have an SSD/NVME as the cache-disk and spinners in the array) appdata should normaly be on cache ONLY. Don't move this to the array. You could map it to another SSD cache-pool if you want. system: same as appdata. Don't move this to the array. Make backups if you don't have 2 ssd's/nvme's for redundancy. The shares 'appdata', 'system' and 'domains' normaly are set to 'cache only'. No mover action. English is not my native language so i leave the explanation someone else :)

Yeah... they got me troubleshooting my own setup for an our or so before i picked up the news

You have 2 options: Use 'External Storage' app-plugin in Nextcloud. Map the /mnt/user/tank volume in your nextcloud container first. Note that your files will not be added to the nextcloud database. Upload all your files manually with command line or a desktop client. This way all your files will be added to the nextcloud database. Maybe someone else can provide a 3th option.

We need a little more info on that. Swapping a failed hard drive shouldn't be too difficult. Check the unraid docs on how to replace a failed harddrive. I can think of many reasons why NOT to do it :) But if you still want to go that route, here and here are some links. How many/what containers do you use? What do you mean with 'stuff going'? A prebuild nas has it's limits performance wise.