Начал осваивать новую платформу – WordPress. Простая установка и настройка, относительное компактный код, возможность изменить внешний вид с помощью готовых тем. Но самое главное – это возможность использовать огромное количество плагинов, среди которых есть как бесплатные, так и коммерческие, позволяющие расширить функционал CMS (Content Management System) до невероятных масштабов и удовлетворить потребности большинства пользователей.
Итак, установив сам движок и пару дополнительных плагинов, первое, чем я озаботился – это сохранностью данных, то есть, способами выполнять резервное копирование сайта. Краткое исследование показало, что штатных средств WordPress не имеет. Был вариант с написание скрипта, делающего выгрузку базы с последующей архивацией, но… это был не наш путь. Я начал искать соответствующий плагин и вскоре нашел подходящий – BackUpWordPress. Заявлено все, что нужно – резервное копирование по расписанию, возможность резервирования как отдельно базы данных, так и файлов. Основной функционал бесплатен, за деньги можно купить возможность резервирования в популярные облачные хранилища.
Установка плагина проста и сводится к копированию файлов в папку plugins и активации через консоль управления. Однако, после установки, плагин никак не хотел делать резервных копий – нажатие кнопки “Запустить сейчас” результата не дало, так же, как и по заданному расписанию. В журналах никаких ошибок. После долгих поисков в интернет, общении с техподдержкой, на одном из ресурсов наткнулся на подобную проблему – у человека так же не создавались резервные копии. И он упомянул, что у него были проблемы с разрешением имён. Я полез проверять файл hosts – там был прописан только localhost. Добавил туда мой домен и внутренний IP – и после этого всё заработало.
Таким образом, в моём случае проблема была связана с особенностями организации сервера – он не выставлен в интернет напрямую, а стоит в DMZ с пробросом необходимых портов с внешнего файрвола. Видимо, плагин в процессе работы не мог разрешить имя узла.