Hi everyone!

I’m currently planning my first home server build and I’m looking for some objective advice on choosing the right OS. I realize this is an unRAID-focused community, so the perspective might be a bit leaned towards it, but I’d love to hear your honest take on whether this platform fits my specific goals or if I should look elsewhere.

I’ll be using 4x18tb an a 2tb SSD for now and I have the following priorities. I’m quite new, so maybe something just not makes sense.

1. Bitrot Protection: I need a system that ensures my critical data (photos in Immich, documents in Nextcloud) is protected against silent data corruption over time. And what would be my options in case of a ransomware?

2. Disk Longevity: I’m undecided on the best approach for drive health. Is it better to use a system that allows individual disks to spin down when not in use, or is it safer for the mechanical health of these 18TB drives to keep them spinning 24/7? I’d love to hear your experiences on this, since in some places I’ve read the spin up process is the most stressful on the disk.

3. Service Deployment: I’ll be running Immich, Nextcloud, and other Docker-based services. I need a reliable way to manage these along with a solid backup strategy.

4. Performance: to my understanding, performance is limited since UnRaid can uses each drive individually. In what aspects will this be a limitation?

I was considering TrueNAS + Proxmox as an alternative, but it might be too much of a learning curve.

Given these requirements, do you think unRAID is the most suitable path, or would another OS serve these specific goals better?

Thanks in advance for your help!

Edited January 2Jan 2 by EddieDS
Added information

yes, no, maybe so. It all comes down to what you want it to do and how you want to interact with it.

I highly discourage the use of nextcloud... what does nextcloud do that you can do better with a different set of dockers...

Short answer:
For 4×18 TB HDD + 2 TB SSD, Docker-heavy workloads (Immich, Nextcloud), and a beginner who still wants real data safety, unRAID is a very strong fit — as long as you understand what it does and does not do.

If you want maximum data integrity guarantees (ZFS everywhere) and are comfortable with higher complexity, TrueNAS SCALE or Proxmox + ZFS can be better.
If you want flexibility, disk independence, easy Docker, and sane recovery options, unRAID shines.

Bitrot protection & ransomware reality (important nuance)

Bitrot

unRAID is not ZFS. That means:

• ❌ No native block-level checksumming like ZFS

• ❌ No automatic silent corruption self-healing

But this does not mean your data is unprotected.

What unRAID does well:

• Parity protects against disk failure

• Filesystems like XFS (default) are extremely stable

• Scrubs + checksums can be layered

• Backups are first-class citizens, not an afterthought

Practical unRAID approach (recommended):

• Store app data on cache (SSD)

• Nightly backups to array using:

  • rsync + checksums

  • or tools like CA Backup / Appdata Backup

• Optional: store critical data twice (array + external backup)

This is operationally safer than ZFS alone, because:

ZFS protects you from corruption — backups protect you from you, ransomware, and bad updates.

Ransomware

No NAS OS “prevents” ransomware.

What matters:

• Offline or immutable backups

• Snapshot separation

• Least-privilege containers

unRAID excels here because:

• Docker containers don’t get raw disk access

• Appdata is centralized

• Backups are simple and visible

Disk longevity: spin-down vs 24/7

This is one of unRAID’s strongest points.

Facts:

• Startup stress is real

• Constant heat also kills drives

• Enterprise drives are designed for 24/7

• Consumer drives benefit from reduced duty cycles

unRAID advantage:

• Per-disk independence

• Only the disk holding the file spins up

• Media reads ≠ spin up entire array

For a home server with 18 TB drives, this is ideal:

• Lower heat

• Lower power draw

• Less wear overall

Contrast:

• ZFS → all disks active

• RAIDZ → no spin-down granularity

Docker & service deployment (this is where unRAID wins)

You’re running:

• Immich

• Nextcloud

• Other Docker services

unRAID’s Docker ecosystem is beginner-friendly but not limiting.

Option A: GUI templates (easy)

• Community Apps

• Pre-built templates

• Automatic updates

• Volume paths visible

Option B: Docker Compose (power user, still clean)

unRAID supports Docker Compose via plugins.

This works natively on unRAID with:

• predictable paths

• no VM overhead

• simple backups

User Scripts plugin (this is huge and often overlooked)

The User Scripts plugin lets you hook into system events.

Examples that matter for this user:

Nightly checksum + backup

rsync -av --checksum /mnt/user/photos/ /mnt/user/backups/photos/

Pre-shutdown Docker backup

docker stop immich nextcloud
tar -czf /mnt/user/backups/appdata_$(date +%F).tar.gz /mnt/user/appdata
docker start immich nextcloud

SMART monitoring / alerts

smartctl -a /dev/sdX >> /mnt/user/logs/smart.log

This is far easier than cron + systemd + permissions in most Linux NAS distros.

Performance: what actually is limited?

Yes — unRAID uses independent disks + parity.

What this means:

• ❌ No striped read/write performance

• ❌ Large sequential writes are slower than RAIDZ

What it does not affect:

• Docker performance

• SSD cache performance

• Media serving

• Databases on cache

• App responsiveness

Reality for this build:

• Immich DB → SSD (fast)

• Thumbnails → SSD (fast)

• Media → HDD (fine)

• Nextcloud → SSD + HDD (fine)

If you were doing:

• High-IOPS VMs

• Heavy databases on spinning disks

Then yes — ZFS would win.

___________________________________________________________

unRAID vs alternatives (my honest comparison)

unRAID (recommended here)

✔ Disk independence
✔ Spin-down
✔ Simple Docker
✔ Easy recovery
✔ Beginner friendly
✖ No native ZFS bitrot protection(zfs snapshot scripts exsit to provide this...)

Proxmox (PVE) + unRAID (best hybrid)

✔ Use unRAID for storage
✔ Use PVE for VMs/lxc helper scripts: https://community-scripts.github.io/ProxmoxVE/scripts
✔ Keep Docker simple
✖ Slightly more complexity

TrueNAS SCALE

✔ ZFS integrity
✔ Kubernetes
✖ Steep learning curve
✖ Less flexible disk expansion

OpenMediaVault

✔ Debian-based
✔ Flexible
✖ More manual work
✖ Weaker Docker UX

So I would highly recommend ZFS and unriad for your use case...

that said unraid has started to improve and integrate with native zfs. via openzfs

https://www.youtube.com/watch?v=UR5RCItyCsw

9 hours ago, bmartino1 said:

yes, no, maybe so. It all comes down to what you want it to do and how you want to interact with it.

I highly discourage the use of nextcloud... what does nextcloud do that you can do better with a different set of dockers...

Short answer:
For 4×18 TB HDD + 2 TB SSD, Docker-heavy workloads (Immich, Nextcloud), and a beginner who still wants real data safety, unRAID is a very strong fit — as long as you understand what it does and does not do.

If you want maximum data integrity guarantees (ZFS everywhere) and are comfortable with higher complexity, TrueNAS SCALE or Proxmox + ZFS can be better.
If you want flexibility, disk independence, easy Docker, and sane recovery options, unRAID shines.

Bitrot protection & ransomware reality (important nuance)

Bitrot

unRAID is not ZFS. That means:

• ❌ No native block-level checksumming like ZFS

• ❌ No automatic silent corruption self-healing

But this does not mean your data is unprotected.

What unRAID does well:

• Parity protects against disk failure

• Filesystems like XFS (default) are extremely stable

• Scrubs + checksums can be layered

• Backups are first-class citizens, not an afterthought

Practical unRAID approach (recommended):

• Store app data on cache (SSD)

• Nightly backups to array using:

  • rsync + checksums

  • or tools like CA Backup / Appdata Backup

• Optional: store critical data twice (array + external backup)

This is operationally safer than ZFS alone, because:

Ransomware

No NAS OS “prevents” ransomware.

What matters:

• Offline or immutable backups

• Snapshot separation

• Least-privilege containers

unRAID excels here because:

• Docker containers don’t get raw disk access

• Appdata is centralized

• Backups are simple and visible

Disk longevity: spin-down vs 24/7

This is one of unRAID’s strongest points.

Facts:

• Startup stress is real

• Constant heat also kills drives

• Enterprise drives are designed for 24/7

• Consumer drives benefit from reduced duty cycles

unRAID advantage:

• Per-disk independence

• Only the disk holding the file spins up

• Media reads ≠ spin up entire array

For a home server with 18 TB drives, this is ideal:

• Lower heat

• Lower power draw

• Less wear overall

Contrast:

• ZFS → all disks active

• RAIDZ → no spin-down granularity

Docker & service deployment (this is where unRAID wins)

You’re running:

• Immich

• Nextcloud

• Other Docker services

unRAID’s Docker ecosystem is beginner-friendly but not limiting.

Option A: GUI templates (easy)

• Community Apps

• Pre-built templates

• Automatic updates

• Volume paths visible

Option B: Docker Compose (power user, still clean)

unRAID supports Docker Compose via plugins.

This works natively on unRAID with:

• predictable paths

• no VM overhead

• simple backups

User Scripts plugin (this is huge and often overlooked)

The User Scripts plugin lets you hook into system events.

Examples that matter for this user:

Nightly checksum + backup

rsync -av --checksum /mnt/user/photos/ /mnt/user/backups/photos/

Pre-shutdown Docker backup

docker stop immich nextcloud
tar -czf /mnt/user/backups/appdata_$(date +%F).tar.gz /mnt/user/appdata
docker start immich nextcloud

SMART monitoring / alerts

smartctl -a /dev/sdX >> /mnt/user/logs/smart.log

This is far easier than cron + systemd + permissions in most Linux NAS distros.

Performance: what actually is limited?

Yes — unRAID uses independent disks + parity.

What this means:

• ❌ No striped read/write performance

• ❌ Large sequential writes are slower than RAIDZ

What it does not affect:

• Docker performance

• SSD cache performance

• Media serving

• Databases on cache

• App responsiveness

Reality for this build:

• Immich DB → SSD (fast)

• Thumbnails → SSD (fast)

• Media → HDD (fine)

• Nextcloud → SSD + HDD (fine)

If you were doing:

• High-IOPS VMs

• Heavy databases on spinning disks

Then yes — ZFS would win.

___________________________________________________________

unRAID vs alternatives (my honest comparison)

unRAID (recommended here)

✔ Disk independence
✔ Spin-down
✔ Simple Docker
✔ Easy recovery
✔ Beginner friendly
✖ No native ZFS bitrot protection(zfs snapshot scripts exsit to provide this...)

Proxmox (PVE) + unRAID (best hybrid)

✔ Use unRAID for storage
✔ Use PVE for VMs/lxc helper scripts: https://community-scripts.github.io/ProxmoxVE/scripts
✔ Keep Docker simple
✖ Slightly more complexity

TrueNAS SCALE

✔ ZFS integrity
✔ Kubernetes
✖ Steep learning curve
✖ Less flexible disk expansion

OpenMediaVault

✔ Debian-based
✔ Flexible
✖ More manual work
✖ Weaker Docker UX

So I would highly recommend ZFS and unriad for your use case...

First of all, I want to thank you for taking the time to provide such a detailed response.

I’ll definitely look into Nextcloud alternatives. It’s just the one I see mentioned most often, but I haven’t settled on it yet.

I’ve been reading around, and using Proxmox seems almost like a religion in some communities. I understand the benefits of snapshots and the independence between services, but I’m still unsure how difficult it would be for someone with my limited experience. The same goes for TrueNAS.

I’m considering a strategy similar to what you mentioned: backing up all Docker containers and configurations to both the HDD array and a cold storage cloud every night. Additionally, sensitive data like photos or important documents would be backed up from the array to the cloud. However, there’s a lot of content, like the media server library, that won't be backed up due to the sheer amount of storage required. That information is replaceable, but if I’m not mistaken, with a ZFS system I could just roll back to a previous snapshot in case of ransomware. Maybe I’m overthinking this scenario.

Regarding bit rot: if it can’t be automatically fixed, from what you said it can at least be detected? I assume that if it happens, the corrupted data could be replaced using either the parity disk or the cloud copy.

I’m using WD180EDGZ drives, which are shucked disks and supposedly enterprise-grade. I bought them second-hand; they have about four years of use and roughly 80 power cycles each. Electricity-wise, it would cost a bit under 30€ a year, so I don’t consider that a major factor. Since each disk would likely start a few times a day in normal use, I’m unsure which approach puts less stress on the hardware.

I’ve used Docker Compose and Portainer briefly before, on a Raspberry Pi for home automation, DNS, and a few small services. I’ll need to study the differences and the benefits of using them in this new setup. As for using Proxmox alongside Unraid, if I’m already deploying services directly on Unraid, what exactly would be the advantage of adding Proxmox to the mix?

Again, thank you so much for your time!

13 hours ago, EddieDS said:

I’m currently planning my first home server build

and

13 hours ago, EddieDS said:

Bitrot Protection: I need a system that ensures my critical data (photos in Immich, documents in Nextcloud) is protected against silent data corruption over time.

Personally, I believe that bitrot on a hard disk is virtually impossible in this day and age—a hard disk either returns the data as originally written to the disk or it returns a read error. (But let's not go there...) IF you do consider bitrot a true problem that you must be planning then you need system hardware that supports and you use ECC RAM. It is more more likely that data will be silently corrupted while in RAM than on a hard disk!

13 hours ago, EddieDS said:

4. Performance: to my understanding, performance is limited since UnRaid can uses each drive individually. In what aspects will this be a limitation?

I didn't see anyone address this. You seem to want to use your Unraid system for long term storage of data that will not be modified. Why is performance even an issue? For the most part, 'write' performance is the most impact parameter compared to other system. 'Read' performance is impacted so far as it is limited by the read speed of the individual hard disk on which the data is actually saved. (In the case of 1Gb LAN speed, the LAN is the limiting factor.)

One more thing in unraids favor; the forum. After using unraid for over 10 years I think the best unraid feature is the forums! There's so many talented people here and everyone is very friendly, welcoming and eager to help. And I have to say, the mods do an fantastic job! I don't think they have to moderate to much,but you can see them in nearly every thread helping out. It's truly astonishing how well this forum works.

Edited January 2Jan 2 by strike

I have lost files due to bit rot on unraid it's why I mention.

And only if you're using btrfs or zfs that can restore a snapshot to fix the file or grouping of files. ...

With my unraid setup, I usually make a share called backup and use that as a station area.

Lately the app data backup plugin has been breaking and not been easily set up make Docker backups and also skip certain folders. A good example is Plex. Well, the app data backup plugin will now detect that there is a Plex install. Setting up to exclude certain folders depending on how you use ZFS

You can be a pain to ignore the media folder and also not backup... the Plex database is what you want.

*excludes overwrite areas in same paths for backup

So I actually use a user script that does what the backup script was going to do but only targets the files, folders, and other systems that I want to Target.

#!/bin/bash
# Unraid Docker + Appdata backup script
# Stops running containers, tars appdata/configs, then restarts containers.

set -euo pipefail

########################################
#            CONFIGURATION             #
########################################

# Where to store backups (handles spaces fine as long as it's quoted)
BACKUP_ROOT="/mnt/vm-zfs/Backups/unraid docker data"

# Base name for the backup file (it will get a timestamp appended)
BACKUP_PREFIX="unraid-docker-backup"

# Core Unraid appdata
APPDATA_DIR="/mnt/user/appdata"

# Unraid Docker XML templates
DOCKER_XML_DIR="/boot/config/plugins/dockerMan/templates-user"

# Arrs stack appdata + docker-compose
ARRS_APPDATA_DIR="/mnt/user/Dockers/arsdata/appdata"
ARRS_COMPOSE_FILE="${ARRS_APPDATA_DIR}/docker-compose.yml"

# Plex database + docker-compose
PLEX_DB_DIR="/mnt/user/Dockers/Plex/database"
PLEX_COMPOSE_FILE="/mnt/user/Dockers/Plex/docker-compose.yml"

########################################
#        DO NOT EDIT BELOW HERE        #
########################################

TIMESTAMP="$(date +%Y%m%d-%H%M%S)"
BACKUP_FILE="${BACKUP_ROOT}/${BACKUP_PREFIX}-${TIMESTAMP}.tar.gz"
CONTAINERS_FILE="/tmp/unraid-docker-running-containers-${TIMESTAMP}.txt"

echo "=== Unraid Docker Backup ==="
echo "Timestamp     : ${TIMESTAMP}"
echo "Backup target : ${BACKUP_FILE}"
echo

# Ensure backup directory exists
echo "[1/5] Creating backup directory if needed..."
mkdir -p "${BACKUP_ROOT}"

########################################
#   Capture and stop running containers
########################################

echo "[2/5] Capturing list of running containers..."

# List names of running containers (one per line)
docker ps --format '{{.Names}}' > "${CONTAINERS_FILE}" || true

if [[ -s "${CONTAINERS_FILE}" ]]; then
    echo "Found running containers:"
    cat "${CONTAINERS_FILE}"
    echo
    echo "[3/5] Stopping running containers..."
    # docker stop accepts a list of names/IDs as separate args
    docker stop $(cat "${CONTAINERS_FILE}") || true
else
    echo "No running containers found."
fi

########################################
#     Build list of paths to backup
########################################

echo
echo "[4/5] Building backup path list..."

paths=()

if [[ -d "${APPDATA_DIR}" ]]; then
    echo "  + Including: ${APPDATA_DIR}"
    paths+=("${APPDATA_DIR}")
else
    echo "  - Skipping (not found): ${APPDATA_DIR}"
fi

if [[ -d "${DOCKER_XML_DIR}" ]]; then
    echo "  + Including: ${DOCKER_XML_DIR}"
    paths+=("${DOCKER_XML_DIR}")
else
    echo "  - Skipping (not found): ${DOCKER_XML_DIR}"
fi

if [[ -d "${ARRS_APPDATA_DIR}" ]]; then
    echo "  + Including: ${ARRS_APPDATA_DIR}"
    paths+=("${ARRS_APPDATA_DIR}")
fi

if [[ -f "${ARRS_COMPOSE_FILE}" ]]; then
    echo "  + Including: ${ARRS_COMPOSE_FILE}"
    paths+=("${ARRS_COMPOSE_FILE}")
fi

if [[ -d "${PLEX_DB_DIR}" ]]; then
    echo "  + Including: ${PLEX_DB_DIR}"
    paths+=("${PLEX_DB_DIR}")
fi

if [[ -f "${PLEX_COMPOSE_FILE}" ]]; then
    echo "  + Including: ${PLEX_COMPOSE_FILE}"
    paths+=("${PLEX_COMPOSE_FILE}")
fi

# Safety check: make sure we have something to back up
if [[ ${#paths[@]} -eq 0 ]]; then
    echo "ERROR: No valid paths found to back up. Aborting."
    # Try to restart containers before exiting
    if [[ -s "${CONTAINERS_FILE}" ]]; then
        echo "Attempting to restart previously running containers..."
        xargs -r docker start < "${CONTAINERS_FILE}" || true
    fi
    exit 1
fi

########################################
#       Create the tar.gz archive
########################################

echo
echo "[5/5] Creating backup archive..."
echo "Running: tar -cvpzf \"${BACKUP_FILE}\" [paths...]"
tar -cvpzf "${BACKUP_FILE}" "${paths[@]}"

echo
echo "Backup complete: ${BACKUP_FILE}"

# Flush to disk
sync

########################################
#     Restart previously running containers
########################################

if [[ -s "${CONTAINERS_FILE}" ]]; then
    echo
    echo "Restarting previously running containers..."
    xargs -r docker start < "${CONTAINERS_FILE}" || true
    echo "Container restart commands issued."
else
    echo
    echo "No containers were running before backup; none to restart."
fi

# Cleanup temp file
rm -f "${CONTAINERS_FILE}"

echo
echo "=== Unraid Docker Backup finished successfully ==="
exit 0

There are many user scripts including a post with all my user scripts for code prosperity and a bunch of others on the form. Space invader YouTube videos and mutg have active forms that go over this as well. There's even an rsync backup post that can go over and assist you with setting up backups. https://forums.unraid.net/topic/97958-rsync-incremental-backup/

Other programs exist as well including plugins and applications and Dockers that can do the same like lucky backup and rclone plugin...

Based on the disk that you've reported here in the Western digital Enterprise drives, this would be fine in a ZFS array and can be ran 24/7. Unraid does not ship a snapshot script which is also used to help fight it brought and some forms of redundancy backup. Snapshots are not a backup in and of themselves.

But snapshots can be used to restore a file on x date when changes have been made. This is the bit route protection. And backup config restore.

But this would Mark your 18 TB for raid Z1 and ZFS and be used as a tank or deep storage. (I would assume)

Large files such as pictures and media files would be here and anything else that requires space would be entered into these disks as they would run 24/7. And we would build a system that would run 24/7.

Using ZFS consumes more RAM and unraid is a ram hungry system to begin with as the whole OS is mutable and Boots into the ram of the computer.

If you're comfortable with portainer, you can also run portainer on top of unraid's Docker system and use docker containers. If you do so, use one not both to control dockers.

Unraid has a nice Docker web UI. Even with compose and the compose plug-in systems, it's fairly straightforward. To add a composed file. Make your edits. Add an EnV file. Make your edits...

For me as I'm still testing some things with virtualized unraid. Proxmox allows me the ability to back up a virtual disks and the disk systems themselves. And because unraid now has moved the ability where I no longer need the ZFS array. I can let Proxmox control my ZFS discs.

Pass a ZFS data set from my ZFS discs on proxmox into the VM as a virtiofs.

#!/bin/bash

# Create mount points
mkdir -p /host

# Mount VirtioFS shares from PVE
mount -t virtiofs data /host
#old qemu 9p mode
#mount -t 9p -o trans=virtio,version=9p2000.L data /host

Pass a temporary Vdesk for cached disk for btrfs for pool system.

And then I'm entirely in vm land where I can now use VM backups and PBS to backup entire systems at those states.

For me it's easier backups and the ability to use ZFS send to receive to a remote system to store my snapshots and data. Not a priority can be a bit complex but gives me a little bit more freedom and control over virtual space.

this give me a "best of both worlds" kind of setup pve for all my VM needs. Unraid for all my docker needs.

Edited January 2Jan 2 by bmartino1
Data - typo

2 hours ago, Frank1940 said:

Personally, I believe that bitrot on a hard disk is virtually impossible in this day and age—a hard disk either returns the data as originally written to the disk or it returns a read error. (But let's not go there...) IF you do consider bitrot a true problem that you must be planning then you need system hardware that supports and you use ECC RAM. It is more more likely that data will be silently corrupted while in RAM than on a hard disk!

Wasn’t aware that bitrot was not an issue anymore. My MOBO is a domestic one and therefore not ECC compatible.

In case of a corrupted file, which would give a read error as you say, would it overwrite the preexisting backupc? Or would show up some error in the process?

2 hours ago, Frank1940 said:

I didn't see anyone address this. You seem to want to use your Unraid system for long term storage of data that will not be modified. Why is performance even an issue? For the most part, 'write' performance is the most impact parameter compared to other system. 'Read' performance is impacted so far as it is limited by the read speed of the individual hard disk on which the data is actually saved. (In the case of 1Gb LAN speed, the LAN is the limiting factor.)

Just a general concern, as said it is my first server, so I’m unsure on what services I will end up making use of. At the moment, it will be connected via 2,5Gb to my PC, and witch 1Gb to the network.

1 hour ago, strike said:

One more thing in unraids favor; the forum. After using unraid for over 10 years I think the best unraid feature is the forums! There's so many talented people here and everyone is very friendly, welcoming and eager to help. And I have to say, the mods do a fantastic job! I don't think they have to moderate to much,but you can see them in nearly every thread helping out. It's truly astonishing how well this forum works.

It’s my first time here and I have quickly noticed it haha.

bitrot is a concern but due to new hardware and systems its been mitigated, not removed!

Again. I HAVE lost files due to it on unriad... this is why i'm pro ZFS snapshot. Shouldn't be a issue even without ecc ram. bios and hard drives have things on chips to help this. Mitigated doesn't mean it doesn't exist nor happen... This is why its important to backup and follow a 321 rule on important files. 3 disks 2 location with ideal 1 being offsite... (a backup is only good if it can be restored)...

Using disk file systems for correct loads. Linux, windows apple all have different file systems. XFS, btrfs, ext, zfs, hfs, applefs, ntfs, fat32.... all have pro cons use case and is what your hard drive will use to store data....
https://docs.unraid.net/category/manage-storage/

Example such as large reads and writes on a database, i wouldn't normally not store this on a zfs without a special vdisk metadata drive to handle the high read/writes.
*but again that gets into complex systems... default unraid array disk and parity use xfs where cache and pool disk default to btrfs

It comes down to what you want it to do and how you want to interact with it. I like to tinker. and do things because i can. that doesn't mean its stable nor you should try.

Unraid in and of itself would be a perfect fit and using youtube video form space invader to learn along the way.

https://www.youtube.com/c/SpaceinvaderOne

Edited January 5Jan 5 by bmartino1
Data - typo

11 minutes ago, EddieDS said:

In case of a corrupted file, which would give a read error as you say, would it overwrite the preexisting backupc? Or would show up some error in the process?

It depends on where is was corrupted. If it was corrupt in RAM, it is not detected. If ECC RAM is used, it should be detected before written to disk. (I believe ECC Ram is detect only...) If the HD finds an error, it will try to fix things. (Correctable read errors are not that uncommon. You only need to look at the drive specs to find that occurrence rate.) If it is fixed, it is a 'normal' read. If unfixable, the drive throws a read error. Unraid may to able to reconstruct the original data using parity. (I am not sure what error it displays at this point.) (Quick thought here... If there actually is bitrot on a HD, you should be able to recover the original data by pulling the disk and allowing Unraid to emulate the disk. If the data is fixed, you had bitrot. If not, you wrote corrupted data to the HD in the first place.)

1 hour ago, bmartino1 said:

I have lost files due to bit rot on unraid it's why I mention.

And only if you're using btrfs or zfs that can restore a snapshot to fix the file or grouping of files. ...

With my unraid setup, I usually make a share called backup and use that as a station area.

Lately the app data backup plugin has been breaking and not been easily set up make Docker backups and also skip certain folders. A good example is Plex. Well, the app data backup plugin will now detect that there is a Plex install. Setting up to exclude certain folders depending on how you use ZFS

You can be a pain to ignore the media folder and also not backup... the Plex database is what you want.

*excludes overwrite areas in same paths for backup

So I actually use a user script that does what the backup script was going to do but only targets the files, folders, and other systems that I want to Target.

#!/bin/bash# Unraid Docker + Appdata backup script# Stops running containers, tars appdata/configs, then restarts containers.

set -euo pipefail

#########################################            CONFIGURATION             #########################################

# Where to store backups (handles spaces fine as long as it's quoted)
BACKUP_ROOT="/mnt/vm-zfs/Backups/unraid docker data"

# Base name for the backup file (it will get a timestamp appended)
BACKUP_PREFIX="unraid-docker-backup"

# Core Unraid appdata
APPDATA_DIR="/mnt/user/appdata"

# Unraid Docker XML templates
DOCKER_XML_DIR="/boot/config/plugins/dockerMan/templates-user"

# Arrs stack appdata + docker-compose
ARRS_APPDATA_DIR="/mnt/user/Dockers/arsdata/appdata"
ARRS_COMPOSE_FILE="${ARRS_APPDATA_DIR}/docker-compose.yml"

# Plex database + docker-compose
PLEX_DB_DIR="/mnt/user/Dockers/Plex/database"
PLEX_COMPOSE_FILE="/mnt/user/Dockers/Plex/docker-compose.yml"

#########################################        DO NOT EDIT BELOW HERE        #########################################

TIMESTAMP="$(date +%Y%m%d-%H%M%S)"
BACKUP_FILE="${BACKUP_ROOT}/${BACKUP_PREFIX}-${TIMESTAMP}.tar.gz"
CONTAINERS_FILE="/tmp/unraid-docker-running-containers-${TIMESTAMP}.txt"

echo "=== Unraid Docker Backup ==="echo "Timestamp     : ${TIMESTAMP}"echo "Backup target : ${BACKUP_FILE}"echo

# Ensure backup directory existsecho "[1/5] Creating backup directory if needed..."mkdir -p "${BACKUP_ROOT}"

#########################################   Capture and stop running containers########################################

echo "[2/5] Capturing list of running containers..."

# List names of running containers (one per line)
docker ps --format '{{.Names}}' > "${CONTAINERS_FILE}" || true

if [[ -s "${CONTAINERS_FILE}" ]]; then
    echo "Found running containers:"
    cat "${CONTAINERS_FILE}"
    echo
    echo "[3/5] Stopping running containers..."
    # docker stop accepts a list of names/IDs as separate args
    docker stop $(cat "${CONTAINERS_FILE}") || trueelse
    echo "No running containers found."fi

#########################################     Build list of paths to backup########################################

echoecho "[4/5] Building backup path list..."

paths=()

if [[ -d "${APPDATA_DIR}" ]]; then
    echo "  + Including: ${APPDATA_DIR}"
    paths+=("${APPDATA_DIR}")
else
    echo "  - Skipping (not found): ${APPDATA_DIR}"fi

if [[ -d "${DOCKER_XML_DIR}" ]]; then
    echo "  + Including: ${DOCKER_XML_DIR}"
    paths+=("${DOCKER_XML_DIR}")
else
    echo "  - Skipping (not found): ${DOCKER_XML_DIR}"fi

if [[ -d "${ARRS_APPDATA_DIR}" ]]; then
    echo "  + Including: ${ARRS_APPDATA_DIR}"
    paths+=("${ARRS_APPDATA_DIR}")
fi

if [[ -f "${ARRS_COMPOSE_FILE}" ]]; then
    echo "  + Including: ${ARRS_COMPOSE_FILE}"
    paths+=("${ARRS_COMPOSE_FILE}")
fi

if [[ -d "${PLEX_DB_DIR}" ]]; then
    echo "  + Including: ${PLEX_DB_DIR}"
    paths+=("${PLEX_DB_DIR}")
fi

if [[ -f "${PLEX_COMPOSE_FILE}" ]]; then
    echo "  + Including: ${PLEX_COMPOSE_FILE}"
    paths+=("${PLEX_COMPOSE_FILE}")
fi

# Safety check: make sure we have something to back upif [[ ${#paths[@]} -eq 0 ]]; then
    echo "ERROR: No valid paths found to back up. Aborting."
    # Try to restart containers before exiting
    if [[ -s "${CONTAINERS_FILE}" ]]; then
        echo "Attempting to restart previously running containers..."
        xargs -r docker start < "${CONTAINERS_FILE}" || true
    fi
    exit 1
fi

#########################################       Create the tar.gz archive########################################

echoecho "[5/5] Creating backup archive..."echo "Running: tar -cvpzf \"${BACKUP_FILE}\" [paths...]"
tar -cvpzf "${BACKUP_FILE}" "${paths[@]}"

echoecho "Backup complete: ${BACKUP_FILE}"

# Flush to disksync

#########################################     Restart previously running containers########################################

if [[ -s "${CONTAINERS_FILE}" ]]; then
    echo
    echo "Restarting previously running containers..."
    xargs -r docker start < "${CONTAINERS_FILE}" || true
    echo "Container restart commands issued."else
    echo
    echo "No containers were running before backup; none to restart."fi

# Cleanup temp filerm -f "${CONTAINERS_FILE}"

echoecho "=== Unraid Docker Backup finished successfully ==="exit 0

There are many user scripts including a post with all my user scripts for code prosperity and a bunch of others on the form. Space invader YouTube videos and mutg have active forms that go over this as well. There's even an rsync backup post that can go over and assist you with setting up backups. https://forums.unraid.net/topic/97958-rsync-incremental-backup/

Other programs exist as well including plugins and applications and Dockers that can do the same like lucky backup and rclone plugin...

Based on the disk that you've reported here in the Western digital Enterprise drives, this would be fine in a ZFS array and can be ran 24/7. Unraid does not ship a snapshot script which is also used to help fight it brought and some forms of redundancy backup. Snapshots are not a backup in and of themselves.

But snapshots can be used to restore a file on x date when changes have been made. This is the bit route protection. And backup config restore.

But this would Mark your 18 TB for raid Z1 and ZFS and be used as a tank or deep storage. (I would assume)

Large files such as pictures and media files would be here and anything else that requires space would be entered into these disks as they would run 24/7. And we would build a system that would run 24/7.

Using ZFS consumes more RAM and unraid is a ram hungry system to begin with as the whole OS is mutable and Boots into the ram of the computer.

If you're comfortable with portainer, you can also run portainer on top of unraid's Docker system and use docker containers. If you do so, use one not both to control dockers.

Unraid has a nice Docker web UI. Even with compose and the compose plug-in systems, it's fairly straightforward. To add a composed file. Make your edits. Add an EnV file. Make your edits...

For me as I'm still testing some things with virtualized unraid. Proxmox allows me the ability to back up a virtual disks and the disk systems themselves. And because unraid now has moved the ability where I no longer need the ZFS array. I can let Proxmox control my ZFS discs.

Pass a ZFS data set from my ZFS discs on proxmox into the VM as a virtiofs.

#!/bin/bash

# Create mount pointsmkdir -p /host

# Mount VirtioFS shares from PVE
mount -t virtiofs data /host
#old qemu 9p mode#mount -t 9p -o trans=virtio,version=9p2000.L data /host

Pass a temporary Vdesk for cached disk for btrfs for pool system.

And then I'm entirely in vm land where I can now use VM backups and PBS to backup entire systems at those states.

For me it's easier backups and the ability to use ZFS send to receive to a remote system to store my snapshots and data. Not a priority can be a bit complex but gives me a little bit more freedom and control over virtual space.

this give me a "best of both worlds" kind of setup pve for all my VM needs. Unraid for all my docker needs.

10 minutes ago, bmartino1 said:

bitrot is a concern but due to new hardware and systems its been mitigated, not removed!

Again. I HAVE lost files due to it on unriad... this is why i'm pro ZFS snapshot. Shouldn't be a issues even without ecc ram. bios and hard drives have things on ships to help this. Mitigated doesn't mean it doesn't exist nor happen... This is why its important to backup and follow a 321 rule on important files. 3 disks 2 location with ideal 1 being offsite... (a backup is only good if it can be restored)...

using disk file systems for correct loads. linkux, windows apple all have different file systems. XFS, btrfs, ext, zfs, hfs, apfs, ntfs, fat32.... all have pro cons use case and is what your harddrive will use to store data....

Example such as large reads and writes on a dataabse i wouldn't normaly not store this on a zfs with out a specal vdisk meta data drive to handle the high read/writes.
*but again that gets into compolex systems... default unraid array disk and partiy use xfs where cahce and pool disk default to btrfs

It comes down to what you want it to do and how you want to interact with it. I like to tinker. and do things becasue i can. that doent' mean its stable nor you should try.

Unraid in and of itself would be a perfect fit and using youtube video form space invader to learn along the way.

https://www.youtube.com/c/SpaceinvaderOne

I’m slowly rereading all this, since I get lost at some points. Probably means I’m getting into deeper water than I thought, and I might be trying to make everything more complex than what I can handle.

I’ll review some of the concepts that I’m not getting, and will check out the YouTube channel you recommended.

Thanks again!

3 minutes ago, Frank1940 said:

It depends on where is was corrupted. If it was corrupt in RAM, it is not detected. If ECC RAM is used, it should be detected before written to disk. (I believe ECC Ram is detect only...) If the HD finds an error, it will try to fix things. (Correctable read errors are not that uncommon. You only need to look at the drive specs to find that occurrence rate.) If it is fixed, it is a 'normal' read. If unfixable, the drive throws a read error. Unraid may to able to reconstruct the original data using parity. (I am not sure what error it displays at this point.) (Quick thought here... If there actually is bitrot on a HD, you should be able to recover the original data by pulling the disk and allowing Unraid to emulate the disk. If the data is fixed, you had bitrot. If not, you wrote corrupted data to the HD in the first place.)

Thanks for the insight!

1 hour ago, Frank1940 said:

(I believe ECC Ram is detect only...)

If you have multibit ECC it can correct too. I can't remember if single bit ECC does. I had multibit ECC in my old server, and it saved me multiple times from corruption. But I agree, it is more likely that data will be silently corrupted while in RAM than on a hard disk. If I were worried about bitrot, I would go for a server with ECC ram. Or use ZFS, preferably both. I have backup of my most important data, but most of my data is video files, which I don't have a backup of. But if a videofile gets bitrot, the most I would notice are some artifacts on playback in a scene or two. Pictures are more prone to corruption for some reason, and as a result, you may not be able to open the file at all.

I have ECC RAM in my current server too, but it's "on-die ECC" which is not as good as normal ECC. But I chose to go for consumer-grade hardware when I upgraded my hardware last time. But personally, I don't worry that much about bitrot. I can restore important data from backup if I have to.