Добрый день, Гиктаймс!Некоторое время назад, на тостере попалось несколько интересных вопросов о хранении информации на жестких дисках, которые вызвали желание копнуть немного глубже, и я провел небольшое исследование.
Часть информации уже пробегала на Хабре, но не все. А кое-что я не смог найти в русскоязычном инете, поэтому и решил поделиться найденным с сообществом.
Про размагничивание данных на диске.
В нормальных бытовых условиях (отсутствие резкой смены температуры/влажности/давления, отсутствие ударов), намагниченная поверхность диска может хранить информацию несколько десятков лет. Гарантировать сложно, так как реальные промышленные тесты не проводились, а те, что проводятся — обычно как раз и представляют собой смену внешних условий для воздействия аггрессивной средой.
Но большинство сходятся на том, что мощность магнитного поля деградирует со скоростью примерно 1% в год.
При этом нельзя сказать, что через 50 лет не прочитается половина диска — это некорректно, ибо деградация поля не равна поломке — тут роль играет чувствительность считывающих головок и точность механизма позиционирования.
Даже в одной партии жестких дисков хорошего производителя на выходе получаются немного отличные пластины, и цельное устройство тщательно калибруется на заводе. Повторная калибровка в домашних условиях невозможна.
Со временем, внешне может показаться, что это ухудшилась магнитная запись, но в подавляющем большинстве случаев — ухудшение считывания связано с механической деградацией материалов — это вызывает и ошибки позиционирования и чувствительность головок.
В этом случае, для критических данных, можно потратиться на восстановление в компании, где блины вынут и считают данные с них напрямую, даже если механика и электроника полностью навернулась — сами пластины и информация на них подлежит считыванию.
Есть множество свидетелей, у которых старые диски, лежащие в шкафчике, отлично читаются спустя 15, и даже 20 лет (я, кстати, тоже один из них). А бывает, что диск не заводится, едва перейдя гарантийный срок годности.
Итак, в современных дисках сперва выходит из строя электроника и механика, раздалбываются разъемы, могут даже устареть стандарты, но вряд ли основной причиной будет размагничивание данных.
К этому можно еще добавить, что первыми должны размагнититься низкоуровневые разметки дорожек и секторов, которые были нанесены производителем, и которые штатными способами пользователь перезаписывать не сможет. Правда мощность поля у разметки гораздо выше, что заметно под микроскопом, но тем не менее ничто не вечно.
Выводы из этого пункта — перезаписывать информацию на диске, чтобы «обновить» магнитную запись — нет никакого резона.
Гораздо важнее обеспечить отсутствие агрессивного внешнего воздействия, как самое элементарное — закрутить его понадежнее, чтобы уменьшить вибрации. Включение-выключение ведет к расширению/сужению металла, это один из важных факторов, почему быстрые HDD живут меньше, чем медленные диски из «green» серий, которые не особо нагреваются. Но не стоит забывать, что если диск на ощупь не горячий, это не значит, что металл не расширился — тут важна не относительная температура для восприятия человеком, а просто смена температуры с нуля до скольки-небудь.
О секторах
Это не совсем 512 байт. Это область, в которой для пользовательских данных выделено 512 байт. Также есть служебная информация о секторе — это низкоуровневая метка начала и конца сектора, а также блок коррекции данных, обычно он идет после пользовательских данных. Плюс неразмеченное место между секторами (gap).
Метки сектора наносятся производителем во время так называемого низкоуровневого форматирования. В древние годы, это можно было делать самостоятельно из BIOS, но сейчас штатными способами это уже недоступно пользователю. Объем служебных данных, может варьироваться в зависимости от оптимизации firmware диска, но в считается, что сектор вмесне со служебными данными занимает 577 байт.
Точнее так было раньше.
В 2007 году было предложено увеличение размера сектора, и после процедур согласования и утверждения, начиная с 2011 года, все выпускающиеся диски уже форматируются с сектором размером в 4096 байт пользовательских данных (примерно 4211 байт со служебными данными) — так называемый Advanced Format.
Упрощение адресации (в восемь раз меньше на том же обхъеме), увеличивает производительность и уменьшает объем служебных данных.
Блок ECC данных
В 512 байтных секторах, ECC Блок занимал 50 байт. В 4096 байтных секторах, ECC блок увеличился до 100 байт, но так как уменьшилось само количество секторов, на самом деле мы сэкономили место в четыре раза (100 байт на 4096 байт вместо 400 байт на 8*512 байт).
Вдобавок, на более длинной цепочке данных алгоритм коррекции работает эффективнее, в результате и место сэкономили и эффективность увеличили. По разным оценкам скорость вычисления ECC увеличилась на 5-10%. А значит, контроллер диска меньше напрягается и может заняться другими вещами. Косвенно это влияет и на общую производительность записи/чтения данных.
Один из главных плюсов — это конечно экономия места.
За счет уменьшения объема, выделенного под блоки ECC, и уменьшения общего количества секторов (меньше gap, меньше меток), общий размер места, выделяемый для пользовательских данных, увеличился более чем на 10%!
Есть и еще один маленький плюс, связанный с bad block-ами. В случае брака или дефекта поверхности, сразу плохим будет помечен бОльший участок, это ускоряет внутреннее тестирование — если есть дефектный участок, будет быстрее проверить и пометить парочку секторов, чем пару десятков. И например, если мы обрезаем кусок червивого яблока, мы отрезаем и часть хорошего. Так и тут — полезнее плохой сектор пометить не в притык.
Но конечно от дисков с бэдами лучше быстрее избавиться.
Единственное исключение — логические бэд блоки. Они связаны именно с ECC — когда по разным причинам (внезапно отключилось электричество, баг firmware, лунные бури...), и ECC оказался некорректным — такой сектор будет считаться сбойным, но его можно исправить — утилит сейчас существует множество, начиная с известной Victoria.
Про виртуальные 512- байтные сектора
Логотип с «512e» означает, что сам диск уже 4кб-секторный, но работает в режиме эмуляции виртуальных 512 байтных секторов.
Логотип с «4Kn» говорит, что диск поддерживает 4к нативный интерфейс, такие диски в продаже с 2014 года.
Многие все еще популярные ОС (тут я говорю про Windows 7 и Windows Vista), не поддерживают 4к диски нативно.
Тем не менее, старые диски на них работают отлично, а новые диски предоставляют интерфейс с виртуальными 512-байтными секторами.
О виртуальных 512-байтных секторах следует помнить, когда вы тестируете 512е диски, или во время теста работаете на устаревшей ОС.
Например, запись рандомных 512-байтных секторов в таких условиях будет выглядеть как «считать 4кб, записать 4к», что явно будет выдавать непонятную деградацию скорости на графике. В тоже время как линейная скорость записи и чтения будет показывать нормальную производительность.
Windows поддерживает 4кn диски нативно, начиная с Windows 8 и Windows server 2012.
Про Cluster Straddling.
Это касается именно тех дисков, которые работают в 512е эмуляции (а таких в ходу еще много)
Разобъем такой диск на партиции и отформатируем с дефолтными настройками. Стандартный кластер NTFS- 4 килобайта. Блок HFS+ (или ext4) — обычно тоже 4 килобайта. И физический сектор диска — уже тоже 4 килобайта. Очень удобный размер (даже x86 mem страница — тоже 4 кбайта).
Но во время форматирования, логический кластер/блок файловой системы, может промахнуться мимо старта физического сектора диска, в результате ваш 4 килобайтный кластер/блок будет лежать между двумя 4 килобайтными физическими секторами жесткого диска, из чего следует деградация скорости работы — каждый раз при чтении блока, будет прочитываться два сектора, а при записи — еще и считываться.
Эту проблему решают различные align утилиты — тот же WD Align Tool или HGST Align Tool для Windows 7 и выше.
Только применять их нужно ПОСЛЕ того, как вы разбили диск на партиции — утилита проверит, что границы партиций совпадают с началом нового 4кбайтного сектора, и подвинет их, если это потребуется. После чего можно работать без падения производительности.
Где информация читается быстрее — в начале или в конце диска?
На жестких дисках, начальный сектор находится на внешней стороне диска, а последний сектор — на внутренней.
В начале времен, количество секторов на дорожке было одинаково, но это было настолько в дремучее время, что можно и не вспоминать.
Сейчас дорожки, находящиеся ближе к началу диска, то есть с внешней стороны, содержат больше секторов. Точнее дорожки логически объединяются в зоны, и количество секторов задается для каждой зоны.
Итак, линейная скорость записи и чтения информации расположенной в начале диска, значительно выше. Точные цифры зависят от производительности самого диска, но в процентах — разница может составлять 200% и даже немного больше процентов между самой широкой и самой узкой зонами.
Как же хранить?
Если сравнивать с CD, DVD и флешками — CD и флеш диски явно проигрывают в длительности хранения данных. DVD могут поспорить, но тут все неоднозначно — нужны и качественные болванки, и хороший привод, и запись производить не на максимальной скорости, и все равно, есть вероятность, что данные перестанут читаться. Вдобавок, 4.5 или даже 9 гб на DVD — это не так уж много, плюс отсутствие комфорта. И сохранить можно только раз — связываться с DVD-RW для длительного хранения данных вообще не стоит.
Если же брать Blue Ray диски, то стоимость пишущего привода и болванок такова, что если не дешевле, то почти равноценно через 5 лет купить новый жесткий диск и переписать на него данные.
На текущий момент, недорогие способы хранения личных данных в основном делятся на:
* Если данных не слишком много, и инет позволяет — можно хранить в облаке, а лучше в двух разных независимых облаках, предварительно зашифровав данные трукриптом/архиватором. Тут я прорекламирую WinRAR, который кроме архивирования с паролем, вдобавок умеет использовать ECC. Можно увеличить размер архива на некоторый процент, но зато иметь возможность восстановить данные из любого поврежденного места этого архива, в пределах этого процента. Есть даже возможность разбивать архив на тома, и том для восстановления создать отдельным файлом. В древности, я этим активно пользовался со старыми дискетами, когда целая дискета могла просто не прочитаться в чужом дисководе.
* Съемный HDD, но рекомендую менять носитель с периодичностью в 3-5 лет на более новый, стараясь не слишком далеко отходить от гарантийного срока. Можно просто купить SATA/USB переходник и апгрейдя системный диск на более быстрый/емкий, старый диск отдавать под бэкапы.
* Купить недорогой домашний NAS с рейдом. Этот способ заметно дороже предыдущих двух, но он позволяет легко производить замену вышедшего из строя диска, и вдобавок иметь бэкап диск всегда включенным, полностью автоматизировав процесс.
UPD: DaemonGloom рекомендует замечательные устройства WD My Cloud Mirror, которое идет практически по цене жестких винтов, плюс небольшая переплата за корпус/контроллер:
«По текущим ценам — устройство на 2x4TB даёт 100 долларов переплаты, 2x6TB — 80 долларов.»
Лично я делаю резервную копию всего важного на второй диск, и периодически скидываю архивы на внешний USB диск вручную.
Таким образом есть а) рабочая копия, б) ежедневный архив на втором диске, и с) примерно ежемесячный архив на внешнем отключенном диске. Но в принципе уже начинаю подумывать про NAS.
А как храните вы?
Комментарии (70)
Rumlin
19.05.2016 16:01Первое о чем подумалось — Seagate и муха ЦЦ.
Имхо для надежного хранения надо более одного HDD. И NAS с зеркальным рейдом выглядит наилучшим домашним решением по надежности. Если надежность стоит любых денег.
saboteur_kiev
19.05.2016 16:17Если надежность стоит любых денег, то вообще можно напридумывать много чего…
Текущее решение от меня не потребовало никаких вложений — лишний винт сперва появился во апгрейда системы, лет 20 назад, а потом так и пошло — апгрейднул системный или второй винт, старый на бэкап, предыдущий бэкапный уже на хлам. И буквально несколько лет назад впервые в качестве внешнего бэкапного винта специально купил новый USB-шный, чтобы не мучаться с переходником.
Про NAS я подумываю уже года два, но меня напрягает, что стоимость NAS дороже стоимости дешевого компа с двумя винтами, на котором я могу поднять зеркальный рейд на любой винде/линуксе.
Пока меня текущее решение особо не напрягает, я может подожду, пока в продаже появятся простые NAS решения на какой-нить ардуине, по цене два винта + 50$ максимум.Rumlin
19.05.2016 16:23Да, у NAS много программных плюшек, которые к бэкапу отношения не имеют — ftp, DLNA и т.п.
DaemonGloom
20.05.2016 12:01Если вас устроило бы 80-100 долларов переплаты, то есть замечательные устройства WD My Cloud Mirror.
По текущим ценам — устройство на 2x4TB даёт 100 долларов переплаты, 2x6TB — 80 долларов.
Foolleren
19.05.2016 16:32зеркало не защищает от повреждения информации, только от отказа диска. (как зеркало будет определять на каком диске правильная а на каком не правильная информация?)
AMDmi3
19.05.2016 17:51+1Зависит от ФС и менеджера томов. ZFS, например, использует контрольные суммы, и в случае ошибки не только читает блок с другого диска, но и восстанавливает на исходном.
MyFearGear
19.05.2016 21:57о, это самая беспроблемная проблема с жесткими из всех возможных: винт восстанавливается тремя строчками в консоль, данные не страдают — лепота.
ChiefMate
19.05.2016 16:15Личные сокровища — тексты, большой фотоархив в RAW и JPG, немного любимой музыки и пара дорогих сердцу фильмов. Суммарно чуть более 600 ГБ.
Первая копия — в основном ноуте, на терабайтном HDD. Вторая — на 4ТБ USB-винте, подключенном к домашнему роутеру, там же и акронисовский снапшот системного диска, максимум месячной свежести. Третья — в бесплатном терабайтном облаке, которое как-то удачно отхватил по акции. Всё личное, что в облаке — упаковано в TrueCrypt контейнеры, за исключением музыки, фильмов и — отчасти — фото, не все из которых нужно прятать.
Самое важное, вроде сканов паспортов и пр.- еще и на флешке, зашифрованной БитЛокером, на одном брелоке с ключами от машины. Самые дорогие фото — старые, семейные — еще и у родителей, на всякий случай.
Обновление бэкапов — вручную (после того, как из-за автоматизированной синхронизации потерял часть уникального контента сразу во всех расположениях, предпочитаю повозиться, но контролировать процесс лично). Обновлять архивы раз в неделю — хватает, обычно в ночь на субботу, без спешки, под пивко )saboteur_kiev
19.05.2016 16:25Потеря контента всегда обидно. Очень очень давно потерял архив с ранней фидошной почтой, дискеты не прочитались.
Но делать вручную — неудобно. Синхронизацию настроил одностороннюю, а основные документы — я уже говорил — ежедневные архивы автоматом, а вот на внешний винт скидываю вручную, тут предварительно и сравниваю по размеру файлов.
Foolleren
19.05.2016 16:36автоматика вещь полезная, например не весть откуда взявшиеся 10 гб трафика обнаруженные прочтением логов на досуг намекнули, что надо проверить содержимое.
alexeyborealis
19.05.2016 16:27> NAS с рейдом… иметь бэкап диск всегда включенным
RAID is not a backup.saboteur_kiev
19.05.2016 16:28Я писал, что NAS целиком отведенный под бэкап.
Что же касается рейда — а зачем вообще нужен NAS без рейда?
alexeyborealis
19.05.2016 16:35+1Думается мне, что в NAS'е диски могут полечь сразу все вместе либо физически (от неполадки источника питания, например, читай — сгореть), либо данные на них пострадать от глюков софта. Потому втыкаемый раз в неделю накопитель, как в комментарии выше, будет надёжнее. Вот о чём я.
saboteur_kiev
19.05.2016 17:55У вас есть пример, когда в NAS сгорели все диски? Я быстропогуглил и не нашел, то есть это крайне редкий случай.
Один диск — рано или поздно точно полетит, и игра заключается в том, успеешь ли ты его заменить на новый ДО или уже после, с гемором и восстановлением. NAS с простым зеркалом решает эту проблему.
NAS же можно использовать также само — держать в шкафу и втыкать раз в неделю, но при этом буду совершенно спокоен, что даже если там один диск полетит, я его заменю. Без спешек. Без нервотрепок. Даже без дополнительных действий — просто старый винт вынул, новый вставил, и NAS сам его накатит. Причем вся эта процедура не мешает мне собственно продолжать делать бэкапы — я ж новый винт могу и через 5 минут вставить и через неделю, когда мне будет удобно.Foolleren
19.05.2016 18:41Чисто гипотетически, может гроза вдарить, пожар случиться, метеорит упасть, соседи затопить(кипятком) блок питания напортачить, вероятность всего хоть и маленькая, но иметь несгораемый сейф для документов никогда не помешает.
saboteur_kiev
19.05.2016 19:27Гроза/пожар/метеорит могут испортить внешний диск также как и NAS.
А если гроза/пожар/метеорит попадут в Вас, вам будет уже не до бэкапов.Foolleren
19.05.2016 20:39+1Если продолжать эту тему, то небольшой пожар и удар грозы в лан кабель не страшны диску внутри несгораемого сейфа.
Jump
20.05.2016 04:17Довольно спорно.
Я бы сказал, что в большинстве случаев, для бэкапов рэйд не нужен вообще.
Рэйд обеспечивает бесперебойность работы.
В случае с хранилищем бэкапов бесперебойность работы не важна, данные меняются редко.
Поэтому для бэкапов оптимальней использовать не рэйд, а второй диск на который будет дублироваться информация с некоторой задержкой.
Areso
20.05.2016 09:39Поддерживаю, потому, выбирая NAS с рейдом, я подумал, и выбрал 2 NAS'a без рейда (один у себя, один у родителей). Содержимое синхронизируется между ними и находятся они физически в разных локациях. Бывают случаи, что мрет raid-контроллер, запарывая информацию, само устройство тоже может дать дуба с тем же результатом, пожары/потопы и воров никто не отменял. И маленький криптоконтейнер в облаке)
Dmitry_4
20.05.2016 10:28Рэйд радикально снижает вероятность успешного восстановления данных при сбое, особенно через много лет. Надо делать дубликацию даных, чем прекрасно занимается Drive Extender в windows home server 2003.
Barafu
19.05.2016 19:26Имею 4 диска WD Green по 3 Тб в компе, объединённых в BTRFS-RAID, итого 6 Тб места с контролем CRC, что оказалось очень важно. Смотрю логи — файло вроде лежит себе, нормально открывается, а CRC раз — и не сошёлся. Перед чтением прозрачно восстанавливается. Самое важное лежит ещё и в облаке. Ничего не шифрую, мне пофиг, что майор Моссада будет знать мой номер страхования.
4144
19.05.2016 22:43+1Btrfs может испортить данные и RAID не поможет.
Был у меня однажды Btrfs в raid1. Через какое-то время, система начала намертво виснуть, предположительно при работе с btrfs. Потом подтвердил что именно при работе с btrfs. После такого зависания, перезагрузка только через reset. В итоге на btrfs образуются inode с ошибками, штатный дисколечитель может их только найти, но не исправить. Спец утилитой возможно удаление таких inode. Далее через какое-то время проблема повторяется. Новое ядро уже не виснет целиком, а подвешивает в состояние z только один процесс.
После нескольких таких итераций, раздел с btrfs перестал монтироваться. Восстановил всю или почти всю информацию через утилиты восстановления. Потом переформатировал в mdadm raid1 + ext4.
ядро rt.
Каких-либо сбоев или подвисаний, за исключением btrfs, в это время не было.saboteur_kiev
19.05.2016 22:47+2Ребята,
Рейд это не защита от потери данных, это защита от сбоев. Единичные случаи, когда основная функция рейд1 (продолжение работы в случае сбоя одного из дисков) не работает, не означает что им не нужно пользоваться.
Но нужно помнить, что бэкап данных — это бэкап, и если он сбойнет — у вас есть рабочая копия. Сбойнул бэкап — чиним бэкап, сбойнула рабочая копия — восстанавливаем рабочую копию. Главное чтобы было и то и другое, а лучше еще и третье.
Все делятся на тех, кто
* Не делает бэкапы
* Уже делает бэкапы
* Делает бэкапы и проверяет их целостность4144
19.05.2016 23:22Raid не отменяет бэкап, как и наоборот.
Но чаще всего выходят из строя именно винчестеры, а не происходят какие-то сбои.
Т.е. raid неплохая защита рабочих данных (в бэкапе они обычно несколько устаревшие)
Также не все данные на столько ценны, что каждый раз их нужно записывать в бэкап. Иногда их можно восстановить после полной потери, на пример скачать. Но это долго и сложно. Тут как раз обычно спасает raid.
svr_91
20.05.2016 11:58А если, например, какой-то из дисков умрет не сразу, а постепенно? Например, начнут понемногу появляться bad блоки. Raid от этого спасет?
saboteur_kiev
20.05.2016 11:59Битый винт будет релоцировать сектора, пока сможет, это скажется на общей производительности, и рейд тут поможет в том смысле, что вынимаете битый диск, и меняете. А пока вы его меняете, все работает на целом.
svr_91
20.05.2016 14:22Нет, ну а если первый винт не заметит, что у него появился битый сектор и скопирует битые данные на второй винт?
saboteur_kiev
20.05.2016 14:27Какой первый винт?
Данные в зеркале копируются не с винта на винт, а контроллер пишет сразу на два винта, независимо.
Кроме того, вы начинаете ударяться в такие редкие проблемы, которые практически не встречаются. Типа как magic numbers для CD дисков.svr_91
20.05.2016 14:41Ну предположим, есть большой документ, в котором случайно повредился один сектор из-за bad блока на диске. Мы этот документ открыли, изменили, записали. Контроллер решил, что нужно скопировать этот документ на 2 диска, в результате мы получаем 2 поврежденных документа. Поэтому интересно узнать, отслеживает ли контроллер каким-то образом такую ситуацию, или такая ситуация не может случиться по каким-то другим причинам?
По поводу редких проблем, какие проблемы Вы называете редкими? Если имеются в виду битые сектора, то, мне кажется, не такая уж и редкая это проблема. По крайней мере, на своем жд я битые сектора получал.
Как по мне, наверное даже страшнее получить порченные данные и не узнать об этом, чем испортить данные и узнать об этом сразу.Barafu
20.05.2016 15:59+1А о каком рейде речь? dmraid читает как есть, а вот btrfs имеет контрольную сумму на каждый файл, прочитает второй диск и найдёт правильную копию. Затем молча восстановит первый файл тоже. За это и любим, хотя он самый медленный из всех.
saboteur_kiev
20.05.2016 16:47«Ну предположим, есть большой документ, в котором случайно повредился один сектор из-за bad блока на диске. Мы этот документ открыли, изменили, записали.»
То есть, открыв документ, вы не заметили что он кривой?
Если это не многостраничный plaintext, в котором вы не долистали до битого участка, то любой Word вам скажет, что document is corrupted уже на момент чтения. Либо документ прочитается с целого винчестера, а на битом этот сектор пометится как bad и не будет считан.
Битые сектора и некорректный ECC код — весьма разные вещи. Сектор либо может быть прочитан, либо не может — за этим следит контроллер жесткого диска. Чтобы у вас повредился ECC, чтобы контроллер диска этого не заметил, чтобы этого не заметила программа, работающая с документом — все три ошибки уже представляют собой невероятные случаи, которые могут произойти с очень редким шансом. Но чтобы все три сразу — …Foolleren
20.05.2016 17:57производители оценивают этот шанс как 1 бит из 10^12-10^15 не то чтобы много, но вполне реально столкнуться.
4144
20.05.2016 14:36Такое если и случится, то очень редко.
Скорее при каких-то странных обстоятельствах вроде работающий винчестер выпадет из рейда. Это может как раз говорить о том, что с этим винчестером что-то не так, хотя он еще не умер.
Также для проверки такого состояния, иногда запускается синхронизация дисков в raid. Исправить подобную ошибку вряд ли сумеет, но найдет точно.
Barafu
20.05.2016 00:40Человек на работе случайно сделал dd на диск с данными. Без всяких рейдов. Переписал первые несколько гигабайт образом другой файловой системы, потом нажал CTRL+C. И ничего, я штатным btrfs-tools всё поправил, пропали только затёртые файлы, остальные сохранились вместе с именами и путями. Было это осенью 2015 на debian testing. А ваши злоключения в каком веке случились?
4144
20.05.2016 03:51Debian unstable с apsosid ядром.
Что-то около полугода назад: https://bugzilla.kernel.org/show_bug.cgi?id=108241
severgun
20.05.2016 14:55-1Хороните молодого.
BTRFS для бэкапов? Вы серьезно? Это максимально сырой experimental без адекватно работающих средств восстановления.
Уже наступал на грабли. Никому не советую. Разлетается как рейд так и просто ФС в клочья и ничем уже не собрать.Barafu
20.05.2016 17:25+2Вот это я вообще обожаю. Если при релизе сказать «Ребят, мы тут за недельку сбацали ФС, всё работает, пользуйтесь все!» — то это сразу надёжный продукт, а если честно признаться «Вот тут и тут ещё сыровато, вот этим пока не пользуйтесь, и вообще, не забывайте бекапить!» — то это уже 10 лет «максимально сырой experimental»?
Миром IT правят маркетологи.
Incognito4pda
19.05.2016 20:35+14-ый год использую WD MyCloud на 4 ТБ, проблем не замечал. Софтовый диагност, через веб морду, всегда радостно рапортует о хорошем состоянии накопителя. После данной статьи задумался о замене MyCloud на такой же, только двух дисковый RAID.
Alexsey
20.05.2016 09:444-ый год использую WD MyCloud на 4 ТБ
Если он используется для бекапов то я бы уже задумался над заменой. 4 года для винта это все же весьма много, а рапортовать о нормальном состоянии он может практически до самой (внезапной) смерти.
veam
20.05.2016 08:55+1Я делаю раз в полгода бэкап системного ссд (гигов 30-40), остальные некритичные данные храню на 4 ТБ дисках.
Докупаю новые когда старые забиваются.
Бэкап этих данных обошелся бы слишком дорого, сгорят так сгорят. Судьба значит такая.
dannk
20.05.2016 09:30У меня NAS с RAID на два диска, плюс бекапы в OneDrive (1tb) и на Amazon Cloud (фотографии бесплатно в любом количестве). Хранить бекапы только локально у себя в шкафу не спасет в случае пожара или ограбления…
dmitry_ch
20.05.2016 09:50линейная скорость записи и чтения информации расположенной в начале диска, значительно выше.
Да, был даже такой подход к ускорению дисков в серверах: задействовать из всей поверхности диска только часть, дающую достаточно высокое быстродействие. Выгода была в цене дисков (SSD все еще не сильно дешевы), так что надо хорошенько все посчитать, но сама идея хороша. Плюс, на самый крайний случай, у нас еще остается неиспользованная часть диска, а ей можно найти применение самые разные.
Скажем, разбить диск на два раздела, один в быстрой части поверхности, другой в медленной. Собрать из «первых» разделов всех дисков один том хранения, из вторых — другой. На первом томе держать данные, которые требуют быстроты, на второй делать бекап (конечно, понимая, что оба раздела каждого диска физически делят один носитель, так что с умом их нагружать). Точнее, конечно, из части дисков делаем тома быстрый1 и медленный1, из второй части дисков — быстрый2 и медленный2. А бекапы, конечно, гоним «перекрестно» — с быстрый1 на медленный2 и с быстрый2 на медленный1.
Areso
20.05.2016 09:57Как контролировать целостность всех файлов на жестком диске (или хотя бы в выбранных директориях) по чексумам без применения ультрасовременных файловых систем и рейда? С расписаниями, отчетами, вот это все. В случае чего, чтобы просто руками со второго устройства перетащить битый файл. Linux, x86, ARM, FS ext3.
Teemon
20.05.2016 12:07хороший вопрос. И то же самое интересует для виндоус.
Foolleren
20.05.2016 14:56под виндовсом 8 10 2012(r2) есть ReFS
D:\>format /fs:refs /q /i:enable
если операционка обнаружит факап то восстановит сбойный файл из загашника
вариант для конченых извращенцев
сделать 3 (можно и больше для уменьшения накладных расходов) VHD файла и слепить из них raid-5 в случае если какой-то сектор окажется повреждённым то это будет выяснено и восстановлено.
saboteur_kiev
20.05.2016 12:11Можно любой велосипед написать, который будет генерировать чексуммы для выбранных вами файлов, и сравнивать потом отчеты.
Но проблема заключается в том, что файлы — меняются, список файлов — меняется.
То, что вы проверили пару терабайт файлов убедились, что они цельные и записали чексуммы, не поможет вам просто посмотреть на чексуммы и сказать что все окей — нужно заново проверять пару терабайт файлов, и сравнивать с чексуммами.
Поэтому не совсем понятно, какая у вас стоит задача.severgun
20.05.2016 15:01Ну люди вон вручную на 5 бэкапов под пивко файлы кидают, почему бы под пивко чексуммы не считать?
Areso
20.05.2016 18:45Именно так. Один раз пройтись по всей выбранной директории/логическому диску, выдать таблицу (типа csv) в формате файл-чексумма. Поставить в крон. Через неделю при проходе сделать такую же таблицу, а далее, сравнить её с предыдущей (если предыдущая есть). Если файл (ключ) одинаковый, но отличается его значение (чексумма), то смотрим дату изменения. Если изменений не было, то генерируем отчет и помечаем данный файл как битый. Храним 2 таблицы — за текущий прогон и за предыдущий.
saboteur_kiev
20.05.2016 19:25Под виндой, можно сохранять чексумму в альтернативный ntfs поток этого файла, что удобно. Некоторые антивирусы тоже так делают (или делали) — хранят данные о сканировании в альтернативных потоках.
azsx
20.05.2016 12:06На двух компьютерах я установил синхронизацию через программу syncthing. Второй компьютер стоит у родителей, синхронизация через интернет, статического ip адреса не требуется. Перекачивал даже террабайтные каталоги, постоянно храню и обновляю сотни гигабайт.
Плюсы:
— территориально удаленные копии;
— всё работает само по себе;
— настраивается, чтобы второй пользователь не мог удалять ваши файлы (он удалит, они перезакачаются).
Минусы:
— требователен к процессору (считает md5, у меня i5-2500);
— нет шифрования (сами шифруйте);
— сложный для моего понимания веб-интерфейс.
AlexCherny
20.05.2016 12:06Посмотрите ветку «Домашний бэкап» на forum.ixbt.com/topic.cgi?id=11:37198 там и экспертов хватает, и примеров решения подобной задачи.
MasterDan
20.05.2016 12:06Сейчас можно недорого и быстро собрать NAS самому, даже крайне бюджетная платформа даст большие возможности, благодаря развитию файловых систем, таких, как ZFS, можно дома получить контрольные суммы, проверку целостности данных, снапшоты 'из коробки'. Установка и настройка Nas4Free, FreeNAS расписаны по шагам. Себе делал, руководствуясь 2gusia.livejournal.com
Teemon
20.05.2016 12:10Интересная и полезная тема, спасибо.
Как насчет того, чтобы резервный жесткий диск для бэкапа данных воткнуть физически в компьютер, подключить к sata и питанию, но через bios «выключить» этот sata-порт? будет ли он «работать» и тратить ресурс?
По необходимости раз в N дней включать его через биос, делать бэкап, проверять данные и выключать.
Все-таки хранить диск «на полке» и втыкать в комп по необходимости — лениво и только лишний риск уронить.
Как ни крути, думаю, 90% данных у домашних пользователе — это таки фотографии.
Организация NAS в качестве бэкапа может быть удобна только для тех, кто хочет бэкапить данные с устройств, находящихся в сети (телефоны, планшеты и т.д.).
Если бэкапить данные с компа — то проще к компу и подключить, разве нет?saboteur_kiev
20.05.2016 12:15А перегружать комп и лазить в биос, не лениво? У меня комп перегружался последний раз, когда электричество отрубили на 4 часа. То есть от силы пару раз в год. Гораздо проще usb винт подключить. Если опасаетесь уронить — прикрутите внешний USB диск, где-то рядом с компом и просто USB кабель втыкайте-вытыкайте.
Для полной автоматизации — NAS или пользуйтесь облаками — всякими яндекс дисками, гуглдрайвами — для подавляющего большинства, объемов там хватает.
Rumlin
21.05.2016 07:48Купите карман в корпус (Mobile Rack) т.к. включение и выключение питания самые не хорошие процессы. HDD выключен в БИОС, но питание подается при каждом включении компьютера и он все равно работает — тут только выдергивать из него разъемы, когда он не нужен и пусть стоит в корпусе. Либо «карман» — там отключение кнопкой.
sim2q
20.05.2016 19:35К этому можно еще добавить, что первыми должны размагнититься низкоуровневые разметки дорожек и секторов
вроде как даже они сильнее намагниченыsaboteur_kiev
20.05.2016 21:14Они размечаются теми же самыми головками, на той же самой поверхности, потребляя ту же самую энергию.
Даже если там пройтись 10-20 раз по тому же месту, особого разницы не будет.sim2q
20.05.2016 21:24не могу точно сказать за давностью, но казалось, что видел где то осциллограммы где разметка выделялась
Foolleren
21.05.2016 08:08+1это было давно, сейчас разметку выполняют на заводе специальной машиной
На пластину жесткого диска с помощью шприца наносится пара капель коллоидной суспензии частиц Fe2O3. Затем с помощью специального покровного стекла суспензия размазывается тонким слоем по ее поверхности, на которой в отраженном свете проявляется магнитный контраст. Его, в принципе, достаточно, чтобы даже невооруженным взглядом оценить наличие или отсутствие информации — на рисунке четко видны сервометки, разделяющие диск на сектора.
При 800-кратном увеличении оптического микроскопа становятся четко различимы отдельные сервометки, несколько хуже выделяются дорожки с данными, записанные более слабым полем
https://habrahabr.ru/company/neuronspace/blog/254671/saboteur_kiev
21.05.2016 14:28Точно, спасибо.
P.S. Прочитав статью, с удивлением нашел ниже свои же камменты… Совсем забывается ;(
rvt
20.05.2016 21:12У меня все важное и накопленное непосильным трудом :) автоматически бэкапится на ноутбуки жены и дочери и в 2 облака. 5 копий, думаю, надежно будет…
Foolleren
Насчёт WinRAR, мне больше нравится в добавок к ECC делать многотомный архив c томами для восстановления, ECC помогает в том случае если файл удаётся вернуть с ошибками, а то бывает и такое, что файл пропадает насовсем, или в процессе происходит ошибка и виндовс с умным видом вообще не копирует, конечно можно добавить всякий софт копирующий сбойные файлы, но это уже несколько утилит для одной задачи.
saboteur_kiev
Да! Этой штукой пользовался в дремучие в конце девяностых, уже был winrar, но ни флешек ни инета нормального не было, и что-то большое возили на дискетах, делая многотомный архив. Можно было на отдельную дискету том для восстановления скинуть, и тогда даже утеря одной целой дискеты с архива не мешала все считать.
casuss
WinRARFS (простите, не удержался, но идея прям на поверхности ведь)
Foolleren
Идею давно уже используют используют в различных RAID с цифрами отличными от 0 и 1. правда это всё дорого если есть условие, что потеря пары дисков не сказывается на работе массива, а с тормозами в любой матплате раид 5 есть.