С минимальными знаниями внешний сервис. Их много.

Чтобы доставлялось как-то со своего сервера, минимально надо проверить и настроить SPF, DKIM, PTR. А также пробить ip виртуалки по спам листам.

Sendmail такое себе решение, сложное и устаревшее.
Лучше и проще настроить postfix или exim.
Чтобы настроить почтовик надо немало знать, на самом деле о том, как это всё работает, чтобы настроить его для своей задачи. Брать какой-то пошаговый howto довольно бесполезно в любых ситуациях, а в этой и подавно... Даже если будет работать, доставляемость чаще всего будет никакая. Без этих знаний куда разумнее будет использовать готовый внешний сервис.

Аpache + mod_php быстрее чем apache + php-fpm, на самом деле. Apache не ставят не из-за скорости обработки отдельных запросов, а из-за ресурсоёмкости излишней на каждый запрос, даже к статике.

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

Надо было запускать друш с нужной версией php просто.
Как-то так:
/path/to/fresh/php-cli /path/to/drush
Пути конечно могут быть разными, но скорее всего для php что-нибудь вроде /usr/bin/php8.1

drush uli если есть доступ из консоли.

Будет работать только из корня проекта.

Какая-то каша. /vendor/bin/drush это абсолютный путь, он может быть только один и явно странный.
Под каким пользователем ведётся разработка?
Чтобы было удобнее, можно делать отдельных пользователей для отдельных сайтов, например.

Лучше делать как предлагает @yaro, но если хочется через $database->query(), то надо не пытаться запихнуть аргументы прямо в текст запроса, а использовать плейсхолдеры для аргументов, а их передавать в массиве вторым аргументом qurey():

VasyOK wrote: Или мне .bashrc для каждого сайта создавать?

Для каждого пользователя, скорее...

На самом деле, просто не под рутом это надо сделать, а под пользователем, который работает с сайтом, и соответственно не в /root/.bashrc, а в таком же файле в домашней папке этого пользователя.

Боюсь, что для drush arb не добавили нужного аргумента.
Можно не пользоваться drush для архивирования, вообще говоря. Или только дамп им снимать, чтобы не задумываться о пароле к базе, а файлы нужные паковать tar, например.

А что именно делать в вашей конкретной ситуации, зависит от задачи. Например, для резервного копирования, обычно достаточно снять дамп и сохранить /sites/, или даже sites/*/files, если используется система контроля версий для кода, и это лучше делать специализированными инструментами автоматически и регулярно.

Например, easylist.

Либо у пользователя mysql, под которым работает Drupal добавить PROCESS.
Либо запускать drush c ключами:
--extra-dump=--no-tablespaces или --extra=--no-tablespaces в зависимости от версии drush.

Не использовать CDN. Это почти всегда надёжнее, а если не надо всемирного присутствия, то и вовсе использование CDN имеет мало смысла.
Исключение, пожалуй, только трансляция чего-нибудь тяжёлого, типа видео HD. Но и тогда часто бывает дешевле набрать сервера с гигабитными каналами, чем оплачивать трафик CDN.

Вам нужна конфигурация nginx или другого веб сервера, а не php-fpm для внедрения boost.

У вас что-то не так с apache-itk, или с конфигом apache, или пулов php, судя по всему. Потому, что php должен не от www-data запускаться, а от соответствующего пользователя, владельца сайта.

В общем, это не решение проблемы, а борьба с последствиями других проблем.

Надо смотреть в логах, что именно это за ошибка. Может какие-то зависимости надо ставить, например?
В общем, пока тут слишком мало деталей, чтобы что-то советовать...

Ну и вообще, какие именно функции нужны? Чем собственно, будет производиться отправка, и.т.п.
Может вообще не нужно модуля дополнительного?

Что именно и как не заработало?
Какую ошибку, и при какой настройке?

Сайты всегда лучше изолировать друг от друга если есть возможность.

Создать сайт на drupal.
Импортировать данные.
Более подробный ответ на вопрос в таком виде невозможен.

/var/www/www-root/data/

Это точно не так. Надо разбираться, смотреть логи. Что-то перекорёжено вероятно в настройках.

Например: head -n 100 dump.sql | grep "drop table"

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

karmike wrote: Теперь надо перезайти в MySQL как skradmin и можно импортировать базу, заранее закачанную на хостинг:

Нет, не надо. Можно прямо под root импортировать.

Ну и не обязательно всё это делать в интерактивном режиме.

Уточню: Опция "--add-drop-table" входит в --opt (вместе с --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset), и является умолчанием.
Именно поэтому, чаще всего, ничего чистить не приходится.