Технические подробности работы резервного копирования ISPmanager

Материал из ISPWiki
Перейти к: навигация, поиск

Формат хранения данных

  • Отдельные пользователи сохраняются в хранилище в отдельных файлах
  • Большие архивы могут быть разбиты на тома небольшого размера (по умолчанию 100Мб), что уменьшает требования к свободному месту на диске и позволяет в случае частичного извлечения данных запрашивать из хранилища только часть архивов
  • В качестве формата хранения архивов использован .tgz. Это позволяет извлекать данные из архивов, используя сторонние приложения
  • Мы использовали собственную утилиту isptar, которая, помимо создания архива в формате .tgz, сохраняет список файлов со смещениями. Этот список добавляется в конец архива и позволяет быстро извлекать файлы, не распаковывая весь файл, как это происходит с классическим ".tgz" архивом

Общая архитектура

Резервное копирование реализовано в виде нескольких взаимодействующих между собой приложений.

backup2/backup2_pro
Формирует очередь резервного копирования, если она пуста. Затем извлекает из нее по очереди записи и запускает для каждой из них отдельный процесс backup2/backup2_pro. Этот процесс получает настройки резервного копирования для пользователя, формирует заготовки файлов в каталоге .system (реальные данные будут сохранены в эти файлы после запуска backup2_system), а затем выполняет резервное копирование, запуская isptar
isptar
Архиватор, задача которого прочитать данные с жесткого диска и запаковать их в .tgz архивы
backup2_cp
Отвечает за работу с хранилищами (локальное, FTP, Dropbox, Yandex, Amazon). Его задача - прочитать архив, сформированный isptar, и загрузить его в хранилище. backup2_cp запускается из isptar и backup2/backup2_pro (для загрузки информации о резервной копии и листинга файлов). Он так же отвечает за контроль свободного места в хранилище
backup2_system
Резервное копирование данных, не представленных в виде отдельных файлов, как то: настройки пользователя в панели, базы данных, почтовые ящики, доменные имена, web домены и т.д. backup2_system' извлекает данные и сохраняет их в виде специальных файлов в каталоге .system. backup2/backup2_pro создает необходимый набор файлов в этом каталоге. После isptar, когда доходит очередь до резервного копирования этих файлов, запускает для каждого из них процесс backup2_system
restore2/restore2_pro
Извлекает данные из архива
backup2_download
Формирует резервную копию в виде отдельного файла для скачивания. В случае, если резервная копия была сохранена в нескольких томах, они будут объединены в один
backup2_import
Позволяет импортировать архив сформированный backup2_download и загрузить его в текущее хранилище
backup2_cgi
Позволяет скачать часть архива в виде отдельного .tgz файла. Например, это может быть дамп отдельных баз данных или набор файлов и каталогов

Схема взаимодействия приложений при резервном копировании в ISPmanager Lite

Backup-lite.png

Схема взаимодействия приложений при резервном копировании в ISPmanager Business

Резервное копирование MASTER работает полностью аналогично тому, как оно работает в ISPmanager Lite. MASTER самостоятельно делает резервную копию метаданных и самостоятельно заливает её в хранилище (даже если для MASTER не выбрана роль сервера обработки резервного копирования). Для каждой роли пользователя в каталоге .system создается специальный файл, node.<node role>. Для каждого такого файла backup2_system запускает на соответствующей ноде процесс резервного копирования. Когда резервное копирование роли завершено, backup2_system скачивает с BACKUP NODE получившиеся файлы листинга и информации (.info) и добавляет размер в основной .info файл на MASTER. В общем случае схема взаимодействия в ISPmanager business выглядит следующим образом. Однако, когда взаимодействующие роли находятся физически на одном сервере, схема взаимодействия меняется. Например, если BACKUP NODE совпадает с NODE, работу процессов isptar --client и isptar --server выполняет isptar --create.

Данные каждой роли, даже если некоторые из них расположены на одном сервере, сохраняются в отдельных файлах.

Одновременно может осуществляться резервное копирование нескольких пользователей, если основная роль этих пользователей расположена на различных узлах. Backup-business.png

Контроль свободного места

ISPmanager business может осуществлять резервное копирование нескольких пользователей одновременно. Чтобы контролировать использование дискового пространства хранилища запускается демон (backup2_cp --server (daemon)). Данный процесс собирает информацию о занятом месте из .info файлов, хранящихся на MASTER и контролирует, чтобы общий объем залитых в хранилище данных никогда не превышал установленное ограничение.

(daemon) не обслуживает запросы на резервирование места самостоятельно, их получают клиенты backup2_cp --client - процессы, которые запускаются на каждом сервере обработки резервного копирования и на MASTER. Клиент получает запрос от процесса backup2_cp --put через UNIX socket и передает его через PIPE в (daemon).

В случае использования локального хранилища, ограничение на общий объем резервных копий устанавливается на каждый сервер отдельно (вряд ли кого-то интересует суммарный объем бэкапов на всех серверах). Таким образом, если у вас есть 2 сервера обработки резервного копирования и установлено ограничение в 1Тб, ваши резервные копии могут занимать как 1Тб (если все пользователи по какой-то причине будут бэкапиться на один узел) так и 2Тб, если бэкапы распределятся равномерно. Все резервные копии пользователя всегда создаются на одном и том же узле. Если место заканчивается на одном узле - старые бэкапы удаляются на всех узлах, даже если на каких-то место еще осталось. Количество хранимых резервных копий будет одинаково для всех пользователей вне зависимости от того, на каком узле хранятся их резервные копии.


Общее ограничение на кол-во резервных копий по умолчанию равно 14 (для каждого пользователя, т.е у вас может быть, к примеру, всего 18 резервных копий, но каждый пользователь может находиться только в 14 из них) может быть изменено через параметр конфигурационного файла BackupCountLimit. Количество резервных копий может быть больше установленного ограничения (ограничение на количество резервных копий, по умолчанию 14 - 7 ежедневных дифференциальных и 7 полных). Так как вначале мы делаем резервную копию, а только потом удаляем старую. Старая копия может быть удалена раньше, если в хранилище недостаточно места. Но последняя полная резервная копия никогда не может быть удалена до того, как будет сделана новая.

Если пользователю не хватает места на две полные резервные копии, его резервное копирование будет завершаться с ошибкой.

Обработка ошибок

Каждый раз, когда backup2/backup2_pro начинает резервное копирование пользователя, информация о резервной копии записывается в var/ispmgr.backup.cleanup. При запуске и завершении backup2_cp --server (daemon) просматривает этот файл, и удаляет все файлы относящиеся к этим резервным копиям. В случае успешного завершения резервного копирования backup2/backup2_pro удаляют запись из var/ispmgr.backup.cleanup, сделанную при старте.

Конвертация резервных копий

Для конвертации резервных копий из формата dar, необходимо выполнить команду sbin/backup2_conv. После конвертации информация о старых резервных копиях в формате dar будет перемещена в директорию old, которая расположена в рабочей директории, указанной в конфигурационном файле панели.

По умолчанию путь к старым резервным копиям после конвертации /usr/local/mgr5/var/backup/ispmgr/old

При конвертации старые файлы из хранилища удалены не будут (никогда). Вы должны удалить их самостоятельно (предварительно убедившись, что все прошло успешно), или позаботиться о том, чтобы вам хватило свободного места на хранилище.

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