То нужно что-то что позволит с ним работать, по нужному протоколу. Например, если это smtp, то это может быть и https://www.drupal.org/project/smtp, и https://www.drupal.org/project/symfony_mailer с smtp транспортом и наверняка ещё есть что-то.

Если не используется внешний почтовый сервер, конечно нужно - чем-то посылать-то всё равно нужно.

Всё что ставится на стороне Drupal, требует чего-то внешнего:

• это может быть и внешний сервис
• почтовый сервер на стороне той же виртуалки
• почтовый сервер на стороне хостера

Модули просто дают разные дополнительные возможности, например, делать атачи, использовать не только php mail(), использовать какие-то не smtp сервисы для отправки и.т.п. Т.е. расширяют возможности взаимодействия с почтой, но не доставляют её клиентам непосредственно.

Так она чаше всего и будет в спаме - этого мало.
Как минимум, надо настроить SFP запись, DKIM, например с помощью opendkim, и PTR соответствующий имени хоста почтовика.

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

Чтобы доставлялось как-то со своего сервера, минимально надо проверить и настроить 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"