Комментарии 19
1. Вместо
2. Крон ребутить не нужно
3. Посмотрел статью про баш — тут те же яйца, только в профиль. Отличия: там один файл, а тут два; там bash, а тут php
4. Глупо/не глупо — зависит от задачи
5. Эксклюдить svn — это лол. Попробуйте выполнить
А по поводу mysql — какая задача по бэкапу базы стоит? Если некритичный дамп небольшой базы чтобы неспешно раскидать по разработчикам, тогда ок. Но если РЕАЛЬНО важный бэкап, то лучше редкого снепшота mysqldump'ом и более частых копий бинарных логов еще ничего не придумали.
#/usr/local/bin/php кошерно #!env php — ведь кто его знает где именно установлена консольная версия php2. Крон ребутить не нужно
3. Посмотрел статью про баш — тут те же яйца, только в профиль. Отличия: там один файл, а тут два; там bash, а тут php
4. Глупо/не глупо — зависит от задачи
5. Эксклюдить svn — это лол. Попробуйте выполнить
svn help exportА по поводу mysql — какая задача по бэкапу базы стоит? Если некритичный дамп небольшой базы чтобы неспешно раскидать по разработчикам, тогда ок. Но если РЕАЛЬНО важный бэкап, то лучше редкого снепшота mysqldump'ом и более частых копий бинарных логов еще ничего не придумали.
за #!env php спасибо, встречаю впервые.
не знаю как у вас, у меня крон ребутить приходится. По поводу статьи на баше это вы зря. Там один файл на один проект. у меня один файл на все базы, и еще один на все www. Допустим, вы можете использовать одну из этих двух статей и имеете 10+ проектов. Вы готовы писать писать конфиг для всех проектов отдельный? Или бэкапить все в один файл? Задачи согласен разные. Но обычная — сделать бэкап проектов, редко проект один. А svn файлы не являются мусором лишь в том случае, когда нужно полностью восстановить исходники и статику. С таким я еще не встречался. Даже если нужно восстановить всю статику, чего у меня никогда не было, ни на одном проекте не зависимо от размера, проще из архива восстановить только статику, а исходники все равно есть в svn. Зачем мусорить бэкапы ими?
По поводу бинарников тоже не соглашусь. Большие проекты соответственно master-slave и данные могут потеряться только в исключительных случаях, но иметь дамп достаточно важно. Именно в текстовом виде, а не в виде бинарного лога.
По поводу бинарников тоже не соглашусь. Большие проекты соответственно master-slave и данные могут потеряться только в исключительных случаях, но иметь дамп достаточно важно. Именно в текстовом виде, а не в виде бинарного лога.
/usr/bin/env — путь один и тот же на любом юниксе от маков до netbsd.ни тот ни этот скрипты я использовать не буду, потому что от проекта к проекту сильно меняются как структура каталогов, так и базы. Как минимум если у меня будет pgsql, то эти скрипты мне не подойдут. Но для файлов я буду пользоваться rsync.
svn export нужно использовать потому что в .svn хранится практически копия рабочей копии и при (не дай бог) уничтожении репозитория эта информация никак не поможет его восстановить, но место в архиве занимать будет.Бинарные логи нужно бэкапить потому что это единственный способ восстановить базу данных до состояния максимально близкого к моменту ее падения. Есть такое выражение «накатить транзакционный лог» — первый шаг по восстановлению данных после серьезного падения сервера бд.
Ах да! По поводу крона.
И все.
$ crontab -u USERNAME -e
И все.
cron не требует релоада.
не знаю, кому может пригодится этот очередной велосипед…
я понимаю, автор получил фан, написал сабж, но может быть стоило лучше разобраться в существующих универсальных системах бекапа? (тот же рсинк или rdup)
да и писать системные скрипты на php — это моветон и непереносимость как минимум.
у меня на некоторых серверах вобще нет php и ставить не собираюсь, а rsync,bash,tar есть.
я понимаю, автор получил фан, написал сабж, но может быть стоило лучше разобраться в существующих универсальных системах бекапа? (тот же рсинк или rdup)
да и писать системные скрипты на php — это моветон и непереносимость как минимум.
у меня на некоторых серверах вобще нет php и ставить не собираюсь, а rsync,bash,tar есть.
rsync??? у меня есть проект, который умещается в gzip под 10 гигов, и переносится в течении нескольких часов, но при этом в нем огромное количество файлов и rsync работает над ним пару суток. Да и потом это системные скрипты для бэкапа проектов. У вас много проектов не на php? тогда на чем они? Повторю, это ЭЛЕМЕНТАРНЫЕ скрипты, перенести их на другой язык программирования элементарно. К сожалиню bash не имеет api для работы с mysql, например. моветон — брать си бимоль 3-ей актавы не имея слуха. А данный пример комильфо для веб-проектов.
и такой банальной вещи как инкремента у вас нет.
у меня базы мускуля по 10 гигов+куча веб контента на 50 гигов — предлагаете мне все это дело пропускать через gzip? :))
а такие вещи как же ionice+nice?
вобщем, посмотрите лучше в сторону duplicity — не идеал, но все выше озвученные мной фичи есть (+ есть в стандартных репах и легко сетапится)
у меня базы мускуля по 10 гигов+куча веб контента на 50 гигов — предлагаете мне все это дело пропускать через gzip? :))
а такие вещи как же ionice+nice?
вобщем, посмотрите лучше в сторону duplicity — не идеал, но все выше озвученные мной фичи есть (+ есть в стандартных репах и легко сетапится)
На одном из проектов база в 2 гига выбирается дольше, чем гзипится. на порядок. Обе операции укладываются в пару минут. А контента у меня там пару теров. И все это дело гзипится и переносится куда быстрее, чем юзать rsync. Раз в неделю можно позволить.
Повторю, ни раз еще данные скрипты не подводили.
Повторю, ни раз еще данные скрипты не подводили.
Глупо делать необоснованные заявления, и называть что-то глупостью, не зная исходных.
А зачем отдельно бекапить файлы, если они и так под свном лежат? :) тогда уже надо репу бекапить, ну и всякие загруженные пользователями файлы
улыбнули слова про гибкость php по сравнению с bash и вот эти строки
>>> system('mkdir -p /usr/backup/mysql/'.date('d.m.Y').'/');
>>> exec('tar cpzvf /usr/backup/www/'.date('d.m.Y').'/'.$file.'.tar.gz --exclude=*.log* --exclude=*.svn* '.$dir.$file);
>>> system('mkdir -p /usr/backup/mysql/'.date('d.m.Y').'/');
>>> exec('tar cpzvf /usr/backup/www/'.date('d.m.Y').'/'.$file.'.tar.gz --exclude=*.log* --exclude=*.svn* '.$dir.$file);
ИМХО, дату лучше записывать наоборот — YYYY-MM-DD…
Ну и да. Системные скрипты на PHP — это моветон.
Ну и да. Системные скрипты на PHP — это моветон.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Элементарные PHP скрипты для резервного копирования данных