Путь 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. Надеюсь, что мой опыт окажется вам полезен. Будут вопросы, пишите, с радостью отвечу. Спасибо за внимание!
