Здравствуйте, cppguard, Вы писали:
C>Всю сознательную жизнь считал, что можно создать RAID1, RAID5 и т.д. и хранить там данные, которые очень важны. Да, от взрыва серверной не спасёт, но пока сервер работает исправно, данные должны быть в безопасности. И вот настал момент, когда я озаботился созданием NAS, стал курить мануалы про RAID, ZFS и прочее. Что же мы имеем? Аппаратный RAID вообще лучше не использовать, потому что контроллер — слабое место, а с новым может и не завестись. Есть mdraid, но при замене HDD в массиве на много TB операция восстановления может затянуться. Есть ZFS, но там какие-то вопросы со стабильностью. Если конкретно, то я думал создать RAIDZ1, чтобы иметь возможность спокойно "терять" один диск, но везде пишут, что resurface в RAIDZ1 это опасная операция. Ладно, возвращаемся к обычным зеркалам, параллельно смотрим в копилочку и думаем про RAID6/RAIDZ2, и тут нас добивают — "write hole", причём эта проблема может ещё и долго спать прежде, чем будет обнаружена порча данных.
C>Существует вообще способ организовать хранение данных и не париться?
Мне кажется, что это здесь уже было. А распечатать на принтере ни кто не предлагал?
Программа – это мысли спрессованные в код
Re[2]: Надёжный способ хранения данных без облаков
L.K.:
LK>+ ручной бэкап на офлайновый носитель (карманный SSD).
SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD.
V_>Вышеописанных проблем не видел, хотя все это крутится уже лет 10 в разных кофигурациях:
Представьте контроллер эту самую "foreign configuration" случайно испортит или не так поймёт и испортит
И... он больше не включится
И дальше вы сами ничего сделать не сможете. Придётся идти к специалистам, платить деньги
А было бы это зеркало, просто подцепили бы один из дисков к компу и скопировали файлы
При том что зеркало для вашего кейса предлагает ровно такую же функциональность — при выходе одного диска из строя, его можно заменить на новый
RAID-5 имеет смысл только если вы хотите из нескольких дисков маленького объёма сделать себе большой
Здравствуйте, TailWind, Вы писали: V_>>Вышеописанных проблем не видел, хотя все это крутится уже лет 10 в разных кофигурациях:
TW>Представьте контроллер эту самую "foreign configuration" случайно испортит или не так поймёт и испортит TW>И... он больше не включится
Я не люблю представлять, я протестировал на разных конфигурациях до копирования данных.
В любом случае, это энтерпрайз железо. Старое, но энтерпрайз, там несколько другие стандарты.
Плюс всякие Patrol read, consistency check и прочее, по расписанию в фоновом режиме из контроллера. Можно хоть ОС переустанавливать в процессе этих операций.
В наихудшем случае есть еще облачный бэкап.
TW>При том что зеркало для вашего кейса предлагает ровно такую же функциональность — при выходе одного диска из строя, его можно заменить на новый TW>RAID-5 имеет смысл только если вы хотите из нескольких дисков маленького объёма сделать себе большой
Это RAID-0.
RAID-5 и 6 допускают выход одного или 2-х дисков, произвольного из массива
Re[6]: Надёжный способ хранения данных без облаков
BB>>SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD. S>это точно правда ? S>у меня есть ssd которые я не использовал 2 года и данные целые
Хорошая постановка вопроса
Достоверно известно, что ячейки памяти деградируют от количества циклов перезаписи (стирания)
Причём изначально у памяти только с завода уже есть плохие ячейки
Они выдают случайные значения во время чтения
Но данные будут целы так как защищены ECC, который может исправить N неверных битов
Соответственно если накопится сбойных битов больше N, то сектор прочитать не получится
Хотя это и не приведёт к выходу из строя всего SSD
Есть качество памяти
У хорошей N превышает количество сбойных ячеек в несколько раз
У плохой всего лишь немного больше — быстрее сдохнет
А дальше надо строить модель электрическую
Чем больше циклов перезаписи, тем быстрее ячейка будет менять состояние с 1 на 0?
А какое это время у нормальных ячеек? год, два, десять, сто лет?
А у часто перезаписанных? Насколько часто перезаписанных?
Короче, факт имеет место быть
Но тестов как всегда никто не делал )
Зачеркнуть тоже
Если он сломается, вы сами не сможете скачать с него данные
А с зеркального рейда сможете. Причём у вас будет два дубликата
C>думаем про RAID6/RAIDZ2
тем более не сможете
если с raid-5 вы возможно и разберётесь сами, то с raid-6 точно нет
А за бабло в сервис центре это будет очень дорого. Оно вам надо?
C>Существует вообще способ организовать хранение данных и не париться?
NAS — внутри raid зеркало
Раз в неделю туда делаем синхранизацию всего рабочего диска
Каждый день делаем архив самой главной рабочей папки с текущими проектами и кладём на другой диск компа
Храним архивы за последнюю неделю
Если вы случайно сами удалите свой файл, или измените код так что уже вернуть обратно нельзя, можно взять этот файл из вчерашнего архива
_>windows soft raid, mirror disks
У меня как то было зеркало на рабочем компе
В один прекрасный день SATA кабель отвалился у одного из дисков
Комп загрузился и работал как ни в чём не бывало
Знаете что это значит? Что диски перестали быть синхронными
Больше я на рабочем компе рейдов не делал
sergey2b:
BB>>Известно, что SSD деградирует, находясь в оффлайне. S>это точно правда ? S>у меня есть ssd которые я не использовал 2 года и данные целые
Я написал, что деградируют, а не гарантированно дохнут.
Всю сознательную жизнь считал, что можно создать RAID1, RAID5 и т.д. и хранить там данные, которые очень важны. Да, от взрыва серверной не спасёт, но пока сервер работает исправно, данные должны быть в безопасности. И вот настал момент, когда я озаботился созданием NAS, стал курить мануалы про RAID, ZFS и прочее. Что же мы имеем? Аппаратный RAID вообще лучше не использовать, потому что контроллер — слабое место, а с новым может и не завестись. Есть mdraid, но при замене HDD в массиве на много TB операция восстановления может затянуться. Есть ZFS, но там какие-то вопросы со стабильностью. Если конкретно, то я думал создать RAIDZ1, чтобы иметь возможность спокойно "терять" один диск, но везде пишут, что resurface в RAIDZ1 это опасная операция. Ладно, возвращаемся к обычным зеркалам, параллельно смотрим в копилочку и думаем про RAID6/RAIDZ2, и тут нас добивают — "write hole", причём эта проблема может ещё и долго спать прежде, чем будет обнаружена порча данных.
Существует вообще способ организовать хранение данных и не париться?
Re[4]: Надёжный способ хранения данных без облаков
Здравствуйте, TailWind, Вы писали:
TW>Даже имея все живые диски, но сломанный контроллер, вы не сможете без подготовки сами скачать данные TW>Вам нужно будет определить размер блока (там стандартные штук пять) TW>Определить порядок дисков TW>И алгоритм замешивания блоков TW>Есть проги, которые вероятно вы можете скачать в интернете TW>Но без подготовки это не тот геморрой который вам нужен, по сравнению с тем, если у вас сломается NAS с зеркалом внутри и вам нужно будет открыть его любой программой, которая понимает файловую систему linux
Я использую Avago (LSI, Broadcom) .10-и летней давности. 92728i, 9260. Их навалом на eBay. RAID 5 и RAID6. SAS и SATA диски
Вышеописанных проблем не видел, хотя все это крутится уже лет 10 в разных кофигурациях:
1. Другой контроллер определяет конфигурацию с дисков и предлагает import foreign configuration. Даже если другая модель. В том числе если дисков не хватает. Понятное дело, что RAID будет degraded или совсем не рабочий если, скажем, нет 2-х дисков в RAID5. При добавлении автоматом достраивает на фоне свой массив.
2. Диски (порядок) можно произвольно перепутать — определяет без проблем
Все это дело без прог, в BIOS. Единственный момент, что не все контроллеры работают с 4K дисками, большей несовместимости я не видел.
Естественно, я еще использую облачный бэкап поверх всего этого.
Да, по самим дискам. На рабочей станции использую массив из 2Tb 2.5 SATA
На домашнем сервере — SAS БУ. Сами диски энтерпрайзного уровня по моему опыту оказываются более надежные чем новые потребительского.
Если полетит — заказал, заменил и все дела. Уже лет 5 про-запас лежит один SAS, чтобы сразу поменять.
C>Да, от взрыва серверной не спасёт, но пока сервер работает исправно, данные должны быть в безопасности.
Следует начать с модели угроз/рисков, от которых планируется строить защиту.
Из того, что ты пишешь, например следует, что от вирусов-шифровальщиков ты не предполагаешь защищаться.
C>Всю сознательную жизнь считал, что можно создать RAID1, RAID5 и т.д. и хранить там данные, которые очень важны. Да, от взрыва серверной не спасёт, но пока сервер работает исправно, данные должны быть в безопасности. И вот настал момент, когда я озаботился созданием NAS, стал курить мануалы про RAID, ZFS и прочее. Что же мы имеем? Аппаратный RAID вообще лучше не использовать, потому что контроллер — слабое место, а с новым может и не завестись.
ну в целом я видел как это реально работало
почему-то ломались именно диски, а не контроллеры
видимо, из-за того что диски активно использовались, а не были просто удобной заменой ленте
и рейд проблему решал
Re[5]: Надёжный способ хранения данных без облаков
Здравствуйте, Bill Baklushi, Вы писали:
BB>SSD деградируют всегда, за счет утечки заряда.
Если без питания лежат на полке. Время от времени втыкать в комп.
Re[4]: Надёжный способ хранения данных без облаков
M>>Не проще ли использовать готовое решение — VCS (subversion например) для таких целей? TW>Я бы послушал советы про это
хм, неожиданный вопрос (я предполагал, что с системами контроля версий/ревизий все тут в той или иной степени имели дело).
На всякий случай поясню, что я предлагаю VCS именно как инструмент работы с ревизиями рабочих данных в виде append-only истории (вместо ежедневного архивирования "главной рабочей папки").
А не средство backup`а.
Вышеупомянутый subversion сам по себе требует бэкапа (https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.backup).
Для репликации subversion репо есть штатные средства: https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.replication
(на на практике я их не использовал).
Re[4]: Надёжный способ хранения данных без облаков
TW>>Нет. Лучше размером поменьше A>Чем лучше? На большой диск поместится больше копий с нужной глубиной с разных систем. И вся его работа — принять этот файл. Раз в день и/или неделю, старое удалить.
Ну, представьте диск сдох и вам нужно поменять блок магнитных головок
Если не видели его никогда, посмотрите в google картинках
Допустим их 6. Это будет выглядеть как 3 пинцета таких, которые сами слипаются между собой, а вам нужно надеть их на диски
А если их всего две? Насколько проще работать с ними?
Вероятность успешной пересадки 2х головок выше, а поломки меньше
Если у вас заклинило моторчик у диска
Надо переставлять блины в новый корпус
Если вы сместите их друг относительно друга на несколько градусов, диск работать не будет
В то время как с одним блином таких проблем не будет
TW>>Да никто не будет следить за этим TW>>Даже за backup'ами все забывают следить A>Лень закрой дверь, да. Но планировщик может сам следить за появлением событий в журнале и вызывать действия. А там от уведомлений на почту до дёрганья дашборда состояния компании. Сейчас ещё в тележку модно слать.
А кто будет следить за тем, что планировщик работает?
А не перестал, по какой либо причине
Вот какую проблему я пытался описать
Re[2]: Надёжный способ хранения данных без облаков
Здравствуйте, m2user, Вы писали:
M>Следует начать с модели угроз/рисков, от которых планируется строить защиту.
Аппаратный или программный сбой в диске.
BB>SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD.
Cтарые-добрые HDD и так стоят в NAS. И как будто HDD не ломаются. А SSD бывает размером с usb-флешку, его можно постоянно носить в кармане, страхуясь от некоторых рисков (облако вдруг отключено, облачные бэкапы недоступны, а физический NAS в то же самое время сломался или сгорел в пожаре).
C>Существует вообще способ организовать хранение данных и не париться?
Автоматический бэкап на географически удаленный носитель. Потому что как бы ни был надежен твой личный сервер (или даже 3 сервера), один пожар в доме уничтожит все. Или наводнение. Или землетрясение. Или жена, или ребенок, или еще что угодно.
Re[4]: Надёжный способ хранения данных без облаков
L.K.:
BB>>SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD. LK>Cтарые-добрые HDD и так стоят в NAS. И как будто HDD не ломаются.
Те HDD, что стоят во включенном NAS деградируют за счет сил трения. Те, что лежат в тумбочке — нет.
SSD деградируют всегда, за счет утечки заряда.
LK>А SSD бывает размером с usb-флешку, его можно постоянно носить в кармане, страхуясь от некоторых рисков (облако вдруг отключено, облачные бэкапы недоступны, а физический NAS в то же самое время сломался или сгорел в пожаре).
На здоровье, одно другому не мешает. Небольшие важные данные можно носить с собой на флешке (или двух ). Большие бэкапы — на винте в тумбочке. Рабочие материалы — на NAS или на винте в компе. IMO.
Здравствуйте, cppguard, Вы писали:
C>Существует вообще способ организовать хранение данных и не париться?
Сделай RAID с тремя дисками, чтобы было 3 копии на каждом диске и нормально будет. Можешь отдельный диск использовать, все данные на нём будут, в крайнем случае. Если один диск сломается — у тебя есть ещё две копии, при восстановлении данных шанса потерять данные практически нет.
Просто помни, что не только взрыв в серверной бывает, ещё может быть скачок напряжения, могут попасться три диска из одной партии с одинаковым багом, которые одновременно сдохнут, много всякого в жизни бывает. Поэтому RAID не отменяет необходимость бэкапа. Но если иметь это в виду, то надёжность у рейда нормальная.
Хардварный рейд используют во-первых для производительности (к примеру там может быть DDR кеш с батарейкой, который даст и производительность и надёжность), во-вторых для идиотов, т.к. там всё максимально просто: диск сдох, лампочка рядом со слотом загорелась. Подошёл, нажал на кнопочку, вылез сломанный диск. Взял из шкафа новый диск, вставил его и ушёл дальше пить чай, хардварный рейд всё сам сделает. С софтварным рейдом надо заморачиваться. Но если ты айтишник, то ничего сложного там нет. Для домашних целей софтварный рейд предпочтительней, мне кажется.
Здравствуйте, cppguard, Вы писали:
C>Существует вообще способ организовать хранение данных и не париться?
Возьми Synology на 5 дисков минимум, настрой "raid," удовлетворяющий твои хотелки и боязни.
Ну, и помня, что NAS — это в первую очередь про Network-attached storage, а не про backup, настрой периодические резервные копии в облако, и в отдельный носитель, хранящийся отдельно в безопасном месте
Re[2]: Надёжный способ хранения данных без облаков
Здравствуйте, TailWind, Вы писали:
TW>Зачеркнуть тоже TW>Если он сломается, вы сами не сможете скачать с него данные TW>А с зеркального рейда сможете. Причём у вас будет два дубликата
О, вот это новость. Я думал, что RAID5 это то же зеркало, только ещё и есть диск с контрольными суммами. И если бы так, то при выходе одного из дисков из строя, как минимум, одна копия остаётся целой. Но когда я узнал, что без пересборки массива добавлять диски можно только в зеркало — задумался.
TW>NAS — внутри raid зеркало TW>Раз в неделю туда делаем синхранизацию всего рабочего диска
Так с "write hole" массив будет выглядеть здоровым, а данные будут испорчены. Или я неправильно понял суть проблемы?
Re[3]: Надёжный способ хранения данных без облаков
C>О, вот это новость. Я думал, что RAID5 это то же зеркало, только ещё и есть диск с контрольными суммами. И если бы так, то при выходе одного из дисков из строя, как минимум, одна копия остаётся целой. Но когда я узнал, что без пересборки массива добавлять диски можно только в зеркало — задумался.
О, Господи, нет конечно
Это даже близко не так
Пространство разбито на блоки
Допустим raid-5 из 3-х дисков
Значит будет два блока с данными и один с XOR этих данных между собой
И это пишется не так:
d0 d1 XOR
d2 d3 XOR
d4 d5 XOR
А порядок меняется местами:
d0 d1 XOR
d2 XOR d3
XOR d4 d5
Даже имея все живые диски, но сломанный контроллер, вы не сможете без подготовки сами скачать данные
Вам нужно будет определить размер блока (там стандартные штук пять)
Определить порядок дисков
И алгоритм замешивания блоков
Есть проги, которые вероятно вы можете скачать в интернете
Но без подготовки это не тот геморрой который вам нужен, по сравнению с тем, если у вас сломается NAS с зеркалом внутри и вам нужно будет открыть его любой программой, которая понимает файловую систему linux
TW>>NAS — внутри raid зеркало TW>>Раз в неделю туда делаем синхронизацию всего рабочего диска C>Так с "write hole" массив будет выглядеть здоровым, а данные будут испорчены. Или я неправильно понял суть проблемы?
Я не знаком с термином "write hole"
Но если вы имеете в виду, что один диск будет иметь немного более старую копию
Это не такая большая проблема
Если ваш основной комп выйдет из строя, NAS всё равно будет работать
Вы в штатном режиме скачаете данные
Если он тоже сломался. И диски в рейд-mirror у него оказались не синхронные
Ну выберите тот что лучше. Или с обоих что-то соберёте
Но это уже сценарий катастрофы. Когда сломалось всё
Ну хотите поставьте 1 диск без raid туда. Но мне два приятнее
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, cppguard, Вы писали:
C>>Существует вообще способ организовать хранение данных и не париться?
P>Возьми Synology на 5 дисков минимум, настрой "raid," удовлетворяющий твои хотелки и боязни.
P>Ну, и помня, что NAS — это в первую очередь про Network-attached storage, а не про backup, настрой периодические резервные копии в облако, и в отдельный носитель, хранящийся отдельно в безопасном месте
Купил в 2017 NAS QNAP на 4 диска за 20+ т.р., использовал как Media Server,
через лет 5 он перестал добавлять в хранилище файлы через свой интерфейс ,
как это все чинить ХЗ, я не линуксоид, сколько времени потребует разобраться не представляю.
Да и до того этот интерфейс был чрезвычайно корявый и неудобный.
сколько возьмет сервис за починку такого тоже не представляю, думаю очень много.
NAS стоит мертвым грузом. С виндой думаю как нибудь разобрался бы в таком случае.
Здравствуйте, cppguard, Вы писали:
C>Существует вообще способ организовать хранение данных и не париться?
Древние боги в преддверии катастрофы (прохождения массивного гравитационного объекта сквозь солнечную систему) тоже озаботились этой проблемой и решили сохранить информацию в бункерах на астероидах, определить их можно по искусственной круговой орбите, реплики находятся на разных расстояниях от солнца, при желании их можно найти в БД объектов солнечной системы НАСА.
Для надёжности был выбран и второй вариант реализации — хранение в виде самовоспоизводящегося кода ДНК у таких растений как пшеница (имеющей тройное ДНК явно искусственного происхождения), а также у человека, т.е. у искусственно созданных видов растений и животных, также при из проектировании боги заложили устойчивость к вредителям, если речь про пшеницу, или высокую степень размножаемости и волю к жизни, если речь про гомо сапиенс. Вопрос в поиске ключа расшифровки. Ключ расшифровки по идее тоже должен храниться в надёжных, самореплицируемых и устойчивых ко всем угрозам и рискам видах, по сути на виду. Мы его не видим, потому что в нас заложена искусственная слепота на предмет данного ключа. Выявление механизма этой слепоты может служить ключом к поиску ключа расшифровки. В общем, спроектировал один раз вид гомо сапиенс, они сами выживают тысячи лет, и париться не нужно. Для извлечения информации просто похищаешь ночью особь в тарелку, вычитываешь инфу во сне или под наркозом и утром возвращаешь особь обратно, как будто ничего и не было. А если нужно вычитать инфу с пшеницы, то специальным аппаратом вычитываешь, они правда оставляют следы на полях, но это незначительная полочка.
Более древние боги заложили свою информацию в ДНК жизни, этими фрагментами кишит вся планета, и париться не нужно.
Ещё более древние боги заложили информацию в неравномерности реликтового излучения вселенной. Тоже достаточно надёжный способ, уровень риска сопоставим с уровнем риска вселенной, т.е. максимально высокая надёжность. Заложил эту информацию один раз при большом взрыве и всё, дальше вселенная живёт, и париться не нужно до её тепловой смерти. Причем в данном случае сообщение не зашифрованои не закодировано, а представлено в виде рисунка, т.е. послания, понятного любому разуму во вселенной. Достаточно просто соединить линиями точки на карте реликтового излучения. Если вы сделаете это, то обомлеете. Вообще странно, что об этом не трубят во все трубы, возможно, кто-то очень не хочет, чтобы правда всплыла.
Подробнее см. работы Пенроуза и альтернативщиков типа Калмыкова.
Здравствуйте, swame, Вы писали:
S>Купил в 2017 NAS QNAP на 4 диска за 20+ т.р., использовал как Media Server, S>через лет 5 он перестал добавлять в хранилище файлы через свой интерфейс ,
И че, даже не попытался по ftp или по http в любом интернет броузере подцепиться напрямую по IP-шнику?
Чтоб понять это приложение/аддон Media Server'а поломалось или сам nas?
S>как это все чинить ХЗ, я не линуксоид, сколько времени потребует разобраться не представляю.
ТС, я так понял, вообще сам собирается nas поднимать, наверняка с простым интуитивно понятным интерфесом разберётся
Здравствуйте, TailWind, Вы писали:
TW>Комп загрузился и работал как ни в чём не бывало TW>Знаете что это значит? Что диски перестали быть синхронными
так нотификация сработает что рейд развалился. а собственно проблема в чем? старые данные то остались в целости и сохранности, вопрос только о тех, которые записаны с момента нотификации о развале зеркала до момента окончания синхронизации.
> Те HDD, что стоят во включенном NAS деградируют за счет сил трения. Те, что лежат в тумбочке — нет.
мои WD RED в режиме 24/7 отработали уже более 51 тысячи часов, полет нормальный.
Здравствуйте, paucity, Вы писали:
P>Здравствуйте, swame, Вы писали:
S>>Купил в 2017 NAS QNAP на 4 диска за 20+ т.р., использовал как Media Server, S>>через лет 5 он перестал добавлять в хранилище файлы через свой интерфейс ,
P>И че, даже не попытался по ftp или по http в любом интернет броузере подцепиться напрямую по IP-шнику?
P>Чтоб понять это приложение/аддон Media Server'а поломалось или сам nas?
Nas работает, медиасервер работает, не работает файловый менеджер на загрузку файлов на NAS.
S>>как это все чинить ХЗ, я не линуксоид, сколько времени потребует разобраться не представляю.
P>ТС, я так понял, вообще сам собирается nas поднимать, наверняка с простым интуитивно понятным интерфесом разберётся
Интерфейс то просто и понятный, только в нем то это не работает, то это.
И с этим всем надо ковыряться неопределенное количество времени.
Каждую неделю какие-то бесполезные обновления прилетают.
А ТС спрашивает как "не париться"
Здравствуйте, cppguard, Вы писали:
C>Всю сознательную жизнь считал, что можно создать RAID1, RAID5 и т.д. и хранить там данные, которые очень важны.
C>Существует вообще способ организовать хранение данных и не париться?
Самое эффективное — это скопировать на отдельные девайсы и хранить в обесточенном состоянии, так как обычно люди теряют данные если например вирус на комп подцепили и он все что есть зашифровал. Те же жесткие диски внешние, но хотябы раз в год их включать и тестить.
На самом компе естественно рейд1 из любых дисков, даже пусть ssd — для важной информации. Они стоят ничто, и чтобы 2 накрылось одновременно это невероятное событие (лучше брать из разных партий и разных магазинов... накрываются обычно те что были с проблемами и обычно в самые первые недели — бракованные или уронили контейнер при перевозке). Но для совместимости лучше брать одинаковые диски, вообщем в разных магазах и чуть со сдвигом по времени купить тот же девайс, ну а первый купленный жестко протестить пару недель, чтобы наработал на проблемы если есть. У SSD — там проблемы в одинаковых действиях, если в прошивке баги, то если 2 девайса напорятся на это одновременно, то рейда 1 как бы и небыло.
Рейд1 из 2.5" ноутбучных hdd — я предпочел другим вариантам (для хранения данных). Ноутбучные диски должны выдерживать удары, вообщем их делают более живучими. Они тихие, но увы естественно относительно медленные, но для сохранения данных скорее топ — с них еще и восстановить можно, обычно диски не убиваются что все потеряно(а с SSD обычно все потеряно).
Здравствуйте, Bill Baklushi, Вы писали:
BB>L.K.:
LK>>+ ручной бэкап на офлайновый носитель (карманный SSD). BB>SSD зачеркнуть. Известно, что SSD деградирует, находясь в оффлайне. Для этой цели лучше использовать старые добрые HDD.
это точно правда ?
у меня есть ssd которые я не использовал 2 года и данные целые
Re[5]: Надёжный способ хранения данных без облаков
BB>Я написал, что деградируют, а не гарантированно дохнут. BB>Инфа 100% Читал не раз и тут и на IXBT.
Цитата из datasheet на Sandisk NAND:
Data Retention
The data in memory might change after a certain amount of storage time. This is due to charge loss or charge gain. After block erasure and reprogramming, the block might become usable again.
Но это очень обтекаемо и непонятно насколько быстро
Нет графиков и таблиц для разного состояния изношенности ячейки
Здравствуйте, cppguard, Вы писали:
C>Существует вообще способ организовать хранение данных и не париться?
Существует.
Проработать сценарии восстановления после сбоев. Сколько есть времени на диагностику сбоя, на устранение и возврат в рабочее состояние. Запасные диски, контролеры, компьютеры, сервера. Исходить из того, что сбой произойдёт и разработать план конкретных действий с лимитами времени.
Делать резервные копии. Регулярно. В гарантированно консистентном состоянии. И на лету. Хранить их на дисках рядом (в этой же системе), специально диск для архивов купить. Архивация в локальной системе куда быстрее и эффективнее чем по сети. И параллельно сдвигать на соседние системы. Одна из схем — второй диск для бэкапов на каждой станции и асинхронный обмен между ними через сеть по планировщику. Суть в том, что одного хранилища бэкапов не достаточно. Но сильно лучше, чем ни одного. А на станциях всегда есть возможность воткнуть второй-третий диски.
Не жалеть денег на покупку дисков. Всегда лучше прикупить лишний диск "чтобы был". И размером побольше.
Следить за состоянием дисков (smart, журналы ОС) и своевременно реагировать на проявление проблем, не дожидаясь полного отказа системы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[2]: Надёжный способ хранения данных без облаков
Здравствуйте, TailWind, Вы писали:
TW>У меня как то было зеркало на рабочем компе TW>В один прекрасный день SATA кабель отвалился у одного из дисков TW>Комп загрузился и работал как ни в чём не бывало TW>Знаете что это значит? Что диски перестали быть синхронными TW>Больше я на рабочем компе рейдов не делал
И напрасно. Ребилд дисков после сбоя — стандартная операция. Хоть кабель, хоть поверхность и замена участника. В этом и смысл зеркала.
Даже виндовое программное зеркало ребилдится и синхронизирует данные без участия человека. Или, например, контролер intel onboard.
С появлением ssd смысл в рейде сильно нивелирован. Куда удобнее отдельные диски под разные задачи.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Re[2]: Надёжный способ хранения данных без облаков
A>Всегда лучше прикупить лишний диск "чтобы был". И размером побольше.
Нет. Лучше размером поменьше
Чтобы было поменьше головок, блинов
В идеале 1 блин
Проще найти такое в тонких дисках, если не знаешь как проверить
A>Следить за состоянием дисков (smart, журналы ОС)
Да никто не будет следить за этим
Даже за backup'ами все забывают следить
У меня настроено уведомление на email об успешном или не успешном backup'е
Так вот они одно время перестали приходить (я поменял пароль на сервер)
А я и не заметил
После этого я сделал к backup'у лампочки
После заверения backup запускался скрипт, который по http обращался на мой web server, где я часто бываю, и там взводился флажок, что backup успешен
Если он не взведён допустим неделю, загорается красная лампочка. Вот эта тема работала
Re[2]: Надёжный способ хранения данных без облаков
TW>Каждый день делаем архив самой главной рабочей папки с текущими проектами и кладём на другой диск компа TW>Храним архивы за последнюю неделю
Не проще ли использовать готовое решение — VCS (subversion например) для таких целей?
TW>Если вы случайно сами удалите свой файл, или измените код так что уже вернуть обратно нельзя, можно взять этот файл из вчерашнего архива
архив это тоже свой файл, в том смысле, что его можно случайно удалить. В этом преимущество использования VCS с неизменяемой обычным пользователем историей.
Re[3]: Надёжный способ хранения данных без облаков
Здравствуйте, TailWind, Вы писали:
TW>Нет. Лучше размером поменьше
Чем лучше? На большой диск поместится больше копий с нужной глубиной с разных систем. И вся его работа — принять этот файл. Раз в день и/или неделю, старое удалить.
TW>Да никто не будет следить за этим TW>Даже за backup'ами все забывают следить
Лень закрой дверь, да. Но планировщик может сам следить за появлением событий в журнале и вызывать действия. А там от уведомлений на почту до дёрганья дашборда состояния компании. Сейчас ещё в тележку модно слать.
TW>>Нет. Лучше размером поменьше A>Чем лучше? На большой диск поместится больше копий с нужной глубиной с разных систем. И вся его работа — принять этот файл. Раз в день и/или неделю, старое удалить.
Большой диск очевидно опасен тем, что при выходе его строя будет потеряно больше данных.
Поэтому я например больше 2TB не беру (а лучше 1TB).
Re[3]: Надёжный способ хранения данных без облаков
rm2>ну допустим проект на сотни гигов. картинки там, видеофайлы. как на это vcs отреагирует?
Для каждой ситуации свое решение. Есть и коммерческие VCS, рассчитанные на крупные медиафайлы, и subversion для этих целей тоже нередко используется.
Обычные документы (openoffice/pdf) и изображения (фото) я без проблем храню в SVN, но не в таких объемах (репо <10GB).
А распечатать на принтере ни кто не предлагал? 
