rPman

В биосе тоже ничего не видит.

значит это аппаратная проблема, либо помер ssd либо контроллер на материнке

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

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

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

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

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

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

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

Внутри ssd есть своя как бы файловая система, скорее всего похожая на cow, где каждая следующая запись пишется в новое место, даже если это один и тот же сектор с точки зрения пользователя (это нужно для равномерного распределения записей по ячейкам), значит можно раскрутить этот лог назад, если система не успела исполнить для этих участков trim. Но, к сожалению, записи происходят сразу по всему объему диска (современные чипы памяти это многоуровневые цепочки бит, запись которых происходит циклически, первые биты записываются быстро, последующие биты в цепочках - медленно, когда происходит запись, сначала контроллер пишет данные в каждые первые биты этих цепочек и запускает фоном процесс перераспределения, чтения записанных данных в первые биты и перезапись их в глубь каждой цепочки, это медленнее, как минимум именно так реализуют кеширование записи на дешевых пользовательских накопителях (а может и на всех). Именно поэтому примерно 20% свободного места на диске будут записаны на максимальной скорости а затем скорость упадет в десяток раз именно потому что свободных 'первых бит' не остается и контроллер ждет окончание перераспределения.

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

Если держать ssd в жарком месте (например, например в машине, на солнцепеке) то скорость деградации сильно увеличивается до месяца +-

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

Тебе все ответили по поводу не совсем верной постановки вопроса.

Если речь о хранении на hdd установщиков игр а устанавливать сами игры на ssd то да, это хороший вариант, ssd не выгодно использовать для хранения данных, которые редко используются или используются только для последовательного чтения.

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

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

Если же речь о том, как можно воспользоваться hdd для установки игры на ssd которая на него не влезает (точнее тебе охота больше игр или доустановить компоненты, так как приложение должно хотя бы в минимальном варианте поместиться на диске), то есть способ, воспользоваться фичей файловых систем (ntfs в данном случае умеет только каталоги) - символические ссылки.

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

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

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

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

Постарайся не переносить ресурсные файлы игр (текстуры и модели).

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

NVM_Express - это спецификация, т.е. описание и стандарт, включающий в себя не только описание разъема, условий использования но и протокола в том числе.

Это как говорить что автомобиль это двигатель... или дом - это стены и крыша... оркестр - это дирижер... (chatgpt отличные аналогии приводит)

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

у меня так на очень дешевых комплектующих работала следующая схема linux сервер, специально выделенные медленный hdd + 250гб ssd диск в качестве кеша, полученный ускоренный раздел публикуется с помощью iscsi по гигабитной сети, его монтирует windows машина и на этом диске размещены игрушки (ark будь он неладен 400гб с еженедельными обновлениями по 50-100гб), чуть больше чем за год сожрал 250тб ресурса. Итоговая скорость запуска была примерно в 3 раза быстрее чем если hdd подключить напрямую к windows машине.

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

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 - на запись).