Простой способ автоматического создания бекапа joomla сайтов с помощью Akeeba backup + Crontab

Всем привет.
Хочу описать процесс полностью автоматического создания резервных копий сайтов на CMS Joomla с помощью компонента Akeeba backup, причем его бесплатной версии.
Знаю, что джумлу на хабре не особо жалуют, но думаю все же найдутся хабровчане, которые создают сайты с её помощью.

В качестве примера буду использовать Joomla 2.5.16
Первым делом нам нужно установить компонент Akeeba Backup. Скачать его можно отсюда: www.akeebabackup.com/downloads/akeeba-backup.html

Что из себя представляет резервная копия, сделанная с помощью Akeeba backup
На выходе мы получим файл с расширением jpa, который включает в себя все файлы нашего сайта, а также дамп базы данных. Данный бекап очень легко накатить на любой сервер, следуя пошаговым инструкциям. Как это сделать, напишу ниже.


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

Первым делом нам необходимо активировать возможность делать бекап не только из панели Joomla. Для этого переходим в Компоненты -> Akeeba backup -> Component Parameters. Нужно установить переключатель на ДА в свойстве Enable front-end and remote backup. Указать секретное слово, которое будет использоваться для генерации ссылки, опционально можно включить уведомления по e-mail о выполнении бекапа.



Теперь необходимо написать небольшой shell скрипт, который будет запускаться планировщиком Crontab.
Выглядит он так:
#!/bin/bash
wget --max-redirect=10000 "http://<Адрес сайта>/index.php?option=com_akeeba&view=backup&key=<Секретное слово, которое мы указывали в настройках>"
find ${<Полный адрес до каталога с бекапами>} -type f -mtime +<Возраст файла в днях> -delete  #Например find ${/site/BACKUP} -type f -mtime +30 -delete  - удалит все файлы старше 30 дней

Данный скрипт осуществляет бекап нашего сайта.

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



Если у вас есть полный доступ к серверу, на котором располагается сайт, то нужно занести строчку в конфиг crontab, по умолчанию расположенный в /etc/ с именем crontab

Всё, теперь наши бекапы будут делаться в автоматическом режиме по расписанию и складываться в каталог, прописанный в настройках компонента Akeeba Backup. По умолчанию: administrator/components/com_akeeba/backup/

В дальнейшем планирую расширить bash скрипт, чтобы он удалял устаревшие бекапы и также переносил эти файлы на дропбокс. Если есть какие-то мысли, как это сделать, прошу поделиться в комментариях.

Как восстанавливать сайт из резервной копии
Для того, чтобы восстановить сайт или перенести его на другой сервер, необходимо скачать набор файлов под названием Akeeba Kickstart: www.akeebabackup.com/downloads/akeeba-kickstart.html

Этот набор включает в себя следующие файлы:
  • jquery.min.js-библиотека Jquery
  • json2.min.js-библиотека Json
  • kickstart.php-PHP скрипт, выполняющий восстановление
  • ru-RU.kickstart.ini-язык локализации


Необходимо поместить эти файлы на сервер и туда же скинуть файл с бекапом, который имеет расширение jpa.
Далее просто пройти по адресу: http://<Ваш сайт>/kickstart.php и следовать инструкциям.
Если вы восстанавливаете сайт на том же сервере, где он и был, то часть настроек подтянется автоматически, иначе нужно будет указать новые настройки для корректного формирования конфига: путь к БД, имя БД, имя пользователя БД и тд.
После выполнения всех инструкций, система восстановит сайт. И никаких танцев с бубном с перезаливкой руками всех файлов(особенно противно это делать по FTP), а также ручной правкой конфигурационного файла configuration.php в корне сайта.


UPD 17.12.2013: Расширил скрипт, теперь он удаляет устаревшие бекапы.

UPD 16.05.2014: Хотел заморочиться с отправкой бекапа на дропбокс, но выходит больно кропотливо, гораздо проще использовать облачное хранилище с поддержкой WebDAV, я использовал Яндекс диск. Вот так выглядит скрипт:
#!/bin/bash
 
#переходим в каталог, в который складываются бекапы, сделанные Akeeba Backup
cd site/backup
 
for i in *.jpa;
do
   # username:password - имя пользователя и пароль к аккаунту Яндекса  
   # указанные в пути каталоги /backups/sites/ должны быть предварительно созданы в Яндекс диске
   curl -T ${i} --user username:password https://webdav.yandex.ru/backups/sites/
   # при желании можно удалять эти бекапы с веб сервера для экономии места командой rm
   rm ${i}
done

Ну и создаем по аналогии задание в cron под запуск скрипта
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 13

    0
    мне кажется бэкап можно считать выполненным, когда не только создан архив, но и из архива успешно развернут сайт на запасном сервере (например, в офисе).
    Как вот это сделать?
    PS: вроде бы akeeba раньше платным был для joomla2,5? или я ошибаюсь? или сделали бесплатным?
      0
      внизу топика есть спойлер с именем: Как восстанавливать сайт из резервной копии
      Там как раз описан процесс восстановления.
      У Akeeba довольно давно существует платная Pro версия, которая позволяет как раз настроить автобекап прямо из админки джумлы, но, как оказалось, есть способ реализовать авторезервирование и с бесплатной версией способом, описанным мной в топике.
        0
        Как вручную развернуть кикстартом я знаю.
        Вы же говорите об автоматическом архивировании?
        Вот и я спрашиваю об автоматическом архивировании ПЛЮС автоматическом развертывании на резервном сервере.
          0
          Я считаю, что в этом не очень много смысла. Вы имеете ввиду такой сценарий: что-то пошло не так, сайт крешится и тут же срабатывает скрипт восстановления из ближайшей резервной копии. Вы это имеете ввиду? Просто я не очень понимаю, зачем еще нужна автоматизация восстановления. Она итак через кикстарт делается в несколько кликов, избавляя нас от массы рутины. Если нам нужно залить сайт на другой сервер, без правки конфига (хоть руками, хоть через кикстарт) нам не обойтись в любом случае. Автоматом этого просто не сделать.
          Мне нужен был процесс автоматического резервирования, так как это довольно стандартная практика, делать бекапы, и делать их постоянно. Это действительно нужно, и приятно, когда не нужно заботиться о том, чтобы не забыть его сделать, достаточно раз настроить систему для автоматического процесса.
          Само же восстановление из бекапа много более редкий процесс, и почти всегда этот процесс требует присутствия человека все же, как я считаю. Как минимум для того, чтобы понять, что же пошло не так.
            0
            бывало много случаев, когда у людей долгое время работал автоматический бэкап.
            Вот он работает месяц два, год и все довольны, но резервными копиями никогда не пользовались — не было потребности. Испытали один раз в самом начеле и успокоились.
            А когда потребность пришла (на сервере сломался винт), то оказалось, что многочисленные файлы бэкапа создаваемые годами на самом деле полное фуфло — из них оказалось нельзя восстановить.
            Например, где-то в середине эксплуатации закончилось место под бэкапы и они получались нулевой длины.
            Или провайдер обновил версию какой-то библиотеки на сервере и она стала работать немного не так, а ее вызывала функция создания бэкапа… Провайдер сменил версию PHP или SQL а модуль архивации с ними не был оттестирован… На сайте может вдруг оказался вирус, который поразил и систему архивирования… Да мало ли что…

            Поэтому я говорю, что хорошо было бы иметь в запасе развернутую копию реального сервера.
            Ну или по крайней мере раз в месяц пытаться извлечь из бэкапа — дай бог чтоб извлеклось…

            .
      0
      Слушайте, ну а в чём проблема по SSH сделать .tar + дамп БД?
        0
        Можно и так, только разворачивание сайта из бекапа займет больше времени(разархивировать, накатить дамп, переписать конфиг, если скидываем сайт на другой сервер), чем через компонент Akeeba backup, и скрипты писать придется посложнее немного. Я, например, являюсь ламеров в linux системах и мне такое на данный момент не осилить.
        0
        Имел дело с дампом сайта через Akeeba — представлял собой zip (дамп) + php (распаковщик).
        Кикстарт развернуть дамп не осиливал и падал с ошибкой, zip удалось вскрыть только модулем TotalCommander'а — 7zip, WinRAR и встроенный в Win7 zip-модуль видели только часть файлов. Вот такая классная штука.

        Так что мы лучше как-нибудь по старинке: rsync + rdiff-backup
          0
          Я не могу знать, какая у вас была проблема. Возможно архив с бекапом изначально был битый, возможно на сервере не доставало необходимых настроек для php(хотя kickstart об этом сразу уведомляет).
          Могу лишь судить по своему опыту, я пользуюсь этим компонентом уже 2 года и использовал его для резервирования где-то на 6-7 сайтах, никаких проблем не возникало ни разу.
          0
          Сегодня настроил Akeeba backup.
          Есть несколько замечаний, верней дополнений к статье:

          1) Если в настройках установить ZIP формат архива ( у меня joomla 3.2 и последняя версия akeeba backup), то архив разворачивается так:
          а) создаем на нужном сервере http папку, например /srv/www/htdocs, в которую копируем zip архив с бакапом
          б) распаковываем в папке архив так — unzip backup.zip
          в) создаем пустую базу данных, пользователя с паролем и правами доступа к базе на нашем новом сервере
          г) просто входим на сайт www.site.com и видим, что из распакованной папки installation автоматически запустился установщик, а это значит что не нужно использовать kickstart, скачивая его для восстановления. Архив уже содержит все в себе. Не забываем настроить на сервере индекс для обработки файла index.php по умолчанию. К примеру, для nginx — добавим в конфиг index index.php, но думаю, что это не нужно разжевывать.

          2) akeeba backup стоит 40$ или евро, не помню. Его можно использовать бесплатно, но тогда нет автоматизации по отправке архивов на амазон например. Мне на амазон и не нужно. Мне нужно, чтобы бакапы копировались на сторонний сервер, чтобы, если упадет основной сервер, например с помощью rm -fr от корня, то я мог бы использовать архив со своего второго сервера.
          Что делать? Ответ здесь:
          а) на второй сервер ( у нас ведь там юникс, линукс не так ли? ) копируем с akeeba сайта remote cli, специальный файл, который умеет коннектиться к основному сайту.
          б) настраиваем крон 0 3 * * * /backups/get_backup.sh > /dev/null 2>&1
          содержимое файла get_backup.sh

          #!/usr/bin/sh
          cd /backups
          /usr/bin/php remote.phar --action=backup --host=http://www.site.com --secret=mysecretfromsite --profile=1 --download --dlmode=http --dlpath="/backups/"

          в) далее, не забываем сделать chmod +x для /backups/get_backup.sh и ручками запускаем его, для тестирования. В случае ругани, не забываем что нужно добавить необходимые библиотеки для php и прописать папку /backups в PEAR для php.ini

          Собственно все. Как это работает:
          1) Сервер 2 коннектится к серверу 1 и создает на сервере 1 согласно профилю 1 ( это описано в статье выше ) бакап.
          2) Далее, сервер 2 скачивает в папку /backups сервера 2 архив с сервера 1, который только что был создан

          Ура. Мы имеем в папке /backups архивы за каждый день. Как удалять старые, не буду описывать, мне это не нужно. Пусть себе живут. Скрипт на шеле, думаю легко написать с помощью гугла.
            0
            «Знаю, что джумлу на хабре не особо жалуют, но думаю все же найдутся хабровчане, которые создают сайты с её помощью.»

            И при этом по статистике Joomla! в лидерах по созданным сайтам на этой CMS.

            Это с какого перепугу! Хорош вешать ярлыки! Я просто промолчу про 1эС.

            Версии 3.3 и 2.5 просто подарок.

            Спасибо за солюшен.
              0
              Здравствуйте! Помогите мне разобраться со скриптом копирования на яндекс диск. Скрипт Бэкапа сделал таким

              <?php
              $curl_handle=curl_init();
              curl_setopt($curl_handle, CURLOPT_URL, 'http://мой сайт/index.php?option=com_akeeba&view=backup&key=код');
              curl_setopt($curl_handle,CURLOPT_FOLLOWLOCATION, TRUE);
              curl_setopt($curl_handle,CURLOPT_MAXREDIRS, 10000);
              curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER, 1);
              $buffer = curl_exec($curl_handle);
              curl_close($curl_handle);
              if (empty($buffer))
              echo «Sorry, the backup didn't work.»;
              else
              echo $buffer;
              ?>

              и сохранил в файле skript.php, после чего указал на хостинге в Cron
                0
                погуглить методы, отвечающие за работу php с файловой системой. Перейти с помощью данных методов в каталог, в котором храняться бекапы.
                Сделать цикл перебора всех файлов-бекапов, и для каждого применять curl
                Получится что-то типа этого:
                foreach ($files_to_send as $file) {
                    echo shell_exec("curl --user {$WebDAV['login']}:{$WebDAV['password']} -T \"$file\" {$WebDAV['url']}") . "<br>\n";
                }
                


                Подробнее можно почитать здесь

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