Можно ли заставить ЯД (Яндекс Диск) - синхронизировать атрибуты/владельца файлов?

Смысл в облаке чтобы ты заплатил больше, чем если бы поднял это сам.

ядиск 10Тб 21948 руб в год.
-
hdd 8Tb 20000 руб. *2 = 40т.р.
nas 35 т.р.
Итого: 75т.р.
На стоимость ядиска выйдете только через 3.5 лет. и с меньшим на 2Тб объемом. ИМХО тут «заплатил больше» не очень сильно прослеживается.

Вы разные обьемы сравниваете и зачем-то берете готовый NAS за который переплата. Можно например собрать комп на атоме( 5 000 новый блок питания, 1 тысяча рублей материнка с встронным интел атом и 500 рублей за корпус на том же авито, 100 рублей за набор кнопок, и пусть 34 000 за новый 10 тб диск.) Итого 40 тысяч примерно. Как раз отобьется года за 2.

Для бэкапа можно и свой винт купить.

Не можно, а нужно. man 3-2-1

Можно например собрать комп на атоме( 5 000 новый блок питания, 1 тысяча рублей материнка с встронным интел атом и 500 рублей за корпус на том же авито, 100 рублей за набор кнопок, и пусть 34 000 за новый 10 тб диск.)
Итого 40 тысяч примерно.

+ещё 34 т.р. за ещё один диск.
Итого: 80 т.р. примерно.
Получилось дороже того, что я предложил. И вы в своей сборке память забыли.

Зачем еще один диск? Сравниваем одинаковые объёмы, а не рандомные.

Про память забыл, там будет стоить рублей 500.

Зачем еще один диск?

Чтобы был хоть какой-то бэкап. На самом деле, конечно, нужно хотя бы ещё два.

Зачем еще один диск?

Чтобы зеркало. Мы вроде как не про бесполезные данные говорим.

Зачем зеркало для одного пользователя? Для сохранности нужно делать бекапы и хранить их отдельно. В шкафу например. Зеркало тут не поможет

Зачем зеркало для одного пользователя?

Простите, а какая разница сколько пользователей?

Для сохранности нужно делать бекапы и хранить их отдельно.

Зеркало и бэкапы это вообще-то немного разные вещи. А с учетом:

хранить их отдельно. В шкафу например.

Сильно разные вещи.

Разница в том, что для одного пользователя nas с зеркалом городить бессмысленно. Потому что это зеркало обеспечивает бесперебойность работы здесь. А пользователь не может пользоваться этим nas 24 часа в сутки, ему надо спать. Именно бесперебойность работы, а не сохранность данных. Когда этот nas сгорит, то помрут оба диск скорее всего. А вот если бекап будет хранится отдельно, то когда nas помрет, то данные можно будет восстановить.

Зеркало и бэкапы это вообще-то немного разные вещи.

Я про это и говорю.

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

ИМХО тут все проще. Облако это другой девайс который ничего не знает о ваших цифровых или цифросимвольных UID/GID. И одна из функций облака это синхронизация между разными девайсами у которых может не совпадать всё, ни цифровое/цифросимвольное представление UID/GID, ни username/groupname. Поэтому сохранение подобной информации не имеет смысла.

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

Разница в том, что для одного пользователя nas с зеркалом городить бессмысленно.

Это вам пользователь сам рассказал? Или это вы так за него решили?

Потому что это зеркало обеспечивает бесперебойность работы здесь. А пользователь не может пользоваться этим nas 24 часа в сутки, ему надо спать.

Вы под использованием подразумеваете непрерывное чтение/запись? Тогда встречный вопрос: Зачем вам одежда, жильё, бытовая техника и т.д. ? Вы ведь не пользуетесь этим 24 часа в сутки.

Когда этот nas сгорит, то помрут оба диск скорее всего.

Диски не помрут, но с вытаскиванием данных возможно случится проблема, тут надо смотреть по конкретным моделям NAS. Но вероятность выгорания NAS ниже чем смерть харда.

А вот если бекап будет хранится отдельно, то когда nas помрет, то данные можно будет восстановить.

Если вы про эпизодический втыкаемый хард, то шансов умереть у него больше. Из личного опыта, пользователь завел себе эпизодически втыкаемый хард (новый падла!), вот он сдох после пары бэкапов.

Из личного опыта, пользователь завел себе эпизодически втыкаемый хард (новый падла!), вот он сдох после пары бэкапов.

это который hdd c usb коннектором?

В облако можно и через браузер заливать, например.

Точно! Хорошо дополнили.
А ещё, если в облаке всякие плагины с редакторами присутствуют, то можно и новые файлики создать.

Кто-то с винды юзает, там тоже чёрте что с атрибутами

Винду я как раз учел упомянув цифросимвольное :)

Из личного опыта, пользователь завел себе эпизодически втыкаемый хард (новый падла!), вот он сдох после пары бэкапов.

это который hdd c usb коннектором?

Угу, он самый.

Там доп. атрибуты и спец.файлы типа линков хранились в текстовом файле в каждом каталоге.

И вроде полумух также поступал.

Яндекс Диск это разводка для лохов, или для тех кому достаточно 10гб бесплатных и нужно только поделиться с друзяшками. У яндекс вот cloud есть, и там s3 и для него есть geesefs, вот это годно и дешево и быстро. Но конечно я не знаю будет ли работать это с .cryfs и .ecryptfs, в силу специфики конечно на таком хранилище те же докер контейнеры или БД конечно не получится заставить работать (или получится, но с огромными костылями и потенциальными проблемами), но вот хранить и отдавать файлы, оно самое то.

Ну значит «хочется странного», мне от облачного хранилища требуется возможность использования его как локального на КАЖДОМ моём хосте, иначе нафиг мне облако? Я и на пару винтов затарю…

А у тебя uid/gid везде одинаковые?

Диски не помрут

В бюджет не включен сетевой фильтр. Так что тут не так однощначно. Несколько скачков напряжения и все.

Зачем вам одежда, жильё, бытовая техника

То чем я постоянно не пользуюсь у меня и нет. Например машины, сушилки и так далее. Я предлагаю прочитать стартовый пост. ТС инвалид. Думаешь он может себе позволить переплату за зеркало?

ТС инвалид. Думаешь он может себе позволить переплату за зеркало?

Вы потомок Ванги?

То что вы хотите - называется сетевая файловая система (один сервер) или и вовсе распределенная ФС (кластер серверов). И это нифига не Яндекс-диск!
В простейшем случае вам нужен свой NFS или Samba-сервер. А Я-Д использовать по назначению - хранение копии бэкапа (в виде архива, который внутри сохраняет все атрибуты файлов).

Зачем передёргивать? Это тупая хранилка файлов с их именами, о чём и пишу.

Но! Есть лайфхаки. Например надстроить над ЯДом cryfs или ecryptfs, имеющиеся прямо в дистрибутиве Debian. Но! cryfs это жуть... Сдохла на 65Gb сете данных. Не может родить команду #df -h ./, предыдущие разы рожала по 42 секунды.

Тогда как ecryptfs справляется за 0 секунд:

/e# /usr/bin/time df -h ./
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/opt/:ecry         623G          85G  539G           14% /e
0.00user 0.00system 0:00.00elapsed 100%CPU (0avgtext+0avgdata 2504maxresident)k
0inputs+0outputs (0major+112minor)pagefaults 0swaps
root@zer0:/e#

А зачем нужны времена/атрибуты на бекапах, киношках, конфигах, фоточках и музыке?

А случаи разные бывают...
Старые фотики помнится файлы кодировали просто по порядку, и если в .jpeg есть exit то в .AVI не остаётся информации о времени записи видео, максимум если в настройках это в уголке видео... Но как это вытащить наружу? Наапример есть у меня камера: Fujifilm S4500 и ей отснят не один терабайт материала, так вот при заливке видео на ЯД - мы теряем дату создания этих видео!
С чего собственно всё и началось. Конечно видео у меня сортированные типа: 2501 (Снятое в январе 25) но вся видеобаза на ЯД - это мусор, ну или всё переименовывать... С датой/временем в имени.

Сейчас беглый взгляд, были фотики: C740UZ, DMC-FS16, S4500 которые есть в базе и файлы там именуются по порядку!

За 3 тысячи ты покупаешь у яндекса терабайт на 3 года, когда в магазине ты можешь купить за эту же сумму терабайт навсегда.

Это мультиконечные палки... Для «эффективности» я купил 3*4Т, но это 20к, это у ЯДа будет 2Т на 8 лет. Но конечно ещё 2Т сверху.
Один диск - может свалить в любой момент, у меня падало даже зеркало на репликации (Поменял один вышедший из строя, и второй упал во время репликации). Тогда это были 3T Барракуды, мало того и третья, валяющаяся в другом доме (бэкапная) - тоже сдохла...
Вот меня не спасло даже правило 3-2-1. Хотя ньюансов не помню, наверное успел с третьей всё востановить пока она не упала.

даже платный файл не более 50Gb

Погрызи ФС на куски и склеивай их в рейд, заодно синхронизироваться будет быстрее )

Не смеши, надёжность этого - ниже плинтуса, даже если взлетит.

одновременно с ним сможет работать лишь один комп

Ну тут да, фатально. Хотя может можно придумать что-то с drbd.

Ты представляешь то о чём пишешь? drbd это по факту тоже только один винт... И монтировать его может только одна машина...

Ты забыл добавить добавить к этой сумме стоимость инфраструктуры, иначе это бессмысленно сравнивать с облачным сервисом.

Даже без инфраструктуры - этих терабайт надо купить 3, 2 в зеркало и один в бэкап.

Хорошо. Расскажи мне зачем тут может понадобится такая же инфраструктура как у яндекса. Для одного пользователя. А я послушаю.

Рассказываю, ты «в командировке» и тебе понадобился файл...

Я рассчитывал что в облаке сохраняется ВСЁ!

Тут даже не уверен не похерит ли тебе какая-нибудь винда атрибуты на файлах, а ты этого хочешь от довольно тупого облака.

При чём тут «косяки»? Но штатно это должно быть.

Не говоря уже о…
оригинальное время модификации
Это вообще не очень надежная штука, потому что очередной говноархиватор от васяна сбросит время модификации. А уж как любят свои винрары-винзипы пользователи винды.

Опять начинается высасывание из пальца.

Photo/Videos/1110(DMC-FS16)MOV# ls -l
итого 609255
-rw-r--r-- 1 n0mad strong   9437696 фев 12  2024 P1020630.MOV
-rw-r--r-- 1 n0mad strong  13632000 фев 12  2024 P1020640.MOV
-rw-r--r-- 1 n0mad strong  23069184 фев 12  2024 P1020643.MOV
-rw-r--r-- 1 n0mad strong  87032320 фев 12  2024 P1020796.MOV
-rw-r--r-- 1 n0mad strong  40371200 фев 12  2024 P1020967.MOV
-rw-r--r-- 1 n0mad strong  11796992 фев 12  2024 P1020970.MOV
-rw-r--r-- 1 n0mad strong  41157120 фев 12  2024 P1030045.MOV
-rw-r--r-- 1 n0mad strong 106693120 фев 12  2024 P1030050.MOV
-rw-r--r-- 1 n0mad strong    786944 фев 11  2024 P1030051.MOV
-rw-r--r-- 1 n0mad strong  31982080 фев 12  2024 P1030078.MOV
-rw-r--r-- 1 n0mad strong  12583424 фев 12  2024 P1030102.MOV
-rw-r--r-- 1 n0mad strong  19137024 фев 12  2024 P1030132.MOV
-rw-r--r-- 1 n0mad strong 100402688 фев 12  2024 P1030141.MOV
-rw-r--r-- 1 n0mad strong  23856640 фев 12  2024 P1030245.MOV
-rw-r--r-- 1 n0mad strong  15991296 фев 12  2024 P1030288.MOV
-rw-r--r-- 1 n0mad strong  11534848 фев 12  2024 P1030290.MOV
-rw-r--r-- 1 n0mad strong  12321280 фев 12  2024 P1030291.MOV
-rw-r--r-- 1 n0mad strong  63701504 фев 12  2024 P1030309.MOV
-rw-r--r-- 1 n0mad strong  39322112 фев 12  2024 P1030319.MOV
-rw-r--r-- 1 n0mad strong  24118272 фев 12  2024 P1030322.MOV
-rw-r--r-- 1 n0mad strong  11273728 фев 12  2024 P1030338.MOV

# du -sh --app Photo 
1,5T	Photo

Я рассчитывал что в облаке сохраняется ВСЁ!

В чужом облаке бывает, что и теряется ВСЁ! В своем впрочем тоже возможно, но тут ты уже ССЗБ, так что пинков раздавать будешь только себе. :)

Давай не будем про форс-мажоры, для них локальные бэкапы придумали.

Тогда какой смысл в облаке? Если оно даже оригинальное время модификации не может сохранить.

Оно сохраняет данные, а не атрибуты.

Адрибут это тоже данные, ну да ладно, все привыкли или хавать или не хавать то что им дал ЯД.

Лично для меня - облако это внешняя система хранения доступная ВСЕГДА

Смешно пошутили.

Давай не будем про «форс-мажоры». В штатной ситуации ЯД всегда пока отвечал и пока файлы не терял. На форс-мажоры есть бэкапы.

А вот в ситуации с cryfs и ecryptfs - засада. Залил в них 65G данных. cryfs 42 секунды исполняет #df, а на ecryptfs всё замечательно, но этот же сет меня обрадовал 16 строками вида:

rsync: [generator] recv_generator: failed to stat "/e/Pictures/#wordpress/pnz.ho
me.blog/heraldy/png-clipart-the-government-of-the-penza-region-\#320\#223\#320\#
265\#321\#200\#320\#261-\#320\#237\#320\#265\#320\#275\#320\#267\#320\#265\#320\
#275\#321\#201\#320\#272\#320\#276\#320\#271-\#320\#276\#320\#261\#320\#273\#320
\#260\#321\#201\#321\#202\#320\#270-penza-governorate-coat-of-arms-oblast-russia
-food-flower.png": File name too long (36)

Зачем зеркало для одного пользователя? Для сохранности нужно делать бекапы и хранить их отдельно. В шкафу например. Зеркало тут не поможет

Бекапы ф шкафу не помогут... Они эпизодично редкие, а винты легко улетают. Как раз бэкап в шкаф обычно делается когда зеркало развалилось. Перед сборкой нового.

Из личного опыта, пользователь завел себе эпизодически втыкаемый хард (новый падла!), вот он сдох после пары бэкапов.

это который hdd c usb коннектором?

Давай не будем «передёргивать». Внутре одни и те же HDD, можешь разобрать, посмотреть. Лично у меня были 3 по 3Т барракуды, по пресловутому 3-2-1. Одна сдохла, купил 4. Начал реплицировать зеркало и вторая сдохла. Не помню, кажется с третьей успел залить данные прежде чем и она сдохла... В итоге от 4 по 3Т Барракуд - ничего не осталось, а на стареньком Samsung 1T аптайм уже за 9 лет перевалил.

А у тебя uid/gid везде одинаковые?

Именно, завожу на новой домашней системе 7 пользователей в одном и том же порядке, даже если не надо. Ну да ладно, пусть владельцев не держат... Но время/дата/rwx - НАДО!

Бекапы ф шкафу не помогут

Бэкапить не обязательно на жесткий диск. Я бекапил на DVD и на дискеты. Просто выбираешь что важно и бекапишь. И можно это делать регулярно. Важно только чтобы бекап хранился не подключенный к компу.

ТС инвалид. Думаешь он может себе позволить переплату за зеркало?

Вы потомок Ванги?

Оба правы... У всех есть периоды когда они и могут позволить и не могут. Пока не мог - купился на ЯД, а он такую жопу состроил.
Так получилось, что «топой» ушло 4 Барракуды, мать их... Теперь сумел позволить 3 Тошибы, надо слить всё с Яндекса, смириться с потерянными датами/временем на множестве видео и забить на ЯД.

Попытки обойти через cryfs, ecryptfs - пока не увенчались успехом, cryfs тормозит жутко, а на ecryptfs надо вычищать «слошком длинные имена». Хотя время/дату/владельца вроде обе сохраняют.

Бекапы ф шкафу не помогут

Бэкапить не обязательно на жесткий диск. Я бекапил на DVD и на дискеты. Просто выбираешь что важно и бекапишь. И можно это делать регулярно. Важно только чтобы бекап хранился не подключенный к компу.

Не смешите... Сколько DVD надо для 4Т? 1000? Сколько они будут стоить? А потом можно почитать топики о времени жизни болванок...
Это «выбираешь то что важно». То что важно, можно забэкапить и на 3-4 бесплатных облака, по 5Гб.
Как раз суть бэкапа - чтобы было всё используемое окружение. Никто не будет постоянно выбирать то что важно. Сейчас как раз рсинкаю пару десяток рсинков древних хостов, на zfs, с дедупликацией. Хочу посмотреть ка он их дедуплицирует.
Всё никак не дойдут руки - до того чтобы собрать все важные файлы оттуда и удалить.

P.S. В случае с винтами «не подключенный к компу» - черевато. Редко включаемые, переносящиеся винты - дожнут чаще чем постоянно стоящие и работающие.

Сколько DVD надо для 4Т

Зачем вам бекапить полностью 4Т? Вы их полностью забиваете с самого начала? Если так, то у вас скорость чтения уменьшается, причем значительно. Так использовать их неправильно.

топики о времени жизни болванок

Тут недавно мелькали темы о снятии данных с дисков, 2007 года или раньше. Из 40 дисков не читалось около 3-х. В оптических дисках нет движущихся частей, поэтому они живут дольше. Насчет дискет же, у меня есть дискеты 20-летней давности. Читаются без проблем.

Внутре одни и те же HDD, можешь разобрать,

у меня есть какой-то старый 2.5, в таком кейзе. просто валялся. включаю как-то в usb, а он трык-трык, не может запуститься.

думаю сдох. дай думаю смению ему кабель. сменил. и он взял и запустился и рабочий до сих пор.

мораль. внутри диски может и одинаковые. вот только у них еще переходник и кабель имеются.

Например надстроить над ЯДом cryfs или ecryptfs

И чем это поможет для сохранения атрибутов (времени,владельца) файлов? Ну зашифровали вы файл, его атрибуты от этого не изменились. При копировании зашифрованного файла в облако его атрибуты в облако не передаются, точно так, как для незашифрованного! Атрибуты файла хранятся в ФС отдельно от самого файла.
Кроме того, смущает требование не использовать ecryptfs на сетевых дисках напрямую во избежании проблем (только шифрование в локальную копию и затем пересылка этой зашифрованной копии на сетевой диск). Вот цитата из https://wiki.archlinux.org/title/ECryptfs

* Network storage mounts
    eCryptfs has long-standing bugs when used on top of NFS and possibly other networked filesystems, for example, #Mounting may fail on a remote host when connecting via Mosh. It is always possible to use eCryptfs on a local directory and then copy the encrypted files from the local directory to a network host. However, if you want to set up eCryptfs directly on top of an NFS mount, with no local copy of the files, eCryptfs may crash or behave incorrectly.

В чужом облаке бывает, что и теряется ВСЁ! В своем впрочем тоже возможно, но тут ты уже ССЗБ, так что пинков раздавать будешь только себе. :)

Давай не будем про форс-мажоры, для них локальные бэкапы придумали.

Локальные бэкапы могут и не спасти от порчи информации.

Адрибут это тоже данные, ну да ладно, все привыкли или хавать или не хавать то что им дал ЯД.

Речь не про конкретно ЯД, а про облака в целом.

А вот в ситуации с cryfs и ecryptfs - засада. Залил в них 65G данных. cryfs 42 секунды исполняет #df, а на ecryptfs всё замечательно, но этот же сет меня обрадовал 16 строками вида:

rsync: [generator] recv_generator: failed to stat "/e/Pictures/#wordpress/pnz.ho
me.blog/heraldy/png-clipart-the-government-of-the-penza-region-\#320\#223\#320\#
265\#321\#200\#320\#261-\#320\#237\#320\#265\#320\#275\#320\#267\#320\#265\#320\
#275\#321\#201\#320\#272\#320\#276\#320\#271-\#320\#276\#320\#261\#320\#273\#320
\#260\#321\#201\#321\#202\#320\#270-penza-governorate-coat-of-arms-oblast-russia
-food-flower.png": File name too long (36)

Что логично.

Так получилось, что «топой» ушло 4 Барракуды

Одинаковые? И если да, то разом купленные?

Тут не поспорить.

3 по 3Т барракуды, по пресловутому 3-2-1

3-2-1 это не про то что у тебя три диска. Это про то, что у тебя три копии на двух разных типах носителей, плюс копия данных «off-site».

Зачем вам бекапить полностью 4Т? Вы их полностью забиваете с самого начала? Если так, то у вас скорость чтения уменьшается, причем значительно. Так использовать их неправильно.

Я ITшник с начала 90х... У меня так много всякого барахла накопилось и потерялось, что 4Т это катастрофически мало.
У меня до некоторого времени даже были многолетние дампы ФИДОшных эх. Это сейчас есть Гугль и Яндекс, я начинал когда их не было, с винтов в 40Мб.
Вот сейчас, уже не первый месяц, играю в «сокобан». В арсенале штук 15 всяких винтов и SSD, на каждом что то есть... Вот и «двигаю» инфу по винтам так - чтобы найти более важное и разместить так чтобы был минимальный шанс потери.
В идеале надо 3 по 20ТБ :))) - 2 в Зеркало, и один под бэкап зеркала.
Залить на них всё в одну кучу и там уже разбираться/размещать.

Например надстроить над ЯДом cryfs или ecryptfs

И чем это поможет для сохранения атрибутов (времени,владельца) файлов? Ну зашифровали вы файл, его атрибуты от этого не изменились. При копировании зашифрованного файла в облако его атрибуты в облако не передаются, точно так, как для незашифрованного! Атрибуты файла хранятся в ФС отдельно от самого файла.

По сути - атрибуты файла это «секретная информация» - поэтому они должны шифроваться!
В cryfs вообще, шифрованное дерево файлов - это структура - никак не отображающая реальное расположение файлов.
С ecryptfs - Хуже. Там всё приближено к реальному дереву и сейчас проверил - время/дата не пролазят, и атрибуты тоже. Тупо скопировал свой ~bin и на другой машине они стали неисполняемыми.

Кроме того, смущает требование не использовать ecryptfs на сетевых дисках напрямую во избежании проблем (только шифрование в локальную копию и затем пересылка этой зашифрованной копии на сетевой диск). Вот цитата из https://wiki.archlinux.org/title/ECryptfs

Спасибо за цитату, но сами же написали поправку: шифрование локально и пересылка - что собственно и делает yandex-disk
Сейчас проверил, ecryptfs - отпадает, не передаёт она время/дату и атрибуты.

По сути облом, я надеялся что прокатит, но cryfs даёт дикие задержки на сруктуре размером 65Gb, а ecryptfs атрибуты хранит в аттрибутах файлов.

Локальные бэкапы могут и не спасти от порчи информации.

Я же просил без форс-мажоров.
Ненавижу слово «могут».
Вот любой из нас завтра может сдохнуть! И что теперь? Не жить?

Что логично.

ЧТО ЛОГИЧНО?
Это не логика, а рукожопство! Если в ФС этот файл есть, а в шифрованную не пролазит - значит автор шифрованной - РУОЖОП!

Вот в cryfs пролазит, но там медленно... Но это уже «особенности» а не «рукожопство».

Я же просил без форс-мажоров.

Разговор про бэкапы без форс-мажоров не имеет смысла. В защите от них вся суть бэкапов. Ну и в сравнении рисков и затрат на их минимизацию.

Вот любой из нас завтра может сдохнуть! И что теперь? Не жить?

Логика вышла из чата.

Нет, не «не жить», но может иметь смысл делать так, чтобы вероятность сдыхания уменьшить. Именно так эта аналогия с бэкапами имеет смысл. «Не жить» — это не про локальные и нелокальные бэкапы, аналогией будет «не хранить никакие данные вообще».

Одинаковые? И если да, то разом купленные?

Одинаковые, да. Сигейт их долго выпускал.
Я не так крут чтобы 4 барракуды разом в начале 2000 купить.
Купил одну, потом ещё одну в зеркало, потом третью для бэкапа зеркала.
Потом одна навернулась. Купил замену, к несчастью такую же.
Начал реплицировать зеркало. При репликации живая сдохла.
Остался бэкап. С него прочитал, но жизнь стала тяжелая и не смог купить ещё одну для зеркала. Так и жили, основная и бэкап.
В очередной раз - привёз бэкапную (я же держал её даже в другом городе). Вставил - а она дохлая... Вот судьбу 4й Барракуды не помню. Купил Тошибу и перенёс то что осталось «во избежании».
Потом уже начались проблемы с развалом дома (Гугль: Ударная 35) и тогда завёл ЯД, потому как стал БОМЖом в законе и железо валялось «по углам». Но увы, ЯД может работать только как хранилка туподанных, на случай потери всего железа...Ну или хранилка затаренных бэкапов, но тут лучше я куплю 4Т Тошибу и за пару лет она окупится. Конечно преимущество ЯДа в том что бэапы можно сдёрнуть когда хочешь и откуда угодно... С реальныим диском это сложнее.

3 по 3Т барракуды, по пресловутому 3-2-1

3-2-1 это не про то что у тебя три диска. Это про то, что у тебя три копии на двух разных типах носителей, плюс копия данных «off-site».

Спасибо за акцент, но сейчас сложно иметь 2 типа, разве что основу держать на ССД, а копию и резервную держать на HDD. Но SSD 4T это 30+ косарей...

Вторым типом может выступить облачное хранилище