Комментарии 60
«переименовать её в следующий формат: [КАМЕРА_ЧТО ИЗОБРАЖЕНО_КОГДА СНЯТО]. Например, на выходе название папки может превратиться из неясного «330_FUJI» в абсолютно осмысленное «FUJI-X20_Корпоратив_ноябрь_2010».»
Мне кажется если начинать с даты, то поиск становится намного удобнее.
Мне кажется если начинать с даты, то поиск становится намного удобнее.
Поддерживаю, причем дату лучше в формате ГГГГ-ММ-ДД, ибо сортировка
Тогда уж еще час--минута-секунда, да и нумерацию имеет смысл добавлять, потому что учитывая скорострельность нынешних камер, и в одну секунду может несколько снимков быть сделано.
То есть примерно ГГГГММДД-ЧЧММСС_номер_что-изображено — это для свежеотснятого, переименовывается сразу при импорте в лайтрум.
То есть примерно ГГГГММДД-ЧЧММСС_номер_что-изображено — это для свежеотснятого, переименовывается сразу при импорте в лайтрум.
Это именование для папки, зачем там время? В любом случае время есть в exif.
ММ-ДД-Мероприятие и ложить в папку ГГГГ.
Сперва тоже так делал, а сейчас, всё же, стал год и во вложенный каталог добавлять. Иначе в десятилетней коллекции при поиске путаешься. Т.е. структура у меня такая выходит:
ГГГГ/ГГГГДДММ Мероприятие/ГГГДДММ-ЧЧММ-оригинальное-имя-файла.jpg
Вот название камеры и прочие параметры особо не выделяю. Тем более, что бывает масса мероприятий со смешанной съёмкой с разных камер.
Вот если нужно выделять параметры (скажем, при астрофото нужны дарки заданных ISO, выдержки и температуры), то я просто натравливаю на каталоги скрипт, который делает симлинки в соответствующих местах (фотоархив лежит на Linux-сервер, а вот в роли каталогизатора я предпочитаю Picasa).
ГГГГ/ГГГГДДММ Мероприятие/ГГГДДММ-ЧЧММ-оригинальное-имя-файла.jpg
Вот название камеры и прочие параметры особо не выделяю. Тем более, что бывает масса мероприятий со смешанной съёмкой с разных камер.
Вот если нужно выделять параметры (скажем, при астрофото нужны дарки заданных ISO, выдержки и температуры), то я просто натравливаю на каталоги скрипт, который делает симлинки в соответствующих местах (фотоархив лежит на Linux-сервер, а вот в роли каталогизатора я предпочитаю Picasa).
У меня все фолдеры ГГГГ.ММ.ДД. Название события. Очень удобно. Если нужно с камерой, добавьте в конце [Canon EOS 7D], например.
Можно и так, особенно если иметь дело с большими потоками данных. Мне оказывается удобнее именно формат, где дело начинается с модели камеры, так как это в первую очередь влияет на пресеты постобработки. Кроме того, дату можно а) извлечь из EXIF, и б) забыть адекватно настроить в фотоаппарате, так что этот критерий иногда довольно условен.
Но для репортажников, там да, момент съёмки может иногда оказаться основным фактором отбора. В общем, думаю, что здесь формат можно ставить как кому удобнее — важнее общий принцип.
Но для репортажников, там да, момент съёмки может иногда оказаться основным фактором отбора. В общем, думаю, что здесь формат можно ставить как кому удобнее — важнее общий принцип.
Я называю так: «20140127. Краткое название съемки». Указывать каким фотоаппаратом отснято не вижу смысла — лишняя информация, которую легко определить взглядом на название файла.
Кстати файлы вообще не переименовываю, т.к. пока ты дочитаешь до нужного файла (фиг его знает как я 8 лет назад обозвал фотографию) проще в превьюшках найти. А вот если есть различные размеры, то в отдельные папки с названием (пример: 1280х724). И эти папки лежат в общей.
Также после обработки фотографий, удаляются все которые не обрабатывались. Остаются только отобранные оригиналы, обработанные оригиналы, ресайз. За более 10 лет не припомню, что бы возвращался к поиску чего то интересного в не удаленных оригиналах. А хранить такой объем нереально. У меня с одной съемки в среднем 1500 кадров. Из них 8-12% обрабатываются — остальное (~1300 кадров х ~10 мб = 13Гб. А если РАВы то еще больше) в корзину.
Вообще если интересно, могу расписать софт и систему хранения подробней.
Кстати файлы вообще не переименовываю, т.к. пока ты дочитаешь до нужного файла (фиг его знает как я 8 лет назад обозвал фотографию) проще в превьюшках найти. А вот если есть различные размеры, то в отдельные папки с названием (пример: 1280х724). И эти папки лежат в общей.
Также после обработки фотографий, удаляются все которые не обрабатывались. Остаются только отобранные оригиналы, обработанные оригиналы, ресайз. За более 10 лет не припомню, что бы возвращался к поиску чего то интересного в не удаленных оригиналах. А хранить такой объем нереально. У меня с одной съемки в среднем 1500 кадров. Из них 8-12% обрабатываются — остальное (~1300 кадров х ~10 мб = 13Гб. А если РАВы то еще больше) в корзину.
Вообще если интересно, могу расписать софт и систему хранения подробней.
Интересно, конечно. Всегда любопытно сравнить реализации.
Именование папок поддерживаю и использую, только без точки после даты (зачем?). Папка записывается в формате «ГГГГММДД Описание события, какое душе угодно, хоть с пробелами и запятыми», к примеру: «20130817 Поездка на шашлыки в горы». Да, названия длинные, но сейчас все ФС поддерживают, зато название папок говорит даже неподготовленному человеку, что это не шифровка.
Есть просто набор фотографий по одной-две в день. Для них отдельную папку нету смысла. Объединяю по месяцам и формат тот же, только без даты:
«ГГГГММ Описание», к примеру: «201312 Семья»
Потом как бы эти папки не копировать — они всегда отсортированы.
Есть просто набор фотографий по одной-две в день. Для них отдельную папку нету смысла. Объединяю по месяцам и формат тот же, только без даты:
«ГГГГММ Описание», к примеру: «201312 Семья»
Потом как бы эти папки не копировать — они всегда отсортированы.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
+к?
может это и не совсем правильно, но храню фотки в dng и могу рандомно править старые и новые, как избежать ситуации, что через энное время появятся битые копии и в бэкапах?
Насколько разумно работать сразу с файлами на NASе, а не с рабочей копией на шустром диске?
может это и не совсем правильно, но храню фотки в dng и могу рандомно править старые и новые, как избежать ситуации, что через энное время появятся битые копии и в бэкапах?
Насколько разумно работать сразу с файлами на NASе, а не с рабочей копией на шустром диске?
Откуда у вас появятся битые фотки? Обычный воркфлоу подразумевает первым этапом импорт фотографий (в лайтруме, апертуре и т.д. и т.п.) и на этом этапе вы видите что собираетесь переписывать с карты памяти. А дальше откуда появиться битым файлам? Если на рабочем компе файлы повредились — восстанавливаем из бэкапа.
Проблема, что нельзя уничтожать промежуточные копии, т.к. битый файл будет неотличим от исправленного.
Файл может побиться в результате вылета при правке например, и заметишь это при следующей правке или экспорте.
И нужно хранить все-все снапшоты.
Файл может побиться в результате вылета при правке например, и заметишь это при следующей правке или экспорте.
И нужно хранить все-все снапшоты.
>Откуда у вас появятся битые фотки?
За 10 лет может много разного произойти. В том числе спонтанные сбои в ФС. Ни одна из известных мне систем от этого не застрахована. Потери питания, отказы железа, переполнения диска. Может быть даже какие-нибудь сбои в программах-каталогизаторах. Факт, что фотографии, когда их много, иногда повреждаются. Наконец, человеческий фактор. Не раз ловил жену на том, что она, например, делала ресайз и сохраняла под именем оригинала. Отучить удалось, но кто знает, что будет ещё? :)
За 10 лет может много разного произойти. В том числе спонтанные сбои в ФС. Ни одна из известных мне систем от этого не застрахована. Потери питания, отказы железа, переполнения диска. Может быть даже какие-нибудь сбои в программах-каталогизаторах. Факт, что фотографии, когда их много, иногда повреждаются. Наконец, человеческий фактор. Не раз ловил жену на том, что она, например, делала ресайз и сохраняла под именем оригинала. Отучить удалось, но кто знает, что будет ещё? :)
У винчетеров, если не ошибаюсь возможна ошибка типа искажение данных примерно 1 бит на терабайт трафика. Если фотки перекладывать с места на место(кто его знает как там винда оптимизирует расположение казалось бы даже неподвижных файлов) то в перспективе таких ошибок может накопится достаточно много чтобы их заметить. Плюсуем сюда вероятность возникновения ошибки в RAM на бытовых ПК(без REGISTERED-модулей памяти) где такие ошибки даже не детектируются аппаратно, которые могут привести к искажению копируемых файлов.
>>Не раз ловил жену на том, что она, например, делала ресайз и сохраняла под именем оригинала.
Именно поэтому хороши iPhoto/Aperture/Lightroom — они не изменяют исходный файл.
А вот первую половину комментария я всё же не очень понял. Мы же тут бэкап обсуждаем. Битые фотки отсекаются на первом этапе — импорта в iPhoto/Aperture/Lightroom. А дальше есть минимум 2 копии (а по хорошему должна быть ещё и третья — оффсайт) и в случае повреждения основной копии достаётся вариант из бэкапа. Если бэкап повреждён — тогда достаётся копия из архива/оффсайт бэкапа.
Но вообще вопрос интересный. Если хочется обеспечить и контролировать целостность второй и n-копии, то я нагуглил программу ICE ECC и её аналоги suse.me/soft/ice-ecc/all/
Именно поэтому хороши iPhoto/Aperture/Lightroom — они не изменяют исходный файл.
А вот первую половину комментария я всё же не очень понял. Мы же тут бэкап обсуждаем. Битые фотки отсекаются на первом этапе — импорта в iPhoto/Aperture/Lightroom. А дальше есть минимум 2 копии (а по хорошему должна быть ещё и третья — оффсайт) и в случае повреждения основной копии достаётся вариант из бэкапа. Если бэкап повреждён — тогда достаётся копия из архива/оффсайт бэкапа.
Но вообще вопрос интересный. Если хочется обеспечить и контролировать целостность второй и n-копии, то я нагуглил программу ICE ECC и её аналоги suse.me/soft/ice-ecc/all/
>Именно поэтому хороши iPhoto/Aperture/Lightroom — они не изменяют исходный файл.
Или постоянно используемая мной Picasa. Но жена бывает умная. И достаёт свой инструмент, хоть GIMP, хоть Photoshop :)
>А вот первую половину комментария я всё же не очень понял. Мы же тут бэкап обсуждаем.
Имеется в виду такая ситуация. Где-то в основном каталоге повреждается фотография. Ты её не открываешь и не видишь, что она повреждена. Через N времени она забекапится во все бэкапы. Уничтожив свои копии. Ещё через K времени открываешь фото, видишь, что оно битое. Лезешь в бэкап. А она и там уже сохранена в таком виде.
Решается этот вопрос или проверкой целостности фото при бэкапе (что нетривиально и не спасёт от повреждений, не приводящих к детектируемому повреждению), или, что лучше, версионным бэкапом. Когда при бэкапе изменённой версии файла сохраняется также и старая версия.
Или постоянно используемая мной Picasa. Но жена бывает умная. И достаёт свой инструмент, хоть GIMP, хоть Photoshop :)
>А вот первую половину комментария я всё же не очень понял. Мы же тут бэкап обсуждаем.
Имеется в виду такая ситуация. Где-то в основном каталоге повреждается фотография. Ты её не открываешь и не видишь, что она повреждена. Через N времени она забекапится во все бэкапы. Уничтожив свои копии. Ещё через K времени открываешь фото, видишь, что оно битое. Лезешь в бэкап. А она и там уже сохранена в таком виде.
Решается этот вопрос или проверкой целостности фото при бэкапе (что нетривиально и не спасёт от повреждений, не приводящих к детектируемому повреждению), или, что лучше, версионным бэкапом. Когда при бэкапе изменённой версии файла сохраняется также и старая версия.
Я согласен 100%.
Поэтому я и написал про то, что рабочие фото должны сохраняться обязательно версионным бэкапом и обязательно автоматически. Иначе потеря 4-10% снимков почти неизбежна.
С архивами, при правильной организации, такого почти не происходит. И бэкапить архивы лучше только после предварительного хотя бы беглого просмотра, вручную или полуавтоматически (с программой/скриптом, но без шедулинга), кмк.
Поэтому я и написал про то, что рабочие фото должны сохраняться обязательно версионным бэкапом и обязательно автоматически. Иначе потеря 4-10% снимков почти неизбежна.
С архивами, при правильной организации, такого почти не происходит. И бэкапить архивы лучше только после предварительного хотя бы беглого просмотра, вручную или полуавтоматически (с программой/скриптом, но без шедулинга), кмк.
Может быть это и неправильно, но я сохраняю лайтрумом измененияв dng-шках, т.к. иногда правлю на разных компах.
>Дело в том, что в данный момент я делаю бэкапы простым копированием фотографий на несколько дисков. Но иногда, время от времени, у меня появляются битые файлы. Если их не отследить и вовремя не восстановить, то они проникают во все копии, и файл потерян… Как быть в такой ситуации?
Я использую версионные бекапы через unison. В случае изменения фотографии в бэкапе будет и старая и новая версии. И так до заданной в параметрах глубины. Так что при обнаружении потери всегда можно найти последнюю целую версию.
Я использую версионные бекапы через unison. В случае изменения фотографии в бэкапе будет и старая и новая версии. И так до заданной в параметрах глубины. Так что при обнаружении потери всегда можно найти последнюю целую версию.
не знаю, зачем нужно трогать названия файлов. там же хронология собьется тогда при последовательном просмотре.
мне достаточно того, что есть папка с годом, в ней папки по месяцам, типа «1312» или «1401». ну если требуется выделить что-то более важное, то создается дополнительная папка «1401. Событие». итого, в каждой папке редко больше полутысячи кадров и превьюшек в виндовс эксплорере более чем достаточно, чтобы найти что то конкретное.
p.s. есть 1 минус — нужно приблизительно помнить год и месяц события, если что-то ищешь :)
мне достаточно того, что есть папка с годом, в ней папки по месяцам, типа «1312» или «1401». ну если требуется выделить что-то более важное, то создается дополнительная папка «1401. Событие». итого, в каждой папке редко больше полутысячи кадров и превьюшек в виндовс эксплорере более чем достаточно, чтобы найти что то конкретное.
p.s. есть 1 минус — нужно приблизительно помнить год и месяц события, если что-то ищешь :)
То ли я не смог понять, как с ним работать
Честное признание смягчает вину :) Time Machine делает копию каждый час. Вот хотя бы описание на вики. В чем расточительность подхода — не понятно. В настойках можно задать правила исключения для уменьшения объема резервных копий.
Конечно эта программа не позволяет настраивать множественный бэкап в несколько мест, но для этого в Mac OS есть другие средства — например, скрипты Automator. Вот пример такого скрипта.
Если совсем серьёзно подходить к вопросу бэкапа, то нужно организовывать и офф-сайт бэкап — т.е. резервную копию в другом месте. Хранить один из резервных дисков у родителей/родственников. Или воспользоваться онлайн сервисом типа CrashPlan.
Я не понял что за Workflow. Это рабочий tmp в котором происходит только обработка изображений? Или эта название всего фото архива? И еще, с какими объемами вы работаете/храните, в ГБ?
Какой-то у вас слишком сложный малопонятный процесс. Я бы сказал прям зоопарк программ и утилит. При таком подходе точно что-то сломается. Часть задач делается руками, что вообще ужасно. Потом
Какой-то у вас слишком сложный малопонятный процесс. Я бы сказал прям зоопарк программ и утилит. При таком подходе точно что-то сломается. Часть задач делается руками, что вообще ужасно. Потом
кульное "личное облако" я так понимаю вы храните в одном помещении, что сводит на нет всю идею архивации. 
Да, касательно именования, думаю, нужно доработать.
У меня, так как фото обычно сугубо семейные, сделано так (Total Commander с фильтрами и массовым переименованием, в т.ч. по EXIF, очень способствует):
Папки именуются: «ГГГГ-ММ-ДД. [_]Событие_или_предметы» (нижнее подчеркивание добавляется при сверхважном событии).
Подпапки: CR2 (Canon потому что), web, proc (для обработанных).
Файлы: ГГГГ-ММ-ДД_ЧЧ-ММ-СС_ИсходноеИмя[_(proc|web|crop|compr)].(JPG|CR2) — таким образом исключается появление файлов с одинаковыми именам.
Проблема возникла только раз, когда сортировал снимки с Nokia 6300, которая, как оказалось, не записывала EXIF, а даты файлов были утеряны ввиду копирования с компьютера на компьютер. Ну папки все до сих пор не подписал :-)
У меня, так как фото обычно сугубо семейные, сделано так (Total Commander с фильтрами и массовым переименованием, в т.ч. по EXIF, очень способствует):
Папки именуются: «ГГГГ-ММ-ДД. [_]Событие_или_предметы» (нижнее подчеркивание добавляется при сверхважном событии).
Подпапки: CR2 (Canon потому что), web, proc (для обработанных).
Файлы: ГГГГ-ММ-ДД_ЧЧ-ММ-СС_ИсходноеИмя[_(proc|web|crop|compr)].(JPG|CR2) — таким образом исключается появление файлов с одинаковыми именам.
Проблема возникла только раз, когда сортировал снимки с Nokia 6300, которая, как оказалось, не записывала EXIF, а даты файлов были утеряны ввиду копирования с компьютера на компьютер. Ну папки все до сих пор не подписал :-)
К сожалению, бэкап фото «как файлов» не спасёт от вирусов — шифровальщиков или удаляторов. Они обычно «перерабатывают» всё, до чего могут дотянуться, в том числе и внешние устройства. Засунув однажды флешку в комп с намерением сделать бэкап, можно обнаружить, что всё на ней и на самом компе зашифровано.
Бэкапить надо куда-нибудь, где удаление и/или изменение — процесс нетривиальный. На DVD/CD, в специальные фототеки (Яндекс фотки, Flickr и прочее), какие-нибудь хитрые внешние хранилища с запретом на модификацию данных.
Бэкапить надо куда-нибудь, где удаление и/или изменение — процесс нетривиальный. На DVD/CD, в специальные фототеки (Яндекс фотки, Flickr и прочее), какие-нибудь хитрые внешние хранилища с запретом на модификацию данных.
DVD/CD
1. Муторно из-за маленького объема.
2. Крайне ненадежно. Краткосрочный бэкап возможен, но точно не архивирование. Однажды попробовал — через год не читалось примерно 20 %.
1. Муторно из-за маленького объема.
2. Крайне ненадежно. Краткосрочный бэкап возможен, но точно не архивирование. Однажды попробовал — через год не читалось примерно 20 %.
Покупаем три или более внешних USB-винчестера.
Пишем резкопию на первый. Отключаем. Проверяем на читабельность на другой машине с другой операционкой. В следующий раз пишем на второй, третий, затем чередуем винты.
Три винта защищают от одновременного вирусования и помирания одного винта.
Пишем резкопию на первый. Отключаем. Проверяем на читабельность на другой машине с другой операционкой. В следующий раз пишем на второй, третий, затем чередуем винты.
Три винта защищают от одновременного вирусования и помирания одного винта.
Это не защитит от падения всех трех винтов на пол… ведь они наверняка будут хранится на одной полке. А если их физически разнести — сильно усложнится логистика, повысится вероятность отказа от своевременного выполнения этой процедуры(только когда петух клюнет).
Это прям даже не программный, а какой-то мануальный RAID-1. Классическое решение с бэкапом habrahabr.ru/company/veeam/blog/188544/
В случае хранения их в трех разных местах? Гарантий, конечно, нет, но вероятность резко снизит.
В любом случае — как и при кое-какой иной деятельности, нужно построить модель угроз (в данном случае — сохранности информации), расписать риски, часть их принять, часть передать, часть парировать тем или иным образом.
Универсального рецепта нет.
Чем больше рисков — тем сложнее и геморройнее обслуживание этого бэкапа.
В любом случае — как и при кое-какой иной деятельности, нужно построить модель угроз (в данном случае — сохранности информации), расписать риски, часть их принять, часть передать, часть парировать тем или иным образом.
Универсального рецепта нет.
Чем больше рисков — тем сложнее и геморройнее обслуживание этого бэкапа.
Я очень много фотаю, у меня такая структура папок на NAS:
Кроме того, я стараюсь тэгировать всё в Picasa, а вопрос бэкапа решается отдельным съёмным диском, который храню в другом географическом месте (да, это не очень оперативно, зато надёжно).
%Год%
%Месяц%-%день% %Название альбома%
Здесь JPEGи
RAW
Здесь RAWы
Кроме того, я стараюсь тэгировать всё в Picasa, а вопрос бэкапа решается отдельным съёмным диском, который храню в другом географическом месте (да, это не очень оперативно, зато надёжно).
Стандартное средство бэкапа на Mac OS X – Time Machine — показалось мне откровенно ужаснымЭто внешне всё выгрядит как копия. Если файл не менялся, то создаются жесткие ссылки на одно и то же содержимое. Физически неизмененные файлы не дублируются. По крайней мере про Mac OS пишут так, а лично подобное делал в Debian с rsync. Удобно. И хотя жесткие ссылки есть в NTFS, подобной утилиты для Windows не видел (и не искал сильно)
Честно скажу: не уверен. Т.е. если у меня копия занимает 121 Гб на диске, то и копия на следующий день будет занимать столько же. А учитывая, что большая часть диска — это и есть фото, то получается. что там одних ссылок на ~100 Гб, что всё-таки маловероятно :)
Абсолютно точно создаются жесткие ссылки там где это возможно. Скорее всего файлы тем или иным образом изменяются. Вот например если я в течении дня не включал Parallels и не монтировал 80 гигабайтный файл с виртуальной машиной — мой бекап обычно меньше гигабайта, если включил, то 80+ гб =) Оптяь же если Вы смотрите размер папки бекапа средствами finder, то он будет соответствовать объему всей информации, которую Вы бекапите, но при этом она дедуплицирована. Например суммарный объем папок бекапа может быть >20 тб на 3 тб жестком диске =)
Хмм… это точно нигде не настраивается?
Я, устав от огромных размеров бэкапов, полез на импортные форумы и там наткнулся на жалобы, что копирование производится «в лоб».
В любом случае, ТМ не устраивает меня именно отсутствием гибкости в настройках, а не только и не столько размером файлов и способом копирования. Но на всякий случай — буду иметь в виду.
Я, устав от огромных размеров бэкапов, полез на импортные форумы и там наткнулся на жалобы, что копирование производится «в лоб».
В любом случае, ТМ не устраивает меня именно отсутствием гибкости в настройках, а не только и не столько размером файлов и способом копирования. Но на всякий случай — буду иметь в виду.
Ну у меня на тайм капсуле хранятся бекапы более чем за год. При этом бекапится все, а винчестер(650 гб) обычно забит больше чем на 80%. Копированием в лоб вряд ли можно этого добиться)
Из настроек — кроме возможности исключать некоторые папки из бекапов я ничего не видел
Из настроек — кроме возможности исключать некоторые папки из бекапов я ничего не видел
Возможно файловая система на внешнем диске не подерживает жесткие ссылки?
TimeMachine требует исключительно HFS+ для работы, которая полдерживает жёсткие ссылки. На других файловых системах можно создать расширяемый образ, в котором будет уже требуемая ФС.
Копия делается исключительно жёсткими ссылками + набор изменений по сравнению с предыдущей копией. Любое изменение файла (переименование, поворот, изменение тегов [если они пишутся в файл]) делает файл отличающимся и система копирует его полностью заново. Периодичность копирования можно настроить сторонним софтом, ежечасное копирование может показаться слишком частым, особенно при таких размерах фотографий (скинул фото – забекапились; разобрал, переименовал, разложил по папкам – забекапились заново; подретушировал – ещё одна копия…).
Кстати, бесплатной программой BackupLoupe можно посмотреть реальный размер каждой копии. Если в копию попало что-то лишнее, то от этой копии можно избавиться, но это не очень просто и очень долго из-за огромного количества файлов.
Копия делается исключительно жёсткими ссылками + набор изменений по сравнению с предыдущей копией. Любое изменение файла (переименование, поворот, изменение тегов [если они пишутся в файл]) делает файл отличающимся и система копирует его полностью заново. Периодичность копирования можно настроить сторонним софтом, ежечасное копирование может показаться слишком частым, особенно при таких размерах фотографий (скинул фото – забекапились; разобрал, переименовал, разложил по папкам – забекапились заново; подретушировал – ещё одна копия…).
Кстати, бесплатной программой BackupLoupe можно посмотреть реальный размер каждой копии. Если в копию попало что-то лишнее, то от этой копии можно избавиться, но это не очень просто и очень долго из-за огромного количества файлов.
подобной утилиты для Windows не видел (и не искал сильно)Реализация резервного копирования на хардлинках под Windows
Резервное копирование на хардлинках под Windows
НЛО прилетело и опубликовало эту надпись здесь
Подкину свою балалайку: полностью отказался от идеи переименования файлов в пользу размещения тегов в EXIF и работе с тегами через интерфейс БД. Использую очень удобную систему phtagr, которая:
а) хранит теги в Exif и дублирует их в базе данных
б) поиск, превью, гео-тегирование
в) нет ограничений на количество фотографий (у меня около 70 тыс)
г) удалённый доступ (веб-интерфейс)
Теги дают существенно большую свободу, так как помимо ключевых персонажей я указываю ещё название мероприятия, например. Таким образом, найти фото дочери в Кратово, или, скажем, обеих сразу, можно указав теги «Ася», «Кратово», «Варя» и проч.
Храню на NAS на базе HP Microserver, основное хранилище дома на NAS4Free, точно такое же у родителей (5 км по прямой) дома под столом, настроена репликация средствами zfs. Кучка скриптов помогают мне автоматизировать работу. Фактически фото- и видео- файлы хранятся в папках вида /2013/2013-01-27/, что даёт возможность быстро ответить на вопрос, скопированы ли файлы с этой флешки на хранилище. Скрипты читают время съемки и раскладывают по папочкам. В результате процесс копирования занимает минуты и считанные клики, а классификация — это уже не спеша хоть с планшета, хоть из гостей.
Данные сами ночью среплицируются к родителям. Обычно спустя два-три дня флешка очищается, чтобы не вносить сумятицу.
Плохо то, что репликация средствами файловой системы — это не бекап. Поэтому делаю скраббинг раз в две недели и слежу за логами.
а) хранит теги в Exif и дублирует их в базе данных
б) поиск, превью, гео-тегирование
в) нет ограничений на количество фотографий (у меня около 70 тыс)
г) удалённый доступ (веб-интерфейс)
Теги дают существенно большую свободу, так как помимо ключевых персонажей я указываю ещё название мероприятия, например. Таким образом, найти фото дочери в Кратово, или, скажем, обеих сразу, можно указав теги «Ася», «Кратово», «Варя» и проч.
Храню на NAS на базе HP Microserver, основное хранилище дома на NAS4Free, точно такое же у родителей (5 км по прямой) дома под столом, настроена репликация средствами zfs. Кучка скриптов помогают мне автоматизировать работу. Фактически фото- и видео- файлы хранятся в папках вида /2013/2013-01-27/, что даёт возможность быстро ответить на вопрос, скопированы ли файлы с этой флешки на хранилище. Скрипты читают время съемки и раскладывают по папочкам. В результате процесс копирования занимает минуты и считанные клики, а классификация — это уже не спеша хоть с планшета, хоть из гостей.
Данные сами ночью среплицируются к родителям. Обычно спустя два-три дня флешка очищается, чтобы не вносить сумятицу.
Плохо то, что репликация средствами файловой системы — это не бекап. Поэтому делаю скраббинг раз в две недели и слежу за логами.
От себя могу порекомендовать BTSync. Схема такова — я бросаю свежие фотографии на HDD. Демон BTSync быстро реплицирует изменения на домашний сервер, сервер отца и остальные машины родственников. В итоге все получают свежие фотографии внука за короткий срок. Torrent-технология позволяет балансировать нагрузку на канал за счёт суммирования полосы доступа.
Одна из опасностей многосторонней синхронизации — при (случайном) удалении на любой машине, данные исчезают везде. Не столь актуально при односторонней синхронизации, но в любом случае, хранить критичные данные под управлением программы с закрытым кодом и находящейся в статусе беты… немного рискованно. То есть это не отменяет какое-то основное резервное копирование.
Простите, что задаю странный вопрос — а чем в качестве каталогизатора не устраивает тот же Lightroom?
Выборка по датам съемки — есть, тегирование — есть, цветовые метки (удобно показывать степень обработки файлов) — есть, стекирование снимков — есть.
И бэкапирование сводится, по сути, к копированию папки с файлами и файлов каталога.
Выборка по датам съемки — есть, тегирование — есть, цветовые метки (удобно показывать степень обработки файлов) — есть, стекирование снимков — есть.
И бэкапирование сводится, по сути, к копированию папки с файлами и файлов каталога.
Вся эта статья с набором банальностей вполне может свестись к одной фразе:
— при скидывании фоток, надо не ленится осмысленно называть целевой каталог.
— при скидывании фоток, надо не ленится осмысленно называть целевой каталог.
Снимаю в RAW на одну SD карту, в базовый JPG — на другую. Скидываю в одну папку RAW'ы, в ней вложенная папка «JPG» c легковесными копиями фотографий, которые можно просматривать даже смартфоном. Именую папки «0001 — (Описание события) — 01.01.2014». На домашнем компьютере 1 копия всех файлов, на NAS — 2 копия, в облаке — 3 копия. Для публикации, для печати — после использования не храню.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каталогизация и резервирование персонального фотоархива