Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Приятно смотреть, когда смотря на код понимаешь «что и как» с первого взгляда =)
Меня умиляют пхпшники. Уже давным-давно есть куча проверенных средств с внушительным функционалом для… да для чего угодно, для бэкапов тех же, а они с завидным упорством продолжают делать велосипеды.
Да не, смысл в бакапах на php есть, для ряда ситуаций. На вирт.хостингах, например, это вполне себе востребованная задача.
Решение ТС несколько убивает тем, что для бакапа базы запускается mysqldump, например… если есть доступ к консоли, то php действительно на фиг не нужен. А если нет доступа, то php решение должно работать без доступа.
Решение ТС несколько убивает тем, что для бакапа базы запускается mysqldump, например… если есть доступ к консоли, то php действительно на фиг не нужен. А если нет доступа, то php решение должно работать без доступа.
Можете привести примеры таких средств, которые бы удовлетворяли всем требованиям:
— бэкапить директории и базы данных
— загрузка архивов в локальную папку или на фтп
— информирование по email о удачном/не удачном завершении
Именно всем, и именно бесплатное. Я искал, но все не то, что нужно. Где-то обязательно что-то не так как хочется или нужно платить
— бэкапить директории и базы данных
— загрузка архивов в локальную папку или на фтп
— информирование по email о удачном/не удачном завершении
Именно всем, и именно бесплатное. Я искал, но все не то, что нужно. Где-то обязательно что-то не так как хочется или нужно платить
bacula, не?
Вот я давно писал на habrahabr.ru/post/121120/
Есть версия и с почтовыми уведомлениями и заливкой по ssh. У меня грузится сразу в dropbox, поэтому почту себе не спамлю — и так видно, появился ли архив на компе, или нет.
Если есть интерес — могу поделиться.
Есть версия и с почтовыми уведомлениями и заливкой по ssh. У меня грузится сразу в dropbox, поэтому почту себе не спамлю — и так видно, появился ли архив на компе, или нет.
Если есть интерес — могу поделиться.
Есть ли смысл бекапа базы данных? Падает форум, сайт, еще что-то… но ведь бекап не спасает информацию полученную между датой бекапа и предполагаемым аварийным случаем. Бекап подходит для редко изменяемых файлов. В случае очень живого форума откат форума на день назад из бекапа практически приравнивается к тому что у вас нет бекапа вообще. Интереснее узнать что делать с репликацией бд в реальном времени.
Лучше откатиться на день, чем на неделю или месяц ;)
абсолютно согласен. Но в случае с базой транзакций валюты эта фишка не сильно выручит)
К базам транзакций валюты велосипедостроителей близко не подпустят:-)
А вы думаете какой-нибудь PayPal будет использовать такой скрипт для бэкапа? :) Как по мне, очевидно, что это для начинающих предназначено. Но для этой целевой аудитории очень востребован web-интерфейс для настройки, так как такого размера конфиг их испугает.
По себе знаю, в моём дампере все настройки делаются через web-интерфейс, по сути там нужно всё выбрать и нажать сохранить. А потом в cron только добавить ссылку на запуск дампера. И тем не менее куча просьб добавить в web-интерфейс настройку расписания (хотя по идее во всех современных панелях управления хостингом и так это делается довольно просто).
По себе знаю, в моём дампере все настройки делаются через web-интерфейс, по сути там нужно всё выбрать и нажать сохранить. А потом в cron только добавить ссылку на запуск дампера. И тем не менее куча просьб добавить в web-интерфейс настройку расписания (хотя по идее во всех современных панелях управления хостингом и так это делается довольно просто).
Лично наблюдали несколько форумов/сайтов конкурентов, которые после падения откатывались на год назад, после чего уже просто умирали. «День» потери данных большинство сообществ переживет безболезненно.
Что касаетя репликации БД, дык обычный master/slave (если боимся что навернется винт основной допустим совсем), восстановление из binlog (если боимся что именно база похерится вдруг почему-то) или innodb (если сервер часто падает).
Что касаетя репликации БД, дык обычный master/slave (если боимся что навернется винт основной допустим совсем), восстановление из binlog (если боимся что именно база похерится вдруг почему-то) или innodb (если сервер часто падает).
WAL (write-ahead log) помогает, если надо совсем-совсем к последней точке восстановиться.
И смысл данного класса, еще и только под PHP 5.3? Ладно бы хоть какую-нибудь web оболочку сделали для настройки этого дела, а так тупо 20 КБ кода, раскиданного по 20 файлам, чтобы сделать тоже самое, что можно сделать shell скриптом на 1,5 десятка строчек.
Может его стоило бы на php 4 написать чтобы он был совместим со всеми серверами? Конечно на 5.3 и только на 5.3. Объяснить почему?
веб обложка, как вы говорите, можно и реализовать, но не является обязательной. Я писал код для себя и он настраивается один раз на сервере и все
веб обложка, как вы говорите, можно и реализовать, но не является обязательной. Я писал код для себя и он настраивается один раз на сервере и все
А Вы ради интереса посмотрите распространённость различных версий PHP. И тогда возможно осознаете, что не поддерживать PHP 5.2 сейчас несколько глупо. Писали бы сразу под PHP 5.4 его уже зарелизили.
Это Вам настроил и всё (понятное дело, что вам всё просто, так как делали под себя), а тот кто ваш скрипт впервые увидел, еще нужно разобраться, что и как настраивается.
Да и кстати, Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip? Ну и потом, чисто любопытно на каких размерах Вы его тестировали?
Я писал код для себя и он настраивается один раз на сервере и все
Это Вам настроил и всё (понятное дело, что вам всё просто, так как делали под себя), а тот кто ваш скрипт впервые увидел, еще нужно разобраться, что и как настраивается.
Да и кстати, Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip? Ну и потом, чисто любопытно на каких размерах Вы его тестировали?
Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip
Не принципиально, хотя вы правы, действительно можно так сделать (поправлю)
Ну и потом, чисто любопытно на каких размерах Вы его тестировали?
2 базы (одна большая — около 2 Гб) + 2 директории, в сумме в архиве около 500Мб
На самом деле еще как принципиально, так как если у вас будет занято половина места на хостинге, то бэкап уже не сделаешь.
По файлам интереснее количество файлов, а не размер, так как один 500 МБ файл обрабатывается, значительно быстрее, чем несколько тысяч маленьких. И сколько времени на это уходило. Как быть с ограничением времени на выполнение скрипта?
По файлам интереснее количество файлов, а не размер, так как один 500 МБ файл обрабатывается, значительно быстрее, чем несколько тысяч маленьких. И сколько времени на это уходило. Как быть с ограничением времени на выполнение скрипта?
Около 20 минут уходит на все про все (в основном это заливка на фтп). Да, кстати время скрипта можно ограничить, нужно в example добавить set_time_limit. хм, или в конфиг вынести, вдруг захочется веб интерфейс сделать )
Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip
Исправил, спасибо за подсказку
А Вы ради интереса посмотрите распространённость различных версий PHP. И тогда возможно осознаете, что не поддерживать PHP 5.2 сейчас несколько глупо
Писал не для кого-то, а для себя, поэтому не использовать всей прелести пхп 5.3 я не мог себе позволить. Более того считаю, что нужно как можно быстрее уже переходить на namespace-ы и отказываться быстрее от старых версий.
У мня так:
сайты в ~/www (1 директория — 1 сайт, например ~/www/site.ru )
Соответственно в
сайты в ~/www (1 директория — 1 сайт, например ~/www/site.ru )
#!/bin/bash
USER="root"
PASSWORD="a6GAVMnu7BNYvfAR"
mkdir -p /backup/`date +%F`/db
for DB in `mysql -u$USER -p$PASSWORD -N -e 'show databases' | grep -v information_schema | grep -v mysql | awk '{print $1}'`; do
mysqldump --user=$USER --host=$HOST --password=$PASSWORD ${DB} | gzip > /backup/`date +%F`/db/${DB}.sql.gz;
echo "${DB} Backup";
done;
cd /home/oleg/www;
for DOMAIN in `ls | cut -f 1`; do
tar czf /backup/`date +%F`/$DOMAIN.tar.gz $DOMAIN;
for LOGFILE in `ls $DOMAIN/log/*.log | cut -f 1`; do
echo "" > $LOGFILE;
done;
echo "${DOMAIN} Backup"
done;
tmpwatch -m 1d /backup/
Соответственно в
ой, не дописал )
Соответственно в /backup/ лежит так
/backup/2012-01-03/
/backup/2012-01-04/
и тд
Внутри директорий-дат лежат отдельные архивы каждого сайта, а в директории
/backup/2012-01-04/db
лежат отдельные архивы каждой базы.
Старые бекапы удаляются через tmpwatch
P.S. засветил пароль от базы, уже сменил, но снаружи все равно доступ закрыт.
Соответственно в /backup/ лежит так
/backup/2012-01-03/
/backup/2012-01-04/
и тд
Внутри директорий-дат лежат отдельные архивы каждого сайта, а в директории
/backup/2012-01-04/db
лежат отдельные архивы каждой базы.
Старые бекапы удаляются через tmpwatch
P.S. засветил пароль от базы, уже сменил, но снаружи все равно доступ закрыт.
Ну это совсем все просто, может для простых ситуаций это и подойдет, но для для серьезных целей
Вроде тоже самое, что и у вас, за исключением заливки по фтп (можно доделать, но я подумываю запустить на сервере дробокс и сливать дампы туда).
ну помимо заливки по фтп, есть еще и другое, к примеру
— создавать не только ежедневные бэкапы, но и недельные, месячные, годовые (причем каждый может иметь свое количество бэкапов)
— игнорировать не нужные папки и файлы (tmp, cache, logs...), причем для каждого проекта они могут быть разными
— игнорировать таблицы или более того импортировать только структуру без дынных
— информирование по email с подробный отчетом о проделанной работе
— более простая настройка (стоит только подредактировать файл конфига и не лезть в код)
— расширяемость (легко дописать что-то свое, к примеру — информирование по sms при неудачном бэкапе, заливку по ссш, веб интерфейс для настроек и т.д.) ведь у любого может найтись то, чего не хватает именно ему
— создавать не только ежедневные бэкапы, но и недельные, месячные, годовые (причем каждый может иметь свое количество бэкапов)
— игнорировать не нужные папки и файлы (tmp, cache, logs...), причем для каждого проекта они могут быть разными
— игнорировать таблицы или более того импортировать только структуру без дынных
— информирование по email с подробный отчетом о проделанной работе
— более простая настройка (стоит только подредактировать файл конфига и не лезть в код)
— расширяемость (легко дописать что-то свое, к примеру — информирование по sms при неудачном бэкапе, заливку по ссш, веб интерфейс для настроек и т.д.) ведь у любого может найтись то, чего не хватает именно ему
Этот гем решит все ваши проблемы с бекапами
github.com/meskyanichi/backup
github.com/meskyanichi/backup
Чтобы всем этим хозяйством пользоваться нужно exec() включенный иметь, такого позволить себе не могу (и не хочу).
exec()?
Можно ногу себе отстрелить, а так все хорошо.
Можно ногу себе отстрелить, а так все хорошо.
:) да, есть такое дело. но т.к. конфиг настраивает админ, то и навредить как-то серверу тоже не выйдет (по крайней мере не могу догадаться как)
ну не знаю как кто а я себе пару раз ногу отстреливал :)
было бы не плохо, если бы вы отстрелили бы мне одну ногу, я вторую бы уже защитил :) иными словами — чем больше возможный атак сейчас найдется, тем быстрее я смогу их исправить, поэтому если есть желание можете указать мне на дыры и я их быстренько прикрою
exec() сам по себе дыра.
Бэкап mysql например можно и него делать.
Берем например вот этот скрипт.
Заменяем addslashes/ereg_replace на mysql_escape_string, получаем более-менее нормальное экранирование.
Меняем порядок в скрипте (сначала должно выполнять создание таблиц — затем создание констрэинтов — затем наполнение данными).
Меняем порядок записи в файл- пишем не гигансткую строку сразу а блоками по мере чтения по 1000-2000 записей из таблиц (базка может быть большой, а оперативки на сервере не так много).
Получаем вполне себе вменяемый бэкап mysql.
Бэкап mysql например можно и него делать.
Берем например вот этот скрипт.
Заменяем addslashes/ereg_replace на mysql_escape_string, получаем более-менее нормальное экранирование.
Меняем порядок в скрипте (сначала должно выполнять создание таблиц — затем создание констрэинтов — затем наполнение данными).
Меняем порядок записи в файл- пишем не гигансткую строку сразу а блоками по мере чтения по 1000-2000 записей из таблиц (базка может быть большой, а оперативки на сервере не так много).
Получаем вполне себе вменяемый бэкап mysql.
да, но mysqldump именно для бэкапа бд предназначен, зачем же изобретать велосипед снова? можно просто убрать уязвимости (если они есть) в его использовании
А за такие советы нужно бить по рукам… В бэкапе есть куча MySQL нюансов. И уж лучше пусть юзают mysqldump, чем подобные примитивные самописки…
Ну дак прежде чем по рукам бить и минусовать — может расскажете все таки про нюансы? :)
К слову phpMyAdmin, Sypex Dumper и т.д. создают полностью корректный бэкап без использования exec() и прочей небезопасной ереси.
Опять таки почитать код этих продуктов думаю никто не запретит. Я же здесь привел скрипт и подсказал в какую строну его модифицировать для получения полноценного.
К слову phpMyAdmin, Sypex Dumper и т.д. создают полностью корректный бэкап без использования exec() и прочей небезопасной ереси.
Опять таки почитать код этих продуктов думаю никто не запретит. Я же здесь привел скрипт и подсказал в какую строну его модифицировать для получения полноценного.
Ну если Вы не заметили, я как бы автор Sypex Dumper, но при этом я им занимаюсь уже около 8 лет, так что имею некоторое представление о нюансах.
Просто очень часто приходится помогать пользователям которые делали бэкапы вот такими вот самодельными бэкаперами.
Что касается нюансов, ну начать можно с кодировки соединения, которой тут не пахнет, продолжить тем, что SHOW TABLES выдает не только таблицы, но и представления (которые нужно бэкапить совсем по другому). Продолжим DROP TABLE без IF EXISTS, что будет выдавать ошибку при попытке восстановить в чистую базу. Не говоря уже о не совсем правильном и быстром собирании строк, использовании инсерта для каждой записи, использовании буферизированного mysql_query, про всякие индексы, блокирование таблиц автор естественно не слышал.
Т.е. да на уровне примера, показать, как в общих чертах работает бэкап MySQL скрипт сойдет, но советовать его применять в реальном проекте, мягко говоря не рационально.
Просто очень часто приходится помогать пользователям которые делали бэкапы вот такими вот самодельными бэкаперами.
Что касается нюансов, ну начать можно с кодировки соединения, которой тут не пахнет, продолжить тем, что SHOW TABLES выдает не только таблицы, но и представления (которые нужно бэкапить совсем по другому). Продолжим DROP TABLE без IF EXISTS, что будет выдавать ошибку при попытке восстановить в чистую базу. Не говоря уже о не совсем правильном и быстром собирании строк, использовании инсерта для каждой записи, использовании буферизированного mysql_query, про всякие индексы, блокирование таблиц автор естественно не слышал.
Т.е. да на уровне примера, показать, как в общих чертах работает бэкап MySQL скрипт сойдет, но советовать его применять в реальном проекте, мягко говоря не рационально.
Ну а мне ни раз и ни два приходилось ходить по остаткам серверов, на которых по тем или иным причинам работали exec(), бэктики и т.д. :)
К тому же я нигде не утверждал что «вот он законченный полноценный скрипт на все времена для бэкапа mysql». Я лишь привел автору аргументы в пользу того что можно при должном желании обойтись и без разрешения выполнения небезопасных функций. И привел в пример скрипта, который на 80-90% существующих базок mysql будет успешно работать. Ну а чтобы доработать до полноценного, ему понадобится сколько, 8 лет? :)
За нюансы вам спасибо. Возможно автор обратит внимание на них, и усовершенствует скрипт. Возможно постигнет нюансы и напишет не только качественный, но и безопасный бэкапер. Или нет.
Возможно не будет заниматься этим, и будет активно продвигать exec().
Забавно, что в таком случае mysqldump с различными опциями сходу решит значительную часть того, чем вы занимались 8 лет.
К тому же я нигде не утверждал что «вот он законченный полноценный скрипт на все времена для бэкапа mysql». Я лишь привел автору аргументы в пользу того что можно при должном желании обойтись и без разрешения выполнения небезопасных функций. И привел в пример скрипта, который на 80-90% существующих базок mysql будет успешно работать. Ну а чтобы доработать до полноценного, ему понадобится сколько, 8 лет? :)
За нюансы вам спасибо. Возможно автор обратит внимание на них, и усовершенствует скрипт. Возможно постигнет нюансы и напишет не только качественный, но и безопасный бэкапер. Или нет.
Возможно не будет заниматься этим, и будет активно продвигать exec().
Забавно, что в таком случае mysqldump с различными опциями сходу решит значительную часть того, чем вы занимались 8 лет.
mysqldump тоже за время своего существования дописывался и переписывался или вы думаете там багов не бывает? :)
Некоторые вещи тот же дампер делает значительно лучше mysqldump. В версии 2 там вообще несколько другой подход к бэкапу, который существенно отличается от того что делает mysqldump. Я об этом писал в статье про Умный бэкап.
Вообще я сейчас как раз делаю аналог дампера, но для файлов, потому и зашел данную статью почитать. Но как оказалось, это совсем не то. В моем случае будет Pure PHP решение, и никаких консольных tar'ов. И задачи решаются поинтересней, инкрементальный/дифференциальный бэкап с шифрованием и заливкой на облачные файлохранилища, версионирование, возможность быстрого восстановление отдельных файлов и другие.
Некоторые вещи тот же дампер делает значительно лучше mysqldump. В версии 2 там вообще несколько другой подход к бэкапу, который существенно отличается от того что делает mysqldump. Я об этом писал в статье про Умный бэкап.
Вообще я сейчас как раз делаю аналог дампера, но для файлов, потому и зашел данную статью почитать. Но как оказалось, это совсем не то. В моем случае будет Pure PHP решение, и никаких консольных tar'ов. И задачи решаются поинтересней, инкрементальный/дифференциальный бэкап с шифрованием и заливкой на облачные файлохранилища, версионирование, возможность быстрого восстановление отдельных файлов и другие.
Ну зачем же такой страшный конфиг делать?
Реквестую .ini, YAML или XML! :)
Реквестую .ini, YAML или XML! :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервное копирование файлов и баз данных