Comments 23
Насколько помню, яндекс считает вебдав неофициальной возможностью и при сильной нагрузке любит его выключать, люди жаловались.
Обработал фото в лайтруме, выгрузил в структурированный каталог.
Далее запуск батника.
Архивирование с паролем во временную папку.
По готовности копируется в облако (самый отечественный почтовый сервис).
И бэкап есть и приватность в силе.
Далее запуск батника.
Архивирование с паролем во временную папку.
По готовности копируется в облако (самый отечественный почтовый сервис).
И бэкап есть и приватность в силе.
Да пожалуйста, но что это отменяет?) Я сильно не параною по поводу того, что фотки на внешнем облаке лежат. Мне главное бэкап и возможность доливки в него с минимальными издержками. Предложенный вами вариант подразумевает заливку каждый раз полного архива фоток я так понимаю. В моем случае это более 800 Гб и это боль.
А, да — про бэкап. Я всё ещё duplicati пользуюсь, с закачкой в вандрайв через их API.
Вроде всё нормально работает, ничего не отваливалось, архивы не помирали.
Вроде всё нормально работает, ничего не отваливалось, архивы не помирали.
ну норм чего, я пытался просто найти что-нибудь именно на iPhoto заточенное из приложений резервного копирования — не нашел и пошел сам педалить — что решение идеальное я даже не претендую ни разу: не секьюрно, достаточно много ручных приседаний — не прям все из коробки. Но у меня не так часто возникает идея подоливать фотки в облако — так что для меня норм работает.
Надолго ли оно работает — не понятно: https://habr.com/ru/post/489492/
Ситуация: инструкция для идиотов, а я умный.
Настройки — синхронизация — галка с нужной папки убирается.
Настройки — синхронизация — галка с нужной папки убирается.
вот щас не понял — что это дает-то? Еще раз проблема: медиатека на внешнем харде. Не лежит она в папке Яндекс диска вообще. Мне ее надо залить в облако.
Символьная ссылка вам в помощь.
ну что ж снимаю шляпу: рабочий хак действительно. Но только вот, боюсь, не будет это нормально работать на моих объемах: я для пробы залинковал сейчас маленькую медиатеку на 17 Гб всего и Яндекс.Диск ушел долго и упорно синкать — внешний хард мне сейчас безболезненно не оторвать, соответственно. Напоминаю, помимо полезного объема там есть еще медиа-трэш в медиатеке, который iPhoto сам создает в процессе своей работы. И это добро, подозреваю, постоянно плодится/распухает/меняется. Это много-много маленьких файликов — на синхронизацию этого дела может уйти масса времени. Я в своих испытаниях это все засунул в один большой архив и быстренько залил в облако. Держать внешний хард подключенным к компу месяц пока там все засинкает Я.Д — не вариант. С другой стороны, проделав это раз, наверно, будет он все быстро синкать — возможно. Надо проверять — в любом случае спс за идею)
Спасибо за интересную статью! Сам живу уже с третьим самописным скриптом для бекапов.
А облако эти tar-файлы распаковывать случайно не умеет?
Не с целью покритиковать, а с целью задать конструктивный вопрос интересуюсь: в дальнейшем эти папки resources/proxies и resources/media синхронизировать планируется? Если да, то придется каждый раз их tar'ить и заливать 33gb? Если нет — то зачем их первый раз бекапить (риторический вопрос) и поймёт ли iPhoto «восстановление» из бекапа без этих двух папок или с их старыми версиями?
Не знаю, как на Mac, а в Линуксе у tar есть параметр --listed-incremental — он позволяет создать «дифференциальный архив», содержащий только то, что изменилось с прошлого бекапа. Таким образом, можно при «последующих доливках» создавать маленькие tar-архивы, содержащие изменения в этих двух папках.
А облако эти tar-файлы распаковывать случайно не умеет?
Не с целью покритиковать, а с целью задать конструктивный вопрос интересуюсь: в дальнейшем эти папки resources/proxies и resources/media синхронизировать планируется? Если да, то придется каждый раз их tar'ить и заливать 33gb? Если нет — то зачем их первый раз бекапить (риторический вопрос) и поймёт ли iPhoto «восстановление» из бекапа без этих двух папок или с их старыми версиями?
Не знаю, как на Mac, а в Линуксе у tar есть параметр --listed-incremental — он позволяет создать «дифференциальный архив», содержащий только то, что изменилось с прошлого бекапа. Таким образом, можно при «последующих доливках» создавать маленькие tar-архивы, содержащие изменения в этих двух папках.
Спасибо за интерес к статье!)
Распаковывать, думаю, нет. Т.е. процедура восстановления из бэкапа подразумевает, что я распакую это сам. Благо, восстанавливаться из бэкапов в реальной жизни приходится не так часто — я в своей практике наступал на это пару раз только, наверно, — отсюда и секрет успеха компании Acronis) iPhoto эти папки конечно же нужны — не зря ж оно их лопатит. Посему я планировал актуальность их поддерживать и как вы правильно заметили заливать каждый раз полный архив поверх. Про то, что tar из коробки умеет дифференциальные бэкапы делать — не знал — спасибо за наводку — это действительно может существенно облегчить доливки — поизучаю вопрос.
Распаковывать, думаю, нет. Т.е. процедура восстановления из бэкапа подразумевает, что я распакую это сам. Благо, восстанавливаться из бэкапов в реальной жизни приходится не так часто — я в своей практике наступал на это пару раз только, наверно, — отсюда и секрет успеха компании Acronis) iPhoto эти папки конечно же нужны — не зря ж оно их лопатит. Посему я планировал актуальность их поддерживать и как вы правильно заметили заливать каждый раз полный архив поверх. Про то, что tar из коробки умеет дифференциальные бэкапы делать — не знал — спасибо за наводку — это действительно может существенно облегчить доливки — поизучаю вопрос.
Давно и успешно использую Air Explorer.
На днях буквально 700 гиг переливал с майлру на яндекс.
Облака все известные поддерживает, синхронизация есть, клиенты вин и мак, и в планах полноценный для линукса.
На днях буквально 700 гиг переливал с майлру на яндекс.
Облака все известные поддерживает, синхронизация есть, клиенты вин и мак, и в планах полноценный для линукса.
А структура и содердание папок не теряется?
Не замечал потерь я никаких.
Вложенность 8-12 уровней, наверное.
Вложенность 8-12 уровней, наверное.
о, интересно — спасибо за наводку — погляжу на досуге. Но опять же дело было не только в объеме или там вложенности папок — это все не так страшно. А вот очень много маленьких файлов, кол-во которых от общего, которые надо засинкать, 80% — уверен повергнет любой бэкап софт в уныние. Не знаю как там AE этот себя ведет, но в Я.Д клиенте не поймешь толком даже прогресс чего там засинкалось, а что нет — шуршит себе чего-то, траффик генерит, а когда там процесс сойдется можно только догадываться. Отсюда и весь мой экскурс — с rsync как-то все более подконтрольно и понятно в этом плане: копирование идет последовательно по папкам с датами и можно четко видеть где мы сейчас находимся + exclude на папки с ресурсами, которые заливаем большими tar'ами. В общем, я практически уверен, что ни один удобный софт такие кейсы не покрывает — уж слишком много специфики.
А я так хранила копии фото/видео с на одном из внешних ресурсов. Он был встроен еще до покупки и добровольно-принудительно рекомендован при первой настройке.
А, спустя год, пришло сообщение «Сократите место на диске, иначе за вас сократят весь диск, бесплатное промо-время закончилось». И теперь у меня паранойя цветет в полный рост.
А, спустя год, пришло сообщение «Сократите место на диске, иначе за вас сократят весь диск, бесплатное промо-время закончилось». И теперь у меня паранойя цветет в полный рост.
Sign up to leave a comment.
Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии