Комментарии 13
мне кажется бэкап можно считать выполненным, когда не только создан архив, но и из архива успешно развернут сайт на запасном сервере (например, в офисе).
Как вот это сделать?
PS: вроде бы akeeba раньше платным был для joomla2,5? или я ошибаюсь? или сделали бесплатным?
Как вот это сделать?
PS: вроде бы akeeba раньше платным был для joomla2,5? или я ошибаюсь? или сделали бесплатным?
внизу топика есть спойлер с именем: Как восстанавливать сайт из резервной копии
Там как раз описан процесс восстановления.
У Akeeba довольно давно существует платная Pro версия, которая позволяет как раз настроить автобекап прямо из админки джумлы, но, как оказалось, есть способ реализовать авторезервирование и с бесплатной версией способом, описанным мной в топике.
Там как раз описан процесс восстановления.
У Akeeba довольно давно существует платная Pro версия, которая позволяет как раз настроить автобекап прямо из админки джумлы, но, как оказалось, есть способ реализовать авторезервирование и с бесплатной версией способом, описанным мной в топике.
Как вручную развернуть кикстартом я знаю.
Вы же говорите об автоматическом архивировании?
Вот и я спрашиваю об автоматическом архивировании ПЛЮС автоматическом развертывании на резервном сервере.
Вы же говорите об автоматическом архивировании?
Вот и я спрашиваю об автоматическом архивировании ПЛЮС автоматическом развертывании на резервном сервере.
Я считаю, что в этом не очень много смысла. Вы имеете ввиду такой сценарий: что-то пошло не так, сайт крешится и тут же срабатывает скрипт восстановления из ближайшей резервной копии. Вы это имеете ввиду? Просто я не очень понимаю, зачем еще нужна автоматизация восстановления. Она итак через кикстарт делается в несколько кликов, избавляя нас от массы рутины. Если нам нужно залить сайт на другой сервер, без правки конфига (хоть руками, хоть через кикстарт) нам не обойтись в любом случае. Автоматом этого просто не сделать.
Мне нужен был процесс автоматического резервирования, так как это довольно стандартная практика, делать бекапы, и делать их постоянно. Это действительно нужно, и приятно, когда не нужно заботиться о том, чтобы не забыть его сделать, достаточно раз настроить систему для автоматического процесса.
Само же восстановление из бекапа много более редкий процесс, и почти всегда этот процесс требует присутствия человека все же, как я считаю. Как минимум для того, чтобы понять, что же пошло не так.
Мне нужен был процесс автоматического резервирования, так как это довольно стандартная практика, делать бекапы, и делать их постоянно. Это действительно нужно, и приятно, когда не нужно заботиться о том, чтобы не забыть его сделать, достаточно раз настроить систему для автоматического процесса.
Само же восстановление из бекапа много более редкий процесс, и почти всегда этот процесс требует присутствия человека все же, как я считаю. Как минимум для того, чтобы понять, что же пошло не так.
бывало много случаев, когда у людей долгое время работал автоматический бэкап.
Вот он работает месяц два, год и все довольны, но резервными копиями никогда не пользовались — не было потребности. Испытали один раз в самом начеле и успокоились.
А когда потребность пришла (на сервере сломался винт), то оказалось, что многочисленные файлы бэкапа создаваемые годами на самом деле полное фуфло — из них оказалось нельзя восстановить.
Например, где-то в середине эксплуатации закончилось место под бэкапы и они получались нулевой длины.
Или провайдер обновил версию какой-то библиотеки на сервере и она стала работать немного не так, а ее вызывала функция создания бэкапа… Провайдер сменил версию PHP или SQL а модуль архивации с ними не был оттестирован… На сайте может вдруг оказался вирус, который поразил и систему архивирования… Да мало ли что…
Поэтому я говорю, что хорошо было бы иметь в запасе развернутую копию реального сервера.
Ну или по крайней мере раз в месяц пытаться извлечь из бэкапа — дай бог чтоб извлеклось…
.
Вот он работает месяц два, год и все довольны, но резервными копиями никогда не пользовались — не было потребности. Испытали один раз в самом начеле и успокоились.
А когда потребность пришла (на сервере сломался винт), то оказалось, что многочисленные файлы бэкапа создаваемые годами на самом деле полное фуфло — из них оказалось нельзя восстановить.
Например, где-то в середине эксплуатации закончилось место под бэкапы и они получались нулевой длины.
Или провайдер обновил версию какой-то библиотеки на сервере и она стала работать немного не так, а ее вызывала функция создания бэкапа… Провайдер сменил версию PHP или SQL а модуль архивации с ними не был оттестирован… На сайте может вдруг оказался вирус, который поразил и систему архивирования… Да мало ли что…
Поэтому я говорю, что хорошо было бы иметь в запасе развернутую копию реального сервера.
Ну или по крайней мере раз в месяц пытаться извлечь из бэкапа — дай бог чтоб извлеклось…
.
НЛО прилетело и опубликовало эту надпись здесь
Можно и так, только разворачивание сайта из бекапа займет больше времени(разархивировать, накатить дамп, переписать конфиг, если скидываем сайт на другой сервер), чем через компонент Akeeba backup, и скрипты писать придется посложнее немного. Я, например, являюсь ламеров в linux системах и мне такое на данный момент не осилить.
Имел дело с дампом сайта через Akeeba — представлял собой zip (дамп) + php (распаковщик).
Кикстарт развернуть дамп не осиливал и падал с ошибкой, zip удалось вскрыть только модулем TotalCommander'а — 7zip, WinRAR и встроенный в Win7 zip-модуль видели только часть файлов. Вот такая классная штука.
Так что мы лучше как-нибудь по старинке: rsync + rdiff-backup
Кикстарт развернуть дамп не осиливал и падал с ошибкой, zip удалось вскрыть только модулем TotalCommander'а — 7zip, WinRAR и встроенный в Win7 zip-модуль видели только часть файлов. Вот такая классная штука.
Так что мы лучше как-нибудь по старинке: rsync + rdiff-backup
Я не могу знать, какая у вас была проблема. Возможно архив с бекапом изначально был битый, возможно на сервере не доставало необходимых настроек для php(хотя kickstart об этом сразу уведомляет).
Могу лишь судить по своему опыту, я пользуюсь этим компонентом уже 2 года и использовал его для резервирования где-то на 6-7 сайтах, никаких проблем не возникало ни разу.
Могу лишь судить по своему опыту, я пользуюсь этим компонентом уже 2 года и использовал его для резервирования где-то на 6-7 сайтах, никаких проблем не возникало ни разу.
Сегодня настроил 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 архивы за каждый день. Как удалять старые, не буду описывать, мне это не нужно. Пусть себе живут. Скрипт на шеле, думаю легко написать с помощью гугла.
Есть несколько замечаний, верней дополнений к статье:
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 архивы за каждый день. Как удалять старые, не буду описывать, мне это не нужно. Пусть себе живут. Скрипт на шеле, думаю легко написать с помощью гугла.
«Знаю, что джумлу на хабре не особо жалуют, но думаю все же найдутся хабровчане, которые создают сайты с её помощью.»
И при этом по статистике Joomla! в лидерах по созданным сайтам на этой CMS.
Это с какого перепугу! Хорош вешать ярлыки! Я просто промолчу про 1эС.
Версии 3.3 и 2.5 просто подарок.
Спасибо за солюшен.
И при этом по статистике Joomla! в лидерах по созданным сайтам на этой CMS.
Это с какого перепугу! Хорош вешать ярлыки! Я просто промолчу про 1эС.
Версии 3.3 и 2.5 просто подарок.
Спасибо за солюшен.
Здравствуйте! Помогите мне разобраться со скриптом копирования на яндекс диск. Скрипт Бэкапа сделал таким
<?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
<?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
погуглить методы, отвечающие за работу php с файловой системой. Перейти с помощью данных методов в каталог, в котором храняться бекапы.
Сделать цикл перебора всех файлов-бекапов, и для каждого применять curl
Получится что-то типа этого:
Подробнее можно почитать здесь
Сделать цикл перебора всех файлов-бекапов, и для каждого применять curl
Получится что-то типа этого:
foreach ($files_to_send as $file) {
echo shell_exec("curl --user {$WebDAV['login']}:{$WebDAV['password']} -T \"$file\" {$WebDAV['url']}") . "<br>\n";
}
Подробнее можно почитать здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой способ автоматического создания бекапа joomla сайтов с помощью Akeeba backup + Crontab