Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии


    Как-то я попал под удачную раздачу Яндексом облачного хранилища и заполучил в свое владение 1 Тб. Первое что у меня возникло в голове — это засунуть туда свою iPhoto медиатеку. Живет она у меня на внешнем харде и объем ни много, ни мало — 800 Гб! Казалось бы чего сложного — взял да залил в облако, но...


    Давайте сделаем небольшой обзор того, как устроена архитектура Яндекс.Диск и ему подобных решений. Собственно, все гениально и просто: есть папка в облаке, есть ее аналог на локальном диске.



    Все что попало в облако подтягивается на локальный диск и наоборот. Гениально и просто. Однако получается, чтобы влить свои 800 Гб в облако с внешнего харда надо иметь не меньше одного дискового пространства на своем несчастном SSD — на рабочем ноуте-то! В общем, очевидно путь бабушек с использованием штатного клиента Яндекс.Диск тут не работает.


    Идем читать мануалы сервиса и выясняем, что есть у них WebDav, — аллилуйя, вот и решение! Монтируем том в систему и пошло поехало. Но понимаем, что объем большой, литься будет не один день, прийдется прерываться по тем или иным причинам, возобновлять заливку.


    На помощь нам тут приходит старый добрый rsync — финальный вариант его использования приведен ниже, а пока вернемся к не очень вдохновляющему моменту во всей этой истории: скорости заливки. Увы, она не высока — вносит свою лепту и ограниченный канал, конечно, но главное это провисание на удаленных файловых операциях (в основном, fsync конечно же), которые должны выполниться для каждого скопированного файла.


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



    Идем читать протокол WebDav и видим там всякие штуки аля MPUT — задумываемся может есть какой волшебный клиент, который эффективно это делает и по отзывам под Mac OS очень хвалят CyberDuck.


    С виду там действительно волшебным образом начинает все быстро заливаться — прям как будто на локальной ФС все происходит. Более подробное исследование показало, что все так и происходит на самом деле — он вовсе не работает как-то супер оптимально с WebDav, используя MPUT там для маленьких файлов, а ровно как и Яндекс.Диск — т.е. у него есть свой локальный кэш (экспериментальным путем было установлено, что он лимитирован примерно 1 Гб) и он, соответственно, создает имитацию быстрых файловых операций локально — отвечает как драйвер ФС приложению, но по сути просто записывает их себе в кэш и тихонько синкает через WebDav.


    Соответственно, пускать на нем rsync, который сначала копирует файл во временный в целевой директории, а потом делает ему move, — нет смысла вообще никакого — CyberDuck просто клинит на этой теме — он пока доходит в своей фоновой синхронизации до файла — того уже нет.



    Делать нечего, лил я через классический клиент Mac OS медленно, но верно порядка 10 дней. Понятно, что мне приходилось это дело в течение 10 дней прерывать по тем или иным причинам. Инет, бывало, пропадал, но, учитывая принцип работы rsync, делал я все доливки, используя опцию --ignore-existing — если rsync файл успешно залил и переименовал + учитывая, что я не менял в это время исходные файлы — не пользовался iPhoto, то факта наличия файла на целевом носителе вполне достаточно, проверкой контрольных сумм и синхронизацией измененных файлов заниматься нет необходимости.


    Последующие доливки дифференциальных бэкапов следует делать, используя опцию --size-only — фотки/видео не меняются как правило — только новые добавляются ну или меняется мета-информация — всякие файлы БД медиатеки и т.п. — в общем, соответствие размера файла на источнике и целевом носителях достаточно для заключения, что его синхронизацию можно пропустить.



    Еще один момент, который пришлось учесть при формировании бэкапа медиатеки: как я и говорил в самом начале, медиатека занимает более 800 Гб, но это не самое страшное — самое неприятное, что файлов там 373К! Причем, как выяснилось сами фото/видео (собственно, самая важная для меня часть с точки зрения резервной копии) — это где-то 70К, а все остальное малополезный медиа-трэш — всякие лица там iPhoto ищет и т.п. — в общем, львиная доля этих файлов располагается в директориях resources/proxies и resources/media в директории медиатеки и занимали в общей сложности 33 Гб в моем случае.


    С учетом, что это по сути бэкап и пользоваться напрямую этой медиатекой из iPhoto не будем, делаем следующее: создаем 2 архива для этих директорий — хоть с помощью tar без сжатия — там jpeg, который все-равно не жмется толком. Далее с помощью директив rsync --exclude скипаем эти директории и все содержимое в них. Т.е. финальная команда у меня выглядела вот так:


    rsync -axv --numeric-ids --progress --ignore-existing --exclude="/resources/proxies/***" --exclude="/resources/media/***" /Volumes/TOSHIBA\ EXT/Медиатека\ Фото.photoslibrary/ /Volumes/webdav.yandex.ru/Медиатека\ Фото.photoslibrary/

    Ну вот, наверно, и все — последующие доливки будем проводить, как и сказал, с помощью директивы rsync --size-only. Бывает еще неприятность от Apple, что меняют структуру директорий или формат хранения данных — но тут, думаю, нам поможет директива --delete (предписывает rsync удалять не существующие файлы/папки на целевом ресурсе при синхронизации). Ну или будем посмотреть, что они придумают там еще — где наша не пропадала.


    P.S. Надеюсь, что мой опыт окажется вам полезен. Будут вопросы, пишите, с радостью отвечу. Спасибо за внимание!


    Parallels
    Мировой лидер на рынке межплатформенных решений

    Комментарии 23

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

            Надолго ли оно работает — не понятно: https://habr.com/ru/post/489492/

              +1
              работает-работает, rclone этот я так понимаю много на себя берет в плане автоматизации — отсюда и проблемы. Здесь же просто WebDav шара в контексте своего аккаунта. Чем я там лью rsync или просто команды cp/mv дергаю они, по сути, даже знать не могут.
                0

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

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

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

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

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

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

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

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

                  Облака все известные поддерживает, синхронизация есть, клиенты вин и мак, и в планах полноценный для линукса.
                    0
                    А структура и содердание папок не теряется?
                      +1
                      Не замечал потерь я никаких.
                      Вложенность 8-12 уровней, наверное.
                        +1
                        о, интересно — спасибо за наводку — погляжу на досуге. Но опять же дело было не только в объеме или там вложенности папок — это все не так страшно. А вот очень много маленьких файлов, кол-во которых от общего, которые надо засинкать, 80% — уверен повергнет любой бэкап софт в уныние. Не знаю как там AE этот себя ведет, но в Я.Д клиенте не поймешь толком даже прогресс чего там засинкалось, а что нет — шуршит себе чего-то, траффик генерит, а когда там процесс сойдется можно только догадываться. Отсюда и весь мой экскурс — с rsync как-то все более подконтрольно и понятно в этом плане: копирование идет последовательно по папкам с датами и можно четко видеть где мы сейчас находимся + exclude на папки с ресурсами, которые заливаем большими tar'ами. В общем, я практически уверен, что ни один удобный софт такие кейсы не покрывает — уж слишком много специфики.
                    0
                    А я так хранила копии фото/видео с на одном из внешних ресурсов. Он был встроен еще до покупки и добровольно-принудительно рекомендован при первой настройке.
                    А, спустя год, пришло сообщение «Сократите место на диске, иначе за вас сократят весь диск, бесплатное промо-время закончилось». И теперь у меня паранойя цветет в полный рост.
                      +1
                      Ну тут вполне готов поверить, но я плачу за этот террабайт хоть и не космические деньги, но верю все-таки в лояльность Яндекса к своим клиентам)

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое