Vendí mi UNAS Pro 8 y volví a TrueNAS

Hace poco vendí mi NAS de UniFi, el UNAS Pro 8, y he decidido volver a TrueNAS. No porque el UNAS sea malo, ni porque UniFi Drive no tenga sentido, sino porque mi forma de usar un NAS está cambiando y necesito algo con más control, más flexibilidad y, sobre todo, volver a tener ZFS como centro de todo.

El UNAS me daba una experiencia muy limpia y sencilla. TrueNAS, en cambio, me devuelve datasets, snapshots, permisos, configuraciones finas por carpeta, libertad para mover el hardware y la tranquilidad de saber que puedo llevarme una configuración a otra máquina si lo necesito.

En este artículo dejo la parte que no tenía sentido meter completa en el vídeo: cómo hice la migración, cómo monté un NAS en el otro, cómo usé rsync, cómo comprobé los datos con checksums y qué pruebas hice con los datasets y el recordsize.

Por qué vuelvo de UNAS a TrueNAS

La razón principal es bastante simple: quería probar el ecosistema de UniFi como NAS, lo probé, me gustó en muchas cosas, pero terminé echando de menos TrueNAS y ZFS.

El UNAS Pro 8 tiene mucho sentido si quieres algo sencillo, integrado y con poca fricción. Entras, creas carpetas, compartes y listo. Para mucha gente eso es justo lo que necesita. Pero en mi caso empecé a notar que quería más control sobre cómo se comporta cada carpeta, cómo se organizan los datos y cómo puedo adaptar el almacenamiento a distintos usos.

También estoy preparando una migración a SSD SATA de 4 TB. Mi idea es reducir ruido, vibraciones y consumo, porque realmente ya no necesito tantísimo espacio como antes. En mis pruebas, el UNAS Pro 8 no aprovechaba los SSD SATA como esperaba, y además la posibilidad de montar un NAS DIY con más puertos SATA me resulta cada vez más atractiva.

Hardware usado

Para esta vuelta a TrueNAS estoy usando una ZimaCube con TrueNAS instalado directamente. La unidad que estoy usando tiene 8 GB de RAM, que no es una barbaridad para ZFS, pero para esta migración, pruebas y uso inicial está funcionando correctamente.

El pool principal quedó montado con:

• 4 discos HDD de 4 TB.
• RAIDZ1.
• Pool llamado slow.
• Datasets separados para ISO, Media, Nextcloud, TM y Youtube.
• Sin special vdev NVMe en la configuración final del vídeo.

La idea de separar por datasets es que cada uno pueda tener propiedades propias: compresión, snapshots, permisos, cuotas, recordsize, compartición por SMB/NFS, etc.

Antes de migrar: copia offsite

Antes de mover nada, lo más importante no es el comando de rsync. Lo más importante es tener una copia fuera de ese pool y fuera de esa máquina.

En mi caso ya tenía una copia offsite en otro NAS. Eso es lo que realmente me dejaba dormir tranquilo. Si durante una migración fallan dos discos, borras algo sin querer, se corrompe una carpeta o te equivocas con un comando, el plan no puede ser “a ver si ZFS me salva”. El plan tiene que ser tener otra copia.

Si no tienes otro NAS ni discos suficientes, una opción temporal es alquilar almacenamiento durante unos días. Por ejemplo, un Hetzner Storage Box puede servir como puente: subes los datos, recreas el pool y luego los bajas. Hetzner documenta que los Storage Box soportan protocolos como SMB/CIFS, SFTP, SCP, WebDAV, BorgBackup, Restic, Rclone y rsync por SSH, y su facturación puede ser por horas hasta el límite mensual según el producto y uso.

Mi primer intento: copiar desde el Mac

La primera idea fue la más cómoda: montar las dos carpetas SMB en mi Mac Studio y copiar de un NAS al otro desde ahí.

Es decir:

• Montar el share del UNAS.
• Montar el share de TrueNAS.
• Arrastrar o copiar de un punto a otro.

Pero en la práctica no fue bien. TrueNAS empezó a dar errores de memoria, así que cambié el enfoque. En vez de usar el Mac como intermediario, hice que el propio UNAS montase el destino de TrueNAS y ejecuté rsync desde allí.

Preparar datasets en TrueNAS

En TrueNAS creé datasets separados dentro del pool slow. La estructura quedó así:

slow/ISO
slow/Media
slow/Nextcloud
slow/TM
slow/Youtube

Desde shell, el equivalente sería algo así:

zfs create slow/ISO
zfs create slow/Media
zfs create slow/Nextcloud
zfs create slow/TM
zfs create slow/Youtube

Y para dejar las propiedades básicas que terminé usando:

zfs set compression=lz4 slow/ISO
zfs set compression=lz4 slow/Media
zfs set compression=lz4 slow/Nextcloud
zfs set compression=lz4 slow/TM
zfs set compression=lz4 slow/Youtube

zfs set atime=off slow/ISO
zfs set atime=off slow/Media
zfs set atime=off slow/Nextcloud
zfs set atime=off slow/TM
zfs set atime=off slow/Youtube

zfs set recordsize=128K slow/ISO
zfs set recordsize=128K slow/Media
zfs set recordsize=128K slow/Nextcloud
zfs set recordsize=128K slow/TM
zfs set recordsize=128K slow/Youtube

En mi caso lo hice desde TrueNAS y automatizando parte del proceso, pero esos comandos reflejan las propiedades importantes.

Montar TrueNAS desde el UNAS

La migración práctica consistió en montar el destino SMB de TrueNAS dentro del UNAS y ejecutar rsync desde el UNAS. Así el tráfico va directo de NAS a NAS y no pasa por el Mac.

Ejemplo para montar el dataset Media compartido por SMB desde TrueNAS:

sudo mkdir -p /mnt/truenas/Media

sudo mount -t cifs //10.0.1.204/Media /mnt/truenas/Media \
  -o username=USUARIO_SMB,password='CONTRASEÑA_SMB',vers=3.1.1,iocharset=utf8,noperm

Para otros datasets, la idea es la misma:

sudo mkdir -p /mnt/truenas/Youtube
sudo mount -t cifs //10.0.1.204/Youtube /mnt/truenas/Youtube \
  -o username=USUARIO_SMB,password='CONTRASEÑA_SMB',vers=3.1.1,iocharset=utf8,noperm

Si no quieres poner la contraseña en el comando, es mejor usar un archivo de credenciales:

sudo install -m 600 /dev/null /root/.smb-truenas
sudo nano /root/.smb-truenas

Contenido del archivo:

username=USUARIO_SMB
password=CONTRASEÑA_SMB

Y entonces montar así:

sudo mount -t cifs //10.0.1.204/Media /mnt/truenas/Media \
  -o credentials=/root/.smb-truenas,vers=3.1.1,iocharset=utf8,noperm

Nota importante: si necesitas preservar permisos POSIX, ACLs Linux o propietarios exactos, SMB no siempre es la mejor ruta. En ese caso es preferible usar rsync por SSH o montar por NFS con usuarios/UIDs coherentes. En mi caso, lo importante era migrar los datos y después controlar permisos y shares desde TrueNAS.

Copiar con rsync

Primero conviene hacer una prueba en seco:

SRC="/ruta/en/unas/Media/"
DST="/mnt/truenas/Media/"

rsync -aH --info=progress2 --dry-run "$SRC" "$DST"

Si la lista parece correcta, lanzas la copia real:

rsync -aH --info=progress2 --partial --append-verify "$SRC" "$DST"

Para carpetas grandes como Youtube o Media, el progreso global ayuda bastante:

rsync -aH --info=progress2 --partial --append-verify \
  "/ruta/en/unas/Youtube/" \
  "/mnt/truenas/Youtube/"

Algunas opciones útiles:

• -a: modo archivo; conserva estructura, fechas y permisos básicos.
• -H: conserva hard links si existen.
• --partial: si se corta, deja archivos parciales para poder reanudar.
• --append-verify: reanuda archivos grandes y verifica lo añadido.
• --info=progress2: muestra progreso global.
• --dry-run: simula sin copiar nada.

Si estás migrando desde un filesystem con ACLs y atributos extendidos compatibles, podrías probar:

rsync -aHAX --numeric-ids --info=progress2 --partial --append-verify "$SRC" "$DST"

Pero con un destino montado por SMB, no asumiría que -A y -X van a preservar todo como esperas. Para eso es mejor probar con una carpeta pequeña antes.

Verificar la copia con checksum

Después de copiar, hice comprobaciones para asegurarme de que los archivos estaban íntegros. Una forma sencilla con rsync es hacer una segunda pasada con checksum:

rsync -aHc --dry-run --itemize-changes "$SRC" "$DST"

La opción -c fuerza comparación por checksum en vez de quedarse solo con tamaño y fecha. Si no muestra cambios relevantes, la copia está bien.

Recordsize: por qué dejé 128K

Una de las cosas que quería comprobar era si tenía sentido usar recordsize más grandes para datasets con archivos grandes, como Youtube, Media o ISO.

Sobre el papel, uno podría pensar que para vídeo o ISOs tendría sentido subir a 1M o 2M. Pero al medirlo en mi pool real de 4 HDD en RAIDZ1, sin red y sin NVMe special vdev, el resultado fue que 128K fue lo más sólido.

La conclusión es sencilla: mejor medir antes de tocar. En este pool HDD-only, los tamaños grandes no mejoraron el rendimiento práctico, así que dejé los datasets en 128K.

Importante: cambiar el recordsize no reescribe automáticamente los archivos existentes. Afecta sobre todo a archivos nuevos o reescritos.

Backup de configuración y claves de cifrado

Otra cosa que hice antes de seguir toqueteando fue sacar copia de seguridad de la configuración de TrueNAS y de las claves de cifrado del pool.

En TrueNAS SCALE, la configuración se puede exportar desde la interfaz, pero también se puede hacer por API.

Qué me llevo de la migración

Volver a TrueNAS no significa que el UNAS Pro 8 sea una mala máquina. Significa que para mi caso concreto, ahora mismo, necesito otra cosa.

UniFi me daba simplicidad. TrueNAS me da control:

• Datasets separados.
• ZFS.
• Snapshots.
• Permisos más flexibles.
• Posibilidad de mover la configuración a otro hardware.
• Libertad para montar un NAS DIY si quiero más SATA o más RAM.

Y sobre todo, me permite adaptar el NAS a cómo trabajo ahora: vídeo, backups, datasets separados, pruebas de rendimiento y una futura migración a SSD SATA.

Mi conclusión sería esta: si quieres algo simple y cerrado, UNAS puede tener muchísimo sentido. Si quieres control fino, ZFS y libertad para cambiar hardware, TrueNAS sigue siendo mi sitio cómodo.

Video en Youtube

🚀 ¿Quieres ir un paso más allá? ¡Hazte miembro!

Apoya mi trabajo y accede a ventajas exclusivas uniéndote a mi membresía desde solo 4€/mes con pago anual:

• ✅ Mira vídeos antes de su publicación.
• ✅ Accede a sorteos mensuales.
• ⛔ Grupo privado exclusivo en Telegram.
• 🛍️ Descuentos exclusivos para miembros
• 🤯 Servidor privado de copias de seguridad (Proxmox Backup Server).
• 🗳️ Vota para elegir próximos vídeos y cursos.

🔥 Solo 48€/año (¡34% de descuento vs pago mensual!)

👉 Hazte miembro aquí

— JC