Comments 60
Приятно смотреть, когда смотря на код понимаешь «что и как» с первого взгляда =)
+2
Меня умиляют пхпшники. Уже давным-давно есть куча проверенных средств с внушительным функционалом для… да для чего угодно, для бэкапов тех же, а они с завидным упорством продолжают делать велосипеды.
+9
Да не, смысл в бакапах на php есть, для ряда ситуаций. На вирт.хостингах, например, это вполне себе востребованная задача.
Решение ТС несколько убивает тем, что для бакапа базы запускается mysqldump, например… если есть доступ к консоли, то php действительно на фиг не нужен. А если нет доступа, то php решение должно работать без доступа.
Решение ТС несколько убивает тем, что для бакапа базы запускается mysqldump, например… если есть доступ к консоли, то php действительно на фиг не нужен. А если нет доступа, то php решение должно работать без доступа.
+1
Можете привести примеры таких средств, которые бы удовлетворяли всем требованиям:
— бэкапить директории и базы данных
— загрузка архивов в локальную папку или на фтп
— информирование по email о удачном/не удачном завершении
Именно всем, и именно бесплатное. Я искал, но все не то, что нужно. Где-то обязательно что-то не так как хочется или нужно платить
— бэкапить директории и базы данных
— загрузка архивов в локальную папку или на фтп
— информирование по email о удачном/не удачном завершении
Именно всем, и именно бесплатное. Я искал, но все не то, что нужно. Где-то обязательно что-то не так как хочется или нужно платить
-2
bacula, не?
0
Вот я давно писал на habrahabr.ru/post/121120/
Есть версия и с почтовыми уведомлениями и заливкой по ssh. У меня грузится сразу в dropbox, поэтому почту себе не спамлю — и так видно, появился ли архив на компе, или нет.
Если есть интерес — могу поделиться.
Есть версия и с почтовыми уведомлениями и заливкой по ssh. У меня грузится сразу в dropbox, поэтому почту себе не спамлю — и так видно, появился ли архив на компе, или нет.
Если есть интерес — могу поделиться.
0
Есть ли смысл бекапа базы данных? Падает форум, сайт, еще что-то… но ведь бекап не спасает информацию полученную между датой бекапа и предполагаемым аварийным случаем. Бекап подходит для редко изменяемых файлов. В случае очень живого форума откат форума на день назад из бекапа практически приравнивается к тому что у вас нет бекапа вообще. Интереснее узнать что делать с репликацией бд в реальном времени.
-1
Лучше откатиться на день, чем на неделю или месяц ;)
+3
абсолютно согласен. Но в случае с базой транзакций валюты эта фишка не сильно выручит)
-1
К базам транзакций валюты велосипедостроителей близко не подпустят:-)
+5
А вы думаете какой-нибудь PayPal будет использовать такой скрипт для бэкапа? :) Как по мне, очевидно, что это для начинающих предназначено. Но для этой целевой аудитории очень востребован web-интерфейс для настройки, так как такого размера конфиг их испугает.
По себе знаю, в моём дампере все настройки делаются через web-интерфейс, по сути там нужно всё выбрать и нажать сохранить. А потом в cron только добавить ссылку на запуск дампера. И тем не менее куча просьб добавить в web-интерфейс настройку расписания (хотя по идее во всех современных панелях управления хостингом и так это делается довольно просто).
По себе знаю, в моём дампере все настройки делаются через web-интерфейс, по сути там нужно всё выбрать и нажать сохранить. А потом в cron только добавить ссылку на запуск дампера. И тем не менее куча просьб добавить в web-интерфейс настройку расписания (хотя по идее во всех современных панелях управления хостингом и так это делается довольно просто).
+3
Лично наблюдали несколько форумов/сайтов конкурентов, которые после падения откатывались на год назад, после чего уже просто умирали. «День» потери данных большинство сообществ переживет безболезненно.
Что касаетя репликации БД, дык обычный master/slave (если боимся что навернется винт основной допустим совсем), восстановление из binlog (если боимся что именно база похерится вдруг почему-то) или innodb (если сервер часто падает).
Что касаетя репликации БД, дык обычный master/slave (если боимся что навернется винт основной допустим совсем), восстановление из binlog (если боимся что именно база похерится вдруг почему-то) или innodb (если сервер часто падает).
0
WAL (write-ahead log) помогает, если надо совсем-совсем к последней точке восстановиться.
0
И смысл данного класса, еще и только под PHP 5.3? Ладно бы хоть какую-нибудь web оболочку сделали для настройки этого дела, а так тупо 20 КБ кода, раскиданного по 20 файлам, чтобы сделать тоже самое, что можно сделать shell скриптом на 1,5 десятка строчек.
+1
Может его стоило бы на php 4 написать чтобы он был совместим со всеми серверами? Конечно на 5.3 и только на 5.3. Объяснить почему?
веб обложка, как вы говорите, можно и реализовать, но не является обязательной. Я писал код для себя и он настраивается один раз на сервере и все
веб обложка, как вы говорите, можно и реализовать, но не является обязательной. Я писал код для себя и он настраивается один раз на сервере и все
0
А Вы ради интереса посмотрите распространённость различных версий PHP. И тогда возможно осознаете, что не поддерживать PHP 5.2 сейчас несколько глупо. Писали бы сразу под PHP 5.4 его уже зарелизили.
Это Вам настроил и всё (понятное дело, что вам всё просто, так как делали под себя), а тот кто ваш скрипт впервые увидел, еще нужно разобраться, что и как настраивается.
Да и кстати, Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip? Ну и потом, чисто любопытно на каких размерах Вы его тестировали?
Я писал код для себя и он настраивается один раз на сервере и все
Это Вам настроил и всё (понятное дело, что вам всё просто, так как делали под себя), а тот кто ваш скрипт впервые увидел, еще нужно разобраться, что и как настраивается.
Да и кстати, Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip? Ну и потом, чисто любопытно на каких размерах Вы его тестировали?
0
Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip
Не принципиально, хотя вы правы, действительно можно так сделать (поправлю)
Ну и потом, чисто любопытно на каких размерах Вы его тестировали?
2 базы (одна большая — около 2 Гб) + 2 директории, в сумме в архиве около 500Мб
0
На самом деле еще как принципиально, так как если у вас будет занято половина места на хостинге, то бэкап уже не сделаешь.
По файлам интереснее количество файлов, а не размер, так как один 500 МБ файл обрабатывается, значительно быстрее, чем несколько тысяч маленьких. И сколько времени на это уходило. Как быть с ограничением времени на выполнение скрипта?
По файлам интереснее количество файлов, а не размер, так как один 500 МБ файл обрабатывается, значительно быстрее, чем несколько тысяч маленьких. И сколько времени на это уходило. Как быть с ограничением времени на выполнение скрипта?
0
Около 20 минут уходит на все про все (в основном это заливка на фтп). Да, кстати время скрипта можно ограничить, нужно в example добавить set_time_limit. хм, или в конфиг вынести, вдруг захочется веб интерфейс сделать )
0
Вы сначала всё закидываете в tar, потом сжимаете его. Зачем, если tar и сам умеет сжимать в gzip
Исправил, спасибо за подсказку
0
А Вы ради интереса посмотрите распространённость различных версий PHP. И тогда возможно осознаете, что не поддерживать PHP 5.2 сейчас несколько глупо
Писал не для кого-то, а для себя, поэтому не использовать всей прелести пхп 5.3 я не мог себе позволить. Более того считаю, что нужно как можно быстрее уже переходить на namespace-ы и отказываться быстрее от старых версий.
0
namespace-ы ничего принципиально не меняют, это можно сказать только дополнительные удобства, так что вполне можно было бы и откатиться для публичной версии.
0
У мня так:
сайты в ~/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/
Соответственно в
+1
ой, не дописал )
Соответственно в /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. засветил пароль от базы, уже сменил, но снаружи все равно доступ закрыт.
+1
Ну это совсем все просто, может для простых ситуаций это и подойдет, но для для серьезных целей
0
Вроде тоже самое, что и у вас, за исключением заливки по фтп (можно доделать, но я подумываю запустить на сервере дробокс и сливать дампы туда).
+1
ну помимо заливки по фтп, есть еще и другое, к примеру
— создавать не только ежедневные бэкапы, но и недельные, месячные, годовые (причем каждый может иметь свое количество бэкапов)
— игнорировать не нужные папки и файлы (tmp, cache, logs...), причем для каждого проекта они могут быть разными
— игнорировать таблицы или более того импортировать только структуру без дынных
— информирование по email с подробный отчетом о проделанной работе
— более простая настройка (стоит только подредактировать файл конфига и не лезть в код)
— расширяемость (легко дописать что-то свое, к примеру — информирование по sms при неудачном бэкапе, заливку по ссш, веб интерфейс для настроек и т.д.) ведь у любого может найтись то, чего не хватает именно ему
— создавать не только ежедневные бэкапы, но и недельные, месячные, годовые (причем каждый может иметь свое количество бэкапов)
— игнорировать не нужные папки и файлы (tmp, cache, logs...), причем для каждого проекта они могут быть разными
— игнорировать таблицы или более того импортировать только структуру без дынных
— информирование по email с подробный отчетом о проделанной работе
— более простая настройка (стоит только подредактировать файл конфига и не лезть в код)
— расширяемость (легко дописать что-то свое, к примеру — информирование по sms при неудачном бэкапе, заливку по ссш, веб интерфейс для настроек и т.д.) ведь у любого может найтись то, чего не хватает именно ему
0
Этот гем решит все ваши проблемы с бекапами
github.com/meskyanichi/backup
github.com/meskyanichi/backup
-3
Чтобы всем этим хозяйством пользоваться нужно exec() включенный иметь, такого позволить себе не могу (и не хочу).
0
exec()?
Можно ногу себе отстрелить, а так все хорошо.
Можно ногу себе отстрелить, а так все хорошо.
-1
:) да, есть такое дело. но т.к. конфиг настраивает админ, то и навредить как-то серверу тоже не выйдет (по крайней мере не могу догадаться как)
0
ну не знаю как кто а я себе пару раз ногу отстреливал :)
-1
было бы не плохо, если бы вы отстрелили бы мне одну ногу, я вторую бы уже защитил :) иными словами — чем больше возможный атак сейчас найдется, тем быстрее я смогу их исправить, поэтому если есть желание можете указать мне на дыры и я их быстренько прикрою
0
exec() сам по себе дыра.
Бэкап mysql например можно и него делать.
Берем например вот этот скрипт.
Заменяем addslashes/ereg_replace на mysql_escape_string, получаем более-менее нормальное экранирование.
Меняем порядок в скрипте (сначала должно выполнять создание таблиц — затем создание констрэинтов — затем наполнение данными).
Меняем порядок записи в файл- пишем не гигансткую строку сразу а блоками по мере чтения по 1000-2000 записей из таблиц (базка может быть большой, а оперативки на сервере не так много).
Получаем вполне себе вменяемый бэкап mysql.
Бэкап mysql например можно и него делать.
Берем например вот этот скрипт.
Заменяем addslashes/ereg_replace на mysql_escape_string, получаем более-менее нормальное экранирование.
Меняем порядок в скрипте (сначала должно выполнять создание таблиц — затем создание констрэинтов — затем наполнение данными).
Меняем порядок записи в файл- пишем не гигансткую строку сразу а блоками по мере чтения по 1000-2000 записей из таблиц (базка может быть большой, а оперативки на сервере не так много).
Получаем вполне себе вменяемый бэкап mysql.
-1
да, но mysqldump именно для бэкапа бд предназначен, зачем же изобретать велосипед снова? можно просто убрать уязвимости (если они есть) в его использовании
0
А за такие советы нужно бить по рукам… В бэкапе есть куча MySQL нюансов. И уж лучше пусть юзают mysqldump, чем подобные примитивные самописки…
0
Ну дак прежде чем по рукам бить и минусовать — может расскажете все таки про нюансы? :)
К слову phpMyAdmin, Sypex Dumper и т.д. создают полностью корректный бэкап без использования exec() и прочей небезопасной ереси.
Опять таки почитать код этих продуктов думаю никто не запретит. Я же здесь привел скрипт и подсказал в какую строну его модифицировать для получения полноценного.
К слову phpMyAdmin, Sypex Dumper и т.д. создают полностью корректный бэкап без использования exec() и прочей небезопасной ереси.
Опять таки почитать код этих продуктов думаю никто не запретит. Я же здесь привел скрипт и подсказал в какую строну его модифицировать для получения полноценного.
0
Ну если Вы не заметили, я как бы автор Sypex Dumper, но при этом я им занимаюсь уже около 8 лет, так что имею некоторое представление о нюансах.
Просто очень часто приходится помогать пользователям которые делали бэкапы вот такими вот самодельными бэкаперами.
Что касается нюансов, ну начать можно с кодировки соединения, которой тут не пахнет, продолжить тем, что SHOW TABLES выдает не только таблицы, но и представления (которые нужно бэкапить совсем по другому). Продолжим DROP TABLE без IF EXISTS, что будет выдавать ошибку при попытке восстановить в чистую базу. Не говоря уже о не совсем правильном и быстром собирании строк, использовании инсерта для каждой записи, использовании буферизированного mysql_query, про всякие индексы, блокирование таблиц автор естественно не слышал.
Т.е. да на уровне примера, показать, как в общих чертах работает бэкап MySQL скрипт сойдет, но советовать его применять в реальном проекте, мягко говоря не рационально.
Просто очень часто приходится помогать пользователям которые делали бэкапы вот такими вот самодельными бэкаперами.
Что касается нюансов, ну начать можно с кодировки соединения, которой тут не пахнет, продолжить тем, что SHOW TABLES выдает не только таблицы, но и представления (которые нужно бэкапить совсем по другому). Продолжим DROP TABLE без IF EXISTS, что будет выдавать ошибку при попытке восстановить в чистую базу. Не говоря уже о не совсем правильном и быстром собирании строк, использовании инсерта для каждой записи, использовании буферизированного mysql_query, про всякие индексы, блокирование таблиц автор естественно не слышал.
Т.е. да на уровне примера, показать, как в общих чертах работает бэкап MySQL скрипт сойдет, но советовать его применять в реальном проекте, мягко говоря не рационально.
+1
Ну а мне ни раз и ни два приходилось ходить по остаткам серверов, на которых по тем или иным причинам работали exec(), бэктики и т.д. :)
К тому же я нигде не утверждал что «вот он законченный полноценный скрипт на все времена для бэкапа mysql». Я лишь привел автору аргументы в пользу того что можно при должном желании обойтись и без разрешения выполнения небезопасных функций. И привел в пример скрипта, который на 80-90% существующих базок mysql будет успешно работать. Ну а чтобы доработать до полноценного, ему понадобится сколько, 8 лет? :)
За нюансы вам спасибо. Возможно автор обратит внимание на них, и усовершенствует скрипт. Возможно постигнет нюансы и напишет не только качественный, но и безопасный бэкапер. Или нет.
Возможно не будет заниматься этим, и будет активно продвигать exec().
Забавно, что в таком случае mysqldump с различными опциями сходу решит значительную часть того, чем вы занимались 8 лет.
К тому же я нигде не утверждал что «вот он законченный полноценный скрипт на все времена для бэкапа mysql». Я лишь привел автору аргументы в пользу того что можно при должном желании обойтись и без разрешения выполнения небезопасных функций. И привел в пример скрипта, который на 80-90% существующих базок mysql будет успешно работать. Ну а чтобы доработать до полноценного, ему понадобится сколько, 8 лет? :)
За нюансы вам спасибо. Возможно автор обратит внимание на них, и усовершенствует скрипт. Возможно постигнет нюансы и напишет не только качественный, но и безопасный бэкапер. Или нет.
Возможно не будет заниматься этим, и будет активно продвигать exec().
Забавно, что в таком случае mysqldump с различными опциями сходу решит значительную часть того, чем вы занимались 8 лет.
-1
mysqldump тоже за время своего существования дописывался и переписывался или вы думаете там багов не бывает? :)
Некоторые вещи тот же дампер делает значительно лучше mysqldump. В версии 2 там вообще несколько другой подход к бэкапу, который существенно отличается от того что делает mysqldump. Я об этом писал в статье про Умный бэкап.
Вообще я сейчас как раз делаю аналог дампера, но для файлов, потому и зашел данную статью почитать. Но как оказалось, это совсем не то. В моем случае будет Pure PHP решение, и никаких консольных tar'ов. И задачи решаются поинтересней, инкрементальный/дифференциальный бэкап с шифрованием и заливкой на облачные файлохранилища, версионирование, возможность быстрого восстановление отдельных файлов и другие.
Некоторые вещи тот же дампер делает значительно лучше mysqldump. В версии 2 там вообще несколько другой подход к бэкапу, который существенно отличается от того что делает mysqldump. Я об этом писал в статье про Умный бэкап.
Вообще я сейчас как раз делаю аналог дампера, но для файлов, потому и зашел данную статью почитать. Но как оказалось, это совсем не то. В моем случае будет Pure PHP решение, и никаких консольных tar'ов. И задачи решаются поинтересней, инкрементальный/дифференциальный бэкап с шифрованием и заливкой на облачные файлохранилища, версионирование, возможность быстрого восстановление отдельных файлов и другие.
0
UFO just landed and posted this here
Ну зачем же такой страшный конфиг делать?
Реквестую .ini, YAML или XML! :)
Реквестую .ini, YAML или XML! :)
0
Ничего плохохо не вижу в php конфиге (удобней с ним работать мне), но как вариант можно и другой тип реализовать. Как я уже говорил выше, всем не угодишь и каждый может для себя расширить функционал. Но спасибо за предложение, возможно реализую и это немного позже
0
Sign up to leave a comment.
Резервное копирование файлов и баз данных