Comments 377
habr.com/ru/company/simnetworks/blog/308266
Ну так, примера ради…
У Вас оператор перед двойкой не тот — если вероятность отказа одного облака равна P, то двух сразу — не P/2, а P^2. В частном случае P=1/2=50% (и только в нем) эти выражения совпадают, но вообще нет (а вероятность отказа облаков, к счастью, намного меньше 1/2 — а значит, P^2 намного меньше P/2).
P.S. Конечно, можно говорить только о вероятности отказа в течение определенного срока (за 1 год, за 10 лет и так далее — чем больше срок, тем больше и вероятность отказа).
тогда вероятность потери будет в два раза ниже чем в одном облаке
Вот эта вещь справедлива только в том случае, если вероятность отказа одного облака 1/2, а это совсем не обязательно.
А кто сказал, что вероятность потери файла от времени — величина постоянная и равная для любого файла?
Неиспользуемый давно файл с большей вероятностью будет перемещён или "потеряется", потому как законы природы и бизнеса одинаковы для обоих облачных провайдеров.
Он и 1/4 явно не равен. Облаками никто бы не пользовался, если бы вероятность отказа была столь высока.
время восстановления с копии в одном облаке на второе 3,65 дня
Надо прибавить время реагирования. Если вы начнёте копировать данные на следующий день, то получится 4,65 дня.
А если это данные долговременного хранения, то узнать о том, что они умерли в каком-то из сервисов вы можете и через месяц (в моем случае более вероятно, через квартал, но допускаю, что я исключение).
В Амазоне, Майкрософте, Гугле есть большие облака и выстроена неплохая система защиты от таких умельцев. Но что произойдёт, когда, например, в AES найдут серьезную уязвимость и все трое дружно бросятся перешифровывать данные забив на свои правила тестирования и релизов — никто не знает. И дублирование облаков вас тоже в этой ситуации не спасёт.
А myspace на самом деле вообще никому сохранности данных не гарантировал, как получилось так и хранили.
Я бы ещё добавил вероятность покупки первого облака вторым с последующим отказом.
Ещё бы добавил вероятность запрета на выдачу данных обоим облакам, если вы проживаете в регионе, который не по нраву правительству той страны, которая генерирует максимальную прибыль обоим облакам.
Ещё вероятность того, что в самом регионе решат закрыть интернет.
…
Сумма вероятностей в современном мире уже стремится к тому, чтобы привысить риски своего облака.
шанс потери с двух облаков, мой друг, это вероятность падения первого облака, умноженная на вероятность падения второго,
Нет. Падения двух разных облаков — это, мягко говоря, не независимые события.
2) Может использоваться одинаковое/сходное железо с одинаковыми уязвимостями (Спектр, ага)
3) Могут находиться в одной юрисдикции (государстве)
4) Могут находиться близко географически (ураганы, землетрясения и пр. дизастеры)
А вот почему вдруг они будут независимы — это и правда интересный вопрос.
Всё вами перечисленное с приставкой «Могут не».
А также единичные баги/отказы/и человеческие ошибки, из разряда «вероятность нахождение 2 бомб в самолете»
Всё вами перечисленное с приставкой «Могут не».
Нет, вы перепутали причину и следствие. Если события независимы — то будет всё мной перечисленное с частицей «не». Обратное неверно.
Во-первых, 100% сохранность данных гарантировать нельзя в принципе. Вероятность того, что какой-нибудь псих получит доступ к ядерной кнопке и разнесет к чертям всю цивилизацию, конечно, невообразимо мала, но тем не менее, она все-таки больше нуля.
А во-вторых, если есть только 2 возможных сценария развития событий, то совсем не факт, что они равновероятны. Блондинки про это как раз и забывают.
Почему же только два? Только один. Возможность потерять данные точно есть.
Если да то можно пользоваться, если нет то сразу переход на другой.
И что, много таких, которые гарантируют 100% сохранность данных?
Насреддин рассказывает, что как-то раз поспорил с эмиром бухарским, что научит своего ишака богословию так, что ишак будет знать его не хуже самого эмира. На это нужен кошелёк золота и двадцать лет времени. Если он не выполнит условия спора — голова с плеч. Насреддин не боится неминуемой казни: — «Ведь за двадцать лет, — говорит он, — кто-нибудь из нас троих обязательно умрёт — или эмир, или ишак, или я. А тогда поди разбирайся, кто лучше знал богословие!»
Я бы сказал, что низкой будет вероятность потери в двух хранилищах одновременно
Хех.
Идея для стартапа: гипероблака.
Берем несколько облачных хранилищ и по аналогии с хранением данных в единичных облаках обеспечиваем целостность данных на нескольких облаках.
С одной стороны /sarcasm
, а с другой ведь наверняка кто-то уже что-то такое намутил.
Облака то может и разные, а дата центры общие)
Храните на перфокартах, это надежно!)
А есть ещё один уровень: у них одинаковый софт который одинаково превращает данные в тыкву, если високосные секунды происходят в год, являющийся целым значением C для x²+y²=-C.
Почему-то до владельцев облаков не доходит, что облака — это не только бабло раз в месяц, но и ответственность каждую секунду. И не юзеры должны быть привязаны к облаку, а облака к юзерам, к их ожиданиям.
P.S. Серьезно, если завтра какой-нибудь AWS или Azure скажет, что их новое бизнес-видение подсказало им, что хранить блочные диски виртуалок немодно, и они дают месяц и по сотне долларов кредитов, чтобы юзеры очень быстро побежали и очистили свои диски, перейдя на новую, более современную, технологию хранения, это будет как бы более-менее честно в мире бизнеса, но ни разу не удобно тем, кто хранит данные: люди должны будут бросить всё, и срочно перестраивать всю свою систему. И если от Амазона я такого не жду, от Азура жду, но все же не очень верю, то от провайдеров менее масштабных (в России это будут облака Я и М, как по мне — посмотрим, как они лет через пять изменятся) вполне реально дождаться «революции». В общем, для долговременного и беззаботного хранения архивов я бы в одлака не поверил, ни в одно, ни в два сразу.
P.P.S. Напомню из «Одноэтажной Америки», про слепую веру в беззаботность:
В свое время я мечтал сделаться богатым человеком. Я зарабатывал много денег и решил застраховать себя таким образом, чтобы получить к пятидесяти годам крупные суммы от страховых обществ. Есть такой вид страховки. Надо было платить колоссальные взносы, но я пошел на это, чтобы к старости стать богатым человеком. Я выбрал два самых почтенных страховых общества в мире – петербургское общество «Россия» и одно честнейшее немецкое общество в Мюнхене. Сэры! Я считал, что если даже весь мир к черту пойдет, то в Германии и России ничего не случится. Да, да, да, мистеры, их устойчивость не вызывала никаких сомнений. Но вот в девятьсот семнадцатом году у вас произошла революция, и страховое общество «Россия» перестало существовать. Тогда я перенес все свои надежды на Германию. В девятьсот двадцать втором году мне исполнилось ровно пятьдесят лет. Я должен был получить четыреста тысяч марок. Сэры! Это очень большие, колоссальные деньги. И в девятьсот двадцать втором году я получил от Мюнхенского страхового общества такое письмо: «Весьма уважаемый герр Адамс, наше общество поздравляет Вас с достижением Вами пятидесятилетнего возраста и прилагает чек на четыреста тысяч марок». Это было честнейшее в мире страховое общество. Но, но, но, сэры! Слушайте! Это очень, о-чень интересно. На всю эту премию я мог купить только одну коробку спичек, так как в Германии в то время была инфляция и по стране ходили миллиардные купюры.
За 10 лет:
- video.sibnet.ru потерял большую часть моих видео
- imageshack.us потерял все мои картинки
- imgur.com то ли удаляет, то ли теряет часть картинок периодически (в тех. поддержке толком ответить не смогли)
Наиболее надежно, быстро и разумно — хранить файлы дома, с использованием mergerfs + snapraid.
Имеете множество серверов с небольшим объемом диска, но хотите его эффективно утилизировать?
Установите Tahoe-LAFS — распределенное избыточное шифрованное хранилище файлов, где storage-ноды хранят кусочки файлов, не зная их содержимое.
С Tahoe-LAFS можно хоть каждую минуту вытаскивать сраные диски, а файлы всё равно останутся доступны.
Авторизации нет, все могут загружать сколько угодно данных. Ноды-хранилища могут устанавливать срок хранения частей файлов, но по умолчанию эта функция отключена, и части не удаляются.
Алгоритм разделения частей устанавливает клиент, при загрузке файла. По умолчанию используются 2-7: чтобы успешно скачать файл, нужно иметь доступ как минимум к 2 частям, при этом на ноды загружается 7 частей.
Дополнительную информацию см. на www.tahoe-lafs.org и leastauthority.com (платный облачный провайдер, использующий Tahoe-LAFS)
Особо чувствительную информацию все равно необходимо хранить в нескольких местах.
… Панорамио.
>Яндекс…
… Фотки.
Но конечно, надо было выбирать какие-то другие помойки, и надеяться, что там из контейнеров фиалками пахнет.
Вообще облака и «HDD на полочке» друг друга отлично дополняют: облака страхуют от пожаров, наводнений и соседей сверху, а диск на полочке — от головотяпства сотрудников облачной компании и угона паролей.
Лучше всего делать две копии — у туда и туда.
в гугл я пришел, когда там гугл фото уже былоНу то есть вы понимаете, что вам просто повезло разминуться.
Вы небось еще и с фейлом клиента Я.Диска разминулись. Я тоже, ибо не держал.
Яндекс фотки все в Я.диск переехали без потерь«Без потерь» — это значит, например, без всех пользовательских комментариев.
Я уже не говорю о том, что найти их на Я.Диске — тот еще квест. Я до сих пор знаю, как к ним добраться, только через «историю».
Зато бонусом ко мне на диск приехало несколько НЕ моих фоток, которые я туда совершенно точно не грузил, а заодно несколько тоже НЕ моих mp3; все чохом с одной датой загрузки.
Зашибись надежность, ящетаю. Так держать.
Найти не сложно… В корне яндекс-диска лежит папка с названием Яндекс.Фотки
Комментарии потерялись… но в качестве альтернативы тут предлагают файлопомойки на домашних насах с убогим интерфейсом и без всякой социальщины. Т.е. комменты к домашним бэкапам в принципе появится никогда не могли, а на яндексе вы ими лет 10 наслаждались, пока фотки работали.
Про косяки с чужими файлами, безопасность и надежность в целом — у меня, как дилетанта в администрировании серверов, ошибок будет точно на порядок больше чем у яндекса.
«просто повезло разминуться» — когда закрывался бесплатный тариф у Adrive.com, у меня было несколько месяцев, чтобы перенести файлы в другое облако. Не припомню случая, чтобы гугл не прислал уведомление, что сервис через несколько месяцев закроется.
Найти не сложно… В корне яндекс-диска лежит папка с названием Яндекс.Фотки… В которой лично у меня лежит ОДНА фотка. Из двенадцати альбомов. Спасибо, кэп...
а на яндексе вы ими лет 10 наслаждались, пока фотки работали.Это прекрасно, но когда мне на голубом глазу заявляют, что «переехали без потерь» — таки это высокохудожественный свист.
В случае домашней файлопомойки я и не закладываюсь на социалку. А в ЯФ опция была, теперь не стало, и все контакты тоже ушли в помойку. Это называется «без потерь», не перепутайте. Ладно, у меня контакты были почти все вторичные, пришедшие из оффлайна. А кто-то небось всерьез повелся…
Про косяки с чужими файлами, безопасность и надежность в целом — у меня, как дилетанта в администрировании серверов, ошибок будет точно на порядок больше чем у яндекса.Вряд ли вы, как дилетант, напишете для своей файлопомойки на домашнем насе скрипт, который снесет вам содержимое диска С:\ — вы, как дилетант, его и писать не будете. Этим да, вы отличаетесь от яндекса (/сарказм).
При минимальном понимании процесса у вас ошибок будет на порядок меньше, чем у яндекса — просто потому, что ваша система на порядков на шесть проще. И это уже не сарказм.
Не припомню случая, чтобы гугл не прислал уведомление, что сервис через несколько месяцев закроется.Лично мне фотохостинг нужен, чтобы публиковать свои фото в сети. И я в гробу видал бегать по всем ресурсам, где что-то публиковал, и судорожно менять ссылки. Даже если хостеры оказались столь любезны, что прислали уведомление за несколько месяцев.
(Справедливости ради: Я.Фотки таки сдержали слово, ссылки менять не пришлось. Правда, картинки все равно несколько месяцев не открывались, но потом все заработало).
У меня вообще никаких печатных слов не осталось. Нет, моих фоток там не лежит. Там лежит кучка каких-то рекламных материалов и скан результатов МРТ совершенно чужого человека. Из двадцати пяти файлов ко мне имеет отношение один. Часть файлов не читается, «ошибка загрузки страницы».
Яндекс, вашу мать, вы совсем охренели, перемешивать чужие данные?
![](https://habrastorage.org/webt/tw/ja/-v/twja-volrhaqizscwna2l8sodie.png)
Это да. Особенно после этого шикарного заявления: «MySpace не делал резервных копий всех пользовательских данных.» Меня, как мелкого сисадмина, за такое гнали бы с работы ссаными тряпками.
Скорее напротив, сочли бы некомпетентным, если бы вы тратили место на бекапы ненужных файлов типа /tmp
Речь идет о неокупаемом проекте, соответственно, файлы которого не представляют коммерческой ценности.
А поскольку фирма еще и не богатая, то приходится выбирать, включив голову, что хранить с резервными копиями, а что нет.
Вас бы гнали из MySpace ссаными тряпками, как вы выражаетесь, как раз за разбазаривание ресурсов.
Храните в облаках, говорили они. Облака надёжны и никогда не потеряют ваши данные, говорили они.
Дело не в физической организации — облака там или нет.
Если речь идет о бесплатной услуге.
Если же речь шла о платной услуге, пусть и в облаках — это немножко другое дело.
Наверняка в договоре-оферте с MySpace было написано «можем удалить когда захотим сами, не за что не отвечаем».
Великий Майли ру дарил мне 100ГБ. Тут я ещё активно стал юзать электронные финансы и короче скинул файлик «с секретами» туда на всякий пожарный. Со временем собралось инфы на 90 ГБ. Туда сюда — пришлось что-то форматироватировать, дай думаю скину всё в облако. Сказано сделано.
В итоге с того момента перестал хранить инфу в принципе. Весь контент с тех 90ГБ был покрыт не тяжелыми конфигами сейвами, а тежяловесы представляли собой фото и видео вновь накопленное после первого файл-луза упомянутого в начале.
Все эти соц сети, весь этот контент с мобилок — все выгружалось туда и не дуплицировалось в личные архивы на компе или даже в облако. Пропала надобность хранить образы инсталлов игр и других тяжеловесов, так как «стим» например всегда разрешить скачать установочный дистрибутив игры без проблем.
В итоге лет г как, диск Д:/ на компе покрывается лишь временными файлами установленных игр, программ и все.
В моем случае это работает. Я не храню коллекцию любимых фильмов и т.п. Их я смотрю онлайне. Ну вы понимайте… а те Файлы в облаке так и хранятся и не повредились.
Да у гугла по умолчанию не большой объём облака, но в сохранности контента я не сомневаюсь. Уверен Смысл есть! Тем у кого есть такая необходимость. Покупка нескольких интересных пакетов даже у разных провайдеров облачного хранения — это достойный и современный ответ на ваши потребности в хранении данных.
Котиков храните в социальных сетях, коллекции фото и видео в облаках. Дистрибутивы игр и программ, документы. А остально вам всегда дадут скачать, тем паче скорости нынче и времена не те что раньше).
А остально вам всегда дадут скачать, тем паче скорости нынче и времена не те что раньше).
Учитывая грядущую суверинетизацию рунета я бы рекомендовал, наоборот, начинать запасаться всем тем, что качается извне — включая игры стима.
Те старые CD у меня не умерли, некоторые причем это особо дешевенькие диски они то читаются процентов на 90-95, просто в некоторых местах есть проблемы, там если присмотреться к поверхности и точки можно обнаружить на них, а на более менее фирменых CD 20 летних все прекрасно ни точек ни просадок скорости, на двд коих у меня раз в 10 больше чем CD в том числе очень много старых 13-17летних все отлично на всех дисках что на фирменных, что на простых, поэтому сама технология двд понадежней будет, по крайней мере она точно другая и пока еще работают все самые простецкие диски
Да, видеоплееры могут пропускать участки и, более того, некоторые DVD специально со сбойными блоками делают — защита от копирования. Смотреть их можно, скопировать — сложно.
«Облаком» может служить еще одна пара hdd расположенная у родственников/знакомых/родителей и т.д.
Смотрите чтоб он не был подключён. К моим родственникам забрался Шифровальщик, и весь backup в утиль сбросил, в то время когда я у себя определялся с железом, и надеялся что там уж точно ничего не может случится, и потом заберу бэкапы.
В части синхронизации есть 2 опасности: 1) Если бекапные ресурсы (например, предоставляемые NAS'ом) прописаны на компе как логические диски, то шифровальщик спокойно доберется до синхронизированной копии — ведь шифровальщик будет прозрачно работать как с обычным виндовым диском. В том числе и поэтому я последние несколько лет никому не советую подключать сетевые ресурсы в качестве логических дисков — безопаснее использовать подключенные сетевые расположения — все равно они так же открываются в проводнике как папка, в Total Commander для ручной синхронизации сетевое расположение так же доступно в панели TC. 2) При полностью автоматизированной синхронизации на сетевой ресурс (в т.ч. облачный; локальный — неважно как подключенный) тоже велик риск затереть копии файлов зашифрованными — хотя, насколько я понимаю, тут есть множество вопросов — будет ли клиент синхро-софта отлавливать изменения содержимого файлов, если их размер и дата-время не менялись и т.п. — хотя для синхронизаторов, которые заявляют о способности синхронизировать только измененные части файлов, — очевидно что будет синхронизировать.
Если же использовать полуавтоматизированную (с ручным запуском, контролем глазами) синхронизацию на дискретные (ротируемые, временно подключаемые) диски (ну или опять же на сетевые ресурсы, повторюсь, НЕ подключенные как логические диски) — например, средствами Total Commander, или FreeFileSync, или GoodSync (который мне любезно подсказали в этой дискуссии) и т.п., то после анализа изменений, до щелчка кнопки «синхронизировать», вы увидите, что список файлов, предлагаемых к синхронизации, неожиданно длинный и нужно насторожиться, выборочно перепроверить и т.п.,… а в первую очередь — срочно отключить внешний диск! Ну а если синхронизировать на сетевое расположение — то срочно метаться не нужно — шифровальщик не прорвется в облако или на NAS… про NAS — под вопросом — есть же модели NAS под управлением Windows (в каких-то редакциях) и если шифровальщики способны перебираться между незащищенными компами в локальных сетях, то почему не прорваться и на такой NAS. Поэтому лучше наверное использовать обычные NAS с операционками в виде кастомизированно-урезанных линуксов.
Инкрементное или дифференциальное резервирование, в том числе и полностью автоматизированное, защищает нас от затирания резервных копий шифрованными оригиналами — ведь шифрованные оригиналы, являясь обновленными файлами (новыми версиями), будут зарезервированы в новые (последние в цепочке) инкрементные или дифференциальные тома в резервной копии — предыдущие тома затронуты никак не будут.
У меня многое на старом ноуте хранится, одна из копий. Проблем с совместимостью точно не будет. Насчёт долговечности наоборот, вопрос открытый.
Я вот как-то раньше не подумал насчет использования старых хардов в этой роли — а теперь жалею, что лет 6 назад пристроил знакомым и даже продал дешево старых внешних хардов с USB 2.0 терабайтов на 6. Резона в пристраивании и продаже не было никакого — а так бы они у меня лежали тихонько в двойных плотных полиэтиленовых пакетах, в металлических коробах — в дальнем подвале.
www.amazon.com/Female-SATA-Adapter-Converter-bidirectional/dp/B001PYSAJI
www.amazon.com/SATA-NGFF-Adapter-Power-Cable/dp/B01FE8NKC2
Сейчас вон, в блоках питания появилась новая мера качества — количество японских конденсаторов. Дожили. Скоро опять будем смотреть -а контакты золоченые? А микросхемы кто производил?
Стримеры, как вариант. Желательно, одну копию держать в другой стране, на случай попадания в дом метеорита, или, «взрыва бытового газа».
А на 4 дисках выгоднее RAID10, тот же объем но выге скорость. Хотя с точки зрения надежности он немного хуже...
А так я за эти же деньги в прошлом году ссдшку на два терабайта на амазоне заказывал — нормально доехала. Винт в европах я тоже как-то покупал пятитерабайтный, но он был на тот момент на треть дешевле, чем в России. А с разницей в цене в 300-500 рублей лучше уж взять в России.
Как работает?
Лет через 5 можно будет проапгрейдиться еще раз. :)
Так что, как не крути (и для тех, кто уедет, и для тех, кто останется), но георезерв в две разные страны — отличная идея.
Сразу восстановим данные из бэкапа, из квартиры родственников
Вы всегда на работе, а ваши дети всегда в школе? Вы никогда всей семьёй не отдыхаете? Например, поход в кино может закончиться террактом, полёт на самолёте авиакатастрофой, поездка на автобусе дорожной аварией… Да тот же взрыв газа у соседа ночью, пока все спят. Второй вопрос, смогут ли ваши родственники, даже если им будет надо, получить доступ к данным? Знают ли они пароли от облака, от зашифрованного файла?
Ленточные накопитили для бекапов самое то.
m.habr.com/ru/post/422851
Для домашнего бекапа хватит и рейд копии диска.
Само собой, если объёмы не терабайтами измеряются.
Все фото правда нужно будет перегонять в форматы попроще + взять программку для каталогизирования, вроде WinCatalog, или что больше по душе.
Само собой все диски нужно хранить не на балконе (регулярные перепады температуры нам не нужны), а в дальнем шкафу, подальше от собак, кошек и детей. Хорошо бы еще парочку экземпляров записать, и положить в другом месте.
Насчёт надежности, хотелось бы почитать что-нибудь.
Если же ты любитель каяков и хочешь все походы сохранять, то их будет сильно мало, там нужно или NAS покупать, или на ленту писать. Но это уже другой портфель.
![FUJITSU DYNAMO](https://habrastorage.org/webt/vw/g_/ij/vwg_ijeefx3gjlzfml4bkxye9nq.jpeg)
![FUJITSU DYNAMO](https://habrastorage.org/webt/vw/g_/ij/vwg_ijeefx3gjlzfml4bkxye9nq.jpeg)
В качестве временного решения, пока она не заведётся, буду пользоваться M-Disc от Verbatim.
Что касается размера, у FUJITSU была целая линейка, вплоть до, кажется, 2 с чем-то гигабайт. Причем с обратной совместимостью.
Вторая копия в облаке mail.ru, первая копия на съемном 2.5" HDD. Нулевая — на 3.5" HDD в медиапроигрывателе.
Паранойя? Может быть, но ни одного файла за 18 лет не потерялось… :)
Почему так? Верить никому нельзя:
— можно ли верить производителю харда? нет — вполне можно напороться на серию с большим количеством брака (хорошо если посыпется сразу по всему миром хором и вы заранее об этом узнаете и можно метнуться-подстраховаться, а если брак отложенный?);
— можно ли верить производителю NAS? — тоже вряд ли.
— можно ли верить разработчику бэкап-софта? — нет — форумы переполнены плачем об отказе софта восстановить из бэкапа или просмотреть его содержимое, или продолжить бекап в инкрементную/дифференциальную цепочку (4 разных бэкап-инструмента я отобрал для себя в результате мучительного многолетнего отбора)
— можно ли верить облачному провайдеру? — нет, в любой момент может все потерять, а с его отказом об ответственности нам уже была предоставлена возможность согласиться, когда регистрировали учетную запись.
Мои инкрементные семейные бэкапы позволяют откатиться назад на 3-4 года с дискретностью примерно в 1 месяц — это на тот случай, если дражайшая супруга (она является «логическим» администратором массива) не найдет что и куда разложила и озадачит меня вопросом — а вот где папка «Бухаем на даче 2015 (2)»? И эти инкрементные бэкапы я уж постараюсь сохранить ближайшие лет 20.
Пословица: «пользователи делятся на тех, кто не делал бэкап и на тех, кто начал его делать» уже сильно устарела — в нынешнее время вынужденно-огромных объемов данных (причем очевидна долговременная ценность только некоторой части данных), тотального снижения качества (и предсказуемости — добротности) и железа и софта, невозможности быть уверенными в целостности инфы, пословица выглядит так:
пользователи делятся на 5 категорий:
1) те, кто никогда не делал бэкап;
2) те, кто начал делать (хоть какой-то) бэкап;
3) те, кто начал делать бэкапы разными средствами, на распределенную систему разнородных машинных носителей
4) те, кто начал проверять целостность бэкапов;
5) те кто начал проверять реальную возможность восстановления из бэкапов
(по категориям 2-5 есть еще подкатегории с уточнением «регулярно»).
Я нахожусь в категории 4 — нерегулярно устраиваю проверки целостности родными инструментами — следовательно, (легкомысленно?) доверяю разработчикам бэкап-софтов, в надежде, что хотя бы один из четырех не уйдет с рынка, не перестанет поддерживать предыдущие форматы и т.п. — в общем актуальность сохранится на 10-15 лет.
Формат «Просто файлы» на синхронизированных хардах — периодически, выборочно (по папкам верхнего уровня) провожу побайтовую сверку средствами Total Commander — тут более-менее можно быть уверенным в целостности файлов и что хард пока не битый.
Какие софт/инструменты?
1.1. N ротируемых внешних хардов 2,5" — Seagate, WD для зеркальной односторонней дискретной синхронизации средствами FreeFileSync — далеко ниже по этому обсуждению я написал большой комментарий-вопрос про возможно уникальный функционал FreeFileSync;
1.2. Периодичность — примерно 1 раз в 2 недели, очередной обновленный диск отношу в другую точку хранения (подвал, другое домохозяйство....); прямо-уперто этим не заморачиваюсь, но стараюсь обменять 1 пару дисков не реже 1 раза в месяц. На случай внезапных локальных проблем пожар/залив соблюдаю правило — два (и тем более — больше) ротируемых диска никогда не встречаются в домохозяйстве где находится исходный ноутбук, диски встречаются только в дистанционной точке хранения, непосредственно при обмене; продолжительность каждого сеанса синхронизации — обычно не более 10 минут.
1.3. Обеспечение сохранности в точке хранения — сам внешний диск плотно завернут в небольшой пакет, пакет — в полужесткий противоударный футляр, футляр — еще в один пакет. Это целесообразно для минимизации вероятности коррозии контактов USB 3.0 (хотя во всех точках хранения у меня все в порядке с влажностью и температурой, но я рассчитываю на очень длительный срок эксплуатации этих дисков — 10-20 лет, так как а) скорости USB 3.0 достаточно; б) семьей решили, что будем по возможности сопротивляться появлению видео в формате 4-8 К и фото по 100-мегапикселей (не нужно все это); в) расчет емкости показывает, что на них свободного места должно хватить, гм, до конца пенсии); футляр в пакете — в металлический (жестяной) ящичек-чемоданчик (ну типа от новогодних конфет для детей) — это нужно на тот всякий случай, если в условиях нынешней напряженной обстановки супостат применит нелетальное массовое оружие — например с мощным электромагнитным импульсом — предполагаю, что металлическая оболочка, пусть и тонкая, повысит вероятность выживания харда (особенно в точке хранения ниже уровня грунта) — но это гипотеза, тут я не спец;
1.3. Выборочные проверки — для отдельных под-под-папок — изредка побайтово проверяю средствами Total Commander; это позволяет выяснить, что некоторая (очень малая) часть файлов в порядке, а так же подтвердить, что хард в целом жив;
1.4. Тотальные проверки — не чаще 1 раза в 2 года — в другом (не там где исходный ноутбук) домохозяйстве подключаю 2 полностью синхронизированных внешних харда к другому ноуту и средствами Total Commander провожу тотальную побайтовую проверку всего массива, сразу на двух хардах. Занимает 14-16 часов, гарантирует целостность файлов, укрепляет веру в харды (это максимальная редкая нагрузка на харды, в целом получается что каждый из них работает не более 50 часов в год).
2) Про облако.
2.1. По очень большому кол-ву параметров избран таки Яндекс.Диск (анализ — это отдельная тема)
2.2. На нем специально заведена семейная учетка — чтобы не путалось с личными.
2.3. Все из корня синхронизируется с основной папкой на основном ноуте — синхронизация двусторонняя зеркальная, Яндекс.Диск по другому не умеет;
2.4. Родня обучена из мобильных устройств ПЕРЕМЕЩАТЬ файло в мобильный клиент Яндекс.Диска — периодически, по потребности. Это позволяет избежать ужасающего дублирования файлов при смене устройств и т.п.
2.5. Соответственно, в папку на исходном ноуте новые файлы попадают либо из других источников (и сразу синхронизируются в Яндекс.Диск) либо синхронизируются из ЯД.
3) Про синхронизацию из ЯД на NAS
3.1. Два NAS в разных домохозяйствах — каждое дважды в неделю синхронизирует файло из ЯД (односторонняя синхронизация ЯД -> NAS; со сдвигом по дням, то есть всего получается четырежды в неделю — четыре состояния ЯД — если почему то это состояние менялось так часто — что вполне возможно в длинные праздники, отпуска и т.п.). Почему не постоянно — потому что все-таки не нужно, NASы стабильно засыпают днем, ночью (т.к. не нужны) — уходят в гибернацию с автоматическим включением по утрам. В целом сеансы синхронизации в NAS занимают 10-25 минут в день (интернет 100 Мбит, ЯД реально быстрый) — если конечно в ЯД не появились 3 ролика по 5 Гбайт.
4) Про NAS
4.1. Однодисковые Synology — относительно свежие, 115 и 116.
4.2. Почему однодисковые? Потому что дома RAID не нужен, потому что локальный RAID не защитит данные от пожара/залива, а от аппаратных проблем защищаемся N-кратным резервированием на множество других носителей.
4.3. Почему Synology? — потому что самые тихие, электро-экономные, с более чем достаточным функционалом. Например, DLNA поддерживается отлично и зачем более горячие, с почти не отключающимися вентиляторами, Vendor1 или Vendor2, снабженные более мощными процами для видео-задач. Выбирал крайне капризно долго — у ряда других производителей сталкивался с настолько пародоксально-неожиданными недостатками в функционале, что просто нет слов… И поэтому применительно к NAS не получилось выполнить требование использовать оборудование разных поставщиков — получилось бы дорого-избыточно-бестолково.
4.4. Харды в NAS — WD Red (не Pro). Почему они — потому что у Seagate по крайней мере несколько лет назад было как-то победнее с хардами, рассчитанными на высокую или среднюю интенсивность пуск-стоп, а у меня NAS предсказуемо работают далеко не постоянно (пусть отдыхают мои верные сайнолоджишки...).
4.5. Трудозатраты администрирования минимальны.
4.6. На всякий случай — нужно иметь в виду — если NAS — значит бесперебойник, если бесперебойник — значит бытовой, если бытовой — значит никель-кадмиевые аккумуляторы, значит замена батарей 1 раз в 2-4 года.
5) Про резервирование на NAS
5.1. Каждое NAS дважды в неделю (то есть всего четырежды) резервирует семейный архив на внешний подключенный неперемещаемый диск (один WD, другой Seagate)
5.2. Инструмент — штатный Synology-агент Hyperbackup, дедупликация поддерживается.
5.3. Настройка занимает минут 5.
5.4. NASы репортят мне по почте о выполнении задач резервирования
5.5. Целостность индексов в архивах проверяю 1 раз в квартал (через веб-интерфейс запускаю, а потом приходит репорт) — занимает несколько часов
5.6. Целостность всего архива проверяю 1 раз в год — может занять много времени, поэтому в день запуска на этом NAS отключаю ночной переход в гибернацию.
6) Про инструменты локального инкрементного бэкапа на внешние харды
Применяю их все, с примерно равной интенсивностью (1 раз в 1-2 месяца), потому что верить никому нельзя. Три из них отбирал очень долго, отсеял множество дорогих, тяжелых, с провалами в функционале, инструментов и множество студенческих недоделок. Писать буду только про локальные бэкапы — во всех инструментах есть облачные возможности, но это отдельная тема.
6.1. Acronis True Image — года с 2005-го лет 8 для инкрементных бэкапов пользовался только им — в сочетании с синхронизацией на ротируемые харды считал достаточным для маловероятных задач розыска-восстановления предыдущих версий файлов и т.п. Версии Acronis True Image я обновлял регулярно, использовал его и для резервирования системных разделов дисков. Так бы оно и продолжалось, однако в 2013-2015 годах Акронис пошел по пути стремительно-принудительного ухудшения функционала и множества ошибок (типа не может найти резервную копию для проверки хотя вот только что в эту копию добавил еще один инкремент, или может проверить, но не может продолжить цепочку, хотя в конфигурации вообще ничего не менялось, то при попытке (на всякий случай) начать восстановление пишет что копия повреждена, однако при повторной попытке через полгода оказывается все в порядке (те же файлы, на том же диске...). Тут же нужно сказать, что это ухудшение функционала все-таки было остановлено, и поэтому Акронис «остался в обойме», но напряг создал. Пришлось пометаться и поискать альтернативы. В целом можно сказать, что последние пару лет Acronis — один из лучших инструментов бытового бэкапа — по функциональности, однако все-таки не лучший по стабильности и предсказуемости.
6.2. Backup4All. Умеет архивировать только файлы — образы системных разделов не создает. Я пользуюсь режимом инкрементного резервирования в стандартный коммерческий zip. Соответственно, дедупликация не поддерживается — перемещенный файл в новом расположении считается новым и (повторно? очередной раз?) попадает в очередной zip-том. Однако т.к. это стандартный коммерческий zip, то это единственный инструмент где целостность архива (очередного тома) я могу проверить НЕ средствами этого инструмента — например, могу заглянуть в архив используя Total Commander — это очень круто, и можно смириться с отсутствием дедупликации. Есть много полезняков и удобств. Например, в отдельном окошке для каждого отдельного zip-тома можно увидеть, по сравнению с предыдущим zip-томом, — какие файлы добавились (напомню — или были перемещены, т.к. нет дедупликации, то одинаковые копии таких файлов могут оказаться в нескольких томах — по количеству перемещений в исходной папке); какие — удалены, какие изменились. Таковая информация накапливается в отдельном bkc-файле, который связывает zip-тома между собой, при этом сами zip-тома никак не зависят друг от друга. Больше такого функционала нет нигде.
6.3. EaseUs — в целом настроек значительно меньше чем в Акронисе, и в разы меньше чем в Backup4All. Но здесь простота = надежность/добротность. все необходимое есть. Предсказуемо делает то, что должен. Без капризов. Из нечастных полезняков — есть возможность объединить (merge) несколько инкрементных и/или дифференциальных архивов — в принципе на перспективе нескольких лет может оказаться полезным — для экономии места можно будет исключить старые (замененные) версии файлов (хотя для фото-видео, с учетом изначальной дедупликации, эффект может быть минимальным — не делаем мы много отредактированных версий роликов или фото). Как и Acronis, EaseUs умеет, кроме файлов, делать образы системных разделов (применимо только в платной версии, т.к. в бесплатной нельзя исключать из процесса папки, которые не нужны в образах, поэтому образ может оказать бессмысленно-большим). Еще полезняк — можно в очередном сеансе вручную указать — инкрементный или дифференциальный очередной том мне нужен. В отличие от Акрониса, где схема — либо цепочка, либо только инкрементная, либо смешанная — настраивается в параметрах задания изначально, и во многих случаях схема не может быть изменена.
6.4 Ashampoo Backup Pro. Пользуюсь режимом резервирования с поддержкой БЛОЧНОЙ дедупликации — соответственно, получаем множество (десятки и сотни тысяч) мелких и сверхмелких файлов. По ряду причин — долго писать — не пользуюсь резервированием в zip — кое-что там кривовато. Решил использовать этот инструмент именно потому что кроме различий в поставщиках и инструментах решил поискать различие и в технологиях резервирования. Все вышеперечисленные софты архивируют в инкрементные (или дифференциальные) тома (т.е. файлы больших размеров), а этот — в россыпь мелких файлов. Было еще несколько софтов, которые используют эту технологию как базовую, но там были косяки. Ashampoo имеет странноватый интерфейс настройки заданий — очень уж много next-next шагов, причем на каждом шаге мало настроек. Может делать и образы системных разделов, но не позволяет исключать не нужные папки — опять избыточный размер образа.
Итак какие мы получаем защиты и преимущества:
— большое количество распределенных синхронизированных копий «просто файлы» и вообще большое количество распределенных физических копий защищает меня от сбоев техники и катастроф на уровне домохозяйств (пожары и т.п.; оговорка — не очень надежно от падения самолета на близкостоящие дома);
— большое количество подконтрольных мне копий защищает от опасности «отключат интернет»;
— «просто файлы» — всегда есть полностью синхронизированная или чуть-чуть недосинхронизированная копия для миграции на новый ноутбук;
— облако — защита от локальных технических проблем и падения самолета;
— высокая частота инкрементных копий на NAS — уменьшает опасность «что-то ценное скопировали и тут же случайно удалили»;
— разноформатность локальных инкрементных копий — защита от скрытых и планируемых косяков разработчиков бэкап-софтов;
— долгосрочность циклов локальных инкрементных копий — поможет при необходимости найти забытое, давно случайно удаленное (причем не сразу спохватились).
Необходимо отметить, что ни один из этих методов-способов не защищает в одиночку более чем от половины опасностей, поэтому в той или иной мере применять их следует все.
Нельзя сказать, что все это напряжно и слишком дорого — все как-то помаленьку выстроилось само собой, примитивно регламентировано и достаточно автоматизировано, много времени не отнимает.
Ну вот как-то так.
Вопрос собственно только почему это бытовые ИБП только на никеле вдруг?
2) Про тип аккумуляторов — не точно выразился, извините. Собственно тип аккумуляторов не важен. Важно то, что в бесперебойниках, доступных по цене для бытового использования, используются аккумуляторы попроще, с ограниченным сроком службы (выдачи приемлемой мощности).
Смысл в том, что если идти по методологии резервирования, предусматривающей наличие одного или более NAS, нужно еще учитывать необходимость установки бесперебойников. Причем начальные затраты — это в целом одноразовая мелочь, а нужно еще и понимать что:
— нужно настроить NAS, чтобы оно видело бесперебойник по USB и могло выключиться — по таймауту работы от бесперебойника или при достижении порога оставшейся мощности (ну и с последующим включением при восстановлении электроснабжения); соответственно, нужно озаботиться подтверждением совместимости бесперебойника и NAS (и у меня есть субъективные подозрения, что у Synology в классе бытовых NAS с этим важным делом обстоит получше, чем у других вендоров);
— нужно быть готовым, что при плановой замене аккумуляторов придется разобраться с тем, какие батареи покупать — через 2-4 года после покупки у поставщиков и бесперебойников и батарей несколько раз сменятся таблицы совместимости, кодовые обозначения и т.п. Например, я глубоко вскопнул эту тему, готовясь к замене батарей в одном из БП. Из всех материалов следовало, что подходящая батарея (как вроде изначально установленная в бесперебойник) относительно невелика по емкости и выглядит почти как правильный кубик. Что-то тут не так — подумал я на основе опыта с другими аппаратами этого вендора и других — сходных по габаритам. Пришлось заранее лезть, все включать, извлекать исходную батарею… и… к счастью убедиться в том, что отсек для батареи позволяет установить другую штатную батарею емкостью в 3 раза больше — так я и сделал — что несколько отодвигает очередной цикл замены; причем когда на сайте производителя после этого я ввел сначала код подходящей батареи + код бесперебойника, то подтверждения соответствия таки нашлось, а вот по коду бесперебойника список совместимых батарей был гораздо меньше;
— несмотря на то, что веб-интерфейс правильного NAS в целом объективно показывает ориентировочное оставшееся время работы от бесперебойника — а через полгода-год это время уже будет немного меньше, чем у новой батареи, нужно быть готовым к тому, что изредка нужно будет иными средствами проверять батарею — ну например, у многих поставщиков бесперебойников есть windows-клиенты и подключив ПК по USB можно посмотреть параметры батареи и т.п. Это слегка напряжно и я это делаю не чаще 1 раза в год.
— при этом нужно быть готовым в необходимости определиться со своевременным сроком замены — например, за 2 года время работы для всех обслуживаемых потребителей (которые допустим, не менялись) снизилось с 30 минут до 15. Уже бежать менять? Или подождать еще год? Или задуматься о том что деградация батарей — не линейная зависимость и к концу срока темпы снижения емкости быстрее чем в начале — и все-таки бежать — чтобы не рисковать NAS-ом?
Нужно закругляться — в общем, при использовании NAS нужно понимать, что абсолютно необходимым является еще один блок (слой) инфраструктуры — бесперебойное электроснабжение. Этот слой нельзя сказать чтобы требовал много денег, но требует понимания, внимания, и 1-2 дня в 2-3 года — суеты и беготни.
Если кто-то задумывается об использовании NAS, то подумайте о том, что облачные ресурсы — этот тоже некоторый малофункциональный NAS, который от бытового пользователя не требует никакого технического обслуживания — все вышеперечисленные хлопоты (меня не напрягают) берут на себя специалисты поставщиков.
==============
Уточнения, связанные с тем, что очень часто при обсуждении очень разных тем на Хабре возникают экологические аспекты:
— проблемы утилизации аккумуляторов от бесперебойников не существует — везде где принимают автомобильные, приму и эти, еще и копеечку заплатят;
4 разных бэкап-инструмента я отобрал для себя в результате мучительного многолетнего отбора
А какие именно инструменты?
Мои инкрементные семейные бэкапы позволяют откатиться назад на 3-4 года с дискретностью примерно в 1 месяцсовременные тулзы делают дедуплицированные бекапы, можно всю жизнь бекапить раз в сутки, места займет только на сколько там разного есть, как гит
Самый оптимальный вариант bluray M-disk, $3 25Gbt, привод около $100. Данные прожигаются, размагничивагие, сбой контролера и т.п. не грозит.
Испытания М-Диска, проведённые Министерством обороны США, показали, что этот диск более стойкий, чем обычные DVD-диски. Испытания проводились в климатической камере с температурой 85 °C, относительной влажностью воздуха 85 % и при освещении светом полного спектра.
Тем не менее Национальная лаборатория метрологии и тестирования Франции показала, что при температуре 90 °C и влажности в 85 % диск DVD+R с неорганическим слоем записи, такой как M-DISC, показывает не большую стойкость, чем обычный DVD±R.
1000 лет, конечно круто, но тут фишка-то даже не в этом: уже через 20 лет может стать проблемой найти устройства воспроизведения. Для LTO вообще может получиться, что то, что записано на одном стримере, при его поломке, на другом может не прочитаться. Люди начинают пробовать на разных и маяться с вытаскиванием инфы. Поэтому кроме бэкапов надо следить за актуальностью их носителей и своевременно обновлять аппаратную часть.
Вероятность выхода из строя или утери носителя далеко не нулевая, особенно на протяжении большого срока.
![320GB Brick Storage 320GB Brick Storage](https://habrastorage.org/webt/43/ri/rn/43rirnpaswh38geqfemo9xvl04m.png)
P.S. Обещали, точнее. Компания обанкротилась всего через шесть лет. Правда сайт ещё работает, но вот на их онлайн магазин мне зайти не удалось.
Где угодно, при условии, что это минимум 2 разных места.
Лента не конкурент этим высококачественным дискам из японии у которых сроки службы не менее 50 лет, с лентой и сравнивать нужно куда попроще диски, к примеру CMC 25Gb которые стоят 35рублей в среднем, то есть около 2100р за 1.5тб. Мне архивы стирать не нужно, то что нужно стирать это не архив и хранится у меня на HDD, а записывать дописывать новые можно и на блюрей.
И тем более лента не конкурент еще более дорогим MDISC которые могут сохранить информацию фактически навечно, и передавать семейный архив как реликвию из поколения в поколение, тогда как ленту и обычные недорогие блюрей диски уже желательно переписать лет через 20.
без внешнего сервера с sas контроллером для первыхЕсть еще на FC. Карту в PCI слот ПК и вперед. Если нет компьютера, то да, проблемы наверное.
Выбор в РФ приводов и дисков никакущий, только оттуда тащить, а если нужно ещё и пересечение…Как и с LTO в общем-то. Хотя у нас на барахолках достаточно много старых лент продают.
любым другим коммерческим сервисом
Здесь слово «коммерческим» явно лишнее. Единственный надежный способ хранения — у себя дома на HDD с периодической проверкой носителя и переносом, хотя и тут могут возникнуть проблемы. Однако такие данные все равно рано или поздно потеряются (например, после смерти владельца).
Насколько я понимаю на данный момент нет действительно надежного способа хранения данных. Единственное, что приходит на ум: высекать их в камне, но это подходит только для небольших текстовых данных. Однако у такого способа хранения хотя бы есть шанс пережить пару веков, а то и тысячелетий.
Хранить инфу вместе с инструкцией по изготовлению читающего устройства или описанием формата данных на человеческом языке
PaperBack is a free application that allows you to back up your precious files on the ordinary paper in the form of the oversized bitmaps. If you have a good laser printer with the 600 dpi resolution, you can save up to 500,000 bytes of uncompressed data on the single A4/Letter sheet. Integrated packer allows for much better data density — up to 3,000,000+ (three megabytes) of C code per page.
Грубо говоря дискетта.
Увеличим до 1200 DPI и красота 13,120,179 байт
Если считать по формуле ((623.7(лист в см2) / 0.00000448027919(пиксель в см2 при размере DPI 1200)) / 31329(qr код 177х177 пикселей)) * 2953
Это если кто-то не придумает трех-мерную кодировку используя цвета. Хотя черно-белый не выцветет.
Если 9600 DPI было бы реально купить то добро пожаловать в 839,785,952 байт.
Только думаю при таких размерах потери будут гарантированы.
Ещё со времён негипертекстового фидонета
UUEncode
Только многократная георепликация, плюс периодический бэкап на внешний винт доставаемый из тумбочки. Уже лет 20, полёт нормальный.
-те, которые делают бекапы
-те, которые будут делать бекапы.
— те, которые делают бэкапы;
— те, которые теперь точно делают бэкапы;
— те, которые проверяют восстановление из сделанных бэкапов.
Скорей всего они тупо переехали на новые серваки, а старая инфа осталась на старых. Потом старые сервера тупо выключили, разобрали и продали — а то, что на них крутилась боевая инфа, знало 1.5 админа, которые… уволились )))))
да конечно это касается старых фото
www.archiveteam.org/index.php?title=Wget#Mirroring_a_website
А вы зря смеетесьМне смешны сроки, а не сами потенциальные возможности.
сейчас в ней 300 миллионов пользователей
Китайцы теперь рынком ролят, и я не удивлюсь если какая то китайская соц сеть после падения зановести просто накроет всю планету за щитаные недели.
Соц сеть Like за месяц набрала аудиторию 5 мил. пользователей, это тоже смешно?
сейчас в ней 300 миллионов пользователей
5 миллионов за месяц != 7 миллиардов за 2 недели.
щитаные недели?
Щитаные недели — это временной интервал говорящий о скорости, а точнее о высокой скорости распространения
Китайцы теперь рынком ролят, и я не удивлюсь если какая то китайская соц сеть после падения зановести просто накроет всю планету за щитаные недели.— это просто вода, и не более? Если да, то ниже мне было смешно с таких данных. Вы же в ответ что написали? То есть, в начале вы Ванга, а уже потом не Ванга?
Вы не в курсе, так откройте папку Windows у себя и поищите файлы и директории i386
Уважаемый мы ушли от темы, мысли в другую сторону пошла, я не об этом пишу вообще и свою мысль высказываю. Тут статья о соц сети и цель моего поста СОЦ сеть. А что не так с Windows можете такой запрос написать в Yandex и получите 20 000 ответов, я тут не это обсудить хотела.
После нескольких случаев потери дорогих мне данных из за багов флеш памяти, напротив, стал относиться к вопросу более "философски". Можно сделать сколько угодно бэкапов всего, кроме себя...
Почему-то вспомнился фильм Blade Runner 2049 — там упоминается какое-то «отключение», после чего мама одного героя (лысого администратора) очень горевала из-за его детских фоточек. :)
Ну а по самой статье: ломается всё и вся. Даже Амазоновские облака теряют данные , причём постепенно и незаметно для потребителя
Но лично я резервные копии я всё равно дублирую в облако, лишним оно в наших условиях
точно не будет.
1. Долгое время для дискретной синхронизации «просто файлы» на внешние ротируемые харды я пользовался бесплатным Personal Backup (PB) — все хорошо, задание на синхронизацию одно, потому что N хардов по одному подключаются под одной и той же логической буквой, структура целевой папки на всех одна и та же; преимуществом Personal Backup перед многими другими инструментами является опция «проверять сразу после копирования», что в рамках одного сеанса позволяет сразу же проверить копии новых (добавленных в исходную папку, в т.ч. и со старыми датами) и измененных файлов. Т.к. в целевой и исходной папке никаких файлов индексов и конфигурации задания синхронизации не лежит, то в этот процесс можно при желании безболезненно вклиниться синхронизацией Total Commander (TC), а потом следующий сеанс опять сделать средствами Personal Backup.
Красота! Но…
2) Проблемой подобных дискретных синхронизаций (средствами PB, TC или подобных) является проблема перемещения файлов в исходной папке — при наведении, например, порядка, в фото-архиве (перемещение в другие папки, переименование папок...). То есть эти файлы уже есть в целевых папках на ротируемых дисках, с ними ничего делать не нужно — их нужно синхронно переместить в новые местоположения внутри структуры каталогов целевой папки. Если наведение порядка приводит к необходимости перекопирования и проверки таких файлов на несколько гигабайт, то это не особо напрягает (особенно если в эти же сеансы требуется еще синхронизировать столько же или больше добавленных и новых файлов). А вот если наведение порядка привело к перемещению десятков гигабайт, то это уже печалька — десятки минут (неважно — с проверкой или без) на каждый ротируемый диск, бессмысленная нагрузка на диски и т.п.)
3) Решение нашлось в лице FreeFileSync — в настройках заданий синхронизации есть опция «Обнаруживать перемещенные файлы» (скриншот например здесь ironfriends.ru/rezervnoe-kopirovanie-i-sinhronizatsiya-fajlov-v-programme-freefilesync — под строкой «Выберите режим резервного копирования «Зеркало» и нажмите «ОК».»).
В разных версиях (локализации?) эта опция может называться типа «Контроль перемещения файлов» — не суть.
Суть в том, что в исходной и целевых папках FFS создает индексные файлы sync.ffs_db в которых и хранится информация о предыдущих (по состоянию на конец предыдущего сеанса синхронизации) расположениях файлов в исходной и целевых папках.
Соответственно, теперь затраты времени на разборки с перемещениями сократились почти до нуля — независимо от количества перемещенных файлов и их суммарного объема. Обратная сторона — теперь синхронизацию можно выполнять только средствами FFS — чтобы изменения прописались в индексных файлах; теперь вклиниваться с помощью PB или TC или чем-то подобным — нельзя. Так же FFS не поддерживает проверку копий — но это не очень существенно — можно сразу после синхронизации побайтно выборочно сравнить файлы в исходной и целевой папке средствами TC.
Вопрос — подскажите, какие еще есть программы для синхронизации, которые поддерживают такой функционал — отслеживание перемещения файлов; отслеживание производится во время очередного сеанса дискретной синхронизации, результаты отслеживания сохраняются в специальных файлах?
Речь идет только о «зеркальной односторонней дискретной синхронизации». Он-лайновые (непрерывные) синхронизации (в т.ч. на локальные NAS), инкрементные бэкапы с дедупликацией (что предусматривает исключение перемещенных файлов из обработки) — это все другие методы для других ситуаций/задач.
Я отсмотрел кучу разных… Sync'ов… — нигде ничего подобного не нашел. Может пропустил? Неужели FFS только один такой?
=============
Примечание для заинтересовавшихся — я задал вопрос для упрощенной ситуации, когда FFS синхронизирует файлы из исходной папки только в одну (физическую, на одном физическом харде) целевую папку. На самом деле, FFS разбирается и с ситуацией когда синхронизация производится в несколько разных (на разных хардах) целевых папок, причем между сеансами синхронизации в исходной папке могут произойти перемещения файлов, — которые, само собой, отслеживаются в индексе в исходной папке, но не обязательно нужно тут же отследить в каждой целевой папке. То есть не нужно синхронизироваться абсолютно одинаково последовательно (при одном и том же состоянии исходной папки) сразу на несколько целевых хардов. Тут есть пара нюансов — если интересно — напишу.
Разработчикам FFS — респект!
В настройках задания есть галочка: «определять перемещения и переименования файлов». Не знаю как качественно это работает, но галочка есть.
При этом прога хранить свои файлы в синхронизируемых папках. В настройках можно отказаться, и хранить файлы в папке программы, но, наверное, суть от этого не изменится.
В настройках есть еще один, по-умолчанию отключенный пункт: «не смотреть в папки, верить файлу состояний». У него вот такое описание: «При включенной опции перед полным Анализом проверяется наличие изменений файла временных меток на медленной серверной стороне, созданного при синхронизации. Если этот файл не изменился, то полный Анализ не производится. Если опция отключена, то всегда производится полный Анализ.»
В общем, мне показалось, что это то, что вам нужно. И вообще, вся прога достойна внимания.
1) Опция "определять перемещения" — точно работает — срочно проверил в пробной версии;
2) Опцию "и переименования файлов" — пока массово проверить не удалось, разберусь по ходу;
3) В левой и правой папках создаются скрытые папки _gsdata_ — внутри них какие-то индексные файлы — по аналогии с индексным файлом, который делает FFS.
4) Насчет «не делать Анализ на медленной стороне» — пока не проверил, но если это работает — то это супер-прорыв для синхронизации большого кол-ва файлов в серверные и особенно облачные ресурсы — буду разбираться; если синхронизировать аккуратно (и особенно — если односторонне и только из одной левой папки) — то это будет сильно экономить время
5) Goodsync я подробно анализировал года 2 назад, тогда таких опций не было (ну или были спрятаны где-то глубже)
6) В Goodsync в настройках, рядом с подсказанной Вами опцией, есть еще и опция «Сравнить контрольные суммы MD5» — этого нет (пока) в FFS и это реально полезно — не нужно отдельно (выборочно) проверять копии файлов, созданные в целевой папке; все сразу можно сделать в одном процессе.
7) Для меня критична именно опция «определять перемещения» — еще в одном каком-нибудь инструменте — не только в FFS, потому что в ситуации с использованием N ротируемых дисков есть некоторая проблема — нельзя перепутать физические целевые папки (на разных ротируемых дисках), т.к. при таком ошибочном сеансе синхронизации сама синхронизация-то состоится все-таки беспроблемно, но займет (иногда — гораздо) больше времени — потому что версия индексного файла в целевой папке перед синхронизацией не будет соответствовать индексу в исходной папке (… и, соответственно, FFS не отловит перемещения файлов, и будет копировать а потом удалять в изначальных расположениях в целевой папке). Соответственно, нужно смотреть на логическую букву, под которой подключается очередной ротируемый диск — как-то это контролировать, бдеть… Поэтому я и подыскивал еще какой-то инструмент с такой же функциональностью — индексы FFS и GoodSync само собой никак не будут пересекаться, а в конфигурациях заданий синхронизации я укажу исключения для индекса «параллельного» инструмента — чтобы не затирать в целевых папках. Ну или вообще изменю регламент — часть ротируемых дисков синхронизировать только FFS, часть — только GoodSync.
Проверю все в триале, запущу в регламент.
СПАСИБО!
… жизнь-то налаживается…
И это тот самый случай, когда господь услышал.
К примеру, у меня стоит автоматическая выгрузка фото в облачные хранилища. Их парочка. Если удалить файл с телефона, то в хранилище фото остаётся.
Спустя продолжительное время зашёл посмотреть что там в хранилище. А там оказывается сохранено много такого, чего не жалко удалить вовсе. Чтобы вычистить это все — нужно себя сильно заставить, а то места же ещё дофига! Данные прибавляются — сервера пыхтят и увеличиваются.
Смею предположить, что у большинства обычных пользователей в этих «бесплатных» тарифах облаков лежит куча ненужной им чухни. На содержание всего этого нужны средства, которые покрываются платежами других пользователей. И так как наверняка у многих стоит автовыгрузка как у меня, то дело лучше не станет.
Вот дропбокс уже ввёл ограничение на бесплатную синхронизацию только трёх устройств на бесплатном тарифе. Дальше больше.
Кинопленка по-прежнему цела, не рассыпалась.
Фотопленки целы.
Единственное — бумажные фотографии со временем блекнут.
Я ни к чему не призываю, просто плата за плотность информации и удобность манипуляций — долговременность хранения, и ничего с этим не поделать.
не осилил все комментарии. там выше кто-нибудь писал, что нужно было смотреть на users agreement с mySpace и если очень уж были нужны гарантии сохранности, то искать облако за деньги с подходящим SLA?
перечислите хотя бы тысячу
Как минимум, их можно записать на ленточный накопитель и перенести в дешёвое долговременное хранилище.
Цифровой бутерброд.
Все остальное само собой бэкапится в самые разные места и в облако. По факту смотрим в основном эти альбомы. Редко кто копается в электронных версиях. Фотографий очень много, пересматривать их редко кому приходит в голову. Печатную подборку смотреть интереснее и проще.
Так что не страшно, если в результате какого-нибудь катаклизма или аварии помрет вся техника или магнитные носители информации. Бумага должна выжить, если, конечно, ее качество не окажется хреновым. Пока нет оснований так думать. Альбомы вроде неплохо сохраняются.
Ждём такую же статью про потерю всех видео с Youtube.
Втрое меньше книжного шкафа…
Кто то пробовал пользовать Siacoin для хранения. Как с надежностью и стабильностью?
bitside.org/siacoin-kriptovalyuta
На данный момент предложение превышает спрос, цены для рентеров ниже рынка облачных хранилищ, для хостера они делятся на коэффициент избыточности ~6. Так что есть смысл вкатываться только если есть включенная машина с простаивающим диском. Ну и время, чтобы со всем этим хорошо разобраться, выставить цены по уму. Ещё потребуется внести небольшую сумму collateal — по сути залог за провал контракта. Она потом при аптайме >~95% по факту не тратится.
MySpace потерял музыку, фото и видео, которые пользователи загружали с 2003 по 2015 годы