Пока хотябы один хард в рейде жив, рейд будет считаться полностью целым и никто ничего не заметит? Какие есть средства мониторинга?

>>35904
Собственно говоря одна из основных идей в отказоустойчивом рейде - делать так, чтобы при вылетании одного из винтов весь работающий на сервере софт продолжал работать так, словно бы и ничего не случилось. Заметить происшествие должны утилиты мониторинга массива и выдать соответствующее предупреждение.
Рейды бывают аппаратными и программными.
В первом случае работай с винтами занимается контроллер и предоставляет массив операционной системе как одно физическое устройство, для каждого контроллера как правило есть своя проприетарная утилита, которая может и не заработать на твоей ОС или на твоей версии ОС. Так же обновлять утилиты не особо спешат и из-за этого она может перестать работать со временем (например после обновления glibc). Без утилиты массив вполне работоспособен, но заметить отвалившийся винт можно только в биос и может быть контроллер выдаст тебе огромное красное сообщение об этом на экране при очередной перезагрузке. Самый страшный недостаток аппаратных рейдов - если у тебя умрет контроллер, то с данными в 80% случаев можно прощаться даже при абсолютно работоспособных винтах или выкладывать кругленькую сумму за их восстановление, поскольку формат у каждой серии контроллеров свой. Преимущества же - скорость работы, простота обслуживания и отсутствие нагрузки на процессор при чтении/записи.
Во втором случае заботу о контроле массива берет на себя операционка, предоставляя доступ как ко всему массиву, так и к каждому винту по отдельности (можно например SMART посмотреть). Преимущества - работает на любом железе, поддерживаемом ОС, винты могут находиться на разных контроллерах и даже иметь разные интерфейсы, да и не обязательно им быть винтами, тот же линукс позволяет строить рейд на любых блочных устройствах, хоть USB флешках, хоть дискетах. Массив можно довольно безболезненно переносить на другое железо, другой контроллер итд. Недостатки - париться с ним придется несколько больше и дольше, например если ты хочешь поставить систему на не первый рейд массив то /boot придется выносить за пределы массива, чтобы биос и загрузчик смогли запустить загрузчик, который смог бы найти и запустить ядро. Так же если ты используешь 5й или 6й рейд то при записи данных в массив или чтения из неполного массива контрольные суммы будут считаться на CPU, что несколько повысит его загрузку. Разница в производительности между программным и аппаратным рейдом конечно существует, но она как правило сводится к тому, что во втором случае используются дешевые контроллеры, которые сильней грузят прерываниями процессор. Чтение/запись же данных на винт куда медленней, чем производительность процессора при обсчете контрольных сумм.

Если говорить об программном рейде под линуксом, то для его управления существует утилита mdadm, которая так же занимается и мониторингом, если ее пустить в режим демона. В таком режиме при вываливании винта из массива она пришлет письмо с руганью. Просмотреть же за состоянием массивов можно так-же в /proc/mdstat. При создании массива с избытком происходит его ребилд, который приводит данные на винчестере к одному виду, копируя данные с одного на другой для первого и высчитывая контрольные суммы для 5го и 6го. По времени такая процедура как правило занимает несколько часов или даже дней, в зависимости от размера массива, размера винчестеров и скорости их работы. Во время ребилда с массивом уже можно полноценно работать. Так же ребилд массива происходит при замене одного из винчестеров, расширении массива, добавлении в массив нового винчестера, очень неудачном пропадании питания.
Если ставить / на рейд, то нужно позаботиться о том, чтобы он поднимался при загрузке. Как правило это сводиться к выставлении типов разделов с рейдом на винтах в fd (Linux Raid Autodetect), и ядро само подхватывает массив при загрузке. Если массив нестандартный или для инициализации требует проприетарные модули ядра, то понадобиться initrd, в котором массив будет подниматься уже через mdadm.
Еще к недостаткам всех raid массивов можно отнести то, что при использовании винтов разного размера, размер единицы массива будет размером самого маленького винта.

Теперь про бекапы.
Преимущество в том, что частично защищает от кривых ручек, например от rm -rf /. До тех пор пока не будет затерт бекап нормальных данных, их еще худо-бедно можно восстановить. Так же бекап может физически находиться на другом сервере, что при грамотном расположении может частично защитить данные в случае физической смерти оригинального сервера от пожара, наводнения, землетрясения, людей в масках и с автоматами, нашествия инопланетян.
Подходов к решению и их реализаций целая куча, не буду всех их описывать, остановлюсь на основных.
Самый простой - периодически копировать все на соседний винт, иногда с архивированием. Преимущество - прост как бревно, в случае архивирования бекап занимает меньше места чем оригинал. Недостаток - если данных много то для каждого раза это очень долгая и ресурсоемкая операция.
Более продвинутый варин - rsync. Умеет копировать не все подряд, а только то, что изменилось, работает как в пределах одного компьютера так и с несколькими, если на целевой машине не запущен rsync сервер то использует ssh, для автоматизации можно как запустить rsync сервер, так и просто настроить беспарольный вход. Недостатки - бекап не сжат, так что экономить место таким способом не получиться.
Ну и самое экзотическое, для защиты исключительно от кривых ручек существуют файловые системы с логированием, типа nilfs2, содержимое которой в большинстве случаев можно вполне успешно восстановить на заданный момент времени после rm -rf /, но она медленная. Хороший вариант для /etc.
В будущем планируется поддержка рейда на уровне файловой системы в btrfs, но сейчас это все еще очень нестабильно, так что использовать не рекомендую.

>>35908
Спасибо огромное. Пожалуй, перейду с аппаратного на программный. Хорошо хоть не системный, было бы больше сложностей. Системный у меня маленький, и бэкаплю сам до и после каждого серьёзного изменения в системе.

стоит ли начинать беспокоиться если довольно часто слышны щелчки парковки головок?, на всякий случай скопировал все нужное на внешний винт, алсо проверил norton disk doctor, ошибок не нашел

>>35912
У меня винты перед тем как умирали щелкали головками. Потом рандомно возрастало время доступа, дальше посыпались ошибки, после чего я его потащил в сервис.

>>35914
Я боюсь относить сломанные диски в сервис. Боюсь, что меня начнут обвинять, а я не смогу найти что ответить. И вообще как-то неприятно, не люблю сломанные вещи.

>>35915
Если тебя начнут обвинять, ничто не мешает тебе молча развернуться и уйти. Вероятность, что у тебя просто примут винт, спросив что с ним случилось, довольно высока, так что попытаться стоит.

>>35914
ну так все же это является предсмертным симптомом или же может быть в порядке вещей?

>>35954
Я наблюдал такое три раза, все три раза относил винты в сервес после появления сбоев в работе, хотя они по прежнему вполне могли использоваться, хоть и с некоторыми ограничениями.