Comments 23
Насколько помню, яндекс считает вебдав неофициальной возможностью и при сильной нагрузке любит его выключать, люди жаловались.
Не ну это запросто да — говорю же за 10 дней отваливался и инет, и шара. Но rsync рулит.
Обработал фото в лайтруме, выгрузил в структурированный каталог.
Далее запуск батника.
Архивирование с паролем во временную папку.
По готовности копируется в облако (самый отечественный почтовый сервис).
И бэкап есть и приватность в силе.
Да пожалуйста, но что это отменяет?) Я сильно не параною по поводу того, что фотки на внешнем облаке лежат. Мне главное бэкап и возможность доливки в него с минимальными издержками. Предложенный вами вариант подразумевает заливку каждый раз полного архива фоток я так понимаю. В моем случае это более 800 Гб и это боль.
Отнюдь. Только то, что надо докинуть. Забыл уточнить: у меня структура в виде папка с датой, там фото. Соответственно свежее событие — отдельная папка, она и ахивируется и шлётся в облако.
ну и отлично же — я просто слишком ленив, чтоб так все настраивать)
А, да — про бэкап. Я всё ещё duplicati пользуюсь, с закачкой в вандрайв через их API.
Вроде всё нормально работает, ничего не отваливалось, архивы не помирали.
ну норм чего, я пытался просто найти что-нибудь именно на iPhoto заточенное из приложений резервного копирования — не нашел и пошел сам педалить — что решение идеальное я даже не претендую ни разу: не секьюрно, достаточно много ручных приседаний — не прям все из коробки. Но у меня не так часто возникает идея подоливать фотки в облако — так что для меня норм работает.
работает-работает, rclone этот я так понимаю много на себя берет в плане автоматизации — отсюда и проблемы. Здесь же просто WebDav шара в контексте своего аккаунта. Чем я там лью rsync или просто команды cp/mv дергаю они, по сути, даже знать не могут.

Когда они вырубили не работал не только rclone. wget и виндовый встроенный клиент тоже не работали. Возможно они провели показательную порку и когда все перестали хранить бекапы у них — включили назад.

Ситуация: инструкция для идиотов, а я умный.

Настройки — синхронизация — галка с нужной папки убирается.
вот щас не понял — что это дает-то? Еще раз проблема: медиатека на внешнем харде. Не лежит она в папке Яндекс диска вообще. Мне ее надо залить в облако.
ну что ж снимаю шляпу: рабочий хак действительно. Но только вот, боюсь, не будет это нормально работать на моих объемах: я для пробы залинковал сейчас маленькую медиатеку на 17 Гб всего и Яндекс.Диск ушел долго и упорно синкать — внешний хард мне сейчас безболезненно не оторвать, соответственно. Напоминаю, помимо полезного объема там есть еще медиа-трэш в медиатеке, который iPhoto сам создает в процессе своей работы. И это добро, подозреваю, постоянно плодится/распухает/меняется. Это много-много маленьких файликов — на синхронизацию этого дела может уйти масса времени. Я в своих испытаниях это все засунул в один большой архив и быстренько залил в облако. Держать внешний хард подключенным к компу месяц пока там все засинкает Я.Д — не вариант. С другой стороны, проделав это раз, наверно, будет он все быстро синкать — возможно. Надо проверять — в любом случае спс за идею)
Спасибо за интересную статью! Сам живу уже с третьим самописным скриптом для бекапов.

А облако эти tar-файлы распаковывать случайно не умеет?

Не с целью покритиковать, а с целью задать конструктивный вопрос интересуюсь: в дальнейшем эти папки resources/proxies и resources/media синхронизировать планируется? Если да, то придется каждый раз их tar'ить и заливать 33gb? Если нет — то зачем их первый раз бекапить (риторический вопрос) и поймёт ли iPhoto «восстановление» из бекапа без этих двух папок или с их старыми версиями?

Не знаю, как на Mac, а в Линуксе у tar есть параметр --listed-incremental — он позволяет создать «дифференциальный архив», содержащий только то, что изменилось с прошлого бекапа. Таким образом, можно при «последующих доливках» создавать маленькие tar-архивы, содержащие изменения в этих двух папках.
Спасибо за интерес к статье!)

Распаковывать, думаю, нет. Т.е. процедура восстановления из бэкапа подразумевает, что я распакую это сам. Благо, восстанавливаться из бэкапов в реальной жизни приходится не так часто — я в своей практике наступал на это пару раз только, наверно, — отсюда и секрет успеха компании Acronis) iPhoto эти папки конечно же нужны — не зря ж оно их лопатит. Посему я планировал актуальность их поддерживать и как вы правильно заметили заливать каждый раз полный архив поверх. Про то, что tar из коробки умеет дифференциальные бэкапы делать — не знал — спасибо за наводку — это действительно может существенно облегчить доливки — поизучаю вопрос.
Давно и успешно использую Air Explorer.

На днях буквально 700 гиг переливал с майлру на яндекс.

Облака все известные поддерживает, синхронизация есть, клиенты вин и мак, и в планах полноценный для линукса.
о, интересно — спасибо за наводку — погляжу на досуге. Но опять же дело было не только в объеме или там вложенности папок — это все не так страшно. А вот очень много маленьких файлов, кол-во которых от общего, которые надо засинкать, 80% — уверен повергнет любой бэкап софт в уныние. Не знаю как там AE этот себя ведет, но в Я.Д клиенте не поймешь толком даже прогресс чего там засинкалось, а что нет — шуршит себе чего-то, траффик генерит, а когда там процесс сойдется можно только догадываться. Отсюда и весь мой экскурс — с rsync как-то все более подконтрольно и понятно в этом плане: копирование идет последовательно по папкам с датами и можно четко видеть где мы сейчас находимся + exclude на папки с ресурсами, которые заливаем большими tar'ами. В общем, я практически уверен, что ни один удобный софт такие кейсы не покрывает — уж слишком много специфики.
А я так хранила копии фото/видео с на одном из внешних ресурсов. Он был встроен еще до покупки и добровольно-принудительно рекомендован при первой настройке.
А, спустя год, пришло сообщение «Сократите место на диске, иначе за вас сократят весь диск, бесплатное промо-время закончилось». И теперь у меня паранойя цветет в полный рост.
Ну тут вполне готов поверить, но я плачу за этот террабайт хоть и не космические деньги, но верю все-таки в лояльность Яндекса к своим клиентам)
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
США
Website
www.parallels.com
Employees
201–500 employees
Registered