Недавно один весьма прогрессивный молодой человек назвал меня ретроградом, за то что я предложил по его мнению слишком ламповый способ хранения данных.
Поэтому полагаю что все очень прогрессивные молодые люди будут огорчены моей статьей - ведь в ней нет ни ссылок на гитхаб, ни облаков, ни даже строчки питона. Всего лишь описание способа, который позволил мне не потерять нисколько моих работ и данных за 15 лет, несмотря на не менее 10 ситуаций, когда жесткий диск с этими данными либо выходил из строя, либо терялся.
Всем фанатам светодиодов дальше лучше не читать.
Много лет назад - еще когда интернет можно было добыть только из модема) я как и многие другие люди познакомился с PC. Неизбежно в процессе общения начали накапливаться файлы, в которых находились проекты, документация, музыка, развлечения - как обычно. Тк работаю я и дома и на работе, очень быстро возникла проблема единообразия среды - хотелось сидеть в кресле где угодно, слушая одну и ту же музыку, фильмы, книги и делать работу одинаково вне зависимости от места.
Через некоторое время выкристаллизовался способ делать это. У меня сформировалось несколько папок - это work(проекты), hard(документация), distr(дистрибутивы ПО) и relax(развлечения).
Эти папки разные по важности находящихся в них данных и по частоте их обновления - если рабочие папки work+hard могут обновляться несколько раз в день, то дистрибутивы и развлечения иногда по месяцу не испытывают никаких изменений. На сегодняшний день, work+hard весят в сумме менее 256 ГБ.
Рабочих мест у меня всегда было не менее 3 - работа, дом, мастерская. 256ГБ по нынешним меркам это очень скромно, поэтому рабочие данные хранятся на каждом компьютере каждого рабочего места.
Итого, вместе с мастер-диском SSD, который всегда в моей сумке получается 4 копии. Алгоритм работы такой: приходя на любое рабочее место я включаю в компьютер USB шнурок с носителем, и запускаю в Total Commander синхронизацию директорий. Работа ВСЕГДА происходит с данными на мастер-диске и поэтому именно на нем всегда находится самая свежая версия файлового архива. Поэтому направление синхронизации ВСЕГДА одно и тоже - все изменения переливаются с мастер-диска на очередной резервный диск - диск компьютера локального рабочего места. Это позволяет не тратить много времени и внимания на этот процесс. Всего лишь 5 тычков мышкой и пара минут.
После этой синхронизации у меня есть две идентичные копии файлового архива, что очень удобно, тк все люди ошибаются, и периодически я например удаляю нужные рабочие файлы. Из второй копии их можно мгновенно восстановить. По окончании работ происходит повторная синхронизация мастер диска на локальный диск рабочего места. Так работаем на всех рабочих местах.
Таким образом если мы по любой причине мастер диск потеряем, то все сделанные где угодно изменения нам доступны, стоит лишь добраться до последнего рабочего места. А дома или на работе наш рабочий архив будет не более чем на день-два отставать от последней версии.
Что касается гораздо более обьемных дистрибутивов и развлечений, с ними алгоритм такой же. За тем исключением, что там в виду меньшей ценности данных как мастер диск можно использовать обычный 2.5" ноутбучный винчестер. Да и самих точек резервирования достаточно 2. В принципе, можно вообще не носить с собой мастер диск этих данных, и брать его лишь в путешествия либо для очередной необходимой синхронизации файлового архива.
Важный вопрос - безопасность файловых архивов. Это решается с помощью любой утилиты криптования диска на лету. Например мне очень нравится TrueCrypt. TrueCrypt абсолютно прозрачен для пользователя и очень быстр, после того как диск подключен, вы не почувствуете никакой разницы в работе с ним или без него. В ваше отсутствие ваши данные недоступны.
Пользуясь таким алгоритмом хранения, я пережил за 15 лет без потерь ???? потерю примерно 10 жестких дисков - как мастеров, так и обычных резервных дисков. В отличии от других людей, которые в таких ситуациях начинали бегать и волноваться, я спокойно выбрасывал диск в корзину, вставлял в машину новый и заливал на него требуемый файловый архив.
Я работаю под Windows, любители unix систем могут автоматизировать синхронизацию на запуске машины и сделать процесс синхронизаций абсолютно автоматическим.
Об особых случаях. Такой механизм хранения оказался уязвим к одной проблеме. Если мастер диск окажется поврежден так, что СОДЕРЖИМОЕ файлов в нем начнет биться, то мы рискуем размножить битые файлы. Однажды (это было давно, и рабочим мастер-диском тогда был обычный ноутбучный диск) у меня возникла такая ситуация. Тогда мне также удалось ничего не потерять, хотя это стоило большего труда, чем обычная синхронизация.
Важно то что работа происходит все время с мастер диска. Когда обычный жесткий диск начинается сыпаться, дефекты начинают появляться на нем везде. Тк при работе используется достаточно много файлов рабочего файлового архива, в тот раз я достаточно быстро наткнулся на битые файлы. У TotalCommander-а есть разные режимы сравнения директорий - со сравнением содержимого файлов, и без. В обычных ежедневных синхронизациях я не включаю сравнение файлов по содержимому, как показывает опыт, это не нужно. Но когда стало ясно что мастер диск повреждает данные, тогда уже пришлось делать синхронизацию файлового архива по содержимому и просматривать diff-ы.
Оказалось, что поврежденных файлов было мало, все они были доступны в зеркалах.
Очередной диск отправился в помойку, я сохранил весь файловый архив без потерь ценой 2 часов труда. За 15 лет такая ситуация возникла 1 раз, SSD который после этого был выбран мастер-диском рабочих файлов работает без нареканий уже года 4.
Желаю всем дочитавшим до конца теплой ламповой безопасности!
Комментарии (159)
anatolykern
05.12.2021 01:39+3Использовал раньше схожую систему с rsync и несколькими дисками, но необходимость любых ручных действий - путь к ошибкам. Именно поэтому в настоящее время гораздо удобнее работать с онлайн системами. Например Dropbox+Backblaze решают эту проблему без необходимости каких-либо ручных действий, добавляя функциональности типа доступа с мобильных устройств и синхронизации фото.
Indemsys
05.12.2021 02:08Backblaze нигде не пишет что он предназначен для синхронизации.
anatolykern
05.12.2021 02:31+1Эти дополнительные функции относятся к Dropbox. Backblaze добавляет version history и offline storage на случай потери всех физических носителей, например в ситуации с приходом "товарищей" и изъятием всего и вся.
Loggus66
05.12.2021 02:07А ещё есть rsync с бэкапным ключом: на точке назначения хранятся актуальные данные, а дифф от актуальных данных переносится в "бэкап за такое-то число".
Плюс - что даёт USB-диск? Копию. Ежели резервный диск неудачно поломается, то информацию с него придётся вытягивать. На сервере же можно многократно усилить защиту от поломок резервного диска с помощью RAID, следующий риск уже - кража сервера или пожар, ну тут уже LTO и 3-2-1 вступают в игру. Каждый сам решает, стоит ли противодействие рискам затрат, однако первый абзац моего коммента полностью решил бы проблему с битыми файлами, т. к. оригиналы ушли бы в каталог того дня, когда начались проблемы.
Finder001 Автор
05.12.2021 03:37+2Зачем что-то вытягивать ?
Если ломается мастер-диск, то образ заливается в новый мастер-диск из последнего живого места бакапа - с работы или из дома.
Если ломается один из локальных дисков, то туда просто перезаливается образ с мастер-диска. В любом случае ничего ниоткуда вытягивать не надо, в этом вся прелесть метода.
aborouhin
05.12.2021 02:58+4Облако - Seafile на своём виртуальном сервере, у которого в качестве хранилища Backblaze B2 (виртуалка у Vultr, у них трафик на/с Backblaze бесплатный, что при многотерабайтовых объёмах приятно). Имеем синхронизацию, шифрование, доступ с мобильных устройств и прочие удалённые сценарии работы + первый (облачный) бекап.
С этого же облака идёт синхронизация на домашний сервер. Там ZFS, которая, по-первых, RAID (Z2, аналог RAID-6), во-вторых, регулярные снэпшоты, которые дают историю изменений глубиной в 1 год (эту историю можно было бы и в Seafile реализовать, но файлов у меня весьма прилично по размеру, место в облаке стóит денег, а потребность восстанавливать старые версии возникает очень редко). Это второй бекап, который и территориально в другом месте, и риски его утраты совершенно другие, чем у первого.
В итоге все риски утери данных максимально закрыты (насколько это, на мой взгляд, разумно для домашнего применения), никаких ручных телодвижений, всё в реальном времени, ну и паранойя по поводу приватности тоже удовлетворена. Если уж сейчас, в отличие от 15 лет назад, можно сделать удобнее и надёжнее, - грех не сделать.
Finder001 Автор
05.12.2021 03:27+1У меня приятель один из лучших ремонтников HDD Москвы. Рассказывал как народ приносит ему харды из осыпавшихся RAID-ов и просит достать оттуда данные. Не понравилось((
Сам я ставить RAID даже не пытался, тк не вижу смысла - зачем мне рейд, если я могу сделать просто 3 независимые копии, да еще и разнести их в пространстве ?
Защитить таким образом все от пожара/ограбления/потопа - или от их комбинации)
aborouhin
05.12.2021 03:59+2Если бы RAID решал все проблемы - ничего из описанного мной, кроме RAID, и не надо было бы :) RAID решает одну конкретную проблему - если сыпется один диск (в RAID-6 даже два, но лучше не доводить до такого), можно его поменять, не перекачивая терабайты данных заново ( у меня на сервере архив данных что-то около 20 Тб, так что это было бы долго и дорого). Т.е. RAID просто уменьшает частоту отказов и увеличивает удобство обслуживания одной из копий данных. Но никоим образом не заменяет необходимости иметь другие копии (в моём случае - рабочий ноут и облако для документов, для других данных другие сочетания, но копий всегда не менее трёх).
aborouhin
05.12.2021 04:09+2Защитить таким образом все от пожара/ограбления/потопа - или от их комбинации)
От маски-шоу, которое приедет к Вам и на работу, и домой, и в мастерскую с выносом всей техники Ваш способ не поможет. А это сценарий куда вероятнее потопа, даже если Вы свято верите, что к Вам-то никаких вопросов никогда не будет :)
Finder001 Автор
05.12.2021 04:13Я не верю свято что вопросов не будет, ясно что докопаться можно при желании и до столба. Как говорится ничто не вечно под луной)
Но 3 независимых полных территориально разнесенных бакапа теоретически лучше чем 1 централизованный, только об этом)
aborouhin
05.12.2021 04:19А кто говорит про один централизованный? В этом и прелесть облака, что его изъять не получится :)
Finder001 Автор
05.12.2021 04:22+3Признаться я категорический противник облаков. Надеюсь еще сделать/написать на эту тему что-то.
Сомневаюсь также, что маски шоу отправятся процессией по всем местам Вашего пребывания. Приедут на работу и выгребут все - да. Чтобы они поехали на квартиру к теще - это я думаю врядли. Думаю они работают без вдохновения, Дзержинских сейчас там нет)
aborouhin
05.12.2021 04:28+2Ну если неприязнь к облакам носит религиозный характер - то тут спорить бессмысленно :) Хотя чем Вам частное облако не угодило, любопытно было бы узнать.
Finder001 Автор
05.12.2021 04:32+3Ну это примерно как поддержка отказа от налички. Вроде бы кеш анахронизм...да вот только штрафы сегодня списываются с любой карты автоматически, и у юзеров нет почти никакой возможности противостоять ошибкам системы, а они случаются((
Примерно так и с облаками. Я сторонник offline систем.
По-другому, недавно у моего сотового оператора упала сеть. Я ехал в магазин, в навигаторе была проложена трасса, когда связь полностью исчезла. Трассу я при предсмертных глюках сети неосторожно сбросил, и оказался вдруг посреди дороги - в полных непонятках - где я и куда я еду((( Через 10 минут копания в телефоне обнаружился там чудом 2ГИС с базой и адрес куда я ехал, я смог перепроложить маршрут и всеже добраться. Но ощущение было как будто оказался на луне(((
Очень не понравилось((
aborouhin
05.12.2021 04:38+1Ну так у меня изначальная мысль и была в том, что риски есть и у оффлайн, и у облачных резервных копий.
Оффлайн - гибель носителя, изъятие, невозможность доступа к носителю (пришлось всё бросить и улететь и т.п.) Облака - невозможность оплаты, провайдер сдуру прекратил обслуживание (abuse прилетел, санкции, просто глюк системы), невозможность доступа (РКН ввёл белые списки и границу закрыли). Ну и т.п.
Но риски эти разные, и вероятность, что они наступят одновременно, пренебрежимо мала. Поэтому одна оффлайн копия (домашний сервер), одна облачная - надёжнее, чем две оффлайн.
Finder001 Автор
05.12.2021 04:44+1В этих рассуждениях безусловно есть зерно.
Чем Вы защищены от ВЛАДЕЛЬЦА облака ? Криптованием ?
Если ПО взаимодействия с облаком надежно защищает Вас от утечки ЧЕРЕЗ облако - то да, Ваша схема дает еще большую защиту чем моя.
Все эти истории - о том как фейсбук например пользуется анонимными данными своих клиентов, которые какбы в итоге не совсем становятся анонимными - наводят на некоторые мысли и сомнения(((
aborouhin
05.12.2021 04:58В Seafile сквозное шифрование, так что владелец облачной инфраструктуры, где данные, собственно, хранятся (Backblaze в моём случае) незашифрованные данные не видит вообще никогда. Впрочем, тот факт, что этот владелец находится в иностранной юрисдикции и не имеет представительства в РФ, достаточно успокаивает сам по себе. Но шифрование, безусловно, ещё более помогает от паранойи :)
Но это уже другой вопрос - защита данных (чтобы не прочитали кому не надо). Я пока что ограничивался вопросами сохранности данных (чтобы свести к минимуму шанс, что я сам когда-нибудь не смогу их прочитать).
Finder001 Автор
05.12.2021 05:03Честно говоря у меня однажды возникло ощущение, что надежность построенной системы сильно выше чем моя собственная, и это тоже было неприятное открытие)
Вообще-то оба вопроса бывают важны - думаю Сноуден хорошо об этом знает, хорошо что мы не знаем то что знает он))
Интересно, спасибо, нужно будет посмотреть внимательно на Ваш способ.
mikhailian
05.12.2021 12:17Да в общем-то не надо и частного облака. Шифровать данные перед бекапом умеют многие продукты.
Я пользуюсь restic, копирую в холодное хранилище на GCP. Всё шифруется и расшифровывается прямо на компьютере, где запущен restic.
MillaBren
05.12.2021 13:49А почему бы просто копию диска под ТруКриптом не залить в облако? В чем здесь может быть минус?
Finder001 Автор
05.12.2021 13:50Наверное в том что конкретно TrueCrypt откажется работать с образом в облаке: он локальный. Впрочем я так понимаю предложено немало софта, реализующего именно такой принцип.
MillaBren
06.12.2021 08:16+1Мне вариант с нелокальным образом даже в голову не пришёл, а вы сразу минусовать:) я имела в виду заливать только залоченный цельный диск как отдельный файл, когда трукрипт с ним уже не работает.
Но ниже уже ответили, что из-за объёма при загрузке в облако. Хотя облака и скорости доступа тоже разные бывают, да и данные можно разбить.
maxwolf
05.12.2021 18:53+4Например в том, что этот «диск» — монолитный, и его нужно каждый раз копировать целиком, что накладно, либо быть готовым столкнуться с неконсистентностью данных при частичном копировании.
redmanmale
06.12.2021 00:04Для телефонов есть опенсорсный бесплатный Organic Maps (на базе OSM).
После установки можно скачать любые регионы, и карта будет полностью оффлайн, с построением маршрутов и прочим.
Dolios
05.12.2021 13:47Интересно. А у вас нет, случайно, ссылки готовый на мануал, как все это подружить?
aborouhin
05.12.2021 14:56По Seafile мне хватило его родной документации. Использование S3-совместимого облачного хранилища, в т.ч. Backblaze, - это штатный описанный в ней случай. Вообще, натолкнулся на упоминание Seafile здесь же на Хабре в комментах, когда уже начал разбираться с Nextcloud - и остался очень доволен.
Про ту часть, которая у меня на домашнем сервере, - там всё специфично для моего железа и конфигурации (у меня там, скажем, Proxmox), но тоже никаких уникальных решений, вроде, нет. По zfs сильно рекомендую в cron сразу поставить регулярный scrub, это одно из его преимуществ перед железным RAID'ом. Ну и zfssnap для снэпшотов, которые обеспечивают историю версий.
Dolios
05.12.2021 15:11Использование S3-совместимого облачного хранилища, в т.ч. Backblaze, — это штатный описанный в ней случай.
Понял, спасибо, буду смотреть доку по S3. Я правильно понял, что за $7 Backblaze дает неограниченное по объему хранилище для бэкапов? А где подвох?
aborouhin
05.12.2021 19:51за $7 Backblaze дает неограниченное по объему хранилище для бэкапов? А где подвох?
Я не скажу ничего за их тарифы для personal backup, я использую Backblaze B2 для бизнеса, там тарификация помегабайтная. Но из того, что мне подходит, это оказался самый дешёвый вариант.
maxwolf
05.12.2021 19:33Раз Вы разбирались и в nextcloud, и в seafile — можете коротенько описать их различия и Ваши от них впечатления?
aborouhin
05.12.2021 19:48+2Ну если очень коротко, то Nextcloud/Owncloud - это такой комбайн, который и облачное хранилище, и groupware, и чат и т.п. За счёт этого он более неторопливый. А у меня миллионы мелких файлов, и на них просадки производительности особенно сильно сказываются, скажем, попытка использовать Google Drive закончилась фиаско, а Dropbox и OneDrive справлялись. Seafile решает одну конкретную задачу, и делает это быстро и эффективно. С моими терабайтами и миллионами файлов справляется отлично.
Nnnnoooo
05.12.2021 20:44Раньше на большом количестве файлов сифайл просто вылетал. Правда пробовал ооочень давно. Хорошо что сейчас пофиксили, значит буду опять пробовать. Главное найти где хранить бекап подешевле.
maxwolf
07.12.2021 03:41Подешевле — не всегда подходит… У scaleway, вроде, до сих пор s3-хранилище бесплатно до какого-то, довольно большого объёма. Я туда взгромоздил s3fs (чтобы не пропадать добру :), но обнаружил, что оно дико тормозит на некоторых операциях. В одной директории скопилось ~20K файлов, и их удаление (вот просто rm *) заняло часов 6…
muxa_ru
05.12.2021 03:04+5Такой механизм хранения оказался уязвим к одной проблеме. Если мастер диск окажется поврежден так, что СОДЕРЖИМОЕ файлов в нем начнет биться, то мы рискуем размножить битые файлы.
Это проблема ЛЮБЫХ бэкапов, потому что глубина хранения версий не бесконечна, и если вовремя не отловить битый файл, то рано или поздно он останется единственной доступной версией этого файла
Finder001 Автор
05.12.2021 03:30Как раз у меня это не проблема. Синхронизация почти всегда происходит без сравнения содержимого файлов, и таким образом, пока мастер диск живой, он по всем зеркалам разливает ЖИВЫЕ файлы, а когда дохнет любой диск - битые файлы в нем заменяются живыми из других зеркал.
Мастер диск не убивает живые файлы битыми, тк сравнения по содержимому и ручной отбор файлов начинается лишь когда есть сомнения в мастер-диске - у меня это случилось 1 раз за 15 лет и заняло пару часов.
muxa_ru
05.12.2021 03:50+3А откуда Вы знаете какой файл у Вас просто "изменённый живой", а какой "битый" ?
Finder001 Автор
05.12.2021 03:54+1Я же написал. Как только стало ясно, что с мастер-диском проблемы - делаем сравнение файлов по содержимому с первым попавшимся зеркалом. Дальше ручками просматриваем неравные файлы. Когда файлы бьются- там внутри мусор в случае бинарных файлов, в случае исходников/текстов все решает Araxis Merge
В моем случае разных было емнип штук 30-40. Потратил 2 часа.
muxa_ru
05.12.2021 04:20+4Как только стало ясно, что с мастер-диском проблемы
1) Между тем как проблемы возникли и тем как "стало ясно" может пройти некоторое время. И битый файл уже может распространиться.
2) Файлы могут побиться и при живом диске.
Повторю, это проблема ЛЮБЫХ цифровых архивов, а не только Вашего метода.
Finder001 Автор
05.12.2021 04:28-4В любом случае
1) у меня 4 зеркала с большой вероятностью с изначально живыми файлами, это раз. И я могу в случае полнейшего капута обойти все 3 точки, делая сравнения файлов по содержимому в поисках нужного живого файла.
2) При живом диске - это как ? при некорректном завершении работы ? Этого я стараюсь не делать, кроме того есть ощущение что на эту тему что-то делает TrueCrupt
3) Практика критерий истины - проблем таких не было)
muxa_ru
05.12.2021 04:42+5При живом диске - это как ?
В том то и дело, что КАК УГОДНО.
Антивирус есть? Сколько он за это время "вылечил" по причине false positive ?
Графический просмотровщик есть? При очередном обновлении он мог начать делать что угодно от "оптимизируем для экономии места" до "добавим/удалим в exif ".
Любой редактор при сохранении файла сбойнул.
Практика критерий истины - проблем таких не было)
Вы откуда знаете? :)
Повторяю, это проблема ЛЮБОГО цифрового архива, который по определению является "архивом шрёдингера". Пока не откроешь - не узнаешь жив он или нет.
Finder001 Автор
05.12.2021 04:51Безусловно, Вы правы.
Тем не менее за прошедшие 15 лет ни разу не возникло ситуации невосстановимой потери файла из моего файлового архива, который оказался бы нужен. Считаю это хороший результат.
muxa_ru
05.12.2021 05:00Считаю это хороший результат.
Я вот одного не пойму.
Вы говорите о том, что у Вашего метода есть недостаток. Что может трактоваться, что Ваш метод хуже остальных.
Вам говорят, что это недостаток ВСЕХ методов, то есть, в данном вопросе, Ваш метод не_хуже остальных.
Вам сказали о том, что Ваш метод менее плохой чем Вы об этом говорите. Фактически - похвалили.
И в каждом своём комментарии я писал о том, что это общая проблема любых цифровых бэкапов, а не только Ваша.
Зачем Вы начали и продолжаете спорить, рассказывая о том, что Ваш метод показывает "хороший результат", если я никогда не утверждал что у Вашего метода плохие результаты?
Finder001 Автор
05.12.2021 05:08Я согласен, озвученная Вами проблема - общая проблема любых цифровых бэкапов
todoman
05.12.2021 14:57+5Автор, кажется, даже не улавливает сути проблемы.
Автор, вот есть у вас, скажем, папка "Самые важные семейные фото". И пиксели в ней посыпались. И фотки не открываются. Но вы об этом не узнаете год (ведь вы не открываете эту папку каждый день), и битая копия семейного архива ляжет во все копии. Ура.
Finder001 Автор
05.12.2021 18:09+2У меня есть минимум 2 копии самых важных семейных фото, хранящихся на РАЗНЫХ дисках.
Да, действительно в оба эти диска в эту папку я заглядывал...давно.
Но если когда-то залезу и увижу там битый файл - я отправлюсь во второе зеркало, в котором с очень большой вероятностью требуемые файлы живые. Возьму их оттуда и буду радоваться.
Битая копия с большой вероятностью никуда не ляжет, тк при малейшем подозрении на глючность мастер харда - те если мне встретится на нем ЛЮБОЙ битый файл - я тутже займусь восстановлением живых файлов из обоих копий, воссоздам снова полный живой файловый архив и сменю неисправный диск на исправный.
Алгоритм ровно тотже что и с рабочими файлами, только там у меня 4 копии по 200 Гигов, а здесь 2 по 2 ТБ
ps есть лишь 1 способ размножить битый файл в моем способе. Нужно чтобы начал сбоить мастер диск, и чтобы он повредил хранимые файлы ДО СИНХРОНИЗАЦИИ. Если он испортит файл ПОСЛЕ синхронизации, то на диске-локальной копии файл останется целым, что и даст мне в дальнейшем возможность его восстановить. Это ВОЗМОЖНО ПОТОМУ ЧТО Я НЕ СРАВНИВАЮ ФАЙЛЫ ПО СОДЕРЖИМОМУ, те при очередном сравнении живой файл не будет прибит поврежденным, тк они будут считаться идентичными.
Finder001 Автор
05.12.2021 18:51+1А, ну и еще один ньюанс - синхронизации я делаю не автоматически. Я каждый раз просматриваю различия при синхронизации глазами. Что и позволяет оперативно заметить неожиданно исчезнувшие/появившиеся/изменившиеся файлы - признаки повреждения жестких дисков, действия враждебного ПО итд - ведь я отлично знаю, что я делал в последней сессии, и что должно измениться, а что нет.
DaneSoul
05.12.2021 18:44+2Повторяю, это проблема ЛЮБОГО цифрового архива, который по определению является «архивом шрёдингера». Пока не откроешь — не узнаешь жив он или нет.
В принципе, есть способы подстраховаться:
1) Хранение и сравнение сhecksum для крупных редко меняющихся файлов.
2) Использование версионного хранилища, например git, для небольших часто меняющихся файлов.muxa_ru
05.12.2021 18:52Хранение и сравнение сhecksum для крупных редко меняющихся файлов.
Всё никак не соберусь и не сделаю себе файл с хэшами фотографий. :(
Заодно можно их проверить на корректность открытия, ну и сравнить файлы с разных носителей.
Finder001 Автор
05.12.2021 19:00+1Можно даже придумать автопоиск на базе описанного мной алгоритма. Если есть несколько дублированных моим способом файловых архивов, можно прогнать их все вместе через CloneSpy, и тогда все уникальные файлы у которых не найдется дубликатов скорее всего и окажутся поврежденными. Это будет показывать консистентность файловых архивов, целостность данных, поврежденные файлы, их количество и неисправный носитель))
Считаю отличное разрешение неопределенности Шредингера в бакапах)
DaneSoul
05.12.2021 19:04+2Всё никак не соберусь и не сделаю себе файл с хэшами фотографий. :(
С фотографиями основная проблема в том, что большая их часть нафик не нужна, но отобрать реально ценные долго, а удалить остальные — жалко, так и накапливаются фото которые потом годами не открываются.Finder001 Автор
05.12.2021 19:56Просмотрел сейчас весь семейный фотоархив. Не вижу там ни одной битой фотки)
vlad-kras
06.12.2021 13:10+1Предполагается ли ситуация, когда одно из мест долго не посещается, например мастерская? Месяц, пара месяцев, зимний сезон, полгода?
При этом один из дисков - пусть офисный - уже сбоит, но пока что незаметно. Часть файлов на нем - просто труха.
В пятницу 13го дома из-за скачка электричества сгорают переносной диск и диск в системнике.
Итого остаются старая копия в мастерской и очень подозрительная копия в офисе. То есть все файлы за время от последнего посещения мастерской потеряны. Особенно плохо будет, когда копия из офиса будет скопирована на новый переносной диск без проверки целостности файлов - вся труха скопируется на новый домашний диск и немного на диск из мастерской.
Finder001 Автор
06.12.2021 13:16не у одного меня паранойя))
Ну в случае если вы предполагаете такие сценарии - просто добавьте в схему резервирования еще пару дисков. Скажем по 1 в рабочий и домашний комп, и делайте там по 2 зеркала)) Купите домой UPS))
У меня описываемых ситуаций за 15 лет не возникло))
lunacyrcus
05.12.2021 04:55+1Это проблема ЛЮБЫХ бэкапов, потому что глубина хранения версий не бесконечна, и если вовремя не отловить битый файл, то рано или поздно он останется единственной доступной версией этого файла
Ну, есть несколько сценариев "битых файлов".
Аппаратные ошибки. От самых аппаратных ошибок диск как-никак сам защищен и откажется работать если уже дело дойдет к некорректируемым ошибкам, так же есть защиты и контроль целостности на уровне драйверов и файловых систем.
Что-то вроде bit flip. Во-первых, если это в памяти произойдет и потом файл перезапишется и окажется битым, то это вопрос защиты памяти. Во-вторых вероятность такого очень уж ничтожно мала (как-то интереса ради прикидывал циферки, но уже не помню, но в общем даже в масштабах огромнейших датацентров это очень редкое явление). Ну в-третьих, такого рода ошибка с наибольшей вероятностью не будет иметь серьезных последствий, тем более для обычного пользователя, и наиболее вероятно что она легко скорректируется (даже незаметно теми же низкоуровневыми средствами, вездесущие коды Рида-Соломона). Чуть более вреда смогли бы нанести всякие модные row hammering, но это только в теории (если предположить например что-то вроде порчи кешированных к отложенной записи данных так), на практике мне все же видится тоже крайне маловероятным и малозначительным по последствиям в таком направлении.
Аварийные отключения питания/BSOD. Это может привести к порче открытых файлов, но это почти 100% пройдет под вниманием пользователя и он тут же примет меры (восстановит, или просто будет ломать клавиатуру и взывать к небесам чтобы вернули ему последних 60 минут печатания). В целом такой сценарий редко ведет к проблемам, еще и потому что многие сколь-нибудь серьезные программы ведут собственные бекапы текущих файлов на случаи таких аварий, или истории изменений если понадобится откат.
Вредоносные изменения. Те же шифровальщики, например (сложно, но некоторые могут умудриться судя по тому что до сих пор разводят их рассылкой по почте как рыбок). Это в общем-то один с наиболее проблемных сценариев, так как файлы могут быть изменены "легально" и эти изменения могут остаться незамеченными. Но против этого есть свои меры если уж нужно, можно контролировать и даты изменения важных файлов и дополнительно их целостность (да и вообще доступ к ним), и в случае чего не пускать в синхронизацию.
Ошибочные изменения. Это тоже технически "легальные" изменения, в общем-то сценарий когда сам пользователь возьмет и как-то запорет файл (ну типа откроет в стандартном блокноте что-то двоичное и сохранит потом). Тоже второй с наиболее проблемных, но тут уж что говорить, "I hope you know what you are doing". Тоже хватает мер против этого, даже простейших вещей хватит - как вот сделать вручную копию важных файлов прямо в "Новая папка (2)" перед тем как с ними что-то делать.
Примерно так, может конечно что-то не описал сходу.
Формально верно заметили, и это можно считать проблемой. Но я лично еще с такой не сталкивался за все время на своем примере, ну по крайней мере не имел сложностей с нее с тех времен как более-менее понимал все подобные сценарии (а во времена до этого я и сами бекапы вообще не делал, так что имел проблемки повеселее когда все же диск умирал :))
Можете описать реальный пример когда это происходило как написали? (когда порченный файл разлетелся по всем бекапам и в общем-то оказался безвозвратно испорчен). Интересно в общем.
aborouhin
05.12.2021 05:15+2Есть же ещё программные ошибки. Классический пример - PST-файлы MS Outlook, которые бьются с завидной регулярностью (без видимых ошибок в работе программы), так что MS даже специальную утилиту для их восстановления выпустили. Но баги не только в Outlook'е, поэтому от такого никто не застрахован.
Помогает только история версий на такую глубину, которая позволяет предположить, что если за это время ошибка не выявлена - то и ценность файла уже невелика. Для некоторых данных это может означать - вечная история версий.
lunacyrcus
05.12.2021 05:41Да, это тоже 1 из сценариев, что-то наверно посередине между вредоносным и пользовательскими ошибками. Но с таким лично для меня все очевидно, глючное ПО в любом случае ненадежно и использовать его не стоит. Решений у этого 2, или отказаться от такого ПО как только так сразу (как минимум чтобы не травмировать свою утонченную психику лишний раз), или сделать конкретно под него какое-то исправление или там костыль или даже батник при старте копирующий эти же PST, чтобы в любом случае решить это в корне и иметь приемлемые данные еще до бекапов (тем более что только на них рассчитывать явно не стоит, разве что они ведутся постоянно в реальном времени, но у этого куча своих минусов). Ну и так далее)
aborouhin
05.12.2021 19:54Как было бы прекрасно, если бы мы могли заранее узнать, "глючное" ПО или нет :) На самом деле, всё глючное, только про конкретный глюк, приведший к порче данных, мы можем узнать очень поздно.
muxa_ru
05.12.2021 05:22+5когда порченный файл разлетелся по всем бекапам и в общем-то оказался безвозвратно испорчен
Старый графический вьювер в Винде пересохранял файлы которые были повернуты при просмотре.
И я не знаю сколько у меня таких файлов. Может ни одного. Может много. Гипотетически я могу написать скрипт который пройдёт по всем файлам, сравнит данные из экзифов/имён с датой в файловой системе, но делать этого не буду.
Я даже не обращу внимание на это, когда буду работать с файлом.
Или вот есть некоторое количество файлов, которые были скачаны с дропбокса и оказались битыми. Случайно увидел на превьюшках в папке. А сколько не увидел?
Ещё, у меня Касперский "вылечил" несколько файлов с логами сайта. При СИНХРОНИЗАЦИИ такие вылеченные файлы будут удалены из бэкапа.
А ещё, можно нажать не ту кнопку и вместо замены в одном файле, произойдёт замена в нескольких файлах. Ага, так бывало.
А ещё, бывали случаи, когда софт сообщал "сейчас я переконвертирую проект в еовый формат" или предлагал "сохранить изменения" когда никаких СОЗНАТЕЛЬНЫХ изменений я на вносил. И я понятия не имею, соглашался ли я на такое или нет.
Это может привести к порче открытых файлов, но это почти 100% пройдет под вниманием пользователя и он тут же примет меры
Если у меня прямо сейчас всё рухнет, то я не вспомню какие именно файлы были открыты и в каком они были состоянии :)
lunacyrcus
05.12.2021 06:39+1Вот за примеры спасибо. Автозамена кстати да, явно одна из таких веселых "потенциально нескучных" штук)
Finder001 Автор
06.12.2021 11:47Слушайте я понял откуда все эти речи про архив Шредингера и неопределенность. Видимо Вы пользуетесь автоматической синхронизацией и НЕ ВИДИТЕ ГЛАЗАМИ изменения своего архива, поэтому он для вас нечто неизвестное.
В тотале я при каждой синхронизации вижу глазами все что изменяется. Именно поэтому я в курсе всех возникающих проблем в момент их возникновения, поэтому и утверждаю, что у меня битые файлы не распространятся - при появлении первых же изменений, не инициированных мной, я сразу начну искать причину изменений.
У меня реально не возникает и никогда не возникало никаких из перечисленных проблем)
muxa_ru
06.12.2021 18:18+1Видимо Вы пользуетесь автоматической синхронизацией и НЕ ВИДИТЕ ГЛАЗАМИ изменения своего архива, поэтому он для вас нечто неизвестное.
Видимо я работаю настолько интенсивно, что (а) не могу проглядеть глазами ВСЕ изменённые файлы и (б)не помню про ВСЕ внесённые изменения.
Реально, смотришь на текст или код и думаешь "блин, а это я сделал? а зачем?"
А ещё есть файлы с хранящимися данными, которые изменяются без того чтобы я их осознанно изменил. Даже не в процессе моей работы с ними, а автоматически.
А ещё может быть так, что обновление софта обновит формат файлов с хранящимися данными.
muxa_ru
05.12.2021 05:25Но я лично еще с такой не сталкивался за все время на своем примере, ну по крайней мере не имел сложностей с нее с тех времен как более-менее понимал все подобные сценарии.
В том то и дело, что без специальной проверки, Вы понятия не имеете сталкивались Вы с этим когда-либо или нет. :)
lunacyrcus
05.12.2021 03:41+1Ну в целом поддерживаю, в долгосрочной перспективе реально нет ничего надежней своего оффлайн хранилища с N количества дисков и периодическими бекапами.
Добавлю разве пару моментов:
TotalCommander синхронизирует относительно медленно, если брать ситуацию с диска на диск (а не через сеть), заметно быстрее копирование на уровне драйвера
Вместо TrueCrypt стоит все же использовать VeraCrypt
katzen
05.12.2021 06:05+3Любой бэкап, к которому имеет доступ непривелегированный оператор и/или клиент, уязвим к накоплению и размножению локальных ошибок и, например, к шифровальщикам.
NTDLL
05.12.2021 07:11Например мне очень нравится TrueCrypt.
Если криптовать бэкап, то важно в каком-нибудь совместимом формате. Например, CryptSync позволяет сохранять зашифрованные 7z архивы.
Посмотрите на этоWARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
This page exists only to help migrate existing data encrypted by TrueCrypt.
www.truecrypt.org/downloads
nixtonixto
05.12.2021 08:15Независимый аудит показал, что он вполне безопасен. Проблемы могут возникнуть тогда, когда злоумышленник УЖЕ имеет доступ к вашему компьютеру, а контейнер смонтирован.
Пользуюсь уже лет 10, ни разу контейнер не повредился. Он лучше архива потому, что виден в системе как ещё один раздел, без задержек на распаковку-упаковку (но со снижением скорости чтения-записи, если выбрана цепочка из 2...3 алгоритмов шифрования), что важно, когда контейнер объёмом за сотню ГБ.NTDLL
05.12.2021 08:45+2Вы меня поймите правильно. При шифровании бэкапа важно, чтобы этот зашифрованный формат через N-лет можно было расшифровать. Причём альтернативной программой. TrueCrypt уже не поддерживается, специально ссылку на сайт оставил. Сайт существует и программу возможно тоже можно скачать. Но на это не нужно рассчитывать.
Такая же история с VeraCrypt. Где гарантии, что их не закроют через год, два и т.д.?
Вот смотрите (предполагаемый вариант развития событий):
1 Всё хорошо, винт работает, вы копируете в облако контейнер, зашифрованный VeraCrypt. Дистрибутив не сохраняете.
2 Проходит несколько лет. Их конторку в результате каких то санкций прикрывают. Вы об этом даже не подозреваете.
3 Проходит несколько лет. Вы всё также копируете в облако контейнер, зашифрованный VeraCrypt. Бац, винт полетел. Вы скачиваете с облака зашифрованный контейнер. Ищете программу VeraCrypt в Интернете. А ЕЁ НИГДЕ НЕТ.
Вот такой прикол.nixtonixto
05.12.2021 10:11-1Мммм… Интернет работает не так. Однажды загруженное в интернет, останется в нём навсегда, если это представляет интерес людям. Даже если умрёт сайт программы — она уже сейчас лежит на куче софпорталов и торрент-трекеров. И даже если что-то окажется утерянным — можно спросить на форумах, и, скорее всего, кто-то вспомнит её название по вашему описанию и/или поделится сохранёнными файлами.
Поэтому важно только, чтобы программа стабильно работала и не портила свои же бэкапы, а уникальность формата её файлов — дело десятое…muxa_ru
05.12.2021 15:26+2Мммм… Интернет работает не так.
В теории, да всё так как Вы написали.
На практике же, старые сайты с дистрибами имеют свойство умирать, в торрентах на старых редких раздачах нет никого, форумы мертвы, но даже если форумы живы, то те кто знал про нужный дистриб - могут быть сами мертвы.
Но даже если вы нашли эту программу, то операционна система:
- не даст запустить инсталягу подписанную старым ключём
- не сможет запустить этот старый код сильно завязанный на функционал самой системыНо даже если вы смогли скачать с форума инсталягу и запустить, то блин.. реально... вы доверите свой бэкап программе полученной хоз от кого с хз какого форума?
Finder001 Автор
05.12.2021 20:16Нужно просто сохранить дистрибы, и виртуальную машину с требуемой ОС и ПО, если все так ужасно))
В реальности описанные проблемы для описанного способа на сегодня неактуальны.
muxa_ru
05.12.2021 20:23Нужно просто сохранить дистрибы, и виртуальную машину с требуемой ОС и ПО, если все так ужасно))
И компьютер который сможет запустить эту версию виртуальной машины :(
nixtonixto
06.12.2021 10:15+1У меня до сих пор стоит старый ноут с XP, он управляет станком и старым лазерным принтером, настройки которого можно корректировать только под XP. Ещё есть предыдущий с 7 и рабочий с 10. И так у многих, поэтому проблем с запуском старых приложений быть не должно, тем более что TrueCrypt полноценный 64-битный и работает без бубна даже на 11. То, что вы описываете — какой-то апокалипсис, когда отключат интернет и умрут все компьютеры старше трёх лет, но в мирное время такое нереально.
muxa_ru
06.12.2021 18:23умрут все компьютеры старше трёх лет
Я гляжу на ситуацию в несколько ином масштабе - https://habr.com/ru/post/312344/ :)
Daddy_Cool
05.12.2021 13:58+2Любопытно, что речь идет именно о последней версии. Учитывая историю Трукрипта и внезапное прекращение работы над ним.
Finder001 Автор
05.12.2021 20:18+2TrueCrypt некоторые очень не любят)
Полагаю именно поэтому им следует пользоваться))
NikaLapka
05.12.2021 09:20-1Сколько воды налили, хотя можно проще изложить и дополнить:
В чём хранить? - True(Vera)Crypt, WinRaR, 7Z, PGP, dm-crypt,... что для вас удобнее, и не забываем, что можно одно вкладывать в другое, как в матрёшке.
Где хранить? - Сперва разделим файлы по размеру: маленькие до 50 Мб, средние 20-50 Гб, большие от 500 Гб. Маленькие файлы можно хранить в любом бесплатном облаке, инстаграме, вконтакте, телефоне, роутере,.. или даже отправить письмом к себе на на почту. Средние файлы, удобно хранить в облаках и хостингах. С большими файлами сложнее, т.к. любая копия будет стоить ощутимых денег, например, покупка отдельного жёсткого диска на 1-2 Тб, или аренда Amazon S3,... . И золотое правило: держите 3-4-5 копий.
inferrna
05.12.2021 10:11У меня с 2007 года ни одного потерянного харда. У одного (на 1ТБ) начали, было, сектора сыпаться, ну да я разметил его по-новой, оставив последние 10% с края неиспользуемыми, и последние 5 лет он исправно работает хранилищем для видео/сериалов (редко записываемые данные). Не знаю, в чём тут секрет - или просто везёт, или в линухе, или в продуманной вентиляции системного блока, или в 48Гб оперативы, которые позволяют не насиловать хдд свопом. Даже не знаю. Но вот так.
v1000
05.12.2021 10:22На счет внешних жестких дисков - жаль, что некоторые производители коробок для жестких дисков не заморачиваются, чтобы добавить поддержку СМАРТ в свои изделия. И не пишут про это на упаковке. Поэтому приходится время от времени вытаскивать диск из такой коробки, толко для того, чтобы проверить его СМАРТ.
nobodysu
05.12.2021 20:14Если на коробке не указана поддержка UASP — то смарта там скорее всего не будет.
Quiensabe
05.12.2021 10:40+4Если считать, что вы в среднем успеваете поработать в двух точках за день, и тратите по 2 минуты на синхронизацию в начале и в конце работы, то 15*365*2*2 = 21900 минут за 15 лет. Или, примерно, полтора месяца по 8 часов в день... Как то дофига.
При этом у вас очень небольшой (по современным меркам) рабочий архив, и вы не пользуетесь возможностями собственного железа (внешние диски все же куда медленнее встроенных). Ваша схема очень жесткая (спонтанно заехать поработать по пути из кино не получится если с собой нет внешнего диска). А износ оборудования вероятно более быстрый (внешние диски быстрее ломаются, они падают, выходят из строя разъемы и т.п.), потеря 10 дисков за 15 лет это немало. Кроме прочего всегда носить с собой полный архив данных и документов - небезопасно. Его могут украсть, или вы можете его потерять, а кто-то найдет и опубликует или еще как-то использует.
Это все не к тому, что ваш способ плох. Но и оптимальным его назвать трудно.
Вам он подходит, это хорошо. Но перечисляя плюсы не надо забывать и о минусах.
Indemsys
05.12.2021 13:19Я бы сказал что архив в пару сотен гигабайт это на пределе современных возможностей синхронизации. Иначе будет действительно неприемлемо долго происходить синхронизация.
Даже сейчас я, к примеру, не пытаюсь синхронизировать файл MS Outlook. Это слишком долго даже на локальных дисках. Абсолютно нереалистичной выглядит синхронизация имиджей виртуальных операционок.
Современные внешние недорогие диски с 2800 Мбайт в сек, почти не уступают внутренним.
И поработать в кино вполне получается. Диски очень маленькие, у меня скотчем даже был прилеплен к лэптопу. Держался несколько лет. Носил везде с собой.
Тут важно понять что значит безопасность для разработчика, корпоративного разработчика, менеджера и прочим категориям. Для все них безопасность будет означать разное.
Если разработчики автономный, то нет смысла шифровать и бояться утери или кражи.
Потому что ключи к использованию всей этой инфы только в голове разработчика.
Если кто-то сумеет с пользой применить или опубликовать сворованное, то снимаю перед ним шляпу.Finder001 Автор
05.12.2021 17:32Только мой личный архив полностью весит больше 2ТБ. Также есть резервируемая копия одного ftp, весом больше 6ТБ.
Вся сила и скорость именно в способности Total Commander делать синхронизацию, не заглядывая внутрь файлов.
Indemsys
05.12.2021 19:36Я больше думаю о рабочем пространстве когда говорю о синхронизации, а не о личных архивах.
Т.е. пространстве где каждый день может накапливаться пару десятков гигабайт изменений мелкими файлами при общем размере в несколько сотен гигабайт.Как известно дисковые операции в 40-50 медленнее работают на мелких файлах.
Тут даже не перекачка при синхронизации тормозит, а сам перебор миллионов файлов.А личные архивы с видосами, фотками, книжками, да, большие, но синхронизировать их быстрее, поскольку значительно меньше файлов.
Еще надо помнить что специализированные инструменты типа GoodSync обладают специальными опциями, которых нет в Total, например безопасное копирование.
Finder001 Автор
05.12.2021 20:01Судя по всему в данном случае речь про какую-то специфическую БД. Описанная ситуация - какая-то большая база обрабатывается машиной...действительно в таких случаях синхронизация может идти медленно. Но при таких обьемах и количестве файлов полагаю будет тормозить что угодно.
Finder001 Автор
05.12.2021 19:21Я же написал про TrueCrypt. Если кто-то сможет открывать диски закрытые TrueCrypt-ом он сразу станет сказочно богат, тк его купит ФБР на вес золота)
2ТБ считаю нормальный личный архив
vau
05.12.2021 10:55+4Попробуйте Syncthing. Он прекрасен
nikhotmsk
05.12.2021 14:32+3(sarcasm mode enabled, не судите строго, я даже надеюсь, что Syncthing решил перечисленные ниже проблемы, просто накипело)
Все эти программы объединяет то, что они безопасные, удобные, надежные, с искусственным интеллектом, которые за вас решают, что и в какую сторону копировать. Но там не написано, что нужно сделать, если программа выдает ошибку
no space left on device, потому что она начала копировать тяжелый файл в одну и ту же сторону, во второй раз, по непонятной причине. Там не написано, что файлы нежелательно переименовывать...Файловая система - привычная и удобная, когда у тебя всего один компьютер - становится неудобной, если компьютеров много, и надо как-то двигать файлы между ними. Автор статьи придумал свой способ. Каждому предстоит это испытание, полное ошибок и трудностей.
Я тоже не люблю облака. Я не пользуюсь ими, потому что догадываюсь, что меня там ждет. Хотя, нормальные люди не парятся и заводят себе яндекс-диск, и хранят там всё. Потом удивляются, что без интернета у них всё недоступно. (компромиссный вариант - облако на домашнем сервере)
Самая лучшая тулза для синхронизации файлов - это самодельная. Только тогда можно понять, почему она повела себя не так, как хотелось, и будет шанс ее доработать под свои потребности.
Я пишу свою тулзу, которая синхронизирует не файлы, а контент. И не только между компьютерами, но и между флешками, которые просто лежат на полке. Вернее, даже не синхронизирует, а просто помнит, где что лежит. Уже одно это чего-то стоит.
Black_Spirit
05.12.2021 11:44Поделюсь своей простой наработкой. Куплен Office на 6 человек за 3400 рублей на год. Получается 50 рублей на человека в месяц. Туда входит OneDrive с 1 ТБ. Папка OneDrive живёт на диске D на домашнем компьютере. Дополнительно на той же машине стоит диск Е и на нем резервируются данные папки OneDrive встроенным архиватором данных Windows. Там же включено версионирование файлов. В принципе, единственная угроза это шифровальщик. Но тут клиент OneDrive должен остановить синхронизацию при массовой замене файлов. Кроме того включен разрешительный доступ к диску Е и только подтвержденные программы туда могут писать.
courser
05.12.2021 11:48Тоже в подобной ситуации. Тоже не признаю облака, кроме как в роли оперативного источника передачи.
Но работать с мобильного диска пока не хочу, так что синхронизирую с основного компа в соновном. Плюс сделал несколько сценариев обратной синхронизации с вторичных компов.
Рекомендую заменить Тотал в этом плане на FreeFileSync - гораздо удобнее, тк заточен именно под синхронизацию, плюс возможности неограниченного количества сценариев - куда, что и когда заливать.
amarao
05.12.2021 12:50Ну, ваша модель подходит вам. У меня, например, различаются проприетарная и открытые иерархии данных, причём, для оптимизации, открытые данные даже в нешифрованном виде лежат (тот же linux, например, у которого время git update ощутимо даже на nvme).
stanislav888
05.12.2021 13:15Очень странный подход, имхо. Я бы делал по другому.
Таскать везде один и тот же ноут, просто подключать к нему доп моники и клавы на месте. Можно таскать даже MacMini или что-то подобное.
Сделать файловый сервер (SAMBA) где-то в одном месте, доступ туда через свой VPN. Если боитесь что в этом месте смениться IP, зарегаться на DynDNS и обращаться к VPN серваку по доменному имени. От поломки ж\диска спасёт RAID.
werter_l
05.12.2021 13:32Попробуйте kopia (https://kopia.io) — открыто, инкрементно, умеет шифровать свой репозиторий, автобэкапы по расписанию.
nikhotmsk
05.12.2021 13:37Странные вещи происходят. В соседней статье у преподавателей вузов возникают трудности. Они не могут объяснить студентам, что такое файловая система. Оказывается, когда сохраняешь проект, надо запомнить, в какой папке он лежит, иначе ты его не найдешь.
Когда у человека был всего один компьютер, запомнить, что где лежит, было легко. Когда появляются много компьютеров в нескольких местах, плюс проигрыватель возле телевизора, плюс флешки, плюс бэкап на сервере, то начинаешь подозревать, что файловая система не удобна.
Она не помнит происхождение файлов. Например, при бекапе копируются все файлы. Zip архив копируется вместе с распакованными файлами, которые лежат рядом с ним. Получается, одно и то же хранится два раза. Не хватает поиска, тегов.
courser
05.12.2021 15:39+3А за "удобство" вы заплатите отсутствием контроля за своей информацией, тк размещаться она станет по скрытым алгоритмам, с доступами у непонятных программ, организаций и людей.
И при малейшем сбое вы окажетесь на месте тех студентов с их облаками и розовыми понями.
Finder001 Автор
05.12.2021 17:56+1Мне жаль Вас расстроить (если это расстроит), но есть совершенно великолепный поиск под винду. Он кстати и для удаленных машин подходит, работает фантастически быстро, делает параметрический и сложный поиск, дико удобен.
Everything https://www.voidtools.com/
DaneSoul
05.12.2021 19:02Zip архив копируется вместе с распакованными файлами, которые лежат рядом с ним. Получается, одно и то же хранится два раза.
Эта проблема не системы, а неправильной организации хранения пользователем. Архивы храним в одном месте, распакованные данные с которыми работаете — в другом и никакой путаницы.Не хватает поиска, тегов.
Поиск можно делать через тот же Double Commander, там довольно гибко параметры настраиваются, не раз выручал.
Вот с тегами — да, беда, основная проблема в том, что нет единого формата и его поддержки разным софтом. В основном решения основаны на ведении программой своей базы данных, в результате все жестко привязывается к одной программе и одной структуре данных — перенес файл в другое место и теги потерялись… Адекватного решения для себя так и не нашел пока.maxwolf
05.12.2021 20:13+1Вот с тегами — да, беда — descript.ion файлы до сих пор нормально поддерживаются в Far Manager, и, на удивление, в некоторых других популярных программах (например, Total Commander, 7-zip file manager, Acdsee)
DaneSoul
05.12.2021 20:46Идея хранения информации о файле отдельно от самого файла ущербная по своей сути, так как файлы могут менять свое расположение и информация будет теряться.
МЕТА-информация должна хранится в самом файле, как EXIF который пишут камеры при съемке.
Есть XMP, есть IPTC, но их поддержка если и есть, то в программах просмотра/редактирования фотографий, типа XnViewMP, но хотелось бы единый универсальный формат применимый для всех файлов и поддерживаемый бы любым файловым менеджером на всех платформах.Nnnnoooo
05.12.2021 20:51Расширенные атрибуты файлов.
И это дааавно уже было придумано, и активно с успехом применялось в уже почившей OS/2. И NTFS если я не ошибаюсь в какой-то мере их умеет поддерживать тоже.
Но в данный момент никому не нужно и многим лучше придумать еще 100500 своих форматов, чем использовать что-то "устаревшее"DaneSoul
05.12.2021 20:58+1Расширенные атрибуты файлов.
Там с кросс-платформенностью между разными операционными и файловыми системами все печально, насколько понял.Nnnnoooo
05.12.2021 21:03Это проблема не столько кроссплатформенности ОС, сколько проблема фич самой файловой системы. Для неподдерживаемых ФС в качестве костылей создавались отдельные файлы/базы с этими атрибутами. Но т.к. никому это не надо было, то и нет поддержки нигде
DaneSoul
05.12.2021 22:18+1Это проблема не столько кроссплатформенности ОС, сколько проблема фич самой файловой системы.
По сути две стороны одной медали, так как операционная система ограничивает выбор файловой системы. А файлы, в том числе МЕТА информацию в них хотелось бы иметь не привязанными к фичам конкретной системы, а свободно переносимыми.Nnnnoooo
06.12.2021 20:06В общем да, классическая проблема курицы и яйца.
Но факт, остается фактом что если бы система все еще была живой и активно использовалась, то и расширенные атрибуты бы тоже применялись и большой шанс что не только в ней (т.к. пока полуось была жива, расширенные атрибуты очень активно применялись и не только в ней, например была поддержка в самых первых версиях Win NT, не только на уровне ФС, но и на уровне софта). Но в любом случае в данные момент это просто абстрактное обсуждение, т.к. в современных ОС их нет :(
maxwolf
07.12.2021 03:28+3Вы прямо так, сходу, рубаете шашкой, что даже становится немного страшно… Ничего «по сути ущербного» в этой идее нет. Она имеет свои недостатки и свои преимущества. Нужно, естественно, чётко представлять себе и те и другие, и выбирать наиболее подходящий под конкретные требования способ. Один недостаток вы совершено верно указали — слабая связь файла, и его описания, но он — не фатальный. Соблюдая определённую дисциплину работы с файлами, можно обеспечить корректное связывание в практическом большинстве случаев. А вот требование хранить метаинформацию внутри файлов — оно, нужно отдавать себе в этом отчёт, практически невыполнимо, из-за огромного разнообразия типов файлов, и программ, которые с ними работают. Т.е. предпочитая этот подход вы, по факту, вообще отказываетесь от возможности работать с метаинформацией, или колоссально ограничиваете набор файлов, с которыми в такой парадигме можно работать.
muxa_ru
05.12.2021 15:52+3Кстати, про облака и "бэкапы из коробки".
Там ведь даже не "коробка", а натуральный "чёрный ящик", который неизвестно как настроен и может в любой момент поменять настройки на самые странные - https://habr.com/ru/post/454180/ .
Finder001 Автор
05.12.2021 18:01+2это просто апофеоз идиотии((
да вот именно таких приколов я бы меньше всего хотел испытать на собственной шкуре
vvbob
05.12.2021 16:42+1До того как облака и дешевый безлимитный интернет стали доступны простым лягушкам, я использовал rsync с внешним USB диском. Обычно вечером в конце рабочего дня подтыкал диск, и запускал скриптик, который собирал в компьютере все папки и сбрасывал на внешний винт изменения, на домашнем компьютере этот же скрипт синхронизировал папки в обратном направлении. Что-бы не париться насчет конкурентных изменения, я просто делал разные папки для работы и для домашних дел. В принципе схема нормально работала, до сих пор сохранились разные данные с датой еще из девяностых. Когда появились облака и интернет стал доступен - я от этого всего отказался, больно заморочно таскать везде винт, запускать.. Все в облаке и в синхронизированных папках на разных компьютерах. Просто и достаточно надежно (соответствует ценности данных).
Indemsys
05.12.2021 17:17+2Не представляю как это можно доверить скрипту.
Каждый раз когда синхронизирую я должен лично проверить что собственно синхронизируется.
Это во-первых даёт возможность освежить в памяти что сделано за день.
Во-вторых не даёт попасть на огромные и бессмысленные объёмы перекачки.
Поэтому как правило синхронизация сопровождается подчищением временных и ненужных файлов. А также рефакторингом дерева каталогов. Т.е. это всегда ручной творческий процесс.vvbob
05.12.2021 17:22+1Ну, было нормально, винт был небольшой, но его хватало вполне, и не пропадало ничего. Скрипт постепенно дорабатывал, но не сказать что сильно. Временные и ненужные файлы легко отфильтровывались по расширениям и названиям папок.
Inskin
06.12.2021 00:00Надеюсь, программа мониторинга smart'a с алертами установлена на всех компах? Я использовал похожую схему, но у меня внезапно в какой-то момент умер SSD во внешней коробке, при том, что его использование не было интенсивным особо. Начал копать инфу в инете, и выяснил, что ssd в коробочках не делают trim так эффективно, как подключенные напрямую в комп, и из-за того, что блоки свободные очень редко помечаются как свободные, записывать становится некуда и начинают использоваться резервные секторы, и они кончаются тоже довольно быстро, после чего диску приходит кирдык непредсказуемого уровня. Я время от времени посматривал, что с диском всё в порядке, но не мониторил постоянно, и после последнего "посматривания" времени ему хватило на то, чтобы кончиться. Конечно, имея копии этого ссд во внешней коробочке на нескольких компах, за такую ситуацию можно переживать меньше, но всё же имейте ввиду.
lair
06.12.2021 00:17На сегодняшний день, work+hard весят в сумме менее 256 ГБ.
Угу. А теперь попробуем реализовать то же самое для работы с архивом фотографий на больше чем терабайт, который при этом неплохо бы держать не на том же физическом диске, что каталог этих фотографий (еще десятки гигабайт).
Finder001 Автор
06.12.2021 11:43Никаких проблем, у меня фотки+видео = relax занимают 2ТБ
lair
06.12.2021 11:45Это не "релакс", это работа. Ежедневная.
А еще бывают, скажем, БД на сотни гигабайт (которые, кстати, с внешнего диска еще и фиг запустишь так просто).
Finder001 Автор
06.12.2021 12:02По скорости синхронизации work+hard синхронизируется дольше чем relax. Дело в количестве файлов - ведь я не сравниваю файлы по содержимому, в рабочих папках 153 тысячи файлов, синхронизация идет меньше минуты, в relax всего лишь 38 тысяч - там много видео.
Вы без проблем можете пользоваться описанным методом для своего рабочего архива фотографий.
Что касается надежного хранения БД - здесь немного сложнее. Тк в БД полагаю все файлы бинарные, то Вы без проблем можете хранить зеркало БД на отдельном диске. Но при синхронизации придется включать сравнение файлов по-содержимому, чтобы базу не поломать. В коментах рекомендовали пару утилит, которые работают побыстрее чем TotalCommander - FreeFileSync && Goodsync.
Можно ли запустить базу с внешнего диска или нет Вас волновать не должно - задача резервного хранения данные сохранить целыми, а не использовать.
Немного непонятно о чем речь с каталогом, если имеется в виду файловая система диска, то просто ставите все на резерв, и все, если это специальная БД с индексом для поиска - тогда эту часть данных также нужно бакапить с синхронизацией файлов по содержимому.
lair
06.12.2021 12:08Вы без проблем можете пользоваться описанным методом для своего рабочего архива фотографий.
Нет, не могу. Нет у меня достаточно быстрых дисков такого объема, и позволить себе долгую синхронизацию я не могу. А учитывая, что дисков нужно два, ситуация только усложняется.
Запустишь с внешнего диска или нет Вас волновать не должно — задача резервного хранения данные сохранить целыми, а не использовать.
Да нет, как раз должно: вы предлагаете всегда работать с мастер-диска, а он внешний.
Немного непонятно о чем речь с каталогом
О том, что для разумной скорости работы этот каталог (это специальная БД) должен быть на другом физическом диске, нежели фотографии.
Finder001 Автор
06.12.2021 12:16>> Да нет, как раз должно: вы предлагаете всегда работать с мастер-диска, а он внешний.
Мастер диск понятие условное) У вас задача сохранения БД, поэтому Вы можете считать мастером диск своей рабочей машины.
Если же Вы хотите переносить БД целиком между двумя рабочими местами, то тогда формально у Вас 2 мастера. Впрочем этот вариант нужно рассматривать внимательно, тк если СУБД хранит еще какие-то настройки в реестре, не развалится ли все если ее вдруг пересадить на другую базу, это вопрос.
>> О том, что для разумной скорости работы этот каталог (это специальная БД) должен быть на другом физическом диске, нежели фотографии.
Ну так используйте отдельный SSD
lair
06.12.2021 12:18Если же Вы хотите переносить БД целиком между двумя рабочими местами, то тогда формально у Вас 2 мастера.
Два мастера — проблема синхронизации.
Ну так используйте отдельный SSD
И вот тут начинаются проблемы сугубо логистического толка: надо носить и втыкать два диска, не путаться в них и так далее.
Finder001 Автор
06.12.2021 12:25>> Два мастера — проблема синхронизации.
Нет никаких проблем. В сумме с носимым диском у Вас получается 3 копии БД: 2 идентичных с последнего места работы, и предыдущая версия на том месте работы где Вы в последний раз не работали. Приходите туда, синхронизируете с носимого диска БД туда, и вот у Вас 3 копии БД последней версии.
>> И вот тут начинаются проблемы сугубо логистического толка: надо носить и втыкать два диска, не путаться в них и так далее.
Есть чудесная штука - Disk Label, сильно упрощает жизнь в таких случаях) Кроме того, можно купить один большой SSD и хранить все носимое на нем)
lair
06.12.2021 12:31Приходите туда, синхронизируете с носимого диска БД туда, и вот у Вас 3 копии БД последней версии.
Не так.
"Приходите, не забываете синхронизировать с носимого диска на локальный, работаете с локальным, останавливаетесь, не забываете синхронизировать с локального диска на носимый".
Понимаете, в описанном вам в статье сценарии вы работаете с носимого диска. Если вы забудете запустить синхронизацию — у вас не будет свежего бэкапа, но не более того. В сценарии, который вы предлагаете мне, если забыть одну из синхронизаций, будет конфликт.
Есть чудесная штука — Disk Label, сильно упрощает жизнь в таких случаях
Неа. Жизнь упрощают только скрипты, которые все делают автоматически. Все, что требует ручной сверки "а туда ли я копирую", неизбежно приводит к ошибке рано или поздно.
Finder001 Автор
06.12.2021 12:41>> В сценарии, который вы предлагаете мне, если забыть одну из синхронизаций, будет конфликт.
Никакого конфликта не будет, просто в базе будут потеряны результаты последней рабочей сессии.
>> Жизнь упрощают только скрипты, которые все делают автоматически. Все, что требует ручной сверки "а туда ли я копирую", неизбежно приводит к ошибке рано или поздно.
Ошибка конечно будет. Но в коментах немало написано про бакап Шредингера от парней, у которых полностью автоматическая синхронизация. Я отличаюсь от них тем, что ЗНАЮ что происходит с моим архивом и моими дисками.
В конце концов - пробуйте...пишите скрипты под свою задачу, многие пишут. Возьмите Syncthing и упражняйтесь...хотя имхо то что Вам нужно не укладывается ни в какую модель, кроме предлагаемой мной.
lair
06.12.2021 12:45Никакого конфликта не будет, просто в базе будут потеряны результаты последней рабочей сессии.
Немножко хуже.
Вот я приехал в рабочее место А. Поработал, блаблабла, забыл слить данные на носимый диск.
Приехал в рабочее место Б, слил данные с диска, начал работать. Фактически, я работаю поверх уже устаревших данных, но я этого уже не знаю. Когда я приду сливать эти данные в рабочем месте А — будет как раз классический конфликт веток.
Ну и да, если для вас "потеряны результаты последней рабочей сессии" — это мелочи, то для меня это не так.
Я отличаюсь от них тем, что ЗНАЮ что происходит с моим архивом и моими дисками.
Каким образом вы "знаете", что происходит, когда за день в рабочих каталогах может меняться несколько сотен, а иногда и тысяч файлов?
хотя имхо то что Вам нужно не укладывается ни в какую модель, кроме моей.
Наоборот. То, что мне нужно, не укладывается в вашу модель.
А еще ваша модель — не важно, в оригинальном или модифицированном состоянии — подвержена проблеме вида "уехал из места А с рабочим диском, приехал в место Б с нерабочим" — что делать?
Finder001 Автор
06.12.2021 12:48>> Ну и да, если для вас "потеряны результаты последней рабочей сессии" — это мелочи, то для меня это не так.
Это и для меня не так. Я пару раз нарушил свои же правила, запорол свою сессию, потерял данные при синхронизации, этого хватило чтобы 15 лет память четко работала)
>> Наоборот. То, что мне нужно, не укладывается в вашу модель.
Я ведь Вас не заставляю ее использовать. Создайте свою, я с удовольствием о ней почитаю.
>> А еще ваша модель — не важно, в оригинальном или модифицированном состоянии — подвержена проблеме вида "уехал из места А с рабочим диском, приехал в место Б с нерабочим" — что делать?
Вообще нет и я несколько раз это обьяснял. На рабочем месте А остался полный рабочий архив, на рабочем месте Б рабочий архив за вычетом последней сессии.
>> Когда я приду сливать эти данные в рабочем месте А — будет как раз классический конфликт веток.
Когда вы сделаете синхронизацию базы с носимого диска на рабочий, у вас не будет никакого конфликта, вы просто затрете данные предпоследней рабочей сессии.
lair
06.12.2021 12:54Вообще нет и я несколько раз это обьяснял.
Так что делать-то в этом случае?
Когда вы сделаете синхронизацию базы с носимого диска на рабочий, у вас не будет никакого конфликта, вы просто затрете данные предпоследней рабочей сессии.
Вы забыли, что последняя рабочая сессия основана на неактуальных данных, и, следовательно, не обязательно валидна.
Finder001 Автор
06.12.2021 12:59>> Так что делать-то в этом случае?
вернуться в точку А и залить новый мастер-диск правильной базой
>> Вы забыли, что последняя рабочая сессия основана на неактуальных данных, и, следовательно, не обязательно валидна.
Я не в курсе вашей специфики, возможно что мой метод вам действительно не подходит.
lair
06.12.2021 13:01вернуться в точку А и залить новый мастер-диск правильной базой
Это я и называю "подвержен проблеме". Потому что очень круто "возвращаться в точку А", которая от тебя в, скажем, двух часах пути. Иногда это просто потерянное время. Иногда это потерянное мероприятие — когда, скажем, ты приехал на съемку, а у тебя умер мастер-диск с планом этой самой съемки.
Finder001 Автор
06.12.2021 13:02Учитывая озвученную мной статистику - 10 мертвых дисков за 15 лет и 0 потерь данных - решайте сами, подходит ли это вам.
Или вам больше нравится потерять все данные разом при смерти вашего рабочего диска)
lair
06.12.2021 13:07Учитывая озвученную мной статистику — 10 мертвых дисков за 15 лет и 0 потерь данных — решайте сами, подходит ли это вам.
Ну так у меня потерь данных за сопоставимое время не больше, чем у вас. А все, которые я помню, случались не из-за отказа диска, а из-за человеческих ошибок.
Или вам больше нравится потерять все данные разом при смерти вашего рабочего диска)
Вот именно потому, что мне это не нравится, у меня есть стратегия бэкапов.
fndrey357
06.12.2021 05:09+1Гы. разбудили парнойю....
У меня как у ТС тоже 4 рабочих компа. Правда информации поменьше.
Все свое такаю в кармане. Синхронизирую на любом компе, куда втыкаю носитель. Достаточно бессистемно. В принципе пару раз спасало.
После очередной потери флешки стал анализировать инфу. Получается, что основное - это архив справочных материалов. Создал папки "Для проектов" на всех доступных компах. И реально архивировать стало копейки.
Сначала был диск на 250 гигов. Потом типа крутая флешка на 64. Потом хорошая брендовая флешка на 32. И все что нужно умещается.
Большие объемы - фотки и прочее - несколько жестких дисков с профилактическим перегоном туда-сюда. Обычно в новогодние праздники.
Finder001 Автор
06.12.2021 12:31>> Сначала был диск на 250 гигов. Потом типа крутая флешка на 64. Потом хорошая брендовая флешка на 32. И все что нужно умещается.
да я этот путь тоже прошел, но у меня к сожалению после предельного сжатия все равно больше 200Гигов рабочих файлов((
fndrey357
06.12.2021 15:01И вы их каждый день реально редактируете? Просто у меня получается реально больше 5-10 гигов не меняется. Остальное синхронизировать - время зря терять.Оно месяцами без изменений.
Finder001 Автор
06.12.2021 23:55За день я редактирую разумеется очень мало файлов. Но общее древо, которое нужно для работы, сильнее сократить не удалось.
fougas
06.12.2021 11:32+1Для решения проблемы синхронизации/резервного копирования смастерил себе https://github.com/okhlybov/mclone
Если вкратце, то это консольная надстройка над Rclone для оффлайновой синхронизации с упором на использование мобильных носителей. Перенос файлов Linux/Windows, множественные пакетные задания, шифрование и пр. в комплекте.
Kirikekeks
06.12.2021 20:27Лучшее хранение обьема 2 тб и ниже. Больше уже надо на ZFS, или для любителей видео на пленке, слава tar'у, если это Вам так надо. Частное облако из упоминавшихся нектклоуд, он как минимум бесплатнее для поделиться. Все что не нужно там отключается. Самое ценное - в виде татушек, на теле. Криптография одеждой. Все остальное - не ваше. Ну как бы вы вытатуировали на чужом теле, пусть даже жёнином и венчанном на Вас. Не Ваше. "Какой то миг её держало платье, но долго это продолжаться не могло".... На детях, у них это модно пока, пару ценных советов. Рукописи вроде не горят. Все, из теплого и лампового , пожалуй.
zv347
07.12.2021 18:51Тоже когда-то заморачивался бэкапами на внешний диск.
Сейчас использую яндекс-диск, файлы в трех идентичных копиях — дома, на работе, в облаке.
Однажды на работе случайно один файл. Естественно, он тут же удалился и в облаке. Пришел домой, вынул ethernet-кабель, включил комп, скопировал тот файл. Profit.vvbob
07.12.2021 18:57На многих облаках вроде можно откатывать удаление файла, я так как-то на дропбоксе случайно удаленный файл восстанавливал. Они хранят не все время, но какой-то лаг есть.
muxa_ru
07.12.2021 21:15Очень смешно бывает, когда в рекламе пишут про полный контроль пользователя, про "мы не храним", а потом предлагают платную услугу по восстановлению удалённого.:)
zvszvs
07.12.2021 20:05Сам "старпер", поэтому понимаю.
Однако:
"По окончании работ происходит повторная синхронизация мастер диска на локальный диск рабочего места."
Все же наоборот.Finder001 Автор
07.12.2021 20:07Я работаю всегда с данными на мастер-диске, и поэтому ошибки нет.
zvszvs
07.12.2021 20:54Тогда локальные диски нужны лишь чтобы заиметь точную копию мастера перед началом работы и после окончания. Цель, я так понял, восстановить ошибочно удаленный файл. Но это не сработает, если файл был и создан и удален после синхронизации. Какое-то не идеальное решение. Я бы просто раз в день делал полную копию без синхронизации на какой-нибудь бэкап. Тоже не очень, но проще.
Indemsys
Тоже поначалу использовал синхронизацию из TotalCommander и мобильный диск.
Тоже пару сотен гигабайт рабочая директория.
Но потом стал иногда забывать доставать диск для синхронизации перед работой, и когда после работы снова синхронизировал с диском получались конфликты между версиями справа и слева. И вот в такие моменты в конце рабочего дня очень легко запороть что-то важное.
Поэтому не поскупился и купил GoodSync. Синхронизирую сразу через сеть. 100 мбит в сек вполне хватает чтобы синхронизировать 250 Гб директории на рабочем и домашнем компьютерах за пару минут. А на мобильном диске делаю еще и backup версию, и тоже с помощью GoodSync.
Finder001 Автор
Goodsync интересно посмотрю. Видимо у вас не было правила работать с мастер диска, в этом случае действительно можно попасть на двустороннюю синхронизацию, да это затратно по времени и чревато.
Я признаться пару раз так тоже делал, после этого правила работать с мастера не нарушал)
Indemsys
Я пришел к выводу из вашего изложения что понятие "мастер" диск достаточно условное.
Достаточно за пару рабочих сессий в двух местах забыть его применить и он перестает быть "мастер" и проблема поштучной синхронизации каждого файла вырастает в полный рост.
Я же применял в свое время Total для синхронизации, но теперь его панель синхронизации кажется очень неудобной. Тут речь об исполнении самого UI (User Interface). Хотя я раньше тоже считал что это верх совершенства.
vlad-kras
То есть ваша синхронизация всегда односторонняя, но какие настройки коммандера? Копируете ТОЛЬКО с переносного диска на стационарные?!
День 1, работа дома. Создается файл "документ1".
День 2, работа в офисе.
Начало дня - синхронизация и теперь на офисном HD есть файл "документ1".
Конец дня. Файл "документ1" переименовывается, получает более подходящее название "документ2". Синхронизация, на офисном HD теперь уже 2 файла "документ1" и "документ2". Первый из них должен был удалиться, его же нет на переносном диске.
День 3, работа дома.
Начало дня - синхронизация, на домашнем HD есть файл "документ1" (он уже там был) и "документ2".
Конец дня. Файл "документ2" переименовывается в "документ3". Попутно "фото1" переименовывается в "фото2". Синхронизация, на домашнем HD теперь "документ1", "документ2" и "документ3". А заодно "фото1" и "фото2".
День 4, работа в офисе. Начало - на офисном HD теперь есть мусорные "документ 1-2" и "фото1", которых вообще быть не должно.
Если представить, что это не "MS-офисные" файлы, которые относительно легко разгрести, а рабочие файлы проекта некой IDE или другой программы, активно создающей "очень нужные вспомогательные" файлы, тогда с такой синхронизацией можно получить свалку старых файлов. Главное, чтобы переименовывать файлы либо переносить из каталога в другой каталог приходилось почаще. Например, фотки сложенные по датам пересортировать в тематические каталоги.
Finder001 Автор
Вы забыли, что у меня мастер-диск - носимый, и я работаю только на нем. Все изменения на нем, потом отображаю их на локальные диски.
То что вы описали - конфликт мастеров, когда вы начали работать на локальном диске вместо мастера.
Dzzzen
Использую похожую схему, только у меня не один ssd диск, а 6 флешек по 64-128 Гб. Соответственно, каждая флешка для своего вида информации - проекты, курсы, дистрибутивы, книги, видео и т.д.
Мастер-диском является именно флешка, а на остальные компы раз в неделю с флешки сливается rar-архив. То, что флешек много, уменьшает возможные потери в случае выхода из строя или утери одного накопителя.
Finder001 Автор
В самом начале пытался также кусочками носить архив) Это сильно утомительно. Оказалось проще оптимизировать и уложить в 1 носитель.
vlad-kras
Никак нет, именно такой сценарий и подразумеваю. Вся работа происходит на переносимом диске. Но придя на новое место происходит копирование с переносимого диска на стационарный. В конце дня - то же самое, копирование с переносимого диска на стационарный.
Поэтому и спрашиваю, какие настройки коммандера?
Finder001 Автор
Синхронизация с мастера на локальный диск. На локальном формируется копия исходного архива. Да я опечатался, спасибо. Надеялся все поймут.
Finder001 Автор
Хотя нет, слова копирования у меня нигде нет - и в статье и в коментах везде синхронизация)
Это кто-то меня неправильно понял, а потом мне же еще и предьявил)
Ну да главное чтобы файлы целы были.
navigators
Есть бесплатный аналог freefilesync делает все тоже самое + может автоматом в ват файле и в режиме реального времени... есть порт под линукс.
Finder001 Автор
Да действительно с ним синхронизацию можно делать в 1 тычок мыши, вместо 5. Спасибо.
redmanmale
Для синхронизации через сеть ещё есть опенсорсный и бесплатный Syncthing.
Настроил папки, запустил как сервис и он сам живёт и обновляет все файлы между всеми машинами.
Bonio
Syncthing — самое удобное решение для сихронизации. Тоже давно его использую.