Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
Теги как раз для чтения.
каких только велосипедов не изобретут, чтобы git не изучать
А медиа файлы вы тоже в git предлагаете хранить?
Исходники надо хранить в системе контроля версий. Тут я с вами полностью согласен. Но если у меня, к примеру, сайт-галлерея, то хранить изображения в git будет неправильно.
Исходники надо хранить в системе контроля версий. Тут я с вами полностью согласен. Но если у меня, к примеру, сайт-галлерея, то хранить изображения в git будет неправильно.
Для сайтов визиток ничего страшного. Если сильно напрягают нюансы, то можно тут прочитать как что оптимизировать.
habrahabr.ru/post/173453/
habrahabr.ru/post/173453/
да, а что тут ужасного?
Если у вас сайт-галерея, то хранить изображения в корне вместе с сайтом уже неправильно. А так, ничего криминального в использовании контроля версий на изображения нет. Это конечно большая тайна, но все же: системы контроля версий используют не только для исходного кода.
А где вы предлагаете устроить удаленный репозитарий git? К тому же бесплатно, без смс.
в статье идет речь о резервном копировании веб-проектов. я вообще не понимаю, причем здесь git?
то что должно храниться в git (исходники) в бэкап по-хорошему можно и не включать, так что это совершенно разные задачи.
да и вообще, как вы предлагаете использовать git для бэкапов продакшн версии сайта со всеми пользовательскими данными и БД?
то что должно храниться в git (исходники) в бэкап по-хорошему можно и не включать, так что это совершенно разные задачи.
да и вообще, как вы предлагаете использовать git для бэкапов продакшн версии сайта со всеми пользовательскими данными и БД?
Что значит «должно»? Моисей взошел на гору, и ему там сказано было «не храни в гите ничего, кроме исходников»?
Да, я храню в гите продакшн версию сайтов (в т.ч. крупнейший интернет-магазин, например) со всеми потрохами, включая десятки тысяч картинок, и не вижу в этом ничего постыдного.
Да, я храню в гите продакшн версию сайтов (в т.ч. крупнейший интернет-магазин, например) со всеми потрохами, включая десятки тысяч картинок, и не вижу в этом ничего постыдного.
нет, Моисей здесь не причем, я руководствуюсь общепринятыми практиками и здравым смыслом
полагаю, что под картинками имеете ввиду аватары пользователей, или какие то другие пользовательские картинки (в противном случае не вижу смысла дискутировать дальше, т.к. в предыдущем комменте говорил именно о пользовательских данных)
как же они попадают в репозиторий? у вас на продакшн сервере при каждой загрузке на сайт этих самих картинок, делается коммит и затем периодически это все пушится на удаленный репозиторий?
должен признать, это довольно интересный способ бэкапа, хоть и извращенный. как минимум этот способ не всем подойдет, хотя бы с точки зрения экономии места на дисках (как писали выше).
а с БД вы как поступаете? и ее в git?
полагаю, что под картинками имеете ввиду аватары пользователей, или какие то другие пользовательские картинки (в противном случае не вижу смысла дискутировать дальше, т.к. в предыдущем комменте говорил именно о пользовательских данных)
как же они попадают в репозиторий? у вас на продакшн сервере при каждой загрузке на сайт этих самих картинок, делается коммит и затем периодически это все пушится на удаленный репозиторий?
должен признать, это довольно интересный способ бэкапа, хоть и извращенный. как минимум этот способ не всем подойдет, хотя бы с точки зрения экономии места на дисках (как писали выше).
а с БД вы как поступаете? и ее в git?
Ну в целом примерно так и есть, с некоторыми нюансами. Не при каждой загрузке, разумеется — точно так же, по расписанию. Какой-нибудь фотохостинг я бы не стал так бэкапить, наверное, а магазин/форум/вордпресс/простосайт (т.е. 99.9% сайтов) — почему нет?
Не вижу никакого извращения, честно. Стереотипы — не всегда хорошо.
Не вижу никакого извращения, честно. Стереотипы — не всегда хорошо.
После того, как у хостера опять случилась проблема, и пришлось восстанавливать бекапы 3-дневной давности, этот способ кажется очень простым и актуальным.
Спасибо за скрипт!
Спасибо за скрипт!
В свете последних событий, было бы неплохо такой же скрипт для стороджа от мейл.ру.
Спасибо за мысль! Обновил топик, немного изменил код, и «добавил поддержку» (нашел нужный адрес) Mail.Ru. Жаль, что не знал об этом, когда писал.
Ничего отправлять в mail.ru не хочется с такой строчкой в лицензионном соглашении:
«5.10. Лицензиат, размещая на Сервисе Контент, предоставляет Лицензиару, его партнерам и Конечным пользователям (при условии получения доступа к Персональному дисковому пространству Лицензиата) на условиях безвозмездной, неисключительной лицензии право использования данного Контента в течение всего срока действия исключительного права на соответствующий Контент на территории всего мира любыми способами, включая, но не ограничиваясь, доведение до всеобщего сведения, просмотр, воспроизведение, перевод и переработку.»
«5.10. Лицензиат, размещая на Сервисе Контент, предоставляет Лицензиару, его партнерам и Конечным пользователям (при условии получения доступа к Персональному дисковому пространству Лицензиата) на условиях безвозмездной, неисключительной лицензии право использования данного Контента в течение всего срока действия исключительного права на соответствующий Контент на территории всего мира любыми способами, включая, но не ограничиваясь, доведение до всеобщего сведения, просмотр, воспроизведение, перевод и переработку.»
Тему копирования файлов на Яндекс диск можно развить немного в другую сторону. В проектах, предоставляющих файлы для скачивания, эти самые файлы можно заливать на Яндекс диск, расшаривать и давать пользователям ссылку на файл в Яндекс диске. При этом если немного постараться, то файлы можно заливать на несколько разных аккаунтов. И теоретически места будет бесконечно много (10Гб * количество задействованных аккаунтов на Яндексе).
Не знаю только, как к этому сам Яндекс отнесется…
Не знаю только, как к этому сам Яндекс отнесется…
Вы несомненно правы. Если кто-то из людей, имеющих доступ в консоль, вдруг узнает пароль и логин от вашего личного хранилища, и еще вдруг обнаружит там фотки вашей обнаженной жены, или не дай боже, не вашей — быть беде.
Добавлю в пост.
Добавлю в пост.
Эх, если б это был сарказм…
Шелдонам, которые думают, что я правда подшучиваю над этой темой, уточняю:
Эта мысль мне в голову не пришла, и я благодарен за отклик тов. vk2. Насколько я знаю людей, несмотря на то, что по-уму для таких дел надо бы заводить отдельный аккаунт на облаке, уверен, что многие эту идею проигнорируют из лени или на авось. И в таком случае действительно случайные люди, включая работников хостинга, могут получить доступ к поистине кладези персональных данных, а в случае с указанными в посте Яндексе и Mail.Ru — не только к файлам, но и ко всей переписке в почте.
И одно дело, когда там хранится сайт-визитка, с его контентом, и так доступным всем и каждому на сайте. И совсем другое — личные файлы и почта.
Так как я не пользуюсь почтой яндекса, и не пользуюсь его хранилищем кроме как для для пары своих сайтов, мне эта мысль в голову не пришла, и я считаю это большим упущением. Это очень опасный момент. И я сразу, как прочел сообщение vk2, включил упоминание об этом в пост в двух местах.
Эта мысль мне в голову не пришла, и я благодарен за отклик тов. vk2. Насколько я знаю людей, несмотря на то, что по-уму для таких дел надо бы заводить отдельный аккаунт на облаке, уверен, что многие эту идею проигнорируют из лени или на авось. И в таком случае действительно случайные люди, включая работников хостинга, могут получить доступ к поистине кладези персональных данных, а в случае с указанными в посте Яндексе и Mail.Ru — не только к файлам, но и ко всей переписке в почте.
И одно дело, когда там хранится сайт-визитка, с его контентом, и так доступным всем и каждому на сайте. И совсем другое — личные файлы и почта.
Так как я не пользуюсь почтой яндекса, и не пользуюсь его хранилищем кроме как для для пары своих сайтов, мне эта мысль в голову не пришла, и я считаю это большим упущением. Это очень опасный момент. И я сразу, как прочел сообщение vk2, включил упоминание об этом в пост в двух местах.
Если исключить задание параметров и вывод отчета, то останется что-то около тридцати строк
Зашёл в пост, чтоб увидеть комментарий про бекап в 30 строк кода, а его тут нет :(
Спасибо за идею. Наконец руки дошли сделать бэкап, благодаря статье.
Только на мой взгляд проще использовать скрипт на bash.
Только на мой взгляд проще использовать скрипт на bash.
Согласен. Была бы возможность. Скрипт кстати можно найти в комментариях к посту vasiatka habrahabr.ru/post/206752/#comment_7122300
Вот как бы средствами Я-диска как-то версии отслеживать — цены бы не было!
Т.е. пишем в одно и то же место один и тот же файл раз в сутки (по сути, перезаписываем), но можно восстановить его состояние на момент «неделя назад». Если это было бы в функционале Я-диска, была бы «тайм-машин из коробки», и милое решение для ненавороченных бекапов.
Может, Яндекс однажды такое реализует?
Т.е. пишем в одно и то же место один и тот же файл раз в сутки (по сути, перезаписываем), но можно восстановить его состояние на момент «неделя назад». Если это было бы в функционале Я-диска, была бы «тайм-машин из коробки», и милое решение для ненавороченных бекапов.
Может, Яндекс однажды такое реализует?
При просмотре содержания директории, содержащей ежедневные копии проекта — представьте себе что Вы уже оказались в описанном интерфейсе, благодаря нажатию по такой-же описанной Вами кнопке «Восстановить состояние».
В чем проблема?
В чем проблема?
На ежедневные копии проекта потратится куда больше места, чем на хранение только изменений во всем дереве папок. Скажем, типичный веб или програмистский «проект» — это сотни файлов и файликов, из которых в сутки (или как часто Вы делаете бекап?) обычно меняются, сами понимаете, штук 10-15. Если в локальной копии можно выкрутиться hardlink-ами, то в удаленной — увы.
Не исключаю (и даже верю), что на стороне Я-диска дедубликация имеет место быть (правда, блоковая), но, во-первых, Вы заливаете бинарный архив (который, надо думать, заметно меняется, даже если 10-15 файлов из пары сотен поменяются, особенно если измененные не лежат в одном месте архива), во-вторых, дедубликация вряд ли учитывается при подсчете занятого места. Ну и время заливания 100 Мб архива, например, если в нем изменились 10 файлов общим весом в 15 кб — тоже можно учесть, мало ли по какому каналу придется работать?
Не исключаю (и даже верю), что на стороне Я-диска дедубликация имеет место быть (правда, блоковая), но, во-первых, Вы заливаете бинарный архив (который, надо думать, заметно меняется, даже если 10-15 файлов из пары сотен поменяются, особенно если измененные не лежат в одном месте архива), во-вторых, дедубликация вряд ли учитывается при подсчете занятого места. Ну и время заливания 100 Мб архива, например, если в нем изменились 10 файлов общим весом в 15 кб — тоже можно учесть, мало ли по какому каналу придется работать?
Ну и сохраняйте только изменения в новые архивы. А при необходимости потом можно восстановить историю. Наверняка для этого есть готовые решения.
Вам не кажется, что Вы несколько странно отвечаете: я пишут, что было бы здорово хранить историю версий, т.к. сохранять по полной копии архива раз в сутки, чтобы сохранить, по сути, изменения, десятка файлов, не хочется, и вообще выглядит как из пушки по воробьям, а Вы мне на это отвечаете, что «Ну и сохраняйте только изменения в новые архивы». Это, поверьте, я и так могу догадаться сделать, вопрос в оптимальности такого подхода.
Я, собственно, к тому, что, существуй версии на Я-диске, задача отслеживания изменений падала бы на Я-систему, зато юзеру не пришлось бы ни о чем думать.
Ну для случаев, когда доступен только ftp или что-то подобное — да, отличный скрипт.
На нормальном хостинге лучше конечно использовать какой-нибудь бэкапер, хотя-бы простейший BackupManager.
Кстати спасибо за урл webdav для майла, как раз думал — а не бэкапить ли туда.
Кстати, а если дедуплицировать на клиенте? obnam, attic и все в таком духе?
Просто с учетом лиц соглашения майла его как основной бэкап использовать боязно — только на encfs
А яндекс — ну что, 10 гигов не найдется на серваке…
На нормальном хостинге лучше конечно использовать какой-нибудь бэкапер, хотя-бы простейший BackupManager.
Кстати спасибо за урл webdav для майла, как раз думал — а не бэкапить ли туда.
Кстати, а если дедуплицировать на клиенте? obnam, attic и все в таком духе?
Просто с учетом лиц соглашения майла его как основной бэкап использовать боязно — только на encfs
А яндекс — ну что, 10 гигов не найдется на серваке…
Спасибо за скрипт, переделаю таки скрипты бэкапа для Box и задумаюсь о копии на Я.Диск.
Сейчас делаю так: монтирую хранилище через DavFS и натравливаю rsync. Минусы только в том, что не везде можно использовать DavFS.
Думал также использовать lftp, он якобы может работать с WebDAV, но природная лень не позволяет посмотреть, так ли это :)
Сейчас делаю так: монтирую хранилище через 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»);
Плюс нет необходимости запускать внешнюю команду — они могут быть заперщены, программа 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? Он довольно навороченый.
А с mail.ru сейчас работает? Мне отдает 405 на все, не пойму, то ли лыжи не едут…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервное копирование веб-проектов на Яндекс.Диск без ООП и натурщиц