Этот формат не поддерживает ни один из браузеров, и показать без конвертации его, в любом случае, не получится. Мало того, ни GD, ни imagemagick этот формат тоже не поддерживают, так что даже конвертация на стороне сервера будет проблемой.

Чтобы показать это как картинку на сайте, её надо конвертировать во что-нибудь более удобоваримое перед загрузкой. Либо написать свой аналог imagefield, который будет это делать на стороне сервера.

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

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

Если ядер более одного и с дисковой подсистемной всё ок, то нагрузка на виртуалку будет больше, а время которое она продлится, если нет блокировок при импорте меньше. Часто, такие операции параллелятся довольно неплохо.

Если хочется визуально поработать с базой, то лучше не ставить phpmyadmin или другие подобные штуки, а поставить себе heidisql или mysql workbench, или использовать средства ide, и работать с mysql через ssh туннель.

Ну а импорт/экспорт данных лучше производить локально на сервере, и проще всего с mysql/mysqldump.

Вам нужен кто-то, кто сможет нормально диагностировать проблему, имея доступ к серверу.
Методом вопрос-ответ это всё сделать будет очень сложно и долго.

К тому же, проблема не на стороне Drupal.

Это свой сервер, или какой-то хостинг?

Если сервер, жив-ли накопитель на котором лежит база? Что в его smart? Что в dmesg, нет-ли сообщений об ошибках чтения/записи?
Также, вполне вероятно, что надо было заново вообще пересоздать структуру данных mysql, а не просто восстанавливаться из бекапа.

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

Не совсем. Здесь подключение есть, а таблицы нет. Когда нет подключения будет другое сообщение.
Может с префиксом что-то напутано или действительно нет таблицы.

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

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

Безопасность это не какие-то настройки, это постоянная работа.

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

Дополнительно:
Возможно, имеет смысл использовать перед сайтом какой-нибудь Cloudflare c настроенным WAF(там есть профиль для drupal) или поднять и настроить WAF на сервере.

Если вам надо локально разворачивать и запускать drupal, у вас поднят каким-то образом веб сервер на вашем компе, то локально.

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

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

Тем не менее, работать будет и с 7.0.

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

Кто же знает, как именно вам удалось скомпоновать два конфига. Что именно у вас получилось?

Не хватает конфига nginx для drupal.
Правильное применение вышеупомянутого официального конфига вполне будет работать и тут. Если у вас не работает, то что-то не так делается.

Зачем переключаться в такой режим, если нет знаний в настройке nginx?
Nginx + Apache mpm-itk + mod_php, который по умолчанию в панели вполне нормальный вариант. С этой связкой будет заметно проще. И если у вас такие вопросы возникают, стоит её и придерживаться.

Если он такой же, то это тоже не то - в нём должен быть редирект, или в https://www. должен быть редирект. Т.е. должен быть один рабочий конфиг с обработчиками и две "заглушки" с редиректами.

А чем именно он правильнее?

Смысла редиректить отдельно на https://jura12.ru и на https://www.jura12.ru просто нет.
Первый вариант редиректа был вполне верным, просто он ни коим образом не решал проблемы с отсутствием сертификата для домена... Редиректы вообще не могут помочь с этим.

Ну тут не нагрузка, а повреждение хранилища, всё равно. Вообще, довольно странно, что удалось этого добиться ddos.
При недостатке памяти, обычно оно не рушится всё же.

Правильный выход перегенерировать сертификат. Т.к. редирект не поможет, если вход будет на https://jura12.ru/.

Как-то так.
Лучше ещё посмотреть и поменять по необходимости настройки pm(тип, количество процессов).
Также тут иногда имеет смысл включить catch_workers_output, и изменить локальные настройки php, типа open_basedir, upload_tmp_dir, sendmail_path и.т.п.

Каков механизм её появления при нагрузке?

Вам надо потратить время и изучить основы того, что предоставляет из себя Drupal. Как в целом строится приложение, какие есть инструменты, основные модули, какие предоставлены api, как выполняется темизация.

Без этого слепо тыкаться будет крайне не эффективно.
Я бы начал с https://www.drupal.org/docs/develop

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

Flag это не о рейтинге.

Вообще, там всё довольно-таки просто. Не за чем пугать зря.

https://www.drupal.org/project/votingapi они используют.
Во views можно работать с этими данными.
Есть функции их агрегации и без views.

Вторая ошибка, может быть из-за серьёзных проблем с mysql, если сломано что-то в структуре его данных, например, если что-то с хранилищем, или кончалось место. Или права не те на файлы.

Тут надо смотреть в лог mysql.

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

А после чего это началось?

Обычно, это совершенно не мешает получить доступ к файлам сайта. Если в данном случае это не так, с такого "хостинга" надо бежать.