Элементарные PHP скрипты для резервного копирования данных

[@Snick]

1. Вместо #/usr/local/bin/php кошерно #!env php — ведь кто его знает где именно установлена консольная версия php
2. Крон ребутить не нужно
3. Посмотрел статью про баш — тут те же яйца, только в профиль. Отличия: там один файл, а тут два; там bash, а тут php
4. Глупо/не глупо — зависит от задачи
5. Эксклюдить svn — это лол. Попробуйте выполнить svn help export

А по поводу mysql — какая задача по бэкапу базы стоит? Если некритичный дамп небольшой базы чтобы неспешно раскидать по разработчикам, тогда ок. Но если РЕАЛЬНО важный бэкап, то лучше редкого снепшота mysqldump'ом и более частых копий бинарных логов еще ничего не придумали.

[@mobilz]

за #!env php спасибо, встречаю впервые.

[@mobilz]

у меня для env все равно нужно прописывать полный путь. Пусть в статье останется как есть, по крайней мере это привычная запись и при ошибках каждый сможет поправить на свой путь.

[@mobilz]

не знаю как у вас, у меня крон ребутить приходится. По поводу статьи на баше это вы зря. Там один файл на один проект. у меня один файл на все базы, и еще один на все www. Допустим, вы можете использовать одну из этих двух статей и имеете 10+ проектов. Вы готовы писать писать конфиг для всех проектов отдельный? Или бэкапить все в один файл? Задачи согласен разные. Но обычная — сделать бэкап проектов, редко проект один. А svn файлы не являются мусором лишь в том случае, когда нужно полностью восстановить исходники и статику. С таким я еще не встречался. Даже если нужно восстановить всю статику, чего у меня никогда не было, ни на одном проекте не зависимо от размера, проще из архива восстановить только статику, а исходники все равно есть в svn. Зачем мусорить бэкапы ими?
По поводу бинарников тоже не соглашусь. Большие проекты соответственно master-slave и данные могут потеряться только в исключительных случаях, но иметь дамп достаточно важно. Именно в текстовом виде, а не в виде бинарного лога.

[@Snick]

/usr/bin/env — путь один и тот же на любом юниксе от маков до netbsd.

ни тот ни этот скрипты я использовать не буду, потому что от проекта к проекту сильно меняются как структура каталогов, так и базы. Как минимум если у меня будет pgsql, то эти скрипты мне не подойдут. Но для файлов я буду пользоваться rsync.

svn export нужно использовать потому что в .svn хранится практически копия рабочей копии и при (не дай бог) уничтожении репозитория эта информация никак не поможет его восстановить, но место в архиве занимать будет.

Бинарные логи нужно бэкапить потому что это единственный способ восстановить базу данных до состояния максимально близкого к моменту ее падения. Есть такое выражение «накатить транзакционный лог» — первый шаг по восстановлению данных после серьезного падения сервера бд.

[@darkk]

Не на любом, но на почти любом. Видал один раз в жизни машину, где env был в /bin, а не в /usr/bin. Но, подчеркну, это было один раз в жизни :-)

[@Snick]

Ах да! По поводу крона.

$ crontab -u USERNAME -e

И все.

[@walker]

cron не требует релоада.

[@walker]

не знаю, кому может пригодится этот очередной велосипед…
я понимаю, автор получил фан, написал сабж, но может быть стоило лучше разобраться в существующих универсальных системах бекапа? (тот же рсинк или rdup)

да и писать системные скрипты на php — это моветон и непереносимость как минимум.
у меня на некоторых серверах вобще нет php и ставить не собираюсь, а rsync,bash,tar есть.

[@mobilz]

rsync??? у меня есть проект, который умещается в gzip под 10 гигов, и переносится в течении нескольких часов, но при этом в нем огромное количество файлов и rsync работает над ним пару суток. Да и потом это системные скрипты для бэкапа проектов. У вас много проектов не на php? тогда на чем они? Повторю, это ЭЛЕМЕНТАРНЫЕ скрипты, перенести их на другой язык программирования элементарно. К сожалиню bash не имеет api для работы с mysql, например. моветон — брать си бимоль 3-ей актавы не имея слуха. А данный пример комильфо для веб-проектов.

[@walker]

rsync пару суток? о_О

в bash нет API для mysql? О_о:

вы не осилили mysqlshow и mysql -e «command»?

[@keymone]

порадовала фраза «У вас много проектов не на php? тогда на чем они?»
а вы что кроме PHP знаете если не секрет?

[@walker]

и такой банальной вещи как инкремента у вас нет.
у меня базы мускуля по 10 гигов+куча веб контента на 50 гигов — предлагаете мне все это дело пропускать через gzip? :))
а такие вещи как же ionice+nice?

вобщем, посмотрите лучше в сторону duplicity — не идеал, но все выше озвученные мной фичи есть (+ есть в стандартных репах и легко сетапится)

[@mobilz]

На одном из проектов база в 2 гига выбирается дольше, чем гзипится. на порядок. Обе операции укладываются в пару минут. А контента у меня там пару теров. И все это дело гзипится и переносится куда быстрее, чем юзать rsync. Раз в неделю можно позволить.
Повторю, ни раз еще данные скрипты не подводили.

[@walker]

1.вы не учитываете CPU и IO нагрузку.
2.решение наколеночное и я не вижу ни одной причины его использовать
3.нет инкремента
4.php (вы еще VB возьмите)
5.зачем-то всунули .svn +жестко зашитые пути в скрипте — в итоге, любой, кто захочет заюзать ваш скрипт перепишет его заново по сути.

[@IntenT]

Глупо делать необоснованные заявления, и называть что-то глупостью, не зная исходных.

[@coldFlame]

А зачем отдельно бекапить файлы, если они и так под свном лежат? :) тогда уже надо репу бекапить, ну и всякие загруженные пользователями файлы

[@zupernintendo]

улыбнули слова про гибкость 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);

[@Dreadatour]

ИМХО, дату лучше записывать наоборот — YYYY-MM-DD…
Ну и да. Системные скрипты на PHP — это моветон.