Несколько соображений:
1) Меня вот что беспокоит — независимо от платности доп. опций и прочих факторов — если это все-таки софтовая ошибка (или ошибка на грани между достоверностью показаний датчиков и корректностью интерпретации этих показаний софтом) — то обновления софта могут содержать как улучшайзеры, так и новые ошибки…
2) Если рассматривать современные авиалайнеры как летающие (супер)компьютеры, то постепенное (понятно, что растянутое на десятилетия) внесение неочевидных погрешностей и недоработок в обновляемый софт — это прекрасный способ планового устаревания проданного товара — как уже происходит с компами и смартфонами и т.п.
3) Наверняка на конфиденциальных совещания топ-менеджмента сейчас рассматриваются два вопроса: а) как отмазаться с минимальными репутационными и финансовыми потерями; б) как извлечь дополнительную среднесрочную прибыль из ситуации (новые лозунги про примат безопасности, непубличный маркетинг в междусобойчике авиа-перевозчиков, ускорить выпуск новых модификаций...)
Вопрос. Нет ли фразеологической неточности вот в этом предложении:
Фатальная проблема этого подхода в том, что декогеренция слабее, чем коллапс – она объясняет, почему мы не видим туманную смесь разных состояний котов, но не говорит, что остается только один кот!
?
не должна ли концовка быть такой:
… но не говорит, что остается кот только в одном состоянии!
или такой:
… но не говорит, что остается только одно состояние кота!
Ведь прямо перед этим говорится о смеси состояний котов, а не о наличии нескольких (физически? квантово? разных?) котов.
Да, именно поэтому нужно сочетать процессы синхронизации (получение резервной копии актуального состояния) — в том числе и на дискретные (временно подключаемые) диски, и процессы инкрементного/дифференциального резервирования.
В части синхронизации есть 2 опасности: 1) Если бекапные ресурсы (например, предоставляемые NAS'ом) прописаны на компе как логические диски, то шифровальщик спокойно доберется до синхронизированной копии — ведь шифровальщик будет прозрачно работать как с обычным виндовым диском. В том числе и поэтому я последние несколько лет никому не советую подключать сетевые ресурсы в качестве логических дисков — безопаснее использовать подключенные сетевые расположения — все равно они так же открываются в проводнике как папка, в Total Commander для ручной синхронизации сетевое расположение так же доступно в панели TC. 2) При полностью автоматизированной синхронизации на сетевой ресурс (в т.ч. облачный; локальный — неважно как подключенный) тоже велик риск затереть копии файлов зашифрованными — хотя, насколько я понимаю, тут есть множество вопросов — будет ли клиент синхро-софта отлавливать изменения содержимого файлов, если их размер и дата-время не менялись и т.п. — хотя для синхронизаторов, которые заявляют о способности синхронизировать только измененные части файлов, — очевидно что будет синхронизировать.
Если же использовать полуавтоматизированную (с ручным запуском, контролем глазами) синхронизацию на дискретные (ротируемые, временно подключаемые) диски (ну или опять же на сетевые ресурсы, повторюсь, НЕ подключенные как логические диски) — например, средствами Total Commander, или FreeFileSync, или GoodSync (который мне любезно подсказали в этой дискуссии) и т.п., то после анализа изменений, до щелчка кнопки «синхронизировать», вы увидите, что список файлов, предлагаемых к синхронизации, неожиданно длинный и нужно насторожиться, выборочно перепроверить и т.п.,… а в первую очередь — срочно отключить внешний диск! Ну а если синхронизировать на сетевое расположение — то срочно метаться не нужно — шифровальщик не прорвется в облако или на NAS… про NAS — под вопросом — есть же модели NAS под управлением Windows (в каких-то редакциях) и если шифровальщики способны перебираться между незащищенными компами в локальных сетях, то почему не прорваться и на такой NAS. Поэтому лучше наверное использовать обычные NAS с операционками в виде кастомизированно-урезанных линуксов.
Инкрементное или дифференциальное резервирование, в том числе и полностью автоматизированное, защищает нас от затирания резервных копий шифрованными оригиналами — ведь шифрованные оригиналы, являясь обновленными файлами (новыми версиями), будут зарезервированы в новые (последние в цепочке) инкрементные или дифференциальные тома в резервной копии — предыдущие тома затронуты никак не будут.
Про пятницу правильно — «все, что сделано в пятницу после 12:00 придется переделывать в понедельник — это в лучшем случае; а в худшем — придется устранять последствия с гораздо большими трудозатратами.»
Уважаемый trimtomato! Спасибо огромное! Плюсую много раз — мысленно, т.к. не хватает кармы для плюсования по факту…
1) Опция "определять перемещения" — точно работает — срочно проверил в пробной версии;
2) Опцию "и переименования файлов" — пока массово проверить не удалось, разберусь по ходу;
3) В левой и правой папках создаются скрытые папки _gsdata_ — внутри них какие-то индексные файлы — по аналогии с индексным файлом, который делает FFS.
4) Насчет «не делать Анализ на медленной стороне» — пока не проверил, но если это работает — то это супер-прорыв для синхронизации большого кол-ва файлов в серверные и особенно облачные ресурсы — буду разбираться; если синхронизировать аккуратно (и особенно — если односторонне и только из одной левой папки) — то это будет сильно экономить время
5) Goodsync я подробно анализировал года 2 назад, тогда таких опций не было (ну или были спрятаны где-то глубже)
6) В Goodsync в настройках, рядом с подсказанной Вами опцией, есть еще и опция «Сравнить контрольные суммы MD5» — этого нет (пока) в FFS и это реально полезно — не нужно отдельно (выборочно) проверять копии файлов, созданные в целевой папке; все сразу можно сделать в одном процессе.
7) Для меня критична именно опция «определять перемещения» — еще в одном каком-нибудь инструменте — не только в FFS, потому что в ситуации с использованием N ротируемых дисков есть некоторая проблема — нельзя перепутать физические целевые папки (на разных ротируемых дисках), т.к. при таком ошибочном сеансе синхронизации сама синхронизация-то состоится все-таки беспроблемно, но займет (иногда — гораздо) больше времени — потому что версия индексного файла в целевой папке перед синхронизацией не будет соответствовать индексу в исходной папке (… и, соответственно, FFS не отловит перемещения файлов, и будет копировать а потом удалять в изначальных расположениях в целевой папке). Соответственно, нужно смотреть на логическую букву, под которой подключается очередной ротируемый диск — как-то это контролировать, бдеть… Поэтому я и подыскивал еще какой-то инструмент с такой же функциональностью — индексы FFS и GoodSync само собой никак не будут пересекаться, а в конфигурациях заданий синхронизации я укажу исключения для индекса «параллельного» инструмента — чтобы не затирать в целевых папках. Ну или вообще изменю регламент — часть ротируемых дисков синхронизировать только FFS, часть — только GoodSync.
Проверю все в триале, запущу в регламент.
СПАСИБО!
… жизнь-то налаживается…
1) Про почту и статью не понял, извините;
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, который от бытового пользователя не требует никакого технического обслуживания — все вышеперечисленные хлопоты (меня не напрягают) берут на себя специалисты поставщиков.
==============
Уточнения, связанные с тем, что очень часто при обсуждении очень разных тем на Хабре возникают экологические аспекты:
— проблемы утилизации аккумуляторов от бесперебойников не существует — везде где принимают автомобильные, приму и эти, еще и копеечку заплатят;
1) Про синхронизацию на внешние харды
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 — уменьшает опасность «что-то ценное скопировали и тут же случайно удалили»;
— разноформатность локальных инкрементных копий — защита от скрытых и планируемых косяков разработчиков бэкап-софтов;
— долгосрочность циклов локальных инкрементных копий — поможет при необходимости найти забытое, давно случайно удаленное (причем не сразу спохватились).
Необходимо отметить, что ни один из этих методов-способов не защищает в одиночку более чем от половины опасностей, поэтому в той или иной мере применять их следует все.
Нельзя сказать, что все это напряжно и слишком дорого — все как-то помаленьку выстроилось само собой, примитивно регламентировано и достаточно автоматизировано, много времени не отнимает.
Коллеги, а вот еще такой аспект — сначала напишу о последнем достижении-облегчении при зеркальной односторонней дискретной синхронизации «просто файлы» на внешние харды, а потом задам вопрос.
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 разбирается и с ситуацией когда синхронизация производится в несколько разных (на разных хардах) целевых папок, причем между сеансами синхронизации в исходной папке могут произойти перемещения файлов, — которые, само собой, отслеживаются в индексе в исходной папке, но не обязательно нужно тут же отследить в каждой целевой папке. То есть не нужно синхронизироваться абсолютно одинаково последовательно (при одном и том же состоянии исходной папки) сразу на несколько целевых хардов. Тут есть пара нюансов — если интересно — напишу.
Все правильно, никакой паранойи. Я с 1989 года не потерял ни одного нужного файла — тогда появилась возможность использовать IBM-совместимый комп. До сих пор где-то (найду быстро) лежат уже непонятно зачем нужные файлы в форматах Лексикон, ChiWriter, Word&Deed и так далее. А в нынешнее время семейный фото-видео-архив хранится в 15 физических экземплярах (ротация внешних синхронизируемых хардов между несколькими разнесенными точками хранения + 2 синхронизируемые NAS в двух домохозяйствах, + собственно бэкап-харды. Количество логических форматов — 6 — просто синхронизированные файлы + бэкап в формате NAS + 4 формата очень-долго-играющих инкрементных бекапов, сделанных разными бекап-программами + облако + ну и сам первичный ноутбук. Харды подбираю одинаковых емкостей, но от разных производителей (которых, к сожалению, становится все меньше и меньше).
Почему так? Верить никому нельзя:
— можно ли верить производителю харда? нет — вполне можно напороться на серию с большим количеством брака (хорошо если посыпется сразу по всему миром хором и вы заранее об этом узнаете и можно метнуться-подстраховаться, а если брак отложенный?);
— можно ли верить производителю NAS? — тоже вряд ли.
— можно ли верить разработчику бэкап-софта? — нет — форумы переполнены плачем об отказе софта восстановить из бэкапа или просмотреть его содержимое, или продолжить бекап в инкрементную/дифференциальную цепочку (4 разных бэкап-инструмента я отобрал для себя в результате мучительного многолетнего отбора)
— можно ли верить облачному провайдеру? — нет, в любой момент может все потерять, а с его отказом об ответственности нам уже была предоставлена возможность согласиться, когда регистрировали учетную запись.
Мои инкрементные семейные бэкапы позволяют откатиться назад на 3-4 года с дискретностью примерно в 1 месяц — это на тот случай, если дражайшая супруга (она является «логическим» администратором массива) не найдет что и куда разложила и озадачит меня вопросом — а вот где папка «Бухаем на даче 2015 (2)»? И эти инкрементные бэкапы я уж постараюсь сохранить ближайшие лет 20.
Пословица: «пользователи делятся на тех, кто не делал бэкап и на тех, кто начал его делать» уже сильно устарела — в нынешнее время вынужденно-огромных объемов данных (причем очевидна долговременная ценность только некоторой части данных), тотального снижения качества (и предсказуемости — добротности) и железа и софта, невозможности быть уверенными в целостности инфы, пословица выглядит так:
пользователи делятся на 5 категорий:
1) те, кто никогда не делал бэкап;
2) те, кто начал делать (хоть какой-то) бэкап;
3) те, кто начал делать бэкапы разными средствами, на распределенную систему разнородных машинных носителей
4) те, кто начал проверять целостность бэкапов;
5) те кто начал проверять реальную возможность восстановления из бэкапов
(по категориям 2-5 есть еще подкатегории с уточнением «регулярно»).
Я нахожусь в категории 4 — нерегулярно устраиваю проверки целостности родными инструментами — следовательно, (легкомысленно?) доверяю разработчикам бэкап-софтов, в надежде, что хотя бы один из четырех не уйдет с рынка, не перестанет поддерживать предыдущие форматы и т.п. — в общем актуальность сохранится на 10-15 лет.
Формат «Просто файлы» на синхронизированных хардах — периодически, выборочно (по папкам верхнего уровня) провожу побайтовую сверку средствами Total Commander — тут более-менее можно быть уверенным в целостности файлов и что хард пока не битый.
И, для дополнительного спокойствия, старые харды, после копирования с них ценной инфы, никуда не девать — а как раз хранить их в дальней кладовке, лучше в другом населенном пункте — на случай падения самолета на основную точку хранения.
Я вот как-то раньше не подумал насчет использования старых хардов в этой роли — а теперь жалею, что лет 6 назад пристроил знакомым и даже продал дешево старых внешних хардов с USB 2.0 терабайтов на 6. Резона в пристраивании и продаже не было никакого — а так бы они у меня лежали тихонько в двойных плотных полиэтиленовых пакетах, в металлических коробах — в дальнем подвале.
Это точно — именно поэтому появились сервисы для «пожизненного» локального бэкапа из Office 365 (пожизненного — на сколько хватит денег и терпения добавлять жесткие диски в локальный storage) и сервисы для бэкапа Cloud-to-Cloud — но тут уже нужно смотреть на стоимость, возможности дедупликации и прочее.
1) Да, судя по всему, применение NAS для получения «вечных» локальных бэкапов для облачных ресурсов — основной способ обретения душевного спокойствия от возможных глюков ресурса и ошибок сотрудников; основной, но не единственный — в принципе можно бэкапить локальную копию, синхронизированную из облачного ресурса на локальный комп — но с NAS это проще автоматизировать, удобнее контролировать. Душевное спокойствие относится только к аспекту «в случае чего — сможем восстановить» — локальная копия всегда рядом (доступность не зависит от интернета); а вот собственно удобство и трудозатратность восстановления — это уже другая тема, зависит от инструмента;
Параноики (и я такой) средствами NAS бекапят еще и в другой облачный ресурс. Хотя по мере развития сервисов и возможного снижения цен постепенно станут популярными бэкапы Cloud-to-Cloud (без задействования локальных мощностей, но тут вопрос со спокойствием — доступность резервной копии зависит от доступности и скорости интернета).
2) Полезное уточнение — здесь в комментариях много пишут про проблемы (ресурса или клиента), связанные с «размножением» файлов с похожими (рассинхронизированными) именами (или именами, дополненными разными date-time), с «отставанием» синхронизации переименований папок и т.п. Насчет Synology — штатный агент Hyperbackup (при резервировании на внешний диск, подключенный к NAS) обеспечивает блочную дедупликацию, поэтому появление нескольких/многих разноименных копий множества файлов или перемещение файлов (переименование папок) не приводит к резкому росту размера резервной копии. Более того, т.к. в «командных» ресурсах по объективным причинам хранится большое количество (очень) похожих файлов (например, варианты одной и той же презентации, адаптированные для разных мероприятий или разных групп слушателей), то размер дедуплицированной резервной копии некоторое время (пока не накопится большое количество инкрементных изменений) может быть и (существенно) меньше размера исходной копии, синхронизированной из облачного ресурса. Думаю, что штатные инструменты локального резервирования для NAS других производителей тоже обеспечивают блочную дедупликацию.
Гм, ну если завязалась дискуссия про негативный опыт… то думаю можно поделиться некоторыми результатами несколько-летнего тестирования ПЕРСОНАЛЬНЫХ (не командных) подписок OneDrive, Google Drive, Яндекс.Диск.
1) По скорости загрузки (с компа или СХД-агентом) OneDrive в 20-80 раз медленнее, чем Google Drive, Яндекс.Диск — проверял много раз, на одинаковых объемах, на одном и том же интернете.
2) В OneDrive очень плохо работает копирование приличных (десятки и сотни гигабайт) данных между учетками; эта операция необходима при переносе данных между учетками — когда учетка предоставила другой папку только на чтение, в целевой учетке можно запустить копирование из этой предоставленной папки в свою папку. Пытался-тужился много раз — ни разу не успешно — процессы просто прекращались с сообщением-издевкой «что-то пошло не так». Такие операции очень удобно делать чтобы не гонять трафик между компом и ресурсом (т.е. чтобы все происходило только на стороне ресурса) при перераспределении файлов между личными и семейными учетками и т.п. — этим часто приходилось заниматься когда по объемам и стоимости ресурсы стали интересны обычным пользователям. В Google Drive, Яндекс.Диск такие операции выполнялись стабильно, а в Яндекс.Диск — как-то удивительно быстро — полТЕРАБАЙТА за несколько часов. Повторюсь — здесь идет речь именно о получении КОПИЙ файлов в другой учетке.
3) Связано с предыдущим пунктом — нормальная выполняемость такого процесса в Google Drive, Яндекс.Диск дополняется (относительным) удобством интерфейса — знакомым неискушенным пользователям как-то легко получается растолковать, что нужно дать доступ просто на просмотр папки — тогда нормально получается сделать копию в свою учетку (чтобы уже потом файлы регламентно синхронизировались в комп или СХД). В OneDrive — как-то сложнее — все время расшаривают полный доступ, и операция копирования недоступна.
4) Нельзя и не похвалить OneDrive — во-первых стоимость — в рамках подписки Office 365 примерно за 3 тыс. руб. в год (общая стоимость «на семью») по 1 терабайту доступно каждому из 5 пользователей (а вот здесь написано про 6 пользователей products.office.com/ru-ru/compare-all-microsoft-office-products?tab=1&OCID=AID679471_OO_Hero_mscomrefreshhome ); во-вторых — OneDrive в веб-интерфейсе показывает размеры папок — причем в представлении списка. Это очень удобно чтобы быстро понимать, например, объемы, которые нужно скачать или синхронизировать. В яндексе и гугле такой возможности пока нет.
Спасибо за статью! Полезный обзор командных, а не личных облачных сервисов.
Дополнение про OneDrive — 15 ГБ ограничение на размер файла — это в командной подписке, в персональной — вообще 10 ГБ — просто смешно; насколько я знаю, в других сервисах по этому параметру персональные и командные подписки не различаются.
Вопросы к автору:
1) Насчет версионности — в каком ресурсе чем измеряется — кол-вом версий или длительностью хранения предыдущих версий?
У Dropbox — 120-дневный журнал www.dropbox.com/plans?trigger=nr.
А как у других? А сколько времени хранится файл в корзине (просто удаленный, а не замененный новой версией)? Это я к тому, что и 120 дней — это не очень много (в конце текущего квартала вполне может потребоваться предыдущая (не последняя) версия отчета за предыдущий квартал); и еще наверное неспроста появилось много софта (в т.ч. СХД-сервисов) для локальных вечно-инкрементных бэкапов из облачных хранилищ, почт и порталов.
2) Если не затруднит — просьба дополнить про анонимную загрузку "… и сервис создаст анонимную ссылку, по которой можно залить файлы через браузер..." — а таким способом какого размера файлы можно зааплоадить через браузер?
1) Вот так вот Марисса Мейер не отдыхала — не отдыхала, мозг не разгружала, ошибочные управленческие решения принимала — и… окончательно доразвалила Yahoo.
2) Насчет достаточности сна — неоднократно по утрам просыпался с обновленным решением на уровне блоков кода или даже архитектуры; во многих случаях такие решения существенно уменьшали объем работы. Точно знаю — попытки вымучить подобные решения увеличением продолжительности рабочего дня мозга моего + нескольких коллег однозначно занимали бы гораздо больше времени, а если решения и приходили бы — то во многих случаях слишком поздно, когда опасно и опять же трудоемко что-то менять (оговорка — согласен, что такие решения проше возникают и реализовываются в небольших командах, в проектах не очень длинных; в больших разработках сложно менять проектные решения, затрагивающие работу десятков-сотен специалистов).
Разве только у нас бывают ситуации, когда садимся реинжирить и удивляемся — откуда у нас здесь несколько сотен строк кода, которые без каких-либо потерь очевидно заменяются десятком вызовов давно отлаженных четко работающих библиотечных функций. Смотрим версии, видим время — 02 ч NN мин — … А!… Это вот тогда ночью кодячили, нужно было успеть…
Хорошо, что последние лет 5-7 таких ситуаций все меньше.
Думать нужно больше чем работать — к тому же думать можно на прогулке, при чтении худ. книги, на лыжах,… ну и во сне. А работать можно только на стуле, глазами в экран.
Очередной маленький, но яркий пример, подтверждающий мысль о том, что нормативные регламенты в области импортозамещения зачастую противоречат целям импортозамещения и регламентам, прописанным в предыдущих действующих нормативных актах.
Смотрим страницу 16 – последний абзац пункта 8 таблицы в приказе прописан так:
«для абонентских устройств радиоподвижной связи — под управлением операционных систем Android, iOS;»
Эта формулировка УСТАРЕЛА ДВАЖДЫ – в связи с выходом Постановления от 7 марта 2018 г. № 234 www.garant.ru/products/ipo/prime/doc/71795772
— по 31 декабря 2018г. включительно формулировка была такая:
«для абонентских устройств радиоподвижной связи — под управлением мобильной операционной системы, сведения о которой включены в единый реестр российского программного обеспечения, или операционных систем Android, iOS;
— с 1 января 2019 формулировка стала такая:
для абонентских устройств радиоподвижной связи — под управлением мобильной операционной системы, сведения о которой включены в единый реестр российского программного обеспечения и которая сертифицирована в соответствии с требованиями законодательства Российской Федерации о защите информации.».
(см. Постановление 325 в действующей редакции (с учетом внесенных изменений) base.garant.ru/71638522,
Удобно найти фразу «Абзац шестой (в редакции постановления Правительства РФ от 7 марта 2018 г. N 234) вступает в силу с 1 января 2019 г.»)
Тут возникает много вопросов:
1) Вступил ли в силу Приказ 722? – Ведь регламент Минюста запрещает регистрировать нормативные акты, противоречащие действующему законодательству – см.: www.consultant.ru/document/cons_doc_LAW_56352/e89fe13c12b4406b57dc23f3462a223cd7beb148
21. В регистрации нормативного правового акта может быть отказано, если при проведении юридической экспертизы будет установлено несоответствие этого акта законодательству Российской Федерации или (и) наличие в этом акте положений, способствующих созданию условий для проявления коррупции.
(абзац введен Приказом Минюста РФ от 26.05.2009 N 155)
Нормативное регулирование в области импортозамещения ПО иностранных правообладателей при закупках государственными организациями в соответствии с ФЗ-44, за последние 3-4 года привело к получению устойчивого обратного эффекта, выражающегося в существенном упрощении процессов приобретения ПО, происходящего из иностранных государств.
Есть еще один вопрос, который почему-то всегда остается в стороне при рассмотрении темы «радость дешОвой мобильной связи и интернета в России». Вопрос: сколько-симочные абоненты — российские и зарубежные сравниваются? Одно-симочные или дву/много-симочные? Ведь нужно же сравнивать не просто цены, заявленные в отдельных тарифах отдельных операторов, но и реальную возможность воспользоваться соответствующими (дешёвыми?) услугами во всех локациях, в которых часто бывает конкретный абонент (ну и соответственно — совокупность (множество) абонентов в «типовых» локациях (работа, проживание, торговые центры); воспользоваться без ущерба для психики (из-за медленного интернета, обрывов связи....)). Разве можно в России комфортно пользоваться мобильным интернетом, имея только одну симку? В том же центральном здании Минкомсвязи на Тверской, на стороне ближе к Тверской отлично работает Оператор 1, и практически не работает Оператор 2, а с противоположной стороны — строго наоборот. И так везде — надсадно проверяю этот момент в Москве и области, в командировках в крупные города. Соответственно, нужно «в принудительном порядке» оплачивать абонентскую плату по как минимум двум (пусть самым дешевым) тарифам двух разных операторов — а это уже явно не дешевле, чем в других странах. Ведь не важно, что в тарифе заявлена потенциальная возможность выкачать дешевый гигабайт — должна же быть и технологическая возможность в конкретных локациях!
И еще — Россия очень своеобразная страна, в которой технологическое развитие зачастую не предполагает повышение комфорта для потребителей технологических продуктов и услуг. Вот смотрите — до выхода 4-го оператора на общероссийский рынок мы имели трех-лоскутность покрытия. То есть при наличии дву-симочного аппарата вероятность остаться на связи составляла 2/3. Теперь во многих локациях появилась четырех-лоскутность — видимо операторы собрались, обсудили, перепилили зоны покрытия — и теперь вероятность стала 2/4 — меньше. Так что гипотетическое появление 5-го (реального, а не виртуального) оператора ничем хорошим нам не грозит — появится пяти-лоскутность.
Самое печальное, что эти лоскуты не фиксируются на длительное время — операторы проводят их ротацию. У меня есть вполне реальный пример — в месте, в котором я сейчас нахожусь (совсем ближнее замкадье) несколько лет назад один из операторов (федеральный, все серьезно) работал просто на урА-уРА-УРА. Радостные сотрудники и жители поблизости обзавелись номерами. И вот он пропал — от слова совсем, зато появился другой (на долго ли?). Причем на местности ничего не изменилось — холмов нет, за последние 40 лет зданий выше 2-ух этажей не строилось.
1) Меня вот что беспокоит — независимо от платности доп. опций и прочих факторов — если это все-таки софтовая ошибка (или ошибка на грани между достоверностью показаний датчиков и корректностью интерпретации этих показаний софтом) — то обновления софта могут содержать как улучшайзеры, так и новые ошибки…
2) Если рассматривать современные авиалайнеры как летающие (супер)компьютеры, то постепенное (понятно, что растянутое на десятилетия) внесение неочевидных погрешностей и недоработок в обновляемый софт — это прекрасный способ планового устаревания проданного товара — как уже происходит с компами и смартфонами и т.п.
3) Наверняка на конфиденциальных совещания топ-менеджмента сейчас рассматриваются два вопроса: а) как отмазаться с минимальными репутационными и финансовыми потерями; б) как извлечь дополнительную среднесрочную прибыль из ситуации (новые лозунги про примат безопасности, непубличный маркетинг в междусобойчике авиа-перевозчиков, ускорить выпуск новых модификаций...)
Вопрос. Нет ли фразеологической неточности вот в этом предложении:
?
не должна ли концовка быть такой:
… но не говорит, что остается кот только в одном состоянии!
или такой:
… но не говорит, что остается только одно состояние кота!
Ведь прямо перед этим говорится о смеси состояний котов, а не о наличии нескольких (физически? квантово? разных?) котов.
В части синхронизации есть 2 опасности: 1) Если бекапные ресурсы (например, предоставляемые NAS'ом) прописаны на компе как логические диски, то шифровальщик спокойно доберется до синхронизированной копии — ведь шифровальщик будет прозрачно работать как с обычным виндовым диском. В том числе и поэтому я последние несколько лет никому не советую подключать сетевые ресурсы в качестве логических дисков — безопаснее использовать подключенные сетевые расположения — все равно они так же открываются в проводнике как папка, в Total Commander для ручной синхронизации сетевое расположение так же доступно в панели TC. 2) При полностью автоматизированной синхронизации на сетевой ресурс (в т.ч. облачный; локальный — неважно как подключенный) тоже велик риск затереть копии файлов зашифрованными — хотя, насколько я понимаю, тут есть множество вопросов — будет ли клиент синхро-софта отлавливать изменения содержимого файлов, если их размер и дата-время не менялись и т.п. — хотя для синхронизаторов, которые заявляют о способности синхронизировать только измененные части файлов, — очевидно что будет синхронизировать.
Если же использовать полуавтоматизированную (с ручным запуском, контролем глазами) синхронизацию на дискретные (ротируемые, временно подключаемые) диски (ну или опять же на сетевые ресурсы, повторюсь, НЕ подключенные как логические диски) — например, средствами Total Commander, или FreeFileSync, или GoodSync (который мне любезно подсказали в этой дискуссии) и т.п., то после анализа изменений, до щелчка кнопки «синхронизировать», вы увидите, что список файлов, предлагаемых к синхронизации, неожиданно длинный и нужно насторожиться, выборочно перепроверить и т.п.,… а в первую очередь — срочно отключить внешний диск! Ну а если синхронизировать на сетевое расположение — то срочно метаться не нужно — шифровальщик не прорвется в облако или на NAS… про NAS — под вопросом — есть же модели NAS под управлением Windows (в каких-то редакциях) и если шифровальщики способны перебираться между незащищенными компами в локальных сетях, то почему не прорваться и на такой NAS. Поэтому лучше наверное использовать обычные NAS с операционками в виде кастомизированно-урезанных линуксов.
Инкрементное или дифференциальное резервирование, в том числе и полностью автоматизированное, защищает нас от затирания резервных копий шифрованными оригиналами — ведь шифрованные оригиналы, являясь обновленными файлами (новыми версиями), будут зарезервированы в новые (последние в цепочке) инкрементные или дифференциальные тома в резервной копии — предыдущие тома затронуты никак не будут.
1) Опция "определять перемещения" — точно работает — срочно проверил в пробной версии;
2) Опцию "и переименования файлов" — пока массово проверить не удалось, разберусь по ходу;
3) В левой и правой папках создаются скрытые папки _gsdata_ — внутри них какие-то индексные файлы — по аналогии с индексным файлом, который делает FFS.
4) Насчет «не делать Анализ на медленной стороне» — пока не проверил, но если это работает — то это супер-прорыв для синхронизации большого кол-ва файлов в серверные и особенно облачные ресурсы — буду разбираться; если синхронизировать аккуратно (и особенно — если односторонне и только из одной левой папки) — то это будет сильно экономить время
5) Goodsync я подробно анализировал года 2 назад, тогда таких опций не было (ну или были спрятаны где-то глубже)
6) В Goodsync в настройках, рядом с подсказанной Вами опцией, есть еще и опция «Сравнить контрольные суммы MD5» — этого нет (пока) в FFS и это реально полезно — не нужно отдельно (выборочно) проверять копии файлов, созданные в целевой папке; все сразу можно сделать в одном процессе.
7) Для меня критична именно опция «определять перемещения» — еще в одном каком-нибудь инструменте — не только в FFS, потому что в ситуации с использованием N ротируемых дисков есть некоторая проблема — нельзя перепутать физические целевые папки (на разных ротируемых дисках), т.к. при таком ошибочном сеансе синхронизации сама синхронизация-то состоится все-таки беспроблемно, но займет (иногда — гораздо) больше времени — потому что версия индексного файла в целевой папке перед синхронизацией не будет соответствовать индексу в исходной папке (… и, соответственно, FFS не отловит перемещения файлов, и будет копировать а потом удалять в изначальных расположениях в целевой папке). Соответственно, нужно смотреть на логическую букву, под которой подключается очередной ротируемый диск — как-то это контролировать, бдеть… Поэтому я и подыскивал еще какой-то инструмент с такой же функциональностью — индексы FFS и GoodSync само собой никак не будут пересекаться, а в конфигурациях заданий синхронизации я укажу исключения для индекса «параллельного» инструмента — чтобы не затирать в целевых папках. Ну или вообще изменю регламент — часть ротируемых дисков синхронизировать только FFS, часть — только GoodSync.
Проверю все в триале, запущу в регламент.
СПАСИБО!
… жизнь-то налаживается…
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, который от бытового пользователя не требует никакого технического обслуживания — все вышеперечисленные хлопоты (меня не напрягают) берут на себя специалисты поставщиков.
==============
Уточнения, связанные с тем, что очень часто при обсуждении очень разных тем на Хабре возникают экологические аспекты:
— проблемы утилизации аккумуляторов от бесперебойников не существует — везде где принимают автомобильные, приму и эти, еще и копеечку заплатят;
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 — уменьшает опасность «что-то ценное скопировали и тут же случайно удалили»;
— разноформатность локальных инкрементных копий — защита от скрытых и планируемых косяков разработчиков бэкап-софтов;
— долгосрочность циклов локальных инкрементных копий — поможет при необходимости найти забытое, давно случайно удаленное (причем не сразу спохватились).
Необходимо отметить, что ни один из этих методов-способов не защищает в одиночку более чем от половины опасностей, поэтому в той или иной мере применять их следует все.
Нельзя сказать, что все это напряжно и слишком дорого — все как-то помаленьку выстроилось само собой, примитивно регламентировано и достаточно автоматизировано, много времени не отнимает.
Ну вот как-то так.
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 — респект!
Почему так? Верить никому нельзя:
— можно ли верить производителю харда? нет — вполне можно напороться на серию с большим количеством брака (хорошо если посыпется сразу по всему миром хором и вы заранее об этом узнаете и можно метнуться-подстраховаться, а если брак отложенный?);
— можно ли верить производителю NAS? — тоже вряд ли.
— можно ли верить разработчику бэкап-софта? — нет — форумы переполнены плачем об отказе софта восстановить из бэкапа или просмотреть его содержимое, или продолжить бекап в инкрементную/дифференциальную цепочку (4 разных бэкап-инструмента я отобрал для себя в результате мучительного многолетнего отбора)
— можно ли верить облачному провайдеру? — нет, в любой момент может все потерять, а с его отказом об ответственности нам уже была предоставлена возможность согласиться, когда регистрировали учетную запись.
Мои инкрементные семейные бэкапы позволяют откатиться назад на 3-4 года с дискретностью примерно в 1 месяц — это на тот случай, если дражайшая супруга (она является «логическим» администратором массива) не найдет что и куда разложила и озадачит меня вопросом — а вот где папка «Бухаем на даче 2015 (2)»? И эти инкрементные бэкапы я уж постараюсь сохранить ближайшие лет 20.
Пословица: «пользователи делятся на тех, кто не делал бэкап и на тех, кто начал его делать» уже сильно устарела — в нынешнее время вынужденно-огромных объемов данных (причем очевидна долговременная ценность только некоторой части данных), тотального снижения качества (и предсказуемости — добротности) и железа и софта, невозможности быть уверенными в целостности инфы, пословица выглядит так:
пользователи делятся на 5 категорий:
1) те, кто никогда не делал бэкап;
2) те, кто начал делать (хоть какой-то) бэкап;
3) те, кто начал делать бэкапы разными средствами, на распределенную систему разнородных машинных носителей
4) те, кто начал проверять целостность бэкапов;
5) те кто начал проверять реальную возможность восстановления из бэкапов
(по категориям 2-5 есть еще подкатегории с уточнением «регулярно»).
Я нахожусь в категории 4 — нерегулярно устраиваю проверки целостности родными инструментами — следовательно, (легкомысленно?) доверяю разработчикам бэкап-софтов, в надежде, что хотя бы один из четырех не уйдет с рынка, не перестанет поддерживать предыдущие форматы и т.п. — в общем актуальность сохранится на 10-15 лет.
Формат «Просто файлы» на синхронизированных хардах — периодически, выборочно (по папкам верхнего уровня) провожу побайтовую сверку средствами Total Commander — тут более-менее можно быть уверенным в целостности файлов и что хард пока не битый.
Я вот как-то раньше не подумал насчет использования старых хардов в этой роли — а теперь жалею, что лет 6 назад пристроил знакомым и даже продал дешево старых внешних хардов с USB 2.0 терабайтов на 6. Резона в пристраивании и продаже не было никакого — а так бы они у меня лежали тихонько в двойных плотных полиэтиленовых пакетах, в металлических коробах — в дальнем подвале.
Параноики (и я такой) средствами NAS бекапят еще и в другой облачный ресурс. Хотя по мере развития сервисов и возможного снижения цен постепенно станут популярными бэкапы Cloud-to-Cloud (без задействования локальных мощностей, но тут вопрос со спокойствием — доступность резервной копии зависит от доступности и скорости интернета).
2) Полезное уточнение — здесь в комментариях много пишут про проблемы (ресурса или клиента), связанные с «размножением» файлов с похожими (рассинхронизированными) именами (или именами, дополненными разными date-time), с «отставанием» синхронизации переименований папок и т.п. Насчет Synology — штатный агент Hyperbackup (при резервировании на внешний диск, подключенный к NAS) обеспечивает блочную дедупликацию, поэтому появление нескольких/многих разноименных копий множества файлов или перемещение файлов (переименование папок) не приводит к резкому росту размера резервной копии. Более того, т.к. в «командных» ресурсах по объективным причинам хранится большое количество (очень) похожих файлов (например, варианты одной и той же презентации, адаптированные для разных мероприятий или разных групп слушателей), то размер дедуплицированной резервной копии некоторое время (пока не накопится большое количество инкрементных изменений) может быть и (существенно) меньше размера исходной копии, синхронизированной из облачного ресурса. Думаю, что штатные инструменты локального резервирования для NAS других производителей тоже обеспечивают блочную дедупликацию.
1) По скорости загрузки (с компа или СХД-агентом) OneDrive в 20-80 раз медленнее, чем Google Drive, Яндекс.Диск — проверял много раз, на одинаковых объемах, на одном и том же интернете.
2) В OneDrive очень плохо работает копирование приличных (десятки и сотни гигабайт) данных между учетками; эта операция необходима при переносе данных между учетками — когда учетка предоставила другой папку только на чтение, в целевой учетке можно запустить копирование из этой предоставленной папки в свою папку. Пытался-тужился много раз — ни разу не успешно — процессы просто прекращались с сообщением-издевкой «что-то пошло не так». Такие операции очень удобно делать чтобы не гонять трафик между компом и ресурсом (т.е. чтобы все происходило только на стороне ресурса) при перераспределении файлов между личными и семейными учетками и т.п. — этим часто приходилось заниматься когда по объемам и стоимости ресурсы стали интересны обычным пользователям. В Google Drive, Яндекс.Диск такие операции выполнялись стабильно, а в Яндекс.Диск — как-то удивительно быстро — полТЕРАБАЙТА за несколько часов. Повторюсь — здесь идет речь именно о получении КОПИЙ файлов в другой учетке.
3) Связано с предыдущим пунктом — нормальная выполняемость такого процесса в Google Drive, Яндекс.Диск дополняется (относительным) удобством интерфейса — знакомым неискушенным пользователям как-то легко получается растолковать, что нужно дать доступ просто на просмотр папки — тогда нормально получается сделать копию в свою учетку (чтобы уже потом файлы регламентно синхронизировались в комп или СХД). В OneDrive — как-то сложнее — все время расшаривают полный доступ, и операция копирования недоступна.
4) Нельзя и не похвалить OneDrive — во-первых стоимость — в рамках подписки Office 365 примерно за 3 тыс. руб. в год (общая стоимость «на семью») по 1 терабайту доступно каждому из 5 пользователей (а вот здесь написано про 6 пользователей products.office.com/ru-ru/compare-all-microsoft-office-products?tab=1&OCID=AID679471_OO_Hero_mscomrefreshhome ); во-вторых — OneDrive в веб-интерфейсе показывает размеры папок — причем в представлении списка. Это очень удобно чтобы быстро понимать, например, объемы, которые нужно скачать или синхронизировать. В яндексе и гугле такой возможности пока нет.
Дополнение про OneDrive — 15 ГБ ограничение на размер файла — это в командной подписке, в персональной — вообще 10 ГБ — просто смешно; насколько я знаю, в других сервисах по этому параметру персональные и командные подписки не различаются.
Вопросы к автору:
1) Насчет версионности — в каком ресурсе чем измеряется — кол-вом версий или длительностью хранения предыдущих версий?
У Dropbox — 120-дневный журнал www.dropbox.com/plans?trigger=nr.
А как у других? А сколько времени хранится файл в корзине (просто удаленный, а не замененный новой версией)? Это я к тому, что и 120 дней — это не очень много (в конце текущего квартала вполне может потребоваться предыдущая (не последняя) версия отчета за предыдущий квартал); и еще наверное неспроста появилось много софта (в т.ч. СХД-сервисов) для локальных вечно-инкрементных бэкапов из облачных хранилищ, почт и порталов.
2) Если не затруднит — просьба дополнить про анонимную загрузку "… и сервис создаст анонимную ссылку, по которой можно залить файлы через браузер..." — а таким способом какого размера файлы можно зааплоадить через браузер?
Спасибо!
1) Вот так вот Марисса Мейер не отдыхала — не отдыхала, мозг не разгружала, ошибочные управленческие решения принимала — и… окончательно доразвалила Yahoo.
2) Насчет достаточности сна — неоднократно по утрам просыпался с обновленным решением на уровне блоков кода или даже архитектуры; во многих случаях такие решения существенно уменьшали объем работы. Точно знаю — попытки вымучить подобные решения увеличением продолжительности рабочего дня мозга моего + нескольких коллег однозначно занимали бы гораздо больше времени, а если решения и приходили бы — то во многих случаях слишком поздно, когда опасно и опять же трудоемко что-то менять (оговорка — согласен, что такие решения проше возникают и реализовываются в небольших командах, в проектах не очень длинных; в больших разработках сложно менять проектные решения, затрагивающие работу десятков-сотен специалистов).
Разве только у нас бывают ситуации, когда садимся реинжирить и удивляемся — откуда у нас здесь несколько сотен строк кода, которые без каких-либо потерь очевидно заменяются десятком вызовов давно отлаженных четко работающих библиотечных функций. Смотрим версии, видим время — 02 ч NN мин — … А!… Это вот тогда ночью кодячили, нужно было успеть…
Хорошо, что последние лет 5-7 таких ситуаций все меньше.
Думать нужно больше чем работать — к тому же думать можно на прогулке, при чтении худ. книги, на лыжах,… ну и во сне. А работать можно только на стуле, глазами в экран.
Приказ Минкомсвязи по данной новости mobile.cnews.ru/news/top/2019-01-31_minkomsvyazi_opredelilo_poryadok_proverki_sootvetstviya
можно скачать здесь publication.pravo.gov.ru/File/GetFile/0001201901220024?type=pdf
Смотрим страницу 16 – последний абзац пункта 8 таблицы в приказе прописан так:
«для абонентских устройств радиоподвижной связи — под управлением операционных систем Android, iOS;»
Эта формулировка взята напрямую из Постановления от 23 марта 2017 г. № 325 в исходной редакции
static.government.ru/media/files/ucxke5tjnh0jadWZ0EFK3xVr2uTXbOmn.pdf — см. стр. 4 (PDF-страница – 6).
Эта формулировка УСТАРЕЛА ДВАЖДЫ – в связи с выходом Постановления от 7 марта 2018 г. № 234 www.garant.ru/products/ipo/prime/doc/71795772
— по 31 декабря 2018г. включительно формулировка была такая:
«для абонентских устройств радиоподвижной связи — под управлением мобильной операционной системы, сведения о которой включены в единый реестр российского программного обеспечения, или операционных систем Android, iOS;
— с 1 января 2019 формулировка стала такая:
для абонентских устройств радиоподвижной связи — под управлением мобильной операционной системы, сведения о которой включены в единый реестр российского программного обеспечения и которая сертифицирована в соответствии с требованиями законодательства Российской Федерации о защите информации.».
(см. Постановление 325 в действующей редакции (с учетом внесенных изменений) base.garant.ru/71638522,
Удобно найти фразу «Абзац шестой (в редакции постановления Правительства РФ от 7 марта 2018 г. N 234) вступает в силу с 1 января 2019 г.»)
Тут возникает много вопросов:
1) Вступил ли в силу Приказ 722? – Ведь регламент Минюста запрещает регистрировать нормативные акты, противоречащие действующему законодательству – см.:
www.consultant.ru/document/cons_doc_LAW_56352/e89fe13c12b4406b57dc23f3462a223cd7beb148
21. В регистрации нормативного правового акта может быть отказано, если при проведении юридической экспертизы будет установлено несоответствие этого акта законодательству Российской Федерации или (и) наличие в этом акте положений, способствующих созданию условий для проявления коррупции.
(абзац введен Приказом Минюста РФ от 26.05.2009 N 155)
(так же см. docs.pravo.ru/document/view/8892/12902 и docs.cntd.ru/document/902159519 )
А регистрация была проведена уже в 2019 году, года действовала формулировка без упоминания операционных систем Android, iOS.
2) Авторы нормативных документов в области импортозамещения ПО по-прежнему только пишут их, без сверхдетального вычитывания?
3) Минкомсвязь не любит мобильную ОС?
И еще — Россия очень своеобразная страна, в которой технологическое развитие зачастую не предполагает повышение комфорта для потребителей технологических продуктов и услуг. Вот смотрите — до выхода 4-го оператора на общероссийский рынок мы имели трех-лоскутность покрытия. То есть при наличии дву-симочного аппарата вероятность остаться на связи составляла 2/3. Теперь во многих локациях появилась четырех-лоскутность — видимо операторы собрались, обсудили, перепилили зоны покрытия — и теперь вероятность стала 2/4 — меньше. Так что гипотетическое появление 5-го (реального, а не виртуального) оператора ничем хорошим нам не грозит — появится пяти-лоскутность.
Самое печальное, что эти лоскуты не фиксируются на длительное время — операторы проводят их ротацию. У меня есть вполне реальный пример — в месте, в котором я сейчас нахожусь (совсем ближнее замкадье) несколько лет назад один из операторов (федеральный, все серьезно) работал просто на урА-уРА-УРА. Радостные сотрудники и жители поблизости обзавелись номерами. И вот он пропал — от слова совсем, зато появился другой (на долго ли?). Причем на местности ничего не изменилось — холмов нет, за последние 40 лет зданий выше 2-ух этажей не строилось.