Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Насчёт WinRAR, мне больше нравится в добавок к ECC делать многотомный архив c томами для восстановления, ECC помогает в том случае если файл удаётся вернуть с ошибками, а то бывает и такое, что файл пропадает насовсем, или в процессе происходит ошибка и виндовс с умным видом вообще не копирует, конечно можно добавить всякий софт копирующий сбойные файлы, но это уже несколько утилит для одной задачи.
Да! Этой штукой пользовался в дремучие в конце девяностых, уже был winrar, но ни флешек ни инета нормального не было, и что-то большое возили на дискетах, делая многотомный архив. Можно было на отдельную дискету том для восстановления скинуть, и тогда даже утеря одной целой дискеты с архива не мешала все считать.
Первое о чем подумалось — Seagate и муха ЦЦ.
Имхо для надежного хранения надо более одного HDD. И NAS с зеркальным рейдом выглядит наилучшим домашним решением по надежности. Если надежность стоит любых денег.
Имхо для надежного хранения надо более одного HDD. И NAS с зеркальным рейдом выглядит наилучшим домашним решением по надежности. Если надежность стоит любых денег.
Если надежность стоит любых денег, то вообще можно напридумывать много чего…
Текущее решение от меня не потребовало никаких вложений — лишний винт сперва появился во апгрейда системы, лет 20 назад, а потом так и пошло — апгрейднул системный или второй винт, старый на бэкап, предыдущий бэкапный уже на хлам. И буквально несколько лет назад впервые в качестве внешнего бэкапного винта специально купил новый USB-шный, чтобы не мучаться с переходником.
Про NAS я подумываю уже года два, но меня напрягает, что стоимость NAS дороже стоимости дешевого компа с двумя винтами, на котором я могу поднять зеркальный рейд на любой винде/линуксе.
Пока меня текущее решение особо не напрягает, я может подожду, пока в продаже появятся простые NAS решения на какой-нить ардуине, по цене два винта + 50$ максимум.
Текущее решение от меня не потребовало никаких вложений — лишний винт сперва появился во апгрейда системы, лет 20 назад, а потом так и пошло — апгрейднул системный или второй винт, старый на бэкап, предыдущий бэкапный уже на хлам. И буквально несколько лет назад впервые в качестве внешнего бэкапного винта специально купил новый USB-шный, чтобы не мучаться с переходником.
Про NAS я подумываю уже года два, но меня напрягает, что стоимость NAS дороже стоимости дешевого компа с двумя винтами, на котором я могу поднять зеркальный рейд на любой винде/линуксе.
Пока меня текущее решение особо не напрягает, я может подожду, пока в продаже появятся простые NAS решения на какой-нить ардуине, по цене два винта + 50$ максимум.
зеркало не защищает от повреждения информации, только от отказа диска. (как зеркало будет определять на каком диске правильная а на каком не правильная информация?)
о, это самая беспроблемная проблема с жесткими из всех возможных: винт восстанавливается тремя строчками в консоль, данные не страдают — лепота.
Личные сокровища — тексты, большой фотоархив в RAW и JPG, немного любимой музыки и пара дорогих сердцу фильмов. Суммарно чуть более 600 ГБ.
Первая копия — в основном ноуте, на терабайтном HDD. Вторая — на 4ТБ USB-винте, подключенном к домашнему роутеру, там же и акронисовский снапшот системного диска, максимум месячной свежести. Третья — в бесплатном терабайтном облаке, которое как-то удачно отхватил по акции. Всё личное, что в облаке — упаковано в TrueCrypt контейнеры, за исключением музыки, фильмов и — отчасти — фото, не все из которых нужно прятать.
Самое важное, вроде сканов паспортов и пр.- еще и на флешке, зашифрованной БитЛокером, на одном брелоке с ключами от машины. Самые дорогие фото — старые, семейные — еще и у родителей, на всякий случай.
Обновление бэкапов — вручную (после того, как из-за автоматизированной синхронизации потерял часть уникального контента сразу во всех расположениях, предпочитаю повозиться, но контролировать процесс лично). Обновлять архивы раз в неделю — хватает, обычно в ночь на субботу, без спешки, под пивко )
Первая копия — в основном ноуте, на терабайтном HDD. Вторая — на 4ТБ USB-винте, подключенном к домашнему роутеру, там же и акронисовский снапшот системного диска, максимум месячной свежести. Третья — в бесплатном терабайтном облаке, которое как-то удачно отхватил по акции. Всё личное, что в облаке — упаковано в TrueCrypt контейнеры, за исключением музыки, фильмов и — отчасти — фото, не все из которых нужно прятать.
Самое важное, вроде сканов паспортов и пр.- еще и на флешке, зашифрованной БитЛокером, на одном брелоке с ключами от машины. Самые дорогие фото — старые, семейные — еще и у родителей, на всякий случай.
Обновление бэкапов — вручную (после того, как из-за автоматизированной синхронизации потерял часть уникального контента сразу во всех расположениях, предпочитаю повозиться, но контролировать процесс лично). Обновлять архивы раз в неделю — хватает, обычно в ночь на субботу, без спешки, под пивко )
Потеря контента всегда обидно. Очень очень давно потерял архив с ранней фидошной почтой, дискеты не прочитались.
Но делать вручную — неудобно. Синхронизацию настроил одностороннюю, а основные документы — я уже говорил — ежедневные архивы автоматом, а вот на внешний винт скидываю вручную, тут предварительно и сравниваю по размеру файлов.
Но делать вручную — неудобно. Синхронизацию настроил одностороннюю, а основные документы — я уже говорил — ежедневные архивы автоматом, а вот на внешний винт скидываю вручную, тут предварительно и сравниваю по размеру файлов.
автоматика вещь полезная, например не весть откуда взявшиеся 10 гб трафика обнаруженные прочтением логов на досуг намекнули, что надо проверить содержимое.
> NAS с рейдом… иметь бэкап диск всегда включенным
RAID is not a backup.
RAID is not a backup.
Я писал, что NAS целиком отведенный под бэкап.
Что же касается рейда — а зачем вообще нужен NAS без рейда?
Что же касается рейда — а зачем вообще нужен NAS без рейда?
Думается мне, что в NAS'е диски могут полечь сразу все вместе либо физически (от неполадки источника питания, например, читай — сгореть), либо данные на них пострадать от глюков софта. Потому втыкаемый раз в неделю накопитель, как в комментарии выше, будет надёжнее. Вот о чём я.
У вас есть пример, когда в NAS сгорели все диски? Я быстропогуглил и не нашел, то есть это крайне редкий случай.
Один диск — рано или поздно точно полетит, и игра заключается в том, успеешь ли ты его заменить на новый ДО или уже после, с гемором и восстановлением. NAS с простым зеркалом решает эту проблему.
NAS же можно использовать также само — держать в шкафу и втыкать раз в неделю, но при этом буду совершенно спокоен, что даже если там один диск полетит, я его заменю. Без спешек. Без нервотрепок. Даже без дополнительных действий — просто старый винт вынул, новый вставил, и NAS сам его накатит. Причем вся эта процедура не мешает мне собственно продолжать делать бэкапы — я ж новый винт могу и через 5 минут вставить и через неделю, когда мне будет удобно.
Один диск — рано или поздно точно полетит, и игра заключается в том, успеешь ли ты его заменить на новый ДО или уже после, с гемором и восстановлением. NAS с простым зеркалом решает эту проблему.
NAS же можно использовать также само — держать в шкафу и втыкать раз в неделю, но при этом буду совершенно спокоен, что даже если там один диск полетит, я его заменю. Без спешек. Без нервотрепок. Даже без дополнительных действий — просто старый винт вынул, новый вставил, и NAS сам его накатит. Причем вся эта процедура не мешает мне собственно продолжать делать бэкапы — я ж новый винт могу и через 5 минут вставить и через неделю, когда мне будет удобно.
Чисто гипотетически, может гроза вдарить, пожар случиться, метеорит упасть, соседи затопить(кипятком) блок питания напортачить, вероятность всего хоть и маленькая, но иметь несгораемый сейф для документов никогда не помешает.
Гроза/пожар/метеорит могут испортить внешний диск также как и NAS.
А если гроза/пожар/метеорит попадут в Вас, вам будет уже не до бэкапов.
А если гроза/пожар/метеорит попадут в Вас, вам будет уже не до бэкапов.
имею опыт: молния ударила в дом — сгорел роутер и NAS
к счастью, NAS обменял по гарантии, а диски остались в полном порядке,
в новом устройстве завелись без проблем, все данные тоже в порядке
к счастью, NAS обменял по гарантии, а диски остались в полном порядке,
в новом устройстве завелись без проблем, все данные тоже в порядке
у меня был не гипотетический случай с грозой лет 10 назад, когда учился в колледже, у нас гроза попала в спутниковую тарелку с интернетами. единственными пострадавшими были сетевухи на части ученических компьютеров+ на шлюзе (странным образом хабы не пострадали), ну а жесткие все живы-здоровы.
Мне известны случай когда удар молнии в утпшку, выжег матплату видеокарту монитор и бп, процессор и винты остались живы,
с другой стороны мне известен случай на своём железе небольшая искра на заземлении вызвала порчу информации на винчестре без выхода из строя самого железа.
с другой стороны мне известен случай на своём железе небольшая искра на заземлении вызвала порчу информации на винчестре без выхода из строя самого железа.
Небось коаксиал еще был?
У нас раза 3 за год молния ударяла — висела воздушка коаксиала, соединявшая 4 подъезда. Небольшая локалка.
Просто меняли сетевушки. А потом как-то молния попала неудачно, выгорела и сетевушка и видяшка и материнка как-то заглючила, что на ней интегрированная звуковая перестала работать.
Тогда купил 3-4 тупых хаба, с коаксиалом-аплинком и витой парой в комп, больше ничего кроме хаба не горело
У нас раза 3 за год молния ударяла — висела воздушка коаксиала, соединявшая 4 подъезда. Небольшая локалка.
Просто меняли сетевушки. А потом как-то молния попала неудачно, выгорела и сетевушка и видяшка и материнка как-то заглючила, что на ней интегрированная звуковая перестала работать.
Тогда купил 3-4 тупых хаба, с коаксиалом-аплинком и витой парой в комп, больше ничего кроме хаба не горело
Я так спалил 3 HDD и 1 SSD. Провод криво вставил и подал на них 12В
К сожалению, есть пример на личном опыте.
Стоял WD live duo в рейде по 3ТБ на диск. Сбойнул софт.
Упала разметка диска после того, как попытался примонтировать внешний диск через USB.
Частично данные потерялись, некоторые фотки затерты на половину изображения, некоторые вообще не читаются.
Вся структура каталогов естественно слетела. Названия слетели, даты создания файлов сохранились только у фоток.
Часть данных безвозвратно утрачены, так как после восстановления на харде стало чуть более 1.5тб вместо прежних 2.7.
От скачков все же можно бесперебойник поставить, а от человеческого фактора и ошибок софта никто не застрахован.
Стоял WD live duo в рейде по 3ТБ на диск. Сбойнул софт.
Упала разметка диска после того, как попытался примонтировать внешний диск через USB.
Частично данные потерялись, некоторые фотки затерты на половину изображения, некоторые вообще не читаются.
Вся структура каталогов естественно слетела. Названия слетели, даты создания файлов сохранились только у фоток.
Часть данных безвозвратно утрачены, так как после восстановления на харде стало чуть более 1.5тб вместо прежних 2.7.
От скачков все же можно бесперебойник поставить, а от человеческого фактора и ошибок софта никто не застрахован.
Довольно спорно.
Я бы сказал, что в большинстве случаев, для бэкапов рэйд не нужен вообще.
Рэйд обеспечивает бесперебойность работы.
В случае с хранилищем бэкапов бесперебойность работы не важна, данные меняются редко.
Поэтому для бэкапов оптимальней использовать не рэйд, а второй диск на который будет дублироваться информация с некоторой задержкой.
Я бы сказал, что в большинстве случаев, для бэкапов рэйд не нужен вообще.
Рэйд обеспечивает бесперебойность работы.
В случае с хранилищем бэкапов бесперебойность работы не важна, данные меняются редко.
Поэтому для бэкапов оптимальней использовать не рэйд, а второй диск на который будет дублироваться информация с некоторой задержкой.
Поддерживаю, потому, выбирая NAS с рейдом, я подумал, и выбрал 2 NAS'a без рейда (один у себя, один у родителей). Содержимое синхронизируется между ними и находятся они физически в разных локациях. Бывают случаи, что мрет raid-контроллер, запарывая информацию, само устройство тоже может дать дуба с тем же результатом, пожары/потопы и воров никто не отменял. И маленький криптоконтейнер в облаке)
Имею 4 диска WD Green по 3 Тб в компе, объединённых в BTRFS-RAID, итого 6 Тб места с контролем CRC, что оказалось очень важно. Смотрю логи — файло вроде лежит себе, нормально открывается, а CRC раз — и не сошёлся. Перед чтением прозрачно восстанавливается. Самое важное лежит ещё и в облаке. Ничего не шифрую, мне пофиг, что майор Моссада будет знать мой номер страхования.
Btrfs может испортить данные и RAID не поможет.
Был у меня однажды Btrfs в raid1. Через какое-то время, система начала намертво виснуть, предположительно при работе с btrfs. Потом подтвердил что именно при работе с btrfs. После такого зависания, перезагрузка только через reset. В итоге на btrfs образуются inode с ошибками, штатный дисколечитель может их только найти, но не исправить. Спец утилитой возможно удаление таких inode. Далее через какое-то время проблема повторяется. Новое ядро уже не виснет целиком, а подвешивает в состояние z только один процесс.
После нескольких таких итераций, раздел с btrfs перестал монтироваться. Восстановил всю или почти всю информацию через утилиты восстановления. Потом переформатировал в mdadm raid1 + ext4.
ядро rt.
Каких-либо сбоев или подвисаний, за исключением btrfs, в это время не было.
Был у меня однажды Btrfs в raid1. Через какое-то время, система начала намертво виснуть, предположительно при работе с btrfs. Потом подтвердил что именно при работе с btrfs. После такого зависания, перезагрузка только через reset. В итоге на btrfs образуются inode с ошибками, штатный дисколечитель может их только найти, но не исправить. Спец утилитой возможно удаление таких inode. Далее через какое-то время проблема повторяется. Новое ядро уже не виснет целиком, а подвешивает в состояние z только один процесс.
После нескольких таких итераций, раздел с btrfs перестал монтироваться. Восстановил всю или почти всю информацию через утилиты восстановления. Потом переформатировал в mdadm raid1 + ext4.
ядро rt.
Каких-либо сбоев или подвисаний, за исключением btrfs, в это время не было.
Ребята,
Рейд это не защита от потери данных, это защита от сбоев. Единичные случаи, когда основная функция рейд1 (продолжение работы в случае сбоя одного из дисков) не работает, не означает что им не нужно пользоваться.
Но нужно помнить, что бэкап данных — это бэкап, и если он сбойнет — у вас есть рабочая копия. Сбойнул бэкап — чиним бэкап, сбойнула рабочая копия — восстанавливаем рабочую копию. Главное чтобы было и то и другое, а лучше еще и третье.
Все делятся на тех, кто
* Не делает бэкапы
* Уже делает бэкапы
* Делает бэкапы и проверяет их целостность
Рейд это не защита от потери данных, это защита от сбоев. Единичные случаи, когда основная функция рейд1 (продолжение работы в случае сбоя одного из дисков) не работает, не означает что им не нужно пользоваться.
Но нужно помнить, что бэкап данных — это бэкап, и если он сбойнет — у вас есть рабочая копия. Сбойнул бэкап — чиним бэкап, сбойнула рабочая копия — восстанавливаем рабочую копию. Главное чтобы было и то и другое, а лучше еще и третье.
Все делятся на тех, кто
* Не делает бэкапы
* Уже делает бэкапы
* Делает бэкапы и проверяет их целостность
Raid не отменяет бэкап, как и наоборот.
Но чаще всего выходят из строя именно винчестеры, а не происходят какие-то сбои.
Т.е. raid неплохая защита рабочих данных (в бэкапе они обычно несколько устаревшие)
Также не все данные на столько ценны, что каждый раз их нужно записывать в бэкап. Иногда их можно восстановить после полной потери, на пример скачать. Но это долго и сложно. Тут как раз обычно спасает raid.
Но чаще всего выходят из строя именно винчестеры, а не происходят какие-то сбои.
Т.е. raid неплохая защита рабочих данных (в бэкапе они обычно несколько устаревшие)
Также не все данные на столько ценны, что каждый раз их нужно записывать в бэкап. Иногда их можно восстановить после полной потери, на пример скачать. Но это долго и сложно. Тут как раз обычно спасает raid.
А если, например, какой-то из дисков умрет не сразу, а постепенно? Например, начнут понемногу появляться bad блоки. Raid от этого спасет?
Битый винт будет релоцировать сектора, пока сможет, это скажется на общей производительности, и рейд тут поможет в том смысле, что вынимаете битый диск, и меняете. А пока вы его меняете, все работает на целом.
Нет, ну а если первый винт не заметит, что у него появился битый сектор и скопирует битые данные на второй винт?
Какой первый винт?
Данные в зеркале копируются не с винта на винт, а контроллер пишет сразу на два винта, независимо.
Кроме того, вы начинаете ударяться в такие редкие проблемы, которые практически не встречаются. Типа как magic numbers для CD дисков.
Данные в зеркале копируются не с винта на винт, а контроллер пишет сразу на два винта, независимо.
Кроме того, вы начинаете ударяться в такие редкие проблемы, которые практически не встречаются. Типа как magic numbers для CD дисков.
Ну предположим, есть большой документ, в котором случайно повредился один сектор из-за bad блока на диске. Мы этот документ открыли, изменили, записали. Контроллер решил, что нужно скопировать этот документ на 2 диска, в результате мы получаем 2 поврежденных документа. Поэтому интересно узнать, отслеживает ли контроллер каким-то образом такую ситуацию, или такая ситуация не может случиться по каким-то другим причинам?
По поводу редких проблем, какие проблемы Вы называете редкими? Если имеются в виду битые сектора, то, мне кажется, не такая уж и редкая это проблема. По крайней мере, на своем жд я битые сектора получал.
Как по мне, наверное даже страшнее получить порченные данные и не узнать об этом, чем испортить данные и узнать об этом сразу.
По поводу редких проблем, какие проблемы Вы называете редкими? Если имеются в виду битые сектора, то, мне кажется, не такая уж и редкая это проблема. По крайней мере, на своем жд я битые сектора получал.
Как по мне, наверное даже страшнее получить порченные данные и не узнать об этом, чем испортить данные и узнать об этом сразу.
А о каком рейде речь? dmraid читает как есть, а вот btrfs имеет контрольную сумму на каждый файл, прочитает второй диск и найдёт правильную копию. Затем молча восстановит первый файл тоже. За это и любим, хотя он самый медленный из всех.
«Ну предположим, есть большой документ, в котором случайно повредился один сектор из-за bad блока на диске. Мы этот документ открыли, изменили, записали.»
То есть, открыв документ, вы не заметили что он кривой?
Если это не многостраничный plaintext, в котором вы не долистали до битого участка, то любой Word вам скажет, что document is corrupted уже на момент чтения. Либо документ прочитается с целого винчестера, а на битом этот сектор пометится как bad и не будет считан.
Битые сектора и некорректный ECC код — весьма разные вещи. Сектор либо может быть прочитан, либо не может — за этим следит контроллер жесткого диска. Чтобы у вас повредился ECC, чтобы контроллер диска этого не заметил, чтобы этого не заметила программа, работающая с документом — все три ошибки уже представляют собой невероятные случаи, которые могут произойти с очень редким шансом. Но чтобы все три сразу — …
То есть, открыв документ, вы не заметили что он кривой?
Если это не многостраничный plaintext, в котором вы не долистали до битого участка, то любой Word вам скажет, что document is corrupted уже на момент чтения. Либо документ прочитается с целого винчестера, а на битом этот сектор пометится как bad и не будет считан.
Битые сектора и некорректный ECC код — весьма разные вещи. Сектор либо может быть прочитан, либо не может — за этим следит контроллер жесткого диска. Чтобы у вас повредился ECC, чтобы контроллер диска этого не заметил, чтобы этого не заметила программа, работающая с документом — все три ошибки уже представляют собой невероятные случаи, которые могут произойти с очень редким шансом. Но чтобы все три сразу — …
Такое если и случится, то очень редко.
Скорее при каких-то странных обстоятельствах вроде работающий винчестер выпадет из рейда. Это может как раз говорить о том, что с этим винчестером что-то не так, хотя он еще не умер.
Также для проверки такого состояния, иногда запускается синхронизация дисков в raid. Исправить подобную ошибку вряд ли сумеет, но найдет точно.
Скорее при каких-то странных обстоятельствах вроде работающий винчестер выпадет из рейда. Это может как раз говорить о том, что с этим винчестером что-то не так, хотя он еще не умер.
Также для проверки такого состояния, иногда запускается синхронизация дисков в raid. Исправить подобную ошибку вряд ли сумеет, но найдет точно.
Человек на работе случайно сделал dd на диск с данными. Без всяких рейдов. Переписал первые несколько гигабайт образом другой файловой системы, потом нажал CTRL+C. И ничего, я штатным btrfs-tools всё поправил, пропали только затёртые файлы, остальные сохранились вместе с именами и путями. Было это осенью 2015 на debian testing. А ваши злоключения в каком веке случились?
Хороните молодого.
BTRFS для бэкапов? Вы серьезно? Это максимально сырой experimental без адекватно работающих средств восстановления.
Уже наступал на грабли. Никому не советую. Разлетается как рейд так и просто ФС в клочья и ничем уже не собрать.
BTRFS для бэкапов? Вы серьезно? Это максимально сырой experimental без адекватно работающих средств восстановления.
Уже наступал на грабли. Никому не советую. Разлетается как рейд так и просто ФС в клочья и ничем уже не собрать.
Вот это я вообще обожаю. Если при релизе сказать «Ребят, мы тут за недельку сбацали ФС, всё работает, пользуйтесь все!» — то это сразу надёжный продукт, а если честно признаться «Вот тут и тут ещё сыровато, вот этим пока не пользуйтесь, и вообще, не забывайте бекапить!» — то это уже 10 лет «максимально сырой experimental»?
Миром IT правят маркетологи.
Миром IT правят маркетологи.
4-ый год использую WD MyCloud на 4 ТБ, проблем не замечал. Софтовый диагност, через веб морду, всегда радостно рапортует о хорошем состоянии накопителя. После данной статьи задумался о замене MyCloud на такой же, только двух дисковый RAID.
Я делаю раз в полгода бэкап системного ссд (гигов 30-40), остальные некритичные данные храню на 4 ТБ дисках.
Докупаю новые когда старые забиваются.
Бэкап этих данных обошелся бы слишком дорого, сгорят так сгорят. Судьба значит такая.
Докупаю новые когда старые забиваются.
Бэкап этих данных обошелся бы слишком дорого, сгорят так сгорят. Судьба значит такая.
У меня NAS с RAID на два диска, плюс бекапы в OneDrive (1tb) и на Amazon Cloud (фотографии бесплатно в любом количестве). Хранить бекапы только локально у себя в шкафу не спасет в случае пожара или ограбления…
линейная скорость записи и чтения информации расположенной в начале диска, значительно выше.
Да, был даже такой подход к ускорению дисков в серверах: задействовать из всей поверхности диска только часть, дающую достаточно высокое быстродействие. Выгода была в цене дисков (SSD все еще не сильно дешевы), так что надо хорошенько все посчитать, но сама идея хороша. Плюс, на самый крайний случай, у нас еще остается неиспользованная часть диска, а ей можно найти применение самые разные.
Скажем, разбить диск на два раздела, один в быстрой части поверхности, другой в медленной. Собрать из «первых» разделов всех дисков один том хранения, из вторых — другой. На первом томе держать данные, которые требуют быстроты, на второй делать бекап (конечно, понимая, что оба раздела каждого диска физически делят один носитель, так что с умом их нагружать). Точнее, конечно, из части дисков делаем тома быстрый1 и медленный1, из второй части дисков — быстрый2 и медленный2. А бекапы, конечно, гоним «перекрестно» — с быстрый1 на медленный2 и с быстрый2 на медленный1.
Как контролировать целостность всех файлов на жестком диске (или хотя бы в выбранных директориях) по чексумам без применения ультрасовременных файловых систем и рейда? С расписаниями, отчетами, вот это все. В случае чего, чтобы просто руками со второго устройства перетащить битый файл. Linux, x86, ARM, FS ext3.
хороший вопрос. И то же самое интересует для виндоус.
под виндовсом 8 10 2012(r2) есть ReFS
если операционка обнаружит факап то восстановит сбойный файл из загашника
вариант для конченых извращенцев
сделать 3 (можно и больше для уменьшения накладных расходов) VHD файла и слепить из них raid-5 в случае если какой-то сектор окажется повреждённым то это будет выяснено и восстановлено.
D:\>format /fs:refs /q /i:enable
если операционка обнаружит факап то восстановит сбойный файл из загашника
вариант для конченых извращенцев
сделать 3 (можно и больше для уменьшения накладных расходов) VHD файла и слепить из них raid-5 в случае если какой-то сектор окажется повреждённым то это будет выяснено и восстановлено.
Можно любой велосипед написать, который будет генерировать чексуммы для выбранных вами файлов, и сравнивать потом отчеты.
Но проблема заключается в том, что файлы — меняются, список файлов — меняется.
То, что вы проверили пару терабайт файлов убедились, что они цельные и записали чексуммы, не поможет вам просто посмотреть на чексуммы и сказать что все окей — нужно заново проверять пару терабайт файлов, и сравнивать с чексуммами.
Поэтому не совсем понятно, какая у вас стоит задача.
Но проблема заключается в том, что файлы — меняются, список файлов — меняется.
То, что вы проверили пару терабайт файлов убедились, что они цельные и записали чексуммы, не поможет вам просто посмотреть на чексуммы и сказать что все окей — нужно заново проверять пару терабайт файлов, и сравнивать с чексуммами.
Поэтому не совсем понятно, какая у вас стоит задача.
Ну люди вон вручную на 5 бэкапов под пивко файлы кидают, почему бы под пивко чексуммы не считать?
Именно так. Один раз пройтись по всей выбранной директории/логическому диску, выдать таблицу (типа csv) в формате файл-чексумма. Поставить в крон. Через неделю при проходе сделать такую же таблицу, а далее, сравнить её с предыдущей (если предыдущая есть). Если файл (ключ) одинаковый, но отличается его значение (чексумма), то смотрим дату изменения. Если изменений не было, то генерируем отчет и помечаем данный файл как битый. Храним 2 таблицы — за текущий прогон и за предыдущий.
На двух компьютерах я установил синхронизацию через программу syncthing. Второй компьютер стоит у родителей, синхронизация через интернет, статического ip адреса не требуется. Перекачивал даже террабайтные каталоги, постоянно храню и обновляю сотни гигабайт.
Плюсы:
— территориально удаленные копии;
— всё работает само по себе;
— настраивается, чтобы второй пользователь не мог удалять ваши файлы (он удалит, они перезакачаются).
Минусы:
— требователен к процессору (считает md5, у меня i5-2500);
— нет шифрования (сами шифруйте);
— сложный для моего понимания веб-интерфейс.
Плюсы:
— территориально удаленные копии;
— всё работает само по себе;
— настраивается, чтобы второй пользователь не мог удалять ваши файлы (он удалит, они перезакачаются).
Минусы:
— требователен к процессору (считает md5, у меня i5-2500);
— нет шифрования (сами шифруйте);
— сложный для моего понимания веб-интерфейс.
Посмотрите ветку «Домашний бэкап» на forum.ixbt.com/topic.cgi?id=11:37198 там и экспертов хватает, и примеров решения подобной задачи.
Сейчас можно недорого и быстро собрать NAS самому, даже крайне бюджетная платформа даст большие возможности, благодаря развитию файловых систем, таких, как ZFS, можно дома получить контрольные суммы, проверку целостности данных, снапшоты 'из коробки'. Установка и настройка Nas4Free, FreeNAS расписаны по шагам. Себе делал, руководствуясь 2gusia.livejournal.com
Интересная и полезная тема, спасибо.
Как насчет того, чтобы резервный жесткий диск для бэкапа данных воткнуть физически в компьютер, подключить к sata и питанию, но через bios «выключить» этот sata-порт? будет ли он «работать» и тратить ресурс?
По необходимости раз в N дней включать его через биос, делать бэкап, проверять данные и выключать.
Все-таки хранить диск «на полке» и втыкать в комп по необходимости — лениво и только лишний риск уронить.
Как ни крути, думаю, 90% данных у домашних пользователе — это таки фотографии.
Организация NAS в качестве бэкапа может быть удобна только для тех, кто хочет бэкапить данные с устройств, находящихся в сети (телефоны, планшеты и т.д.).
Если бэкапить данные с компа — то проще к компу и подключить, разве нет?
Как насчет того, чтобы резервный жесткий диск для бэкапа данных воткнуть физически в компьютер, подключить к sata и питанию, но через bios «выключить» этот sata-порт? будет ли он «работать» и тратить ресурс?
По необходимости раз в N дней включать его через биос, делать бэкап, проверять данные и выключать.
Все-таки хранить диск «на полке» и втыкать в комп по необходимости — лениво и только лишний риск уронить.
Как ни крути, думаю, 90% данных у домашних пользователе — это таки фотографии.
Организация NAS в качестве бэкапа может быть удобна только для тех, кто хочет бэкапить данные с устройств, находящихся в сети (телефоны, планшеты и т.д.).
Если бэкапить данные с компа — то проще к компу и подключить, разве нет?
А перегружать комп и лазить в биос, не лениво? У меня комп перегружался последний раз, когда электричество отрубили на 4 часа. То есть от силы пару раз в год. Гораздо проще usb винт подключить. Если опасаетесь уронить — прикрутите внешний USB диск, где-то рядом с компом и просто USB кабель втыкайте-вытыкайте.
Для полной автоматизации — NAS или пользуйтесь облаками — всякими яндекс дисками, гуглдрайвами — для подавляющего большинства, объемов там хватает.
Для полной автоматизации — NAS или пользуйтесь облаками — всякими яндекс дисками, гуглдрайвами — для подавляющего большинства, объемов там хватает.
Купите карман в корпус (Mobile Rack) т.к. включение и выключение питания самые не хорошие процессы. HDD выключен в БИОС, но питание подается при каждом включении компьютера и он все равно работает — тут только выдергивать из него разъемы, когда он не нужен и пусть стоит в корпусе. Либо «карман» — там отключение кнопкой.
К этому можно еще добавить, что первыми должны размагнититься низкоуровневые разметки дорожек и секторов
вроде как даже они сильнее намагничены
вроде как даже они сильнее намагничены
Они размечаются теми же самыми головками, на той же самой поверхности, потребляя ту же самую энергию.
Даже если там пройтись 10-20 раз по тому же месту, особого разницы не будет.
Даже если там пройтись 10-20 раз по тому же месту, особого разницы не будет.
не могу точно сказать за давностью, но казалось, что видел где то осциллограммы где разметка выделялась
это было давно, сейчас разметку выполняют на заводе специальной машиной
https://habrahabr.ru/company/neuronspace/blog/254671/
На пластину жесткого диска с помощью шприца наносится пара капель коллоидной суспензии частиц Fe2O3. Затем с помощью специального покровного стекла суспензия размазывается тонким слоем по ее поверхности, на которой в отраженном свете проявляется магнитный контраст. Его, в принципе, достаточно, чтобы даже невооруженным взглядом оценить наличие или отсутствие информации — на рисунке четко видны сервометки, разделяющие диск на сектора.
При 800-кратном увеличении оптического микроскопа становятся четко различимы отдельные сервометки, несколько хуже выделяются дорожки с данными, записанные более слабым полем
https://habrahabr.ru/company/neuronspace/blog/254671/
У меня все важное и накопленное непосильным трудом :) автоматически бэкапится на ноутбуки жены и дочери и в 2 облака. 5 копий, думаю, надежно будет…
Старая. но актуальная статья.
Что-то сам подумал о NAS, но не о готовой коробке. Была лишняя лицензия L4 на RouterOS x86, поднял систему на уже не самой молодой материнке с J5005 камнем и 8 Гб оперативки, чего для нетребовательной системе с огромным запасом. ROS развивается, средств для работы с дисками в ней хватает. Все же операционная система как-никак. Поднял там SMB шару на внутреннюю сеть, туда всё и скидываю теперь. Попутно благодаря поддержке Docker контейнеров запустил там qbittorrent для раздач, при этом там запущен еще и HomeAssistant. В новых версиях ROS можно пробрасывать любое устройство в контейнер, так что подключил к нему Zigbee адаптер, что есть гуд.
А вот с этого диска "бэкаплю" нужные папки с данными уже на оффлайн-диски, просто подключаю к ПК в док-станцию, да сливаю всё. Дисков с работы списано несколько штук, уже с переназначенными секторами, но важных данных у меня не слишком много (едва на полтерабайта наберется), и дублирование на несколько дисков, думаю, спасает. Диски включаются попеременно раз в полмесяца, так что старт-стоп нагрузка на механику тоже не особо сильная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как долго или где быстро хранить информацию на диске