mayton2019

Автор правильно написал в первом посту.
dd if=/dev/urandom > /dev/sda3
Запись рандомного шума лучше чем любые фильмы. И быстрее.
Можно добавить через точку с запятой последовательность диск-дубликаций для всех дисков в системе.

dd if=/dev/urandom > /dev/sda1 ; dd if=/dev/urandom > /dev/sda2 ; dd if=/dev/urandom > /dev/sda3

Выбросит или нет из ssh уже не имеет значения. 3 команды пошли в исполнение.

Очень хочется посмотреть на разработчика который занимался компилляцией bash-scripts. Скрипты вообще создавались не для перформанса а просто для организации пакетного исполнения экзешников в определённом порядке или для инсталляции и развёртывания ПО.

Это очень коварный вопрос. Само по себе бэкапирование - это безсмысленная операция если нет четкого сценария ЧТО мы бекапим и КАК мы это дело будем поднимать. Ведь бэкап это тупо набор файлов. Образов или логических копий файлов. Поэтому успех этого мероприятия будет зависеть не от того берем мы rsync или tar или еще бох знает что. А от того какая конфигурация дисков на резервной железке. Какие ендпоинты надо поднять. И надо-ли вообще бэкапить всё? Для серверов приложений например на базе Tomcat/JBoss вам достаточно забэкапить только каталог приложений и настройки и возможно OS environment. Для баз данных там еще все запутаннее. По Oracle RMAN написана книжка размером с пятикнижие Моисея. Вобщем совет автору не бэкапить а провести сценарий полной инсталляции продукта в новое место. Оттуда и появится инструкция по техологии плановых бэкапов только нужный вещей.

Такая конфигурация не имеет право называться базой данных. Присоединяюсь ко всем ораторам. Просто добавлю что портативное устройство должно писать логи операций. Чтобы выполнять разбор полетов и фиксировать что делалось. Можно с ротацией. А база данных должна лежать отдельно. На надежных удаленных серверах.

MySQL - это не совсем DBMS. Это сборный лего-конструктор в котором каждая таблица в отдельности сама определяет свой уровень отказоустойчивости (т.н. engine). Поэтому обсуждать надёжность MySQL нет смысла без обсуждения того как была создана каждая таблица. In general - про надёжность сказать ничего невозможно.

Откуда взялось это техническое задание? Это очень напоминает механику хеширования файлов. Как делают браузеры при сохранении статического контента. Не сложно сделать баш-циклы. Но гораздо полезно понять почему автор этого хочет. Что будет если файлов станет 10001 ? Как именовать каталоги?

ext4 не поддерживает объединение в логические тома. Если-бы при устанвке был использовал LVM (хотя это боян еще тот) или файловые системы такие как BtrFs, Zfs тогда эту операцию можно было-бы провести. Конечно обязательно проконсультиоровавшись с знакомым сисадмином. Тут основная беда в том что это опасные операции и необратимые. Любая ошибка - и ваши данные потеряны причем на многих разделах сразу.

А так... подключите /dev/sda4 просто как папку например /video и используйте.

Судя по профайлу автор - виндузятник причем ему требуются чисто виндозные целевые инструменты разработки такие как C#/Visual Studio. Ничего подобного в линуксе нет и не предвидится. (Любители моно сейчас сидят тихо).

Поэтому переходить ему никуда не надо. Следует оставаться на винде. Ну а если сильно припекло - изучать Linux на виртуалках или прикупить дешевое железо. Благо существуют спец-редакции линуксов которым достаточно слабых машин с 2-4 гигабайтами памяти. Это правда.

Посмотрите black-list Emule. Там может быть эта информация.
emule-security.org

Нет особого смысла изучать графические возможности Linux удаленно. Весь цимес и вся сила Linux заключена в том что конфигурации можно делать через консоль термиала. А это - черный экран и мигающий курсор. А сетевые возможности Linux сильны в интеграции. Роутеры. Файрволы. Серваки веба и файловые сервера. Локально - там нечем заняться.