Это начиналось как эксперимент, но показало определенную практическую полезность.
Старый регистратор, переделанный в сетевое хранилище, вот уже год бесперебойно обеспечивает хранение данных.

Всё бы хорошо, вот только диск в нем внутри - единственный, а USB-порты, чтобы подключить больше дисков - медленные.
Кто еще ни разу не слышал, как в один прекрасный день диск вдруг делает "цок-цок-цок" - и больше диска нет? И когда это произойдет - не предскажет никакой SMART: может, никогда, а может - через пару минут.

Во взрослых системах для этого существуют RAID-массивы, с корзинами дисков, гудением вентиляторов и прочими сопутствующими радостями.
Для SOHO тоже придумали такие ящики, со встроенной корзиной - и непременными вентиляторами. Куда ж без вентиляторов?

Захотелось сделать почти такое же, но маленькое и бесшумное.

За основу взят традиционно TV-бокс. Установку Armbian сейчас пропустим, она сводится к подбору подходящего образа, записи его на SD и установку с этого SD.

Интерфейсов для подключения дисков у него, конечно же, нет, если не считать USB.
Два порта, один ohci/ehci, второй dwc2/dwc3, заявленные скорости 12, 480 и 5000 Мбит/сек.
Но это "сколько поддерживает процессор", в реальности разьемы USB там обычные, USB2 с 4 контактами, то есть максимум 480Мбит.

Подопытные - парочка внешних USB-дисков по 1Т, плюс обычные "ноутбучные" SATA SSD и HDD с USB-шлейфами.
Подключаться всё это будет через USB-хаб с поддержкой USB3.
Справедливости ради - USB3 там только один порт из 7, зато остальные честно работают как USB2, на 480Mбит. Более простой хаб "из Фикспрайса" отказался работать больше чем на 12Мбит, а этого маловато для дисков.

Также понадобился внешний блок питания на 5 В, с не очень стандартным тонким разьемом - для питания хаба (вообще инересно, многие хабы продаются с таким разьемом, но колхозить под него штеккер пришлось самому, подходящих готовых блоков просто нет. Ну хоть разьемы продаются.)

Подключаем к хабу диски, внешнее питание, включаем, смотрим: 

lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            |__ Port 2: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 480M
        |__ Port 4: Dev 6, If 0, Class=Mass Storage, Driver=uas, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M

Как видно, всё заработало на 480Мбит, причем там "хаб внутри хаба" - два разьема (3, 4) идут от первого хаба, два других (1, 2) от внутреннего хаба, подключенного к порту 1 первого.
Всё как и полагается - ведь в USB как раз можно включать вот таким образом до 127, если правильно помню, устройств.

Смотрим, что именно определилось: 

lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda            8:0    0 465.8G  0 disk
sdb            8:16   0 223.6G  0 disk
sdc            8:32   0 931.5G  0 disk
sdd            8:48   0 931.5G  0 disk
...

Так и должно быть.
Следующий этап - собрать два по 1Т в RAID-1: на суперскорости я и не рассчитывал, а вот получить зеркалирование было интересно.

Для этого используем стандартный инструмент mdadm:

apt install mdadm

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc /dev/sdd
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Оба диска - одинакового размера, так что заморачиваться с созданием партиций не потребовалось.
Начался процесс синхронизации, который занял примерно сутки. Наблюдать за ним можно было так:

cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md0 : active raid1 sdd[0] sdc[1]
      976596992 blocks super 1.2 [2/1] [_U]
      [>....................]  recovery =  0.2% (2114752/976596992) finish=873.8min speed=18584K/sec
      bitmap: 5/8 pages [20KB], 65536KB chunk

unused devices: <none>

Ну а потом -

mkdir -p /mnt/raid1_1t
mkdir -p /mnt/ssd
mkdir -p /mnt/hdd

mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/raid1_1t
mkfs.ext4 /dev/sda
mount /dev/sda /mnt/hdd
mkfs.ext4 /dev/sdb
mount /dev/sdb /mnt/ssd

ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root  9 Jun 26 14:58 03610334-7ea3-431a-a77d-046400918be9 -> ../../md0
lrwxrwxrwx 1 root root  9 Jun 26 14:58 441e7958-e44a-4114-8da5-62eb27541c17 -> ../../sda
lrwxrwxrwx 1 root root  9 Jun 26 14:58 9a0b5aff-d19e-40bd-9987-c9b84cd2bc66 -> ../../sdb

Чтобы не перемонтиовать каждый раз вручную - внесем их в /etc/fstab:

UUID=9a0b5aff-d19e-40bd-9987-c9b84cd2bc66 /mnt/ssd ext4 noatime,nodiscard,commit=60,errors=remount-ro  0  1
UUID=441e7958-e44a-4114-8da5-62eb27541c17 /mnt/hdd ext4 commit=60,errors=remount-ro  0  1
UUID=03610334-7ea3-431a-a77d-046400918be9 /mnt/raid1_1t ext4  commit=60,errors=remount-ro  0  1

Перегружаемся для чистоты эксперимента - и вот оно: у маленькой бесшумной коробочки теперь есть маленький бесшумный RAID-массив и пара дисков вдобавок.
При желании это всё можно расширить и увеличить - пока хватает портов и дисков.

Теперь следующая задача - как это раздавать.

Традиционный путь, SMB/NFS:

apt install samba

mkdir /mnt/hdd/samba
chmod 777 /mnt/hdd/samba

vim /etc/samba/smb.conf

[public]
   path = /mnt/hdd/samba
   browseable = yes
   writable = yes
   guest ok = yes
   guest only = yes
   create mask = 0666
   directory mask = 0777
   force user = nobody
   force group = nogroup

Перезапускам сервисы:

/etc/init.d/smbd restart
/etc/init.d/nmbd restart

Теперь этот каталог доступен из Windows как \\server-ip\public
Из линукса:

smbclient //server_ip/public -U nobody -N

apt install cifs-utils
mkdir /mnt/win
mount -t cifs //server_ip/public /mnt/win

Установка NFS

apt install nfs-kernel-server

mkdir /mnt/hdd/nfs
chmod 777 /mnt/hdd/nfs

Замаскируем пути, чтобы не светить реальные диски:

mkdir -p /srv/ext
mount -o bind /mnt/hdd/nfs /srv/ext

Внесем в /etc/fstab:

/mnt/hdd/nfs /srv/ext none bind 0 0

Настроим раздачу:

vim /etc/exports 

/srv/ext *(rw,sync,no_subtree_check)

Перезапустим:

/etc/init.d/nfs-kernel-server restart

Теперь на клиентских машинах можно монтировать каталог:

mount -t nfs server-ip:/srv/ext /mnt

И не очень традиционный способ:

Есть еще возможность подключать пр��странство из хранилища как локальные устройства, через ISCSI.

Примерно то же самое, что и подключение дисковых массивов к серверам, только там это делалось через оптоволоконные каналы, а здесь - по сети.

Если общими словами: есть targets, это целевые устройства, которые находятся "где-то там", и есть initiators, инициаторы, которые к ним подключаются и используют.
Targets находятся на сервере, инициаторы - на тех машинах, которые пользуются ресурсами с сервера.

Ключевое отличие от расшареных дисков и каталогов в том, что тут ничего не расшаривается, target подключается куда-то в одно место, его можно переподключить в другое место на другой машине - но либо сюда, либо туда, не одновременно.
И с точки зрения практически всех программ это не отличается от локально подключенного диска. Если какая-то программа "не хочет" работать с сетевым диском - тут она не увидит ничего необычного.

В свою очередь серверу совершенно необязательно знать, как именно инициатор будет работать с полученным target - какая будет файловая система, используется ли шифрование - он ничего не знает об этом.

Для этого установим на сервере target-daemon: 

apt install tgt

Подключать можно вручную, или с помощью конфигов:

1 способ: 

tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2001-01.servername:service_name
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sda

Название цели "iqn.2001-01.servername:service_name" может быть примерно таким, хотя вроде жестких ограничений нет, просто так исторически сложилось, ИМХО.
Имеет смысл указывать какое-то осмысленное имя сервера и сервиса, чтобы потом на клиенте не перепутать, если будет несколько одинаковых сервисов на разных серверах.

Первая строка создает такую цель, вторая - разрешает доступ к ней всем, третья - создает логическое устройство, LUN, которое может быть связано как с реальным устройством, типа /dev/sda, так и с файлом, например /mnt/raid1_1t/disk.img.

В одном target может быть несколько LUN, на одном сервере может быть несколько разных target.
С помощью настроек можно ограничивать доступ к target разным подсетям, для разных инициаторов (различая их по их iqn-именам) с разными паролями - здесь самый простой вариант.
Сделанные настройки сами не сохраняются, после рестарта сервиса их надо делать вручную или скриптом снова.

2 способ: 

tgt-setup-lun -d /dev/sda -n iqn.2001-01.servername

Сразу создает цель iqn.2001-01.servername, и добавляет к ней LUN, связанный с устройством /dev/sda.
Это такой вариант "проще простого". Тоже не сохраняется сам.

3 способ:

Чтобы не вводить каждый раз команды - можно использовать конфиг-файлы.
Пример конфига можно добыть, применив после создания target еще один скрипт: 

tgt-admin --dump

default-driver iscsi

<target iqn.2025-10.test>
  backing-store /mnt/raid1_1t/t1crypt
  backing-store /mnt/raid1_1t/t1norm
</target>

<target iqn.2025-10.san:backup>
  backing-store /mnt/raid1_1t/backup.img
</target>

Вот этот текст можно поместить в файл /etc/tgt/targets.conf, или сохранить в отдельные файлы .conf в /etc/tgt/conf.d
В данном случае, после перезапуска tgt 

/etc/init.d/tgt restart

или при перезагрузке сервера будут созданы 2 target, в первом 2 LUN, во втором 1.
Важный нюанс: LUN в этом случае нумеруются по алфавиту названий, то есть LUN1 будет соответствовать /mnt/raid1_1t/t1crypt, а LUN2 - /mnt/raid1_1t/t1norm, даже если они записаны в другом порядке.
На стороне клиента будут указаны только номера lun - это если важно не перепутать.
Ну и конечно никто не мешает просто создать их отдельными target, с отдельными настройками если надо.

На стороне клиента это настраивается так:
Нужно установить open-iscsi: 

apt install open-iscsi

Теперь надо найти доступные цели, залогиниться, и можно использовать:

iscsiadm -n node discovery -t st -p server_ip
iscsiadm -n node
server_ip:3260,1 iqn.2025-10.test
server_ip:3260,1 iqn.2025-10.san:backup

Логин в конкретный target - указываем -T, логин во все - без указания.

iscsiadm -n node -l -T iqn.2025-10.test
iscsiadm -n node -l

Вылогин обратно "iscsiadm -n node -u" - но это не частая операция.

После логина в системе появляются новые scsi-устройства, /dev/sd*
Чтобы определить, где какое - можно посмотреть так: 

ls -l /dev/disk/by-path/
lrwxrwxrwx 1 root root  9 Oct 22 20:05 server_ip:3260-iscsi-iqn.2025-10.test-lun-1 -> ../../sdc
lrwxrwxrwx 1 root root  9 Oct 22 20:05 server_ip:3260-iscsi-iqn.2025-10.test-lun-2 -> ../../sdd

Вот поэтому и говорил про порядок LUN: 1 - это crypt, 2 - norm. Сервер ничего не знает о содержимом, он просто сортирует LUN по алфавиту.

Если устройства или файлы не были инициализированы раньше - самое время сделать это сейчас, всё как с обычными дисками - от fdisk если надо (необязательно) до luksFormat или сразу mkfs. 

cryptsetup luksFormat /dev/sdc --key-file /etc/secret_keyfile
cryptsetup open /dev/sdc crypto --key-file /etc/seccret_keyfile

mkfs.ext4 /dev/mapper/crypto
mkfs.ext4 /dev/sdd

И затем - смонтировать:

mkdir /mnt/crypt
mkdir /mnt/norm

mount /dev/mapper/crypto /mnt/crypt
mount /dev/sdd /mnt/norm

Ключевой файл тут использован для того, чтобы не вводить пароль вручную - тогда всё можно автоматизировать скриптом: 

#!/bin/sh
#
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; export PATH

f1="/dev/disk/by-path/server_ip:3260-iscsi-iqn.2025-10.test-lun-1"
f2="/dev/disk/by-path/server_ip:3260-iscsi-iqn.2025-10.test-lun-2"

if [ ! -e "$f1" ]; then
        /etc/init.d/iscsid start
        iscsiadm -m node -l
fi

sleep 10

if [ -e "$f1" ]; then
        cryptsetup open "$f1" cryptor --key-file /etc/secret_key
        if [ -e /dev/mapper/cryptor ]; then
                mount /dev/mapper/cryptor /mnt/crypt
        fi
fi

if [ -e "$f2" ]; then
        mount "$f1" /mnt/norm
fi

и запускать его откуда-нибудь из /etc/rc.local

Теперь у нас локально появились диски, которые на самом деле совсем даже не локально.

То же самое можно сделать в Windows: вместо подключения к привычному сетевому диску - использовать ISCSI:

Пуск -> Панель управления -> Администрирование -> iSCSI initiator,
или запустить вручную iscsicpl

Вкладка Target - ввести адрес сервера, выбрать нужный, Connect.
Затем Управление компьтером -> Управление дисками, найти появившийся диск, отформатировать если надо, и присоединить.
Например, таким образом можно присоединить еще один диск в виртуалку, не меняя саму виртуалку.

Что по скорости?

Проверял все три вида подключений, SMB/NFS/ISCSI: для обычной 100-Мбитной сетки разницы нет никакой.
Как только обьем передаваемых данных выходит за пределы локального кеша в несколько мегабайт - скорость устойчиво фиксируется в районе 12 Мбайт/сек.

Вроде бы немного, но если посчитать - для 100-Мбитной сетки это и есть максимум, быстрее не получится.
Конечно, существуют гигабитные сети, вот только ни ноутбук, ни WiFi-роутер, ни компьютер на столе не поддерживают гигабит.
Получается, по-любому упираемся в скорость передачи данных по сети, независимо от скорости работы с дисками, или иными словами, любой, самый навороченный и крутой NAS сервер будет работать ничуть не быстрее, так как клиенты не могут быстрее.

Что по надежности?

Если с SMB/NFS всё более-менее понятно, то ISCSI вызывало сомнения: насколько оно устойчиво в случае каких-то проблем?
Поэтому провел несколько тестов: программа постоянно пишет на диск файлы, перечитывает их и пишет новые, т.е. запись и чтение.

Самое простое - обрыв связи: вытаскиваем сетевой кабель. Запись/чтение зависает, после восстановления связи продолжается.

Чуть сложнее - отправим клиентскую машину в перезагрузку: всё отмонтировалось, перезагрузилось, примонтировалось, ошибок нет.

Еще сложнее - выдергиваем питание из нее. Включаем - всё примонтировалось, заработало.

Перезагружаем "неожиданно" сервер: операции подвисают, после восстановления сервера восстанавливаются.

Самый плохой вариант - выдернуть питание из сервера: диски перестают реагировать, чтение/запись с ошибкой.
Но если размонтировать диски, разлогиниться, залогиниться обратно - снова всё работает.
Один раз появилась ошибка типа "неправильный luks раздел" - cryptsetup предложил запустить что-то типа check, после чего снова всё заработало.

В общем, вроде бы всё довольно неплохо.
1 терабайт архива - это немного, но если докупить еще пару терабайтников - будет уже 3 в RAID5.
Было бы интересно узнать, сколько вообще можно таким образом понаподключать дисков, видимо, пока будет позволять пропускная способность 480 Мбит/с USB-порта.
Да и диски могут быть побольше чем на 1 терабайт...

А главное - тихо, жужжания ноутбучных HDD практически не слышно.