Вопрос: «Как организовать условно надёжное хранение информации на двух полудохлых НЖМД?»

Имеются два полудохлых SATA НЖМД Seagate 1TB (у одного, согласно SMART, Reallocated Sectors Count равно Pre-fail; а у второго уже Fail). Поскольку они всё-таки не до конца дохлые, а полу, хочется их задействовать в домашнем сервере на Ubuntu 16.04.2 и добиться максимально возможной надёжности. Предположим как максиму: диски будут использоваться для хранения важной информации. Причём, важная информация будет двух видов: много мелких файлов (скажем, фотки по 10MB) и большие файлы (например, образы дисков с других компьютеров — 30-200GB). Есть ли приемлемое решение у данной задачи?

У меня знаний по этой теме ноль, поэтому мысль останавливается где-то на «забацать софтовый RAID 1, сверху накатить ZFS и использовать important»... Что же получится в итоге, неясно, ибо ни первого, ни второго я никогда ещё не делал :) Причём, если решение будет найдено, к нему в обязательное дополнение, как я понимаю, нужен ещё мониторинг как минимум динамики того же параметра SMART Reallocated Sectors Count.

Спасибо за ваше внимание и время!

[РЕШЕНО] Для обеспечения максимально возможной сохранности данных на двух полудохлых НЖМД нужно использовать ZFS в режиме «зеркала» и выставить количество хранимых копий каждого файла в 2 (можно 3). Использовать такое решение с осторожностью, чётко понимая, что применённые меры всё равно НИЧЕГО НЕ ГАРАНТИРУЮТ.

Подробнее тут.

Здравствуйте.

[ 1. ДАНО ]
Домашняя ЛВС.
Сервер - Ubuntu Server 16.04.1 и Samba 4.3.11.
Клиенты - Win7Pro (учётка amok — в Самбе/Убунте есть), WinXP (учётка XPMUser — в Самбе/Убунте отсутствует).

[ 2. ЗАДАЧА ]
Сделать общедоступную шару для win-клиентов с полным беспределом: все могут всё (создавать файлы и каталоги любого уровня вложенности, удалять всё, запускать *.exe).

[ 3. ЧТО СДЕЛАНО ]
Создал каталог /usr/local/samba_shara, сменил пользователя/группу на nobody/nogroup и выставил ему права 0777.

Частично smb.conf

[global]
server role = standalone server
security = user
workgroup = WORKGROUP
guest account = nobody
map to guest = bad user

[shara]
path = /usr/local/samba_shara
browseable = yes
writable = yes
guest ok = yes
force user = nobody
force group = nogroup
force create mode = 0777
force directory mode = 0777

Провожу эксперимент:

1. Создаю с win-клиента известной Самбе учёткой amok в шаре новый файл и каталог
2. Копирую с win-клиента известной Самбе учёткой amok в шару существующий файл и каталог
3. Создаю с другого win-клиента не известной Самбе учёткой XPMUser в шаре новый файл и каталог
4. Копирую с другого win-клиента не известной Самбе учёткой XPMUser в шару существующий файл и каталог

Результат ниже:

$ ls -l --group-directories-first /usr/local/samba_shara/

drwxrwxr-x 2 nobody nogroup 4096 Feb  8 00:40 copied by amok
drwxrwxrwx 2 nobody nogroup 4096 Feb  9 00:17 copied by XPMUser
drwxrwxr-x 2 nobody nogroup 4096 Feb  9 00:15 created by amok
drwxrwxrwx 2 nobody nogroup 4096 Feb  9 00:17 created by XPMUser
-rwxrwxr-x 1 nobody nogroup    0 Feb  8 00:39 copied by amok.txt
-rwxrwxrwx 1 nobody nogroup    0 Feb  8 00:53 copied by XPMUser.txt
-rwxrwxrwx 1 nobody nogroup    0 Feb  9 00:05 created by amok.txt
-rwxrwxrwx 1 nobody nogroup    0 Feb  9 00:17 created by XPMUser.txt

Как видно, в требуемые 0777 попадают не все файлы/каталоги! Более того, для каталогов с точки зрения итоговых прав доступа есть разница кто их создаёт/копирует — amok или XPMUser! Но и это не всё — Самба ещё умудряется различать скопированный и созданный именно amok'ом файлы.

При создании amok'ом нового файла в шаре из лога /var/log/samba/log.MACHINE удалось выудить это:

$ tail -f /var/log/samba/log.fat | grep "Новый"

...
unix_mode(Новый текстовый документ.txt) returning 0777
nobody opened file Новый текстовый документ.txt read=Yes write=Yes (numopen=2)
set_file_oplock: granted oplock on file Новый текстовый документ.txt, 802:6600f6:0/2176840990, tv_sec = 589b87fe, tv_usec = 41953
...

При создании amok'ом нового каталога в шаре из лога /var/log/samba/log.MACHINE удалось выудить это:

$ tail -f /var/log/samba/log.fat | grep "Новая папка"

...
unix_mode(Новая папка) returning 0777
open_file_ntcreate: FILE_OPEN requested for file Новая папка and file doesn't exist.
unix_convert called on file "Новая папка"
unix_convert begin: name = Новая папка, dirpath = , start = Новая папка
New file Новая папка
Новая папка reduced to /usr/local/samba_shara/Новая папка
open_directory: opening directory Новая папка, access_mask = 0x17019b, share_access = 0x0 create_options = 0x1, create_disposition = 0x2, file_attributes = 0x10
unix_mode(Новая папка) returning 0777
...

[ 4. ПРОБЛЕМА/ВОПРОСЫ ]

1. Почему несмотря на заданную опцию force user права доступа вновь создаваемых файлов/каталогов зависят от того, из-под какой именно win-учётки их создают?
2. Каков алгоритм формирования итоговых прав вновь создаваемых в шаре Самбы файлов/каталогов (где задаются и от чего зависят изначальные права; количество и порядок наложения масок самой Самбы на эти права; участвует ли тут файловая система Убунты со своим umask, если да, то на каком этапе; участвует ли клиентская Windows)? Почему при заданных опциях «force create mode = 0777» и «force directory mode = 0777» итоговые права отличны от 0777?
3. Где найти свежий/нормальный/с_примерами список-описание опций smb.conf (ru/eng)? Этот видел.

Помогите, пожалуйста, решить данную, как мне сначала казалось — простейшую, задачу. Без нормальной теоретической подготовки я могу ещё долго безрезультатно проводить натурные эксперименты и заниматься хернёй высчитывая от балды побитово права и umask'и :(

Спасибо!

P. S. Был удивлён, что log level = 10 Самбы стабильно «вешает» tail -f :)