насколько я понимаю идею совр. компьютерной архитектуры - все компоненты имеют какой-то механизм текущей проверки правильности работы: процессор, основная память, жесткий диск, сетевое устойство и т.д.
Для того, чтобы быть уверенной в корректности работы своего "скелета" ОС регулярно считывает и отслеживает данные об этих компонентах, и всё это происходит на аппаратном уровне, т.е. ОС считывает специальные данные с каждого устройства.
Кроме этого, всегда "by design" пытаются обнаружить не ВСЕ возможные сбои, а НАИБОЛЕЕ возможные и случавшиеся.
O каждом компоненте расписать тут можно свиток, напр., в серверной аппаратуре используется "дублированная память", когда для получения N байтов данных испольуется в 2 раза больше модулей памяти, и контроллер памяти аппаратно реализует какой-то механизм обнаружения и починки ошибок в памяти (напр. ECC)
у каждого из этих механизмов - некоторые разные параметры и принципы работы, всё тоже из-за того, что каждый компонент устроен по-разному, и подвержен различным рискам.
жесткие диски тоже имеют механизмы обнаружения и даже предупреждения неполадок. Одна из технологий - http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_SMART
всё ПО на уровне ОС исходит из принципа "всё работает, пока мне не известно обратное" (это не цитата)
для узнавания, что есть обратное есть несколько "стратегических" решений.
У каждого компьютерного компонента есть разные параметры надёжности вписанные в его документацию, напр. http://en.wikipedia.org/wiki/MTBF. При планировке информационной системы в случаях серьёзных затрат от простоя аппаратуры берётся в счет профилактической замены аппаратуры ДО дохождения до этого MTBF.
Кроме этого все эти параметры сравнивают с "операционными условиями".
напр. у большинства компонентов эти условия - какой-то диапазон температуры, атмос. давления, чистоты воздуха и влажности.
Если поместить аппаратуру в один из "экстримов" этих диапазонов - легко понять, что MTBF укоротится.
Поэтому напр. в датацентрах, обычно специальное кондиционирование воздуха - очистка, просушка и охлаждение до 17-23 (в зависимости от "уличной температуры", чем жарче климат на улице - тем ниже держат этот диапазон)
Также, в организациях с тем высоким риском используют специальное "супернадёжное" оборудование, и накладывают на них слоих "высокой доступности", и различные механизмы защиты от конкретных сбоев:- от проблем электро питания - UPS сеть с генератором и двойными аккумуляторами.
- от проблем с воздухом (температура, влажность, чистота) - система кондиционирования, нередко на основе жидкого охлаждения, с дублированием, и с датчиками воздуха внутри помещения с обратной связью к автономной сети и сообщениями дежурному
- 24 часовое дежурство в контрольной комнате с методическим просмотром метрик
- данные хранят на системах RAID различного уровня с различными слоями дублирования, обычно пользуются интегрированными решениями, всякими там NAS - вроде EMC, и выше. эти системы не нужно бэкапить - у них это происходит внутри само собой, и делается это на разных уровнях с частотой в несколько раз в минуту (snapshots). даже замена дисков происходит их персоналом, регулярно.
- долгосрочные контракты поддержки оборудования с заведомо оговорённым временем на реакцию/решение, напр. контракт по условиям NBD - next business day. т.е. реакция будет не позже чем до сл. рабочего дня.
- дублирование наиболее критических сервисов и узлов практически простаивающих большинство времени, пока они не понадобились (redundancy -> high availability)
Это неполный список, и я умышленно вообще не затронул тему резервного копирования, по чьей-то просьбе.
Внимательный читатель заметит, что каждый пункт - стоит $$$
стратегия - какое из всех решений использовать, а каким пренебречь - решение серьёзное, которое может и сэкономить, и погубить. Но главное - это всё решается.
Далее, к корню:
Я понимаю, что вы вдались в эту тему по причине огромных неприятностей причиненных вам из-за какого-то случая сопряженного с потерей данных. Я не берусь быть "учителем", и т.д, и возможно то, что я пишу сейчас - брутально. Но это соответствует действительности.
То, что вы спросили сам вопрос: "как этого можно избежать в будущем?" - это очень хорошо.
а вот то, что вы ограниченили свой вопрос дополнением до
"как этого можно избежать в будущем посредством только ОС линукс?"
подчеркивает, что вы идёте по принципу "и рыбку съесть, и денег не заплатить".
это конечно идея неплохая, но иногда - нереализуемая:
только программным путём, причем без поддержки самой аппаратуры на "железном" уровне каких-то механизмов текущего мониторинга и может даже "предсказания" сбоев, этих сбоев не избежать.
Кроме того, вы (как и большинство других хомо-сапиенов) используете компьютер для работы, т.е. для получения прибыли.
Так отнеситесь к бизнесу серьёзно: есть доход, есть и текущие расходы.
Не брать в счёт тех. сбои при полном отсутствии решения проблемы сбоя - несло в себе довольно легко просчитываемый риск сбоя.
И кто это не взял в счет - не важно уже. Главное - вынести из этого урок на будущее, а не травму (т.е. неосмысленный подсознательный страх)
В некоторых маленьких фирмах живут так: да, если мы простаиваем, то простой нам стоит $$$.
но предупреждение этого простоя мы себе позволить не можем, т.к. он нам будет стоить $$$$.
Значит мы сознательно идём на риск, и не удивляемся/пугаемся если он реализуется.
Это тоже легитимный, по-моему бизнес-подход.
(Конечно им лучше не афишировать, а вписать его в соглашение об услугах маленьким шрифтом  )
Удачи.
С.У.В., и ИМХО.
P.S.
В принципе всё, что железо не может делать - программы не смогут этим железом сделать тоже, т.к. программы всего лишь командуют железом посредством дачей "инструкций", которые это железо "умеет" выполнять.
т.е. практически любой функционал, кроме широкого-системного-статистического, должен быть поддерживаем аппаратно.
|
)