Встраиваем Sypex Dumper в свою админку

    Многие популярные CMS, как с открытым исходным кодом, так и коммерческие, имеют в своем составе модули бэкапа. Но проблема в том, что чаще всего эти модули делаются по остаточному принципу, и весьма примитивны, не учитывают многих тонкостей создания дампа. Также чаще всего эти модули банально никто не тестируют на большие объемы (прогнали его на тестовой полупустой БД и рады).

    В отличии от подобных модулей, Sypex Dumper является скриптом заточенным исключительно на бэкап и восстановление MySQL. И без проблем работающий с базами даже в несколько гигабайт. Но, кроме того, что дампер работает, как отдельное приложение, в нем была предусмотрена возможность встраивать его в сторонний софт.

    В данной статье я расскажу, как быстро и довольно просто встроить Sypex Dumper в административную панель своей CMS (форума, блога и т.п.). А также рассмотрим некоторые недокументированные возможности такой интеграции.

    Вступление


    Для встраивания дампера, я рекомендую следующую схему:
    • Создание в вашей админке страницы на которой будет расположен iframe, в который будет загружаться дампер.
    • Создание файла авторизации для дампера, который будет использовать авторизацию вашей CMS.

    У данной схемы есть следующие преимущества, по сравнению с привычным подключением модуля бэкапа с помощью include в свою систему:
    • Меньше затрат времени (не нужно вписывать дампер в свой интерфейс, да и у дампера не совсем стандартная схема работы).
    • Дампер может работать, как в админке, так и самостоятельно (что полезно, когда по каким-либо причинам в админку зайти нельзя).

    Файл авторизации


    Файл авторизации представляет собой небольшой скрипт, единственная задача которого проверить есть у пользователя права доступа к дамперу. В дампере используются, так называемые, цепочки авторизации. В которых указывается, какие файлы авторизации использовать и в какой последовательности. Разберем файл авторизации на примере недавно созданной интеграции в ImageCMS.

    Название файла состоит из префикса «auth_», названия авторизации (состоящее из английских букв, цифр и знака подчеркивания) и расширения «php».

    Файл авторизации должен содержать набор инструкций, который в случае положительной авторизации пользователя, должен установить значение переменной $auth в true (либо 1). Также в файле авторизации можно менять любые свойства из конфиг-файла (в дальнейшем они попадут в виртуальный конфиг). Доступ к свойствам конфиг-файла через массив $this->CFG.

    <?php
    // Sypex Dumper 2 authorization file for ImageCMS 3
    session_start();
    if(!empty($_SESSION['DX_permission']['backup_create'])){
    	define('BASEPATH', 1);
    	include '../application/config/config.php';
        if($this->connect($db['default']['hostname'], '', $db['default']['username'], $db['default']['password'])){
            $this->CFG['my_db'] = $db['default']['database'];
            $this->CFG['exitURL'] = '../admin/logout';
            $auth = 1;
        }
    }
    ?>
    

    В ImageCMS для авторизации используются стандартные сессии, поэтому в начале скрипта создаем сессию, и получаем данные о пользователе. Для того чтобы проверить права доступа в этой CMS используем родное свойство 'backup_create', если оно истинно значит пользователь может пользоваться дампером.

    Дальше подключаем конфиг-файл CMS-ки, чтобы достать оттуда данные для подключения к MySQL. И с помощью $this->connect() подключаемся к MySQL, в случае успеха запоминаем базу к которой будет доступ в дампере, и настраиваем 'exitURL' – адрес по которому будет переходить дампер при нажатии кнопки выхода. Ну и главное $auth присваиваем 1, говорящую о том, что авторизация успешна.
    После этого нужно будет добавить имя файла авторизации в цепочку авторизации. Это можно сделать в интерфейсе дампера Опции -> Цепочка авторизации, либо в cfg.php в строке

    'auth' => ‘mysql cfg',
    

    Теперь если вы залогинены в CMS, и у вас есть право создавать бэкапы, то для входа в дампер дополнительная авторизация не понадобится.

    Интеграция в интерфейс


    Осталось только встроить дампер в админку CMS. Для чего на нужную страницу админки нужно вставить строку:

    <iframe src="/sxd/" width="586" height="462" frameborder="0" style="margin:0;"></iframe>
    

    где в src подставить адрес дампера (относительный или полный).

    Недокументированные возможности


    Поскольку в Sypex Dumper интерфейс работает полностью на JS, то мы можем довольно просто выполнять любые функции дампера из своей CMS, как с помощью кнопок так и автоматически.

    К примеру для создания бэкапа нужно выполнить команду (предварительно в iframe добавив id=sxdframe):

    sxdframe.sxd.runBackup();
    

    Или такой вариант:

    // Открываем вкладку импорта
    sxdframe.sxd.actions.tab_restore();
    // Выбираем базу test1
    sxdframe.sxd.combos.restore_db.select('test1');
    // Выбираем файл
    sxdframe.sxd.combos.restore_file.select('test1_2012-11-17_10-02-34.sql.gz');
    // Восстановить дамп
    sxdframe.sxd.runRestore();
    


    В связи с подготовкой третьей версии дампера, интересует насколько востребован подобный JS API для него. Также принимаются пожелания по тому, что еще добавить в дампер. И конечно, если возникли какие-то сложности по интеграции, можете смело задавать вопросы.

    В документации разбираются еще несколько файлов авторизации Sypex Dumper.
    Кроме того вы можете скачать готовые файлы интеграции для следующих популярных систем: Drupal, ImageCMS, IPBoard, Joomla, MODx, phpBB, PHP-Fusion, vBulletin, WordPress, XenForo.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 34

      +2
      SypexDumper №1. Как-то делал интеграцию для одного cmf — cogear. Очень просто и удобно.
      • UFO just landed and posted this here
          +1
          А как же уровни доступа к модулям админки?
          Хотя наверно неплохо было бы заблокировать вкладку «файлы», чтобы дампер из админки мог только бэкапить и ресторить.
            0
            Можно просто запретить скачивать по http из каталога backup, в случае боязни увода дампа.
          +5
          Посмотрел код — он ужасен. В конструкторе дефайнятся константы — то есть подключится к двум БД, что бы сделать дамп не получится. Какой тогда смысл в этом объекте? Нет разделения на MVC: в index.php сложено сразу и классы и вёрстка.

          Пожелание.
          Разделить на два уровня: библиотека классов + html-интерфейс, что бы я мог выкинуть интерфейсную часть и подключить только классы инклюдом. Тогда я смогу оставить свой интерфейс админки и просто обращаться к классам примерно так:

          $dumper = new SXDumper($host, $user, $pass, $db);
          $dumper->needStructure = true;
          $dumper->needData = false;
          $dumper->dump($file, $_GET['step']);
          // Без гемороя с обходом чужой авторизации и встроено в интерфейсе моей админки.
          


          А вообще тема актуальная. Хочу в свой велосипед встроить нормальный дампер/импортер что бы не изобретать велик.
            0
            Вот вам и классический пример: код «ужасен», но работает очень быстро!
              0
              Классическое заблуждение. Подумайте, если не использовать глобальные константы и разложить на 3 файла: classes + controller + tpl — разве он станет работать медленнее???
                +4
                Не знаю. Но я пробовал другие веб дамперы и с классами и MVC — работают медленнее. Да и потом, меня вполне устраивает этот код по функционалу и скорости, вне зависимости от его красоты
                  0
                  Не знаю.

                  1. Плохо, что вы не знаете, но утверждаете.
                  2. Этот дампер использует классы так же как и другие тормозящие дамперы.
                  3. Тормознутость, практически, не зависит от красоты кода.
                    0
                    Ну это не совсем так, если дампер раскидать на сотни мелких классов, как сейчас любят, то тормозить будет прилично. Поэтому в дампере классов минимум. Ну а то что всё в одном файле, это скорее наследие первого дампера.
                      0
                      если дампер раскидать на сотни мелких классов

                      Не надо перевирать мои слова. Я предложил всего лишь 3 файла:
                      разложить на 3 файла: classes + controller + tpl
                        0
                        Я и не говорил, что это вы сказали. Я сказал «как сейчас модно». В MVC обычно 3-мя файлами не ограничиваются, в таких случаях.
                          0
                          У дампера критична не скорость его первоначальной загрузки, а максимальный размер базы данных которую он дампит. К слову Sypex Dumper с этим справляется на ура. То что код ужасен не критично. Но как только появится достойный конкурент с превосходным кодом я сразу на него перейду. Хотя бы потому что его можно будет проще и глубже интегрировать в систему.
              0
              Уже предлагал тут, вот что ответил zapimir:
              Планируется, но не в ближайшее время. Вся сложность в том, что дампер может работать в несколько этапов, т.е. работа выполняется за несколько запусков скрипта.
                0
                Да-да-да. Знакомая проблема. И я это предусмотрел в предлагаемом интерфейсе. Смотрите что я написал выше:

                $dumper->dump($file, $_GET['step']);
                
                  0
                  А вообще обязательно делать работу за несколько запусков скрипта? Похоже на какой-то ужасный костыль.
                    +2
                    Обязательно. Если база большая и будет дампиться/импортиться больше 5 минут, то надо разбивать на шаги по нескольким причинам:
                    1. max_execution_time можно обойти, но ограничение nginx обойти не получится и будет «504 bad gataway»
                    2. Что бы показывать пользователю процесс. Что бы он видел как бегут проценты. В противном случае, всё может залипнуть на пару часов и пользователь будет в недоумении: а процесс идёт или соединение с сервром отвалилось пол часа наад? А сколько ещё времени осталось: 2 минуты или 2 суток?
                    3. Что бы пользователь, увидев надпись «осталось 48 часов», мог нажать на кнопку «стоп».

                    Так что это необходимость, а не костыль.
                      0
                      max_execution_time можно обойти, но ограничение nginx обойти не получится и будет «504 bad gataway»

                      Вы правы лишь отчасти. Обойти можно, используя увеличенный proxy_read_timeout и proxy_send_timeout для локейшена с админкой. Другое дело, что далеко не у всех есть доступ к конфигам nginx'a. Нужно еще угадать со значением таймаута.
                    0
                    А с прогрессом задачи как быть и рестартом, будете тоже сами контролировать и выводить?
                      0
                      Конечно. В моей админке уже есть прогресс-бар в нужном стиле. Я хочу только универсальный протестированный класс.
                  +1
                  Ок, вот вы допустим встроили дампер в свою админку, что вы будете делать если база навернулась, её нужно восстановить из бэкапа? В админку вы зайти не можете, т.к. база навернулась. Ну или нужно перенести на другой хостинг, в дампере просто вбиваете логин и пароль от MySQL и разворачиваете базу на новом месте.
                  Возможно имеет смысл выпустить какой-то отдельный класс для встраивания, но врятли сам дампер будет встраиваемый через include.
                    –1
                    Если админка не работает, то программист сможет разобраться. В моей админке система бекапов разработана для домохозяек, что бы секретарша могла сделать бекап, переколбасить контент и поняв что она всё сломала, восстановить обратно. Для этого в админке мне нужно всего 3 вещи:
                    1. Кнопка «создать бекап» (без каких либо опций)
                    2. Список созданных бекапов
                    3. Кнопка «восстановить»

                    Я не хочу встраивать в админку космический корабль с кучей функций, потому что все программисты используют phpMyAdmin, а секретарша в нём не разберётся.
                      0
                      Т.е. вы рассматриваете бэкап только как средство отката изменений? В целом на эту тему тоже задумывался, что нужен еще какой-то упрощенный интерфейс. Пока что, остановился на следующей мысли.
                      Сейчас в разработке еще один продукт, под рабочим названием Sypex Backuper, он будет бэкапить всё, и файлы и базу (для БД у него будет функционал дампера). Как раз склоняюсь к тому, чтобы в нем был режим для блондинок. Там можно будет создавать профили бэкапа, т.е. достаточно юзеру выбрать профиль для нужной CMS и бэкап будет делаться по нему (с минимальными настройками, типа галочки бэкапить кэш или нет). Вот как раз там и сделать режим трёх кнопок.
                        0
                        делал такое, было сложное решение, но внешне — выглядело также просто… полностью поддерживаю.
                    0
                    Я так еще лет 5 назад делал, еще с предыдущим дампером, думая, что жутко костылю и должно быть как-то проще и нативнее, через API или еще как-то. А оказывается это «официально» рекомендованная практика…
                      0
                      Использовал эту штуку ещё году в 2005-2006 на своём PHP-бложике.
                      То, что весь код в одном файле не должно беспокоить. Ведь это закрытый «коробочный» продукт, работает быстро и просто. Зачем в код лезть? Это же не опенсорс вроде.
                        0
                        Интересно насколько реально прикрутить SXD в качестве движка к drupal.org/project/backup_migrate для бэкапа/рестора базы и файлов.
                          0
                          Думаю, что почти не реально. SXD реализован как отдельное приложение, которое можно только 1) открывать отдельно, 2) встроить через фрейм и 3) запускать cron'ом. Т.е. никакого API у него нет и наверное не будет, из-за проблем, описанных в комментариях к этому посту.
                            0
                            У Друпала для этого предусмотрен Batch API т.к. тоже есть много задач, выполняемых в несколько присестов, плюс свой крон который может работать посредством системного или в отрыве от него. В общем, думаю можно прикрутить, если озадачиться.
                            0
                            А зачем его встраивать именно в backup and migrate?
                              0
                              Целостность интерфейса. Свой крон, своя схема «прореживания» старых копий, свой интерфейс для бэкапа/рестора не отходя от кассы.
                                0
                                А там возможен рестор, если нельзя будет зайти в админку?
                            0
                            Нет. Там заложен только бэкап юзерспейса, т.е. файлы, генерируемые движком и пользователями плюс база. В случае если нужно забэкапить/откатить сайт целиком — лучше внешние средства.

                            Бекап/рестор не затрагивает сам движок, оно делается на случай если что-то напорят пользователи или повредится база. Повреждения файлов движка маловероятны и бэкапятся ручками (или внешними средствами) при установке апдейтов.

                            т.е. обычный юзкейс — это Backup migrate каждый день бэкапит базу и файло юзерспейса, а раз в несколько недель делается полный бэкап при помощи SXD+FTP (грубо говоря).

                            Так вот если-бы была возможность заюзать функционал нового бэкапера с дедупликацией — это было бы мегакруто т.к. это основной объём и для тех, кто живёт на шареде — спасение. Просто тут ещё в чём плюшка: Backup migrate умеет посылать бэкапы почтой / выкладывать на внешний FTP.

                            В общем — собаководу на заметку, если будет желание прикрутить — оно реально пригодится.
                              0
                              В новом бэкапере и дампере, также из коробки будет поддержка внешних хранилищ, поддержка web-крона (когда для запуска используется прозрачная картинка) также будет.

                            Only users with full accounts can post comments. Log in, please.