Это надо делать обязательно

Вопросы, связанные с тем, что называется “резервное копирование данных”, часто игнорируются. Или им не придается значения, которое они на самом деле заслуживают. Это происходит в основном с молодыми специалистами. Причем ровно до того момента, как произойдет встреча с порожденными ситуацией проблемами. Эти проблемы связаны с либо (1) потерей важных данных, либо (2) с потерей драгоценного времени на попытки несистемного восстановления данных. Автор этого поста встречался и с тем и другим. Он уяснил, что пренебрегать процедурой “резервное копирование данных” никак нельзя. И с некоторых пор строго следует этой процедуре. Отмечу, что обсуждаемая процедура конечно же имеет свою специфику и множество вариантов.

Как копируется база данных сайта: рабочий вариант

Возьмем для примера сайт, на котором вы читаете этот пост. Кто чуть-чуть разбирается как устроены веб-ресурсы поймет, что сайт разработан на платформе WordPress. А кто не разбирается, просто примите это к сведению. На платформе WordPress сайт состоит из двух крупных компонентов: базы данных и файлов сайта. Файлы сайта – это страницы, скрипты, медиа-файлы. Мной разработанная достаточно легкая и понятная схема резервного копирования базы данных и файлов сайта. Схема обеспечивает практически стопроцентную восстановления данных в случае непредвиденных обстоятельств. Эти обстоятельства хорошо известны: сбои, аварии, несанкционированное вмешательство мошенников или врагов и т.д. Рисунок 1 иллюстрирует данную схему.

Рисунок 1. Схема резервного копирования базы данных сайта.

Имеется два вычислительных узла, на которых асинхронно через cron выполняются скрипты для создания резервных копий. Это сервер, на котором располагаются файлы и база данных сайта, и рабочая станция администратора. База данных управляется СУБД MariaDB. Web-сервер – это Apache + Nginx. Ниже краткое описание работы компонентов этой схемы для создания резервных базы данных.

На сервере стандартная копия базы данных создается программой mysqldump. Далее резервная копия при необходимости архивируется (zip) и по протоколу webdav передается для постоянного хранения в облачное хранилище. Архив и служебные файлы при необходимости удаляются. На рабочей станции администратора резервная копия базы данных по протоколу webdav загружается из облачного хранилища и передается для постоянного хранения в локальное хранилище. Могут быть загружены все версии резервных копий одним архивом или по-отдельности. Служебные файлы удаляются. Описанная процедура используется и для резервного копирования файлов сайта. Разница заключает только в том, что на первом этапе архивируется не дамп базы данных, а папка с файлами.

Данная схема резервного копирования реализована скриптами Python. Конфигурационные параметры (файл json) таковы, что на сервере и рабочей станции исполняется один и тот же скрипт, но настроенный по месту исполнения. Настраиваются служебные папки, журнализация, хранилища, объекты копирования и хранения, активация, архивирование, именование, источники и приемники данных.

Достоинства

Представленная схема резервного копирования обеспечивает:

• Создание и хранение нескольких копий в раздельных и независимых хранилищах.
• Произвольную частоту копирования – дополняет услуги хостинга по резервному копированию данных.
• Детальный выбор объектов копирования – дополняет услуги хостинга по резервному копированию данных.
• Использование локальных и облачных хранилищ для хранения резервных копий.
• Очень гибкую настройку процедуры копирования.
• Минимизацию числа программных компонентов для обеспечения копирования.

Отмечу, что услуги хостинга VDS предусматривают бесплатный backup каждые 7 дней и его хранение не более 15 дней (за две недели хранится до 2 копий VDS).