rPman

Единственное достоинство для резервного копирования у ssd - это высокая скорость (если выбирать nvme) доходящяя до 5 гигабайт в секунду чтения и примерно в 8 раз медленнее запись (зависит от технологии, но те что быстрее - на порядок дороже).
Чтобы получить такую же скорость на основе hdd, нужно городить raid0 (без резервирования) минимум из 10 дисков (скорость одного современного диска 150-300мбайт/сек, осторожно с дисками с черепичной записью, у них скорость записи падает в 10 раз по сравнению с чтением).

Они дороже за гигабайт (особенно если выбирать серверные, надежные, с умным контроллером и какими то гарантиями), причем на порядок.

Они могут потерять данные от простого лежания в столе (обесточенные), а если попадут еще и в жару (например забудешь в машине в солнечный день) то скорость потери данных ускоряется до считанных месяцев, вопрос не исследовал но флешки дохнут на ура (внутри они все то же самое, только контроллер тупой). Дорогие, серверные модели, могут содержать контроллер, который при наличии постоянного питания будет следить за сохранностью данных, но я не встречал информации, есть ли такой функционал в дешевых десктопных решениях.

Поэтому, единственное, зачем имеет смысл использовать ssd для резервного копирования - это вынужденная оперативность, когда нужно максимально быстро сделать резервную копию и продолжить работу. И в этом случае ssd можно использовать как временный буфер. И да, почти тот же функционал (возможность получить замороженное состояние данных чтобы была возможность копировать их на медленный носитель) можно получить программным способом, например с помощью снапшотов файловой системы или master-slave репликацией базы данных на слабую машину, с которой уже и снимаешь копию (это нужно если сам процесс резервной копии замедляет работу на столько, что это не приемлемо).

Поэтому не советую покупать для задач резервного копирования ssd только потому что это 'модно молодежно'

утилита WinDirStat покажет куда делось место
p.s. если у тебя миллионы файлов то возможно туда еще сотни мегабайт уйдет, каждый файл будет отнимать, помимо данных, еще на метаинформацию и выравнивание до размера кластера (обычно 4-8кб)

ты отключи сначала mdadm, он же монопольно держит диск и не отдает (но тогда должны были бы быть ошибки!)
cat /proc/mdstat
выдаст что то типа

Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid1 sdb2[1] sda2[0]
136448 blocks [2/2] [UU]

md2 : active raid1 sdb3[1] sda3[0]
129596288 blocks [2/2] [UU]

md3 : active raid5 sdl1[9] sdk1[8] sdj1[7] sdi1[6] sdh1[5] sdg1[4] sdf1[3] sde1[2] sdd1[1] sdc1[0]
1318680576 blocks level 5, 1024k chunk, algorithm 2 [10/10] [UUUUUUUUUU]

md0 : active raid1 sdb1[1] sda1[0]
16787776 blocks [2/2] [UU]

unused devices:

определяешь какой из массивов из твоихдисков попытался построиться (но не смог скорее всего) и делаешь ему stop
mdadm --stop /dev/md1

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

Собственно все необходимые вопросы, на которые нужно обратить внимание, вы указали в вопросе, гуглить по каждому но в большинстве своем все ответы можно сформулировать самостоятельно, просто подумав и включив логику.

1. Случайный и многопоточный доступ - принципиальная необходимость задумываться об этом исходит из физической особенности накопителей, последовательный доступ от случайного (имеется в виду как у hdd так и у ssd (в меньшей степени, зависит от размера читаемого блока кластера, потребительскиее ssd это 256кб) значительно отличаются (на порядок или даже два) по времени. Аппаратные контроллеры на материнской плате и даже на диске (или драйвера и планировщик ос) могут физически считывать данных больше чем потребуется (read ahead), делая это фоном, после запроса и сохраняя в своей памяти.
Если несколько приложений одновременно потребуют данные с разных областей устройства хранения, специальный планировщик ос может приостанавливать работу этих приложений, собирая как можно больше запросов на данные, сортируя их для оптимальной их обработки. Пользовательское приложение может делать это значительно эффективнее, если заранее озаботится о том, как именно данные будут храниться на диске (обычно речь идет о хранении данных минуя файловую систему).

2. Кеширование чтения - в подавляющем большинстве случаев хватает функционала операционной системы, операционные системы используют разные стратегии (fifo или к примеру на основе частоты запросов), системные вызовы ОС позволяют управлять стратегией кеширования, в т.ч. полное ее отключение (это может быть недоступно для некоторых файловых систем, например fuse в linux, если об этом не позаботился их разработчик), с целью перенести логику выбора кеширования данных в приложение.

3. Кеширование (буферизирование) записи - приложение может управлять, стоит ли ждать окончания физической записи данных на диск или это можно сделать фоном или даже отложить на потом. Например fflush позволяет принудительно сбросить буфера при использовании fwrite (и других от stdlib), более низкоуровневые вызовы позволяют точнее управлять процессом. Помимо инструментов управления кешированием на уровне приложения есть способы настроить это на уровне ОС (например ext4 позволяет настроить стратегию записи data=writeback, это делает файловую систему уязвимой к сбоям но значительно ускоряет запись, так как даже fflush из приложения не будет ждать окончательной записи), так же разные сетевые файловые системы могут накладывать дополнительные ограничения (точно помню что nfs обрабатывает fwrite по другому в отличии от локальных записей, делая больше лишних действий на диске)

p.s. про mmap, меанизмы ОС (как linux так и windows) позволяет вместо работы с файлом по кусочкам (fopen/fread/fwrite/...) 'замапить' указанный файл или даже раздел/диск на область памяти, при доступе к которой прозрачно будут совершаться чтения и записи на диск. Этот способ работы с файлами зачастую самый производительный (кстати по умолчанию используются на исполняемый файл приложения и .dll/.so) и очень часто еще и удобнее, так как кеширование данных будет произведено средствами ос, и при повторном запуске приложения данные уже будут в памяти (при обычном fopen их пришлось бы считывать в память, т.е. копировать что дает 2x накладные расходы на процессор).

-------------

4. Файловые системы это уровень абстракций ОС, значительно добавляет накладные расходы на работу с данными но за счет удобства (например возможность расширить хранилище без полного копирования данных, просто увеличив размер раздела или добавив новый накопитель, как это позволяют файловые системы - комбаины типа btrfs/zfs), разные файловые системы организуют хранение по разному, что значительно влияет на скорость как записи так и чтения.
Например cow файловые системы (xfs/zfs/btrfs) каждое последующую запись делают последовательно, даже если записываемые чанки/кластеры принадлежат разным файлам, даже если это модификация а не добавление в конец, что благосклонно сказывается на скорость записи но отвратительно фрагментирует размещение файлов на диске (там есть механизмы борьбы с этим), т.е. для хранилище файлов разного размера, считываемых/изменяемых целиком такие файловые системы идеальны, но для баз данных наоборот очень неэффективны (в таких фс можно принудительно отключить cow для определенных файлов). btrfs/zfs за эти накладные расходы (незначительные) дают бонусом функционал быстрых снапшотов (почитай про btrfs snapshot incremental backup) и высокую устойчивость к сбоям.
Еще пример, файловые системы, с целью защитить данные от сбоев, добавили к функционалу понятие журнал, промежуточное место, куда записываются данные (метаданные) до тех пор пока приложение не зафиксирует изменения (закрытие файла или fflush), в нормальных ОС существует возможность разместить этот журнал на отдельном, более быстром, накопителе (например ext3/ext4) или отключить полностью. Это позволяет заметно ускорить запись и не покупать на весь объем данных быстрый и дорогой накопитель.
Было время, когда можно было буквально (кажется у xfs но я могу ошибаться) указать разные накопители для метаданных (информация о том как файл размещен на диске и информация о атрибутах файлов) и самих данных, что тоже в условиях значительного отличия скорости работы емких hdd и быстрых но не емких ssd, сэкономить на построении хранилища.

5. Сжатие данных на лету - некоторые файловые системы позволяют прозрачно для приложений пропускать данные через библиотеку сжатия (в пределах кластера или даже нескольких соседних), например ntfs использует compress, а btrfs позволяет выбирать, например zstd (один из лучших по соотношений скорость/сжатие), было время когда включение сжатия на медленных накопителях давала двух-трех кратное ускорение скорости чтения практически бесплатно (а запись почти не замедлялась но повышалась нагрузка на процессор), на современных же накопителях процессор может не поспевать (но есть дорогие контроллеры с таким функционалом).
Еще есть тип сжатия - sparse files (дырявые файлы), части файла, в которые не производилась запись, физически не занимают место (фактически тратится место только крохотная часть в области метаданных файловой системы), при чтении таких частей будут возвращены нули, так же есть функции по замене ранее записанных частей файла на такие дырки. Такие файлы могут понадобиться, например, когда нужно хранить огромные разряженные матрицы с индексацией по позиции, индекс тут будет использоваться от файловой системы но выигрыш по производительности сомнителен и требует измерений под ваши данные.

p.s. любая сторонняя библиотека, добавляющая еще один уровень абстракции к хранилищу, может дать выигрыш только если стратегия работы с данными совпадает с той, на что заточена эта библиотека. Например реляционные базы данных дают готовый и обширный функционал по индексированию данных, многопользовательских транзакций но за счет больших накладных расходов на их поддержание. Помню был тут вопрос про хранение терабайтов данных числовой ключ -> крохотное значение (несколько байтов хеш), так вот майкрософтовская sql уже с миллионами записей могла до секунды на запись диском шерстить (тысячи iops), когда как самодельный и примитивный велосипед с одноуровневым индексом по хешу от значения мог дать скорость доступа и записи 1к1 iops накопителя (от 1 вызов к диску на запрос чтения и от 2 - на запись).

ntfs умеет символические ссылки, которые можно указать ссылающимися на любой каталог в системе, они выглядят как каталог для обычных приложений (только если приложение специально не проверяет является ли это ссылкой, но те кто проверяют, должны обрабатывать правильно) и соответственно могут читать файлы, считая что они находятся на указанном диске.

Создавая файл в таком каталоге он будет создаваться и использовать свободное место на диске, на котором лежит каталог, на который ссылается символическая ссылка.

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

Так же можно использовать команду mklink, позволит создавать любые символические ссылки

Еще Far Commander по кнопке Alt+F6 умеет создавать символические ссылки (интерфейс как у копирования но будет создан линк, сам определяет, нужен ли symbolic или hard, в пределах одного раздела), позволяет настроить отображение их в списке на панели (цвет например) и корректно обрабатывает показ свободного места внизу панели (если включена в настройках) для текущего каталога (если он ссылается на другой диск)

сделать ровно то что ты написал

разбить диск на несколько разделов (это можно будет сделать во время установки linux, выбрав ручное разбиение диска в самом начале), когда спросят с какого диска загружаться - укажи этот новый диск, тогда для запуска linux будешь выбирать меню загрузки биос и загрузчики не подерутся (майкрософт затирает linux по разным поводам)

в зависимости от того какой способ загрузки в биосе выбран и какая разметка диска (mbr и gpt видны и там и там):
* efi загрузка требует/рекомендует gpt разметка, legacy - mbr
* если выбрана gpt разметка но legacy режим то потребуется 1мб раздел biosboot
* если выбран efi режим, то нужен раздел ~100мб efiboot (отформатировать в обычный fat но с пометкой что он efi)
* если выбран legacy режим загрузки и mbr разметка, то для linux хватит 1 раздела /
(иногда требуется /boot раздел, обывателю это не нужно, это актуально для нетипичных конфигураций файловых систем)

Итого 1-2 раздела для linux и 1 раздел ntfs для windows, который прекрасно виден и в windows и в linux, без каких либо настроек.

Но есть совет, windows начиная с 8.1 версии и по сей день по умолчанию включает hibernate режим и использует его даже когда ты выбираешь обычное выключение компьютера (оно делает logout, закрывая все приложения, и включает гибернацию) - чтобы показывать рекорды моментального включения компьютера. К сожалению в этом режиме файловые системы на флешках и дисках считаются некорректно извлеченными, и в редких случаях работа с таким 'некорректно отключенным' диском из linux (любой другой ОС, тут важен факт гибернации) может привести к повреждению данных

Поэтому рекомендую отключить гибернацию, если важно постоянно переключаться между ОС.

Это очень сложный вопрос и на него нельзя ответить коротко.

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

Безопасность начинается не с выбора кошелька (само собой речь идет о не кастодиальных кошельках, причем желательно opensource, так как иначе доказать это невозможно, остальные даже не рассматриваются так как кошельками не являются, как бы они не назывались)

... она начинается (с постройки вариантов атак и способов защиты) с настройки безопасности окружения, которое даст защиту/контроль над информацией, с которой ты работаешь.

В первую очередь машина.
К оборудованию, на котором у тебя будут храниться деньги и с которого будет вестись управление ими (отправляться транзакции и генерироваться адреса) не должно быть доступа как минимум не надежных людей. Т.е. друзья/подруги, знакомые, любовники и прочее прочее как минимум не должны иметь неконтролируемый доступ. Чтобы установить дешевый кейлогер (который может собрать меньше сотни баксов средний программист-железячник) и подключить его в разрыв usb провода или прямо в клавиатуру, большого времени не надо (а уж просто вставить миниатюрный переходник usb-usb и через него переподключить клавиатуру требуется пара секунд)... а дел натворить такой кейлогер (как опция, с удаленным управлением) может много, от просто записывания всех нажатых кнопок для выявления паролей до ввода команд установки трояна на компьютер (его код можно ввести буквально в блокноте).
Не рекомендую беспроводные клавиатуры и мыши, возможно bluetooth более надежными выглядят но много ли из них позволяют сменить пинкод авторизации?

Во вторую очередь приложения:
Не пользуйся кошельком на рядовой машине, с низкими требованиями к безопасности, на которой ты скачиваешь из интернета случайные приложения/расширения к браузеру, играешь игры с торрентов, запускаешь кряки и прочее прочее.
В дешевом виде - можно загружаться со специально подготовленной флешки/внешнего диска (можно как linux так и windows настроить) где ничего кроме необходимых для работы приложений стоять не должно - браузер, расширения для работы, кошелек и все. Все должно быть установлено из доверенных источников и регулярно обновляться. Кстати стратегия обновлений подразумевает что обновления устанавливаются с небольшим лагом, так как есть практика (именно в криптоэкономике) когда свежевыпущенный релиз кошелька содержит критическую уязвимость, и если не приводивший к кражам но к потерям монет (помню было что то с lightning network).
Это диск не должен использоваться в обычное время, так как вирусы давно умеют заражать сторонние флешки даже с чужие ос через бутсектор и даже efi прошивки (да достаточно параметры загрузки ос заменить)

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

Теперь про кошелек
для bitcoin настоятельно рекомендую electrum, параноики могут остановиться на bitcoin-core, в режиме pruned он занимает считанные несколько гигабайт. А вообще есть неплохой мастер выбора кошелька

Seed фразу для генерации нужно генерировать только случайной (никаких удобно запоминающихся фраз и красивых стишков, все эти вещи контролируются и деньги воруются, читал про это, много людей на этом прогорело). Хранить фразу в нескольких местах одновременно легкодоступных (чтобы в момент большого П, представь например пожар или землятрясение, его можно было восстановить) и непонятных для злоумышленника. Это самый сложный момент для большинства и именно на неверном понимании проблемы люди теряют и будут терять свои деньги в будущем. Я видел людей, которые хранили свою сид фразу в текстовом файле на десктопе, я знаю что люди записывают сид на бумажке и складывают в ящик стола/сейф, к которому имеет кто то доступ кроме них. Записать сид фразу в файл в облачном хранилище без шифрования своим паролем и алгоритмом тоже не рекомендую. Использовать облачные клавиатуры на android устройствах для ввода seed фразы тоже нельзя (был пример когда какой то кошелек это не учел и какой то разработчик, имеющий доступ к дампам гугловской клавиатуры, украл монеты). Помним, что windows логирует все нажатые клавиши и отправляет их на сервер. Помним что если вы пользуетесь проприетарным софтом - это уже повод задуматься, кто еще стоит у вас 'за спиной'. Мало того, если пользуетесь открытым софтом но загружаете готовые бинарники - то ситуация точно такая же, да может с меньшими шансами на получить проблему, но не ненулевая и эта проблема не решаема, с философской точки зрения обнулить шансы невозможно.

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

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

Еще момент про аппаратные кошельки.
Если кошелек для своей работы требует компьютер (для ввода пароля, для контроля транзакции) - то это плацебо.
Для работы такого кошелька нужно рабочее окружение, если оно не надежно то они не защитят от кражи, а если у вас есть надежное окружение вам не нужен кошелек.
Если кошелек имеет экран, отображающий действия в транзакции в понятном виде и позволяющий ее отклонить то он имеет смысл как инструмент повышения надежности окружения (т.е. его можно использовать на не очень надежной машине, если внимательно следить за подтверждаемыми транзакциями)
Если кошелек не имеет возможности сделать резервную копию seed фразы - он сам становится точкой отказа, т.е. вы можете потерять все деньги при его поломке/краже.
Т.е. аппаратный кошелек в простом виде - это больше проблема чем решение, исключение, если это будет что тот типа ноутбука/смартфона, о чем выше я и написал

p.s. сложно? а кто сказал что биткоин это просто? криптовалюты это когда ты и только ты становишься ответственным за свои деньги. тут не получится позвонить в банк и полицию и сказать - меня обокрали, точнее позвонить получится но не больше.
Некоторые считают такие риски достаточным основанием чтобы не лезть в криптоэкономику в принципе

Итак, все будет упираться в деньги!

1. выбор железа
* жесткие диски не надежны!
Вероятность выхода типового десктопного диска за 5 лет где то примерно от 1% до 7%, и наибольший шанс в первый год. Самые дешевые transcend, доступные на рынке, у меня на практике показывают еще большую статистику (из 7 дисков за 6 лет, два заменил по гарантии в течении 1 года, и еще один под вопросом, он сбоил на уровне udma в логах, но проблемы скорее из-за материнки и/или кабелей)

* твердотельные диски не подходят для хранения данных, без электричества ячейки теряют заряд и даже в идеальных условиях уже через годы можно получить проблемы (дешевые флешки за 3 года лежания в ящике померли 3 из 4 разных от 8Gb до 64Gb usb3 из midend, разные производители), у ssd есть механизмы против этого но устройство должно быть онлайн постоянно, и еще вопрос, нужно ли принудительно проводить проверку чтения чтобы контроллер заряд обновил или нет (ответ - нужно, но по другой причине ниже).

* тебе нужен NAS с поддержкой raid (хоть какой то, любой дешевый, задача не ускорить а убрать один из сценариев смерти данных)
чтобы хоть как то обеспечить надежность, нужно ее повышать количественно, самый простой способ - RAID 1 или 5 и 6 (остальные бессмысленны), выбирая устройства РАЗНЫХ производителей или хотя бы разных моделей, чтобы не получить одновременные проблемы от контроллера (были и такие косяки, диски одной модели во всем мире почти разом вышли из строя)

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

2.5. При наличии денег делай третью копию на онлайн сервисах хранения данных
Этот вариант увеличивает стоимость бакапа но добавляет надежности к хранению данных и возможно увеличивает время восстановления данных (отличный пример, твой бакап у родни в соседнем городе но они 'на даче', их сервер выключен и приедут они только 'завтра')

3. софт, выбирай сам, для mac timemachine почему нет
ищи возможность настраивать инкрементальный бакап с возможностью восстановить выбранный бакап во времени, это нереально помогает и даже частично исключит проблему с вирусами-троянами с отложенным запуском (пример ситуации - вирус попадает в бакап для этого после заражения не активируется сразу, но активируется после восстановления)
Регулярность бакапов настраивай как можно чаще, сколько позволяет выбранная технология (некоторые позволяют чуть ли не ежеминутно все делать, но это не mac, там файлы сканируются).
Обязательно настраивай мониторинг здоровья архива. Не игнорируй варнинги и сообщения о проблемах. У меня на руках пример смерти raid5, рейд месяц сообщал вникуда об отвале диска и когда помер второй диск данные развалились (один из трех массивов так и не собрался, ковыряюсь все еще)

4. проверяй работоспособность бакапа!
Без этого вся возня бессмысленная. буквально, делай восстановление хоть на левую машину, всех данных, проверяй глазами их корректность, можно какой-нибудь софт на это натравить, но универсальных ответов нет, все от данных зависит и понятия - верные ли они, у меня был момент когда из бакапа восстанавливался битый файл - картинка, читался без проблем, просто вместо изображения - мусор, я тогда так и не понял что это такое, но полагаю если бы я делал такую проверку ранее, я бы это заметил до того как оригинальные данные были бы удалены.

Файлы! С доступом как статика на веб сервере, при необходимости права разруливать через basic auth (само собой https обязателен), добавляя пароли в url. При БОЛЬШОМ количестве файлов и сложной структуры по их управлению, заводи в базе данных прослойку а имена файлов пусть будут завязаны на идентификаторы из этой базы (или как некоторые делают - хеши от содержимого, как бонус дубликаты отлавливать)

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