К примеру, Вы у себя обнаружили сторонний код, просканировали сайт на вирусы согласно инструкции, файлы восстановили из резервной копии, а базу оставили по причине нужности последних статей. Может ли заражение пойти от базы к файлам, если база заражена, а файлы чистые?

Вообще нет, база же не исполняет скрипты. Но если под заражением базы понимать, что есть второй администратор для управления сайтом, то в таком контексте этот администратор может получить доступ к файлам. Есть ещё такой тип атак, называется SQL инъекция. Что это такое в статье: https://habr.com/ru/articles/725134/

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

Если Вы обнаружили вредоносный код на сайте, сторонний файл или есть подозрение на вирус

1) Воспользуйтесь сервисом https://virusdie.ru/ (1 день бесплатно при регистрации) - сканер помогает найти подозрительные файлы, затем на основании отчетов можно вручную удалить вредоносный код. Данный сканер разрешает просканировать бесплатно только один сайт. Если сайтов несколько, то можно скопировать файлы всех сайтов в корневой каталог основного сайта и выполнить сканирование. Как проверить сайт с помощью Virusdie описано -> тут

2) Панель управления -  "Www-домены" - кнопка "R" (Антивирус)  - проанализирует выделенные файлы с помощью сканера Ai-bolit от Revisium

По завершении сканирования будет отображено уведомление и сформирован отчет, который можно будет просмотреть в разделе "Антивирус" панели управления

3) Панель управления - "Менеджер файлов" - кнопка "+"(Антивирус) ClamAV - просканирует выделенные файлы с помощью сканера ClamAV

4) Дополнительно можно просканировать файлы с помощью антивируса Malware Detect. Для этого обратитесь в Центр поддержки хостинга.

5) Проверяем дату изменения файлов

6) Переходим в "Журнал" панели управления и изучаем логи запросов на эту дату. Как читать журнал, описано -> тут

7) Делаем восстановление из резервной копии на дату до заражения -> инструкция

8) Общие рекомендации по очистке сайта приведены в статье: https://blog.cishost.ru/2013/06/20/vzlom-saytov-na-cms.html 

9) Разбор частых вопросов по защите сайтов: https://blog.cishost.ru/2015/06/24/faq-po-zaschite-saytov.html .

Настроить запрет доступа к каталогам можно как вручную -> на примере ограничения доступа к служебным директориям ModX

Либо можно воспользоваться средствами панели.

Для создания доступа к каталогам по заданным логину и паролю:

1) Переходим в панель управления в меню "Ограничение доступа"

2) Задаем путь до защищаемого каталога

3) Далее задаем параметры пользователей, которым разрешен доступ к каталогу.

-кликаем по строке с заданной директорией и нажимаем кнопку  "Пользователи"

- создаем пользователя, указываем имя и пароль

4) После этого в заданном каталоге в конец файла .htaccess будет добавлен код, разрешающий доступ к данному каталогу только указанному пользователю

5) В каталог /etc/ будет добавлен файл .passwd с заданным именем пользователя и хешированным паролем MD5/SHA1 , а так же файл diraccess, указывающий на защищаемый каталог 

6) Теперь при попытке входа в админку необходимо будет сначала пройти базовую авторизацию.

При указании не верных данных будет возвращен ответ 403: "Forbidden. You don't have permission to access this resource"

Рекомендации по ограничению доступа к каталогам с целью защиты CMS от различного рода атак приведены -> тут