Действительно ну что такого в разработке собственного суперкомьютера или процессора в России ? Их же здесь тысячи компаний разрабатывают и производят...
При таких настройках Total делает вам 2 зеркала. Слева должен быть мастер, справа - slave. Создается копия левого файлового древа на правом носителе.
Но еще раз повторюсь, в коментах был предложен FreeFileSync, который делает тоже самое за меньшее количество тыков кнопок - за 1 тык. В тотале перед синхронизацией нужно выделять в директориях папки которые будут синхронизироваться, это лишние тыки.
Сделайте пару маленьких тестовых папок и стреляйте там в ногу в свое удовольствие) Делов на 10 минут)
Ну в случае если вы предполагаете такие сценарии - просто добавьте в схему резервирования еще пару дисков. Скажем по 1 в рабочий и домашний комп, и делайте там по 2 зеркала)) Купите домой UPS))
У меня описываемых ситуаций за 15 лет не возникло))
>> Ну и да, если для вас "потеряны результаты последней рабочей сессии" — это мелочи, то для меня это не так.
Это и для меня не так. Я пару раз нарушил свои же правила, запорол свою сессию, потерял данные при синхронизации, этого хватило чтобы 15 лет память четко работала)
>> Наоборот. То, что мне нужно, не укладывается в вашу модель.
Я ведь Вас не заставляю ее использовать. Создайте свою, я с удовольствием о ней почитаю.
>> А еще ваша модель — не важно, в оригинальном или модифицированном состоянии — подвержена проблеме вида "уехал из места А с рабочим диском, приехал в место Б с нерабочим" — что делать?
Вообще нет и я несколько раз это обьяснял. На рабочем месте А остался полный рабочий архив, на рабочем месте Б рабочий архив за вычетом последней сессии.
>> Когда я приду сливать эти данные в рабочем месте А — будет как раз классический конфликт веток.
Когда вы сделаете синхронизацию базы с носимого диска на рабочий, у вас не будет никакого конфликта, вы просто затрете данные предпоследней рабочей сессии.
>> В сценарии, который вы предлагаете мне, если забыть одну из синхронизаций, будет конфликт.
Никакого конфликта не будет, просто в базе будут потеряны результаты последней рабочей сессии.
>> Жизнь упрощают только скрипты, которые все делают автоматически. Все, что требует ручной сверки "а туда ли я копирую", неизбежно приводит к ошибке рано или поздно.
Ошибка конечно будет. Но в коментах немало написано про бакап Шредингера от парней, у которых полностью автоматическая синхронизация. Я отличаюсь от них тем, что ЗНАЮ что происходит с моим архивом и моими дисками.
В конце концов - пробуйте...пишите скрипты под свою задачу, многие пишут. Возьмите Syncthing и упражняйтесь...хотя имхо то что Вам нужно не укладывается ни в какую модель, кроме предлагаемой мной.
Нет никаких проблем. В сумме с носимым диском у Вас получается 3 копии БД: 2 идентичных с последнего места работы, и предыдущая версия на том месте работы где Вы в последний раз не работали. Приходите туда, синхронизируете с носимого диска БД туда, и вот у Вас 3 копии БД последней версии.
>> И вот тут начинаются проблемы сугубо логистического толка: надо носить и втыкать два диска, не путаться в них и так далее.
Есть чудесная штука - Disk Label, сильно упрощает жизнь в таких случаях) Кроме того, можно купить один большой SSD и хранить все носимое на нем)
>> Да нет, как раз должно: вы предлагаете всегда работать с мастер-диска, а он внешний.
Мастер диск понятие условное) У вас задача сохранения БД, поэтому Вы можете считать мастером диск своей рабочей машины.
Если же Вы хотите переносить БД целиком между двумя рабочими местами, то тогда формально у Вас 2 мастера. Впрочем этот вариант нужно рассматривать внимательно, тк если СУБД хранит еще какие-то настройки в реестре, не развалится ли все если ее вдруг пересадить на другую базу, это вопрос.
>> О том, что для разумной скорости работы этот каталог (это специальная БД) должен быть на другом физическом диске, нежели фотографии.
По скорости синхронизации work+hard синхронизируется дольше чем relax. Дело в количестве файлов - ведь я не сравниваю файлы по содержимому, в рабочих папках 153 тысячи файлов, синхронизация идет меньше минуты, в relax всего лишь 38 тысяч - там много видео.
Вы без проблем можете пользоваться описанным методом для своего рабочего архива фотографий.
Что касается надежного хранения БД - здесь немного сложнее. Тк в БД полагаю все файлы бинарные, то Вы без проблем можете хранить зеркало БД на отдельном диске. Но при синхронизации придется включать сравнение файлов по-содержимому, чтобы базу не поломать. В коментах рекомендовали пару утилит, которые работают побыстрее чем TotalCommander - FreeFileSync && Goodsync.
Можно ли запустить базу с внешнего диска или нет Вас волновать не должно - задача резервного хранения данные сохранить целыми, а не использовать.
Немного непонятно о чем речь с каталогом, если имеется в виду файловая система диска, то просто ставите все на резерв, и все, если это специальная БД с индексом для поиска - тогда эту часть данных также нужно бакапить с синхронизацией файлов по содержимому.
Слушайте я понял откуда все эти речи про архив Шредингера и неопределенность. Видимо Вы пользуетесь автоматической синхронизацией и НЕ ВИДИТЕ ГЛАЗАМИ изменения своего архива, поэтому он для вас нечто неизвестное.
В тотале я при каждой синхронизации вижу глазами все что изменяется. Именно поэтому я в курсе всех возникающих проблем в момент их возникновения, поэтому и утверждаю, что у меня битые файлы не распространятся - при появлении первых же изменений, не инициированных мной, я сразу начну искать причину изменений.
У меня реально не возникает и никогда не возникало никаких из перечисленных проблем)
Респект. Не просто отказаться, так еще и озвучить, и бороться за существование озвучки.
Действительно ну что такого в разработке собственного суперкомьютера или процессора в России ? Их же здесь тысячи компаний разрабатывают и производят...
При таких настройках Total делает вам 2 зеркала. Слева должен быть мастер, справа - slave. Создается копия левого файлового древа на правом носителе.
Но еще раз повторюсь, в коментах был предложен FreeFileSync, который делает тоже самое за меньшее количество тыков кнопок - за 1 тык. В тотале перед синхронизацией нужно выделять в директориях папки которые будут синхронизироваться, это лишние тыки.
Сделайте пару маленьких тестовых папок и стреляйте там в ногу в свое удовольствие) Делов на 10 минут)
Хотя нет, слова копирования у меня нигде нет - и в статье и в коментах везде синхронизация)
Это кто-то меня неправильно понял, а потом мне же еще и предьявил)
Ну да главное чтобы файлы целы были.
Я работаю всегда с данными на мастер-диске, и поэтому ошибки нет.
Синхронизация с мастера на локальный диск. На локальном формируется копия исходного архива. Да я опечатался, спасибо. Надеялся все поймут.
За день я редактирую разумеется очень мало файлов. Но общее древо, которое нужно для работы, сильнее сократить не удалось.
Да действительно с ним синхронизацию можно делать в 1 тычок мыши, вместо 5. Спасибо.
В самом начале пытался также кусочками носить архив) Это сильно утомительно. Оказалось проще оптимизировать и уложить в 1 носитель.
не у одного меня паранойя))
Ну в случае если вы предполагаете такие сценарии - просто добавьте в схему резервирования еще пару дисков. Скажем по 1 в рабочий и домашний комп, и делайте там по 2 зеркала)) Купите домой UPS))
У меня описываемых ситуаций за 15 лет не возникло))
Вы забыли, что у меня мастер-диск - носимый, и я работаю только на нем. Все изменения на нем, потом отображаю их на локальные диски.
То что вы описали - конфликт мастеров, когда вы начали работать на локальном диске вместо мастера.
Учитывая озвученную мной статистику - 10 мертвых дисков за 15 лет и 0 потерь данных - решайте сами, подходит ли это вам.
Или вам больше нравится потерять все данные разом при смерти вашего рабочего диска)
>> Так что делать-то в этом случае?
вернуться в точку А и залить новый мастер-диск правильной базой
>> Вы забыли, что последняя рабочая сессия основана на неактуальных данных, и, следовательно, не обязательно валидна.
Я не в курсе вашей специфики, возможно что мой метод вам действительно не подходит.
>> Ну и да, если для вас "потеряны результаты последней рабочей сессии" — это мелочи, то для меня это не так.
Это и для меня не так. Я пару раз нарушил свои же правила, запорол свою сессию, потерял данные при синхронизации, этого хватило чтобы 15 лет память четко работала)
>> Наоборот. То, что мне нужно, не укладывается в вашу модель.
Я ведь Вас не заставляю ее использовать. Создайте свою, я с удовольствием о ней почитаю.
>> А еще ваша модель — не важно, в оригинальном или модифицированном состоянии — подвержена проблеме вида "уехал из места А с рабочим диском, приехал в место Б с нерабочим" — что делать?
Вообще нет и я несколько раз это обьяснял. На рабочем месте А остался полный рабочий архив, на рабочем месте Б рабочий архив за вычетом последней сессии.
>> Когда я приду сливать эти данные в рабочем месте А — будет как раз классический конфликт веток.
Когда вы сделаете синхронизацию базы с носимого диска на рабочий, у вас не будет никакого конфликта, вы просто затрете данные предпоследней рабочей сессии.
>> В сценарии, который вы предлагаете мне, если забыть одну из синхронизаций, будет конфликт.
Никакого конфликта не будет, просто в базе будут потеряны результаты последней рабочей сессии.
>> Жизнь упрощают только скрипты, которые все делают автоматически. Все, что требует ручной сверки "а туда ли я копирую", неизбежно приводит к ошибке рано или поздно.
Ошибка конечно будет. Но в коментах немало написано про бакап Шредингера от парней, у которых полностью автоматическая синхронизация. Я отличаюсь от них тем, что ЗНАЮ что происходит с моим архивом и моими дисками.
В конце концов - пробуйте...пишите скрипты под свою задачу, многие пишут. Возьмите Syncthing и упражняйтесь...хотя имхо то что Вам нужно не укладывается ни в какую модель, кроме предлагаемой мной.
>> Сначала был диск на 250 гигов. Потом типа крутая флешка на 64. Потом хорошая брендовая флешка на 32. И все что нужно умещается.
да я этот путь тоже прошел, но у меня к сожалению после предельного сжатия все равно больше 200Гигов рабочих файлов((
>> Два мастера — проблема синхронизации.
Нет никаких проблем. В сумме с носимым диском у Вас получается 3 копии БД: 2 идентичных с последнего места работы, и предыдущая версия на том месте работы где Вы в последний раз не работали. Приходите туда, синхронизируете с носимого диска БД туда, и вот у Вас 3 копии БД последней версии.
>> И вот тут начинаются проблемы сугубо логистического толка: надо носить и втыкать два диска, не путаться в них и так далее.
Есть чудесная штука - Disk Label, сильно упрощает жизнь в таких случаях) Кроме того, можно купить один большой SSD и хранить все носимое на нем)
>> Да нет, как раз должно: вы предлагаете всегда работать с мастер-диска, а он внешний.
Мастер диск понятие условное) У вас задача сохранения БД, поэтому Вы можете считать мастером диск своей рабочей машины.
Если же Вы хотите переносить БД целиком между двумя рабочими местами, то тогда формально у Вас 2 мастера. Впрочем этот вариант нужно рассматривать внимательно, тк если СУБД хранит еще какие-то настройки в реестре, не развалится ли все если ее вдруг пересадить на другую базу, это вопрос.
>> О том, что для разумной скорости работы этот каталог (это специальная БД) должен быть на другом физическом диске, нежели фотографии.
Ну так используйте отдельный SSD
По скорости синхронизации work+hard синхронизируется дольше чем relax. Дело в количестве файлов - ведь я не сравниваю файлы по содержимому, в рабочих папках 153 тысячи файлов, синхронизация идет меньше минуты, в relax всего лишь 38 тысяч - там много видео.
Вы без проблем можете пользоваться описанным методом для своего рабочего архива фотографий.
Что касается надежного хранения БД - здесь немного сложнее. Тк в БД полагаю все файлы бинарные, то Вы без проблем можете хранить зеркало БД на отдельном диске. Но при синхронизации придется включать сравнение файлов по-содержимому, чтобы базу не поломать. В коментах рекомендовали пару утилит, которые работают побыстрее чем TotalCommander - FreeFileSync && Goodsync.
Можно ли запустить базу с внешнего диска или нет Вас волновать не должно - задача резервного хранения данные сохранить целыми, а не использовать.
Немного непонятно о чем речь с каталогом, если имеется в виду файловая система диска, то просто ставите все на резерв, и все, если это специальная БД с индексом для поиска - тогда эту часть данных также нужно бакапить с синхронизацией файлов по содержимому.
Слушайте я понял откуда все эти речи про архив Шредингера и неопределенность. Видимо Вы пользуетесь автоматической синхронизацией и НЕ ВИДИТЕ ГЛАЗАМИ изменения своего архива, поэтому он для вас нечто неизвестное.
В тотале я при каждой синхронизации вижу глазами все что изменяется. Именно поэтому я в курсе всех возникающих проблем в момент их возникновения, поэтому и утверждаю, что у меня битые файлы не распространятся - при появлении первых же изменений, не инициированных мной, я сразу начну искать причину изменений.
У меня реально не возникает и никогда не возникало никаких из перечисленных проблем)