sergpewpew

Я исходя из своих наблюдений и опыта решил отказаться от рейдов на ссд и все виртуализировать.
Как бы сделал лично я:
проц для виртуализации без малых ядер, либо это i5 12400, либо отключать у 12700 4 ядра мелких, хотя как правило при включении hyper-v роли в винсервер это автоматом делается. Либо амд камни рассматривать уже, если нужно 8/16 ядер/потоков.
сата ссд тоже самсунг, нвме самунг - pro, все самсунги перед использованием проверить на оригинальность в фирменном софте и если будет обновление прошивки, также обновить.
ОЗУ естественно 64 гига, не ниже. 2 планки по 32 гига, частота 3200
материнка естественно для всего этого дела нормальная с радиаторами на обоих плечах врм. MSI PRO B760-P DDR4, например она. для 12400 охлада хватит и 4 теплотрубки со 120мм вентилем, для 12700 взять какой-нить ID-COOLING SE-206-XT/DEEPCOOL AG620
Винсервер не ниже 2019 года, с обновами естественно.
На сата ссд один хостовую винсервер с ролью hyper-v.
для сервера 1с+sql сервера выделить прям отдельный нвме ссд (именно выделить, а не положить vhdx контейнер на инициализированный в хостовой системе ссд. Можно в инете найти, как в hyper-v напрямую диски прокидывать, чтобы не терять скорость накопителя.
Бэкапить хостовую ОС можно штатными средствами, ну и виртуалку с 1с+sql на хард.
тут и полные резервные копии вам, и защита от случайных ошибок, ибо на виртуалках можно спокойно контрольные точки создавать и возвращаться на них в случае проблем)
Отдельный бэкап также лучше организовать на другой комп.
Софтовый рейд в винде нормально не даст загрузиться хостовой ОС в efi режиме, если системные диски зеркалить, там целый квест с командами нужно провернуть для этого, чтобы efi загрузчик был и на зеркальном диске.
А при виртуализации зеркалить ссд с sql смысла не вижу ,ибо по сути каждый день будет готовая виртуалка с базой в бэкапе. Даже за несколько дней предыдущих в случае чего. Ибо рейд - это не про сохранность данных, а про минимизацию простоя при выходе накопителя. Вот прозапас купить ссд и просто держать его на полочке имеет смысл)
Также не понятно, как будут клиенты подключаться к серваку с 1с, не через толстый клиент же, это тормознутый прошлый век.
Так что тут либо по старинке отдельной виртуалкой rdp сервер можно развернуть, сервер 1с+sql вообще вывести из общей сети внутренней виртуальной сетевой картой в hyper-v, а rdp сервер будет смотреть как в общую сеть одной сетевой расшаренной картой, так и в сторону sql сервера второй внутренней сетевухой. Канальная скорость внутренней сетевухи 10 Гбит, так что узкой полосы не будет в этом плане.
Если веб сервер, то можно развернуть в принципе на том же sql серваке, чтобы не маяться.

Для данных целей RAID не нужен. Тем более SSD.
Берете NVME ssd и все.
Настраиваете регулярный бэкап базы и лога транзакций.
Имея лог транзакций можно восстановить базу на любой период.

чтобы если 1 вышел из строя данные можно было достать из второго NVME

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

1)Для ваших целей - нет.
2)Нет, он не для этого и в этом смысле полностью бесполезен.
3)В большинстве случаев да, как правило небольшая, но зависит от грамотной настройки.

i7 12700 не лучший выбор.
Смотрите в сторону процессора с максимальной частотой на ядро. Ну и в биосе платы обязательно должна быть возможность отключить энергоэффективные ядра.
По поводу дисков
1. SATA ssd samsung 250g - для установки ОС.
2. NVME samsung 500-1000g для базы SQL
3. NVME samsung 1000g для лога транзакций.
4. HDD 2-4гб для первичного бэкапа (бэкап должен хранится на другом компьютере), но одна копия на этом диске.
Для всех SSD дисков есть смысл оставить 30% неразмеченными.
Самсунги под базу и лог берем обязательно серию про. Чтобы кэш DDR на борту был.
Памяти чем больше тем лучше. Частота памяти не важна.

К примеру торговля на i5-11600k летает. База примерно 80гб. Всего пользователей чуть больше 30, активных как правило в районе 20.

Достаточно открыть ssh доступ (можно сменить порт с дефолтного 22 на что то другое, меньше будут беспокоить сканеры ботов), все остальное (большая часть инструментов) будут работать через него.

scp - штатный от ssh, возможности как у обычного cp, не возобновляет прерванное копирование
rsync - умеет работать через ssh, ключ --partial автоматически дозагрузит прерванное копирование, простой скрипт будет перезапускать процесс копирования пока он не завешится корректно

while ! rsync -avz --partial --progress --inplace --append-verify --rsh=ssh /путь/к/локальному/файлу пользователь@удаленный_хост:/путь/к/удаленному/файлу; do
  echo "Переподключение через 10 секунд..."
  sleep 10
done