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

Мой типовой план резервного копирования: 7 ежедневных, 4 еженедельных, 3 ежемесячных точек восстановления. Хранится инкрементально.
Делается, конечно автоматически. Регулярно проверяется целостность.

Хранятся на специальном сервере, или в различных хранилищах, в зависимости от пожеланий клиентов.

До того, как разбираться собственно с командами git, и пытаться методом тыка что-то сделать, неплохо бы понимать концептуально, как вообще строится процесс работы. Как вариант, почитать книжку по ссылке @Selpi.

Видимо, как-то слишком по диагонали, раз возникают такие вопросы и удивления.

В 99.9(9)% случаев, в вашем коде поверх Drupal, нет ничего уникального, каким бы ни был крупным проект. Мало того, часто, этот код в виде модулей, например, выгодно отдать в сообщество, т.к. его будут помогать тестировать и развивать.

А вообще, код это не сервис... Если ваш сервис держится только на закрытом коде, то он и так очень уязвим, на чём бы он не был сделан.

Ну тут поможет
TRUNCATE cache_form;

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

А по UA можно, и библиотеки есть, но надо их регулярно обновлять.

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

Звёздочка в конце просто лишняя в принципе.
Сами исчезнут, если не будет ссылок, или каким-то образом в сайтмап не попадут. То, что они 200 не важно. Ссылки на этой странице стоит сделать неактивными, кстати да.

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

Страницы такого вида и будут открываться, вне зависимости от содержимого robots.txt и отсутствия ссылок, но вот индексироваться они уже не будут, а именно этого и нужно было добиться.

Сделать так, чтобы при некорректных аргументах отдавалось 404 можно, но зачастую это просто не нужно.

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

Что-то переделывать точно придётся, в первую очередь, тему оформления.
Данные, обычно, получается мигрировать.

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

Это может быть очень широкий диапазон, от переделки темы оформления и автоматической миграции, до полной переделки сайта.

Я же выше написал. Где-то на этих страницах есть относительная ссылка с href='ideacrimea/'. Именно при её индесировании и появляются эти результаты в поисковиках и вашем сканере.

Либо её надо исправить/изменить/убрать, либо если она такая должна быть, то можно воспользоваться исключением этих страниц через disallow в robots.txt.

Что именно править надо смотреть на конкретном сайте. Т.е. это не какая-то общая проблема drupal, это проблема вашего конкретного сайта, и вам не глядя никто не сможет сказать, что именно надо делать, чтобы её исправить и откуда она такая взялась.

Чем мешает? Никаких же страниц не создаётся физически, собственно.

А если нет такой ссылки, то как может попасть сканер ваш или поисковика и найти такую страницу? Они не умеют сами выдумывать url, они ходят по имеющимся ссылкам.
Нет, ссылка точно где-то такая есть, надо просто хорошо поискать и исправить.

Чтобы эти страницы появлялись в сканере и в поисковиках, где-то должна быть не правильно сформированная относительная ссылка вида href='ideacrimea/'.

Собственно, в этом основная проблема, а не в http 200 на таких страницах... Раздел новостей у вас, вероятно, сформирован с помощью views, и дополнительные элементы пути там воспринимаются как параметры, и это нормальное поведение, в общем-то.

Да, также это всё может быть если приложение делает запросы к какому-то внешнему сервису, а он не отвечает или тормозит. Тогда и нагрузки не будет, и всё равно будет та же картина.

А ещё вас могут DoSить.

Узнать порт, на котором к почтовику можно подключиться без шифрования, указать его в настройках smtp, "использовать шифрование" установить "нет".

Если почтовый сервер допускает подключение без ssl/tls, то его и использовать. Не где-то в отдельных процессах, а вообще. Имелось в виду это.

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

Слишком много неопределённости.

Что с этим делать, прежде всего зависит от хостинга. Но чаще всего, это говорит о том, что либо очень малО значение MaxClients, либо, что вероятнее, у вас серьёзная нехватка ресурсов, либо что-то стало очень тормозить запросы.

В общем, запросов приходит больше, чем сервер может обработать.

Это можно заливать ресурсами - взять сервер помощнее. Можно решать оптимизацией приложения - например кешировать всё что возможно, что-то упростить и.т.п.
Иногда, может помочь и правильная настройка серверного ПО.

Как проверяли сертификат почтового сервера?
Если отключать проверку, то может вообще ssl/tls не использовать, что толку-то, и хакать модуль не надо будет хотя бы?

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

Установить её на php 5.3. Даже с 5.4 уже у разного контриба возможны проблемы, хотя ядро работать и будет аж до 5.6.

Да.

Ещё раз. При чём тут апач? Проверять надо сертификат почтового сервера, с которым вы соединяетесь по smtp. Не веб сервера.

Вы точно проверили валидность и не просроченность сертификата именно на почтовом сервере (не сайте)? Там не самоподписанный какой-нибудь сертификат?