Чёрт - магия как она есть!
А ведь достаточно, просто понимать, как работает, и настраивается веб сервер.

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

А этот модуль так, для сайта с мелкой базой, в не ответственных случаях сойдёт - не более того.

Буст сохраняет на диск полностью готовые html файлы, и вообще при GET запросах, не вызывает никакого бутстрапа Drupal. Даже до обработчика php дело не доходит, не то что до drupal. Это огромная разница.

Большинство "багов" из-за желания иметь серебряную пулю, попытки использовать где ни попадя в надежде что он "сделает хорошо", и непонимания принципов его работы.

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

Может reverse-proxy ваш и отрезает, например? Или вообще статику отдаёт, в итоге,не апач?

Вы ничего так и не написали о вашей конфигурации, и никто вам не сможет с имеющейся информацией помочь.

Не стоит бред писать.
Буст это прекрасный способ для не часто обновляемого сайта с анонимными посетителями на порядки понизить нагрузку и на много повысить скорость отдачи страниц. Альтернатив этому походу, в таких условиях, фактически нет - это самое быстрое решение, и самое правильное.

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

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

А вот, если надо изменить поведение стороннего модуля, который так не умеет, то да, можно пользоваться ultimate_cron, например. И, заодно, сделать feature request автору модуля чтобы настройка была реализована, раз такая необходимость, всё же возникает.

Поисковикам, иногда, приходится принимать не очень удобные для владельцев сайтов меры, которые бывают с виду странными, но обычно являются каким-либо компромиссом, и оправданы технически. Например, для поисковика https://domain.tld и http://domain.tld это просто два совершенно разных ресурса, и не случайно - так может быть не только в воображении создателей поисковика, но и в реальности. И им приходится учитывать, не самый частый случай, а наиболее общий. Отсюда и эти сложности со склейкой "зеркал".

В очередной раз замечу, что это не правильная постановка вопроса в принципе.
Не надо пытаться упростить себе жизнь, и изучать несколько модулей, которые вам посоветуют. Надо разобраться как работает Drupal в целом.
Найти, с помощью какого модуля решить ту, или иную проблему, чаще всего, очень простая задача как раз.

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

После отключения и удаления модулей в админке, можно удалять и папки. "Удаление" в управлении модулями, это не удаление файлов, а удаление данных модуля из БД.
В прошлый раз вы не сделали этих двух шагов.

Дополню, этот фиксер совсем отстой - он ещё и не очень свежий drush ломает напрочь.
+1 за нормальный uninstall.

Хорошая идея, это структурированный курс, где начиная с некоторых основ даётся упорядоченный материал. Это может быть, и онлайн курс, и книга, и очный курс.
А в блогах и на ютубе, чаще всего, можно нахвататься "по верхам". Собственно, такой подход больше подходит для повышения уже имеющийся квалификации, и лучшего понимания каких-то тонкостей и проблем...

Обучение на основе блогов или видео, часто, очень плохая идея. Это отдельные кейсы, и на их основе очень сложно построить общую картину.

А запрос точно уходит уже на новый сервер?

Т.е. проблема была в том, что яндекс не принимал почту, с не правильно указанным отправителем (не соответствующим почтовому аккаунту).

Exim, конечно, вам не нужен, при этом способе доставки почты.

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

Какое отношение данный ответ имеет к разным robots.txt для разных сайтов в мультисайтинге?

Можно сделать редиректами в конфиге вашего веб сервера, чтобы брался не из корня а из sites/sitename.tld/robots.txt
Можно использовать https://www.drupal.org/project/robotstxt

Если это jpeg, то есть глобальный параметр качества в настройках.
А вообще, есть очень полезный модуль: https://www.drupal.org/project/imageapi_optimize

А попробовать переключиться на imagemagick? Он в целом качественнее обрабатывает изображения.

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

Вот в том-то и проблема, что от разработчиков.
И к сожалению, при этом, абсолютное большинство PHP разработчиков не знают и свой-то стек толком, не то, чтобы тонкости настройки системы в целом.

Вам не кажется, что просто не надо было это публиковать, особенно как "инструкцию", а не вопросы по настройке?

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

Докер поставит полноценную операционку в виртуалке, и себя в неё, если мы говорим о win (даже на 10, просто это будет виртуалка на hyper-v и не придётся ставить virtualbox) или mac. А вот в ней уже будут контейнеры.