ramjke

Пожалуйтесь хостеру сайта-конкурента.
Для этого попингуйте их сайт, потом полученный IP введите в окошко "Search IP address" на сайте https://www.ripe.net/support - это сайт базой данных IP-адресов (расскажет, какой организации (чаще всего, интернет-провайдер, хостер, дата-центр или просто крупной компании) выдан IP).
В результатах поиска будет abuse contact to: - это адрес для жалоб. Скорее всего, по IP-шнику Вы найдете хостера (или сайта, или их прокси серверов - но, скорее, сайта). Напишите жалобу хостеру (обязательно укажите, что Вы являетесь владельцем Вашего сайта и торговой марки или что у Вас там; что Вы уже подали заявление в милицию/написали в Роскомнадзор). Пишите с ящика своего домена/сайта, который упомянту в злосчастной статье. И приложите к письму переписку - мол, клевета и вымогательство денег. Желательно ещё потом пару раз позвонить в техподдержку и узнать, как идут дела по жалобе.
Жалобу действительно можно продублировать обращением в милицию (тогда и номер входящего укажите в жалобе хостеру). С очень большой вероятностью хостер не захочет иметь дело ни с ментами, ни с Вами, и обяжет владельца сайта в течение суток убрать статью.

Вы уверены, что на локальном компьютере у Вас пароль к пользователю тот же, что и был на хостинге?
Ошибки указывают на то, что сайт пытается подключится по неверному паролю к несуществующей базе (русскими словами - пароль, указанный в конфиге, не совпадает с паролем от юзера БД; а также не совпадает названия БД).
Опишите, как Вы переносили сайт. Что у Вас стоит на локальном компьюетере в качестве сервера БД и веб-сервера? Денвер или что-то другое?

Посмотрите, что у Вас висит в кроне
cron -e
Вы говорите, что зависание в одно и то же время - возможно, процесс резервного копирования или ротация логов подвешивает Ваш сервер. Просмотрите в панели управления, на какое время назначено резервное копирование.

DOS? Вам его помогут определить логи запросов /var/log/nginx/access.log или /var/log/apache/access.log - в зависимости от используемого Вами веб-сервера. Если на один IP приходится более десятка запросов в секунду - это точно дос.

Сервер полностью не отвечал? Предьявите /var/log/kern.log и /var/log/syslog, там описаны причины.

Первое, что пришло в голову - Вам нужен отдельный прокси сервер со стабильным подключением в интернет (то есть любая дешёвая VPS). На ней - nginx, перенаправляющий запросы на Ваш домашний сервер. При внештатных ситуациях меняете IP адрес перенаправления в nginx на IP Вашего веб-сервера на резервном канале.
Но, может, проще сразу арендовать VPS под веб-сервер?

Частая причина - неправильные права на папки и файлы.
Проверьте, что у Вас на ВСЕ директории сайта стоят права 755, а на ВСЕ файлы 644.
Сменить права рекурсивно на все вложенные директории может команда
find /home/user -type d -exec chmod 755 {} \;
Рекурсивно на все файлы в вложенных директориях
find /home/user -type f -exec chmod 644 {} \;

У Вас VPS или Вы арендуете общий хостинг?
Если VPS - в конфигурационном файле вебсервера (nginx или apache) укажите новый путь к каталогу.
В случае nginx
/etc/nginx/nginx.conf

location / {
/путь/site.com/folder/;
}
замените на
location / {
/путь/site.com;
}
Если apache

ServerName yourhost.com
DocumentRoot /путь/site.com/folder/

меняете на

ServerName yourhost.com
DocumentRoot /путь/site.com/

Если общий хостинг - просто перенесите ВСЕ файлы сайта в требуемую папку (а лучше - проконсультируйтесь перед этим с техподдержкой).
Если Вы перенесёте только index.php - сайт точно работать не будет.

Упираетесь ли Вы в ресурсы процессора - можно сказать по выводу команды top. Если MySQL съедает более 90% во время выполнения запроса (при условии, что у Вас одно ядро) - точно не хватает производительности процессора.
Посмотрите, не ушли ли Вы в SWAP - возможно, у Вас недостаточно оперативной памяти. Команда free -m или top

Запросы запросу рознь - если у Вас запрос состоит из десятка join, то тут не спасёт даже десяток ядер.
Вообще, 400МГц для веб-сервера - это мало.

Предоставьте информацию по конфигурации сервера и конфигурации MySQL, а также пример запроса. Конфиг MySQL у Вас дефолтный? С включением кеширования ситуация может измениться в лучшую сторону (при условии, что есть для этого достаточно ресурсов).

Можете включить лог медленных запросов - в конфиг mysql добавьте строчки
log-slow-queries=/var/log/slow_queries.log
long_query_time=3

Это не опенкарт выдаёт, а nginx.
У Вас слишком маленький таймаут для рнр.

Пропишите в php.ini следующую строчку
max_execution_time 150;

Если не поможет - поделитесь логом нжинска (каталог по умолчанию /var/log/nginx/error.log