Pull to refresh
Comments 48
каких только велосипедов не изобретут, чтобы git не изучать
А медиа файлы вы тоже в git предлагаете хранить?

Исходники надо хранить в системе контроля версий. Тут я с вами полностью согласен. Но если у меня, к примеру, сайт-галлерея, то хранить изображения в git будет неправильно.
Для сайтов визиток ничего страшного. Если сильно напрягают нюансы, то можно тут прочитать как что оптимизировать.
habrahabr.ru/post/173453/
Если у вас сайт-галерея, то хранить изображения в корне вместе с сайтом уже неправильно. А так, ничего криминального в использовании контроля версий на изображения нет. Это конечно большая тайна, но все же: системы контроля версий используют не только для исходного кода.
Залили файл на 200 мегабайт, оказался ненужным, удалили. А репозиторий разбух на эти 200 мегабайт.
Если бы наши дизайнеры удаляли файлы из гита и они действительно исчезали, то наверное их хватила бы кондрашка.
А где вы предлагаете устроить удаленный репозитарий git? К тому же бесплатно, без смс.
Да, но, если я не ошибаюсь у них бесплатого места 1 гиг.

Для исходников это дохрена.

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

да и вообще, как вы предлагаете использовать git для бэкапов продакшн версии сайта со всеми пользовательскими данными и БД?
Что значит «должно»? Моисей взошел на гору, и ему там сказано было «не храни в гите ничего, кроме исходников»?

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

полагаю, что под картинками имеете ввиду аватары пользователей, или какие то другие пользовательские картинки (в противном случае не вижу смысла дискутировать дальше, т.к. в предыдущем комменте говорил именно о пользовательских данных)

как же они попадают в репозиторий? у вас на продакшн сервере при каждой загрузке на сайт этих самих картинок, делается коммит и затем периодически это все пушится на удаленный репозиторий?

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

а с БД вы как поступаете? и ее в git?
Ну в целом примерно так и есть, с некоторыми нюансами. Не при каждой загрузке, разумеется — точно так же, по расписанию. Какой-нибудь фотохостинг я бы не стал так бэкапить, наверное, а магазин/форум/вордпресс/простосайт (т.е. 99.9% сайтов) — почему нет?

Не вижу никакого извращения, честно. Стереотипы — не всегда хорошо.
После того, как у хостера опять случилась проблема, и пришлось восстанавливать бекапы 3-дневной давности, этот способ кажется очень простым и актуальным.
Спасибо за скрипт!
В свете последних событий, было бы неплохо такой же скрипт для стороджа от мейл.ру.
Спасибо за мысль! Обновил топик, немного изменил код, и «добавил поддержку» (нашел нужный адрес) Mail.Ru. Жаль, что не знал об этом, когда писал.
Ничего отправлять в mail.ru не хочется с такой строчкой в лицензионном соглашении:
«5.10. Лицензиат, размещая на Сервисе Контент, предоставляет Лицензиару, его партнерам и Конечным пользователям (при условии получения доступа к Персональному дисковому пространству Лицензиата) на условиях безвозмездной, неисключительной лицензии право использования данного Контента в течение всего срока действия исключительного права на соответствующий Контент на территории всего мира любыми способами, включая, но не ограничиваясь, доведение до всеобщего сведения, просмотр, воспроизведение, перевод и переработку.»
ну так, encfs спасёт отца русской демократии

Хотя и неудобно прикручивать шифрование поверх сервиса, но через webdav уже сносно. А если уж через webdav получится папки там создавать — так и вообще всё прекрасно.
Тему копирования файлов на Яндекс диск можно развить немного в другую сторону. В проектах, предоставляющих файлы для скачивания, эти самые файлы можно заливать на Яндекс диск, расшаривать и давать пользователям ссылку на файл в Яндекс диске. При этом если немного постараться, то файлы можно заливать на несколько разных аккаунтов. И теоретически места будет бесконечно много (10Гб * количество задействованных аккаунтов на Яндексе).
Не знаю только, как к этому сам Яндекс отнесется…
Не знаю, какой у вас хостинг, но если его пользователи по команде 'ps -axw' видят процессы других пользователей, то они будут рады узнать ваш логин и пароль от Яндекс.Диска.
Вы несомненно правы. Если кто-то из людей, имеющих доступ в консоль, вдруг узнает пароль и логин от вашего личного хранилища, и еще вдруг обнаружит там фотки вашей обнаженной жены, или не дай боже, не вашей — быть беде.
Добавлю в пост.
Ну зачем этот сарказм? Я легко могу представить хостинг, в котором пользователи не имеют доступа к файлам друг друга, но имеют доступ к списку процессов (путь даже не в шелле, а через какой-нибудь system/exec в php). А в хранилище, на секундочку, вы кладете не фотографии жены, а дампы баз, в которых наверняка есть пароли на администраторский интерфейс сайта. Иронизируйте дальше.
Шелдонам, которые думают, что я правда подшучиваю над этой темой, уточняю:
Эта мысль мне в голову не пришла, и я благодарен за отклик тов. vk2. Насколько я знаю людей, несмотря на то, что по-уму для таких дел надо бы заводить отдельный аккаунт на облаке, уверен, что многие эту идею проигнорируют из лени или на авось. И в таком случае действительно случайные люди, включая работников хостинга, могут получить доступ к поистине кладези персональных данных, а в случае с указанными в посте Яндексе и Mail.Ru — не только к файлам, но и ко всей переписке в почте.
И одно дело, когда там хранится сайт-визитка, с его контентом, и так доступным всем и каждому на сайте. И совсем другое — личные файлы и почта.

Так как я не пользуюсь почтой яндекса, и не пользуюсь его хранилищем кроме как для для пары своих сайтов, мне эта мысль в голову не пришла, и я считаю это большим упущением. Это очень опасный момент. И я сразу, как прочел сообщение vk2, включил упоминание об этом в пост в двух местах.
Если исключить задание параметров и вывод отчета, то останется что-то около тридцати строк

Зашёл в пост, чтоб увидеть комментарий про бекап в 30 строк кода, а его тут нет :(
Спасибо за идею. Наконец руки дошли сделать бэкап, благодаря статье.
Только на мой взгляд проще использовать скрипт на bash.
Вот как бы средствами Я-диска как-то версии отслеживать — цены бы не было!

Т.е. пишем в одно и то же место один и тот же файл раз в сутки (по сути, перезаписываем), но можно восстановить его состояние на момент «неделя назад». Если это было бы в функционале Я-диска, была бы «тайм-машин из коробки», и милое решение для ненавороченных бекапов.

Может, Яндекс однажды такое реализует?
При просмотре содержания директории, содержащей ежедневные копии проекта — представьте себе что Вы уже оказались в описанном интерфейсе, благодаря нажатию по такой-же описанной Вами кнопке «Восстановить состояние».

В чем проблема?
На ежедневные копии проекта потратится куда больше места, чем на хранение только изменений во всем дереве папок. Скажем, типичный веб или програмистский «проект» — это сотни файлов и файликов, из которых в сутки (или как часто Вы делаете бекап?) обычно меняются, сами понимаете, штук 10-15. Если в локальной копии можно выкрутиться hardlink-ами, то в удаленной — увы.

Не исключаю (и даже верю), что на стороне Я-диска дедубликация имеет место быть (правда, блоковая), но, во-первых, Вы заливаете бинарный архив (который, надо думать, заметно меняется, даже если 10-15 файлов из пары сотен поменяются, особенно если измененные не лежат в одном месте архива), во-вторых, дедубликация вряд ли учитывается при подсчете занятого места. Ну и время заливания 100 Мб архива, например, если в нем изменились 10 файлов общим весом в 15 кб — тоже можно учесть, мало ли по какому каналу придется работать?
Ну и сохраняйте только изменения в новые архивы. А при необходимости потом можно восстановить историю. Наверняка для этого есть готовые решения.
Вам не кажется, что Вы несколько странно отвечаете: я пишут, что было бы здорово хранить историю версий, т.к. сохранять по полной копии архива раз в сутки, чтобы сохранить, по сути, изменения, десятка файлов, не хочется, и вообще выглядит как из пушки по воробьям, а Вы мне на это отвечаете, что «Ну и сохраняйте только изменения в новые архивы». Это, поверьте, я и так могу догадаться сделать, вопрос в оптимальности такого подхода.
Я, собственно, к тому, что, существуй версии на Я-диске, задача отслеживания изменений падала бы на Я-систему, зато юзеру не пришлось бы ни о чем думать.
Ну для случаев, когда доступен только ftp или что-то подобное — да, отличный скрипт.
На нормальном хостинге лучше конечно использовать какой-нибудь бэкапер, хотя-бы простейший BackupManager.

Кстати спасибо за урл webdav для майла, как раз думал — а не бэкапить ли туда.

Кстати, а если дедуплицировать на клиенте? obnam, attic и все в таком духе?
Просто с учетом лиц соглашения майла его как основной бэкап использовать боязно — только на encfs
А яндекс — ну что, 10 гигов не найдется на серваке…
Спасибо за скрипт, переделаю таки скрипты бэкапа для Box и задумаюсь о копии на Я.Диск.
Сейчас делаю так: монтирую хранилище через DavFS и натравливаю rsync. Минусы только в том, что не везде можно использовать DavFS.
Думал также использовать lftp, он якобы может работать с WebDAV, но природная лень не позволяет посмотреть, так ли это :)
Чтобы не «светить» пароль рекомендую воспользоваться модулем curl который по-умолчанию включен в PHP
Плюс нет необходимости запускать внешнюю команду — они могут быть заперщены, программа curl может не стоять на сервере, результат работы passthru нужно ещё парсить, в то время как библиотека curl даёт errordescription.
Достаточно нескольких команд:

curl_setopt($this->curl,CURLOPT_URL,«webdav.yandex.ru/backup/»);
curl_setopt ( $this->curl, CURLOPT_POSTFIELDS, array(«file»=>"@/path/to/file.zip"));
curl_setopt ( $this->curl,CURLOPT_USERPWD,«user:password»);
Спасибо. Займусь. Я вообще не думал, что это может иметь такие последствия. Теперь обязательно подправлю.
Неплохо бы доработать скрипт для получения ссылки для скачивания (в случае расшаренной папки) — тогда можно рассылать команде разработчиков письмо с темой «Архив %sitename%_YYYYMMDD доступен для скачивания по сслыке...»
Честно говоря, не знаю, как эту ссылку получать в рамках данного скрипта. WebDAV у всех как минимум стандартный, а API для ссылочек у всех может быть разным. Может быть вам подойдет указанный в шапке класс товарища vasiatka? Он довольно навороченый.
В случае с Яндекс.Диском можно использовать следующее обращение (http://api.yandex.ru/disk/doc/dg/reference/publish.xml), что касается Облака Mail.ru, на сколько я понимаю (http://habrahabr.ru/post/191392/#comment_6650952) – сегодня это невозможно.

Прошу прощения за вид этих ссылок.
А с mail.ru сейчас работает? Мне отдает 405 на все, не пойму, то ли лыжи не едут…
Only those users with full accounts are able to leave comments. Log in, please.