Итак, у Вас появился новый компьютер. Или же ещё один сервер. Вот на нем уже стоит свежая операционная система, и предстоит установить ещё много программ. С какой начать? Вариантов предостаточно. Но все же есть такие программы, без которых остальные можно и не устанавливать. Об одной из них и пойдет речь.
Должен заметить, что существуют не только программы, обязательные к установке сразу после операционной системы, но и до! Разумеется, устанавливать такие программы будет некуда, но запустить можно и нужно. Я имею ввиду Memtest86+ — утилиту для тщательного тестирования чипов памяти. Пользоваться компьютером с дефектами в RAM-системе — это подвергать себя огромному риску. И хорошо ещё если компьютер будет просто зависать или сбоить. А если изменение одного бита приведет к незаметному на первый взгляд искажению в бухгалтерской отчетности? Или свежий архив уйдет на диск битым и не подлежащим распаковке, а оригинальные данные будут удалены?
Что ж, допустим, Memtest86+ гонялся всю ночь, пробежал десяток кругов и не обнаружил никаких проблем. Можно ли теперь спать спокойно? Скорее всего, с памятью действительно проблем нет (если было прогнано не меньше десятка кругов, я наблюдал случаи, когда ошибки обнаруживались после 7 чистых кругов). Но что насчет дисков, где хранятся данные? Не ждет ли какой-то из них подходящего случая, чтобы пригласить в гости пушного зверька?
Сведущие люди скажут: «используй RAID-1 (mirror) и будет тебе счастье». С одной стороны, да, дублирование данных действительно помогает уменьшить риск их потери. Но все равно есть ненулевая вероятность того, что все диски в зеркале будут иметь дефекты, что может привести к потере данных. Кроме того, просто установить ОС на raid-массив не достаточно, необходимо ещё и постоянно контролировать его состояние. К сожалению, почему-то не все об этом помнят, и когда возникают проблемы с чтением файлов, оказывается, что raid-массив уже полгода как находится в degraded состоянии (реальный случай).
На самом деле, есть куда более прямой способ контролировать состояние винчестера, чем дожидаться его смерти или вылета из raid-массива. Это S.M.A.R.T. Вкратце — это мониторинг состояния накопителя, который производится самим накопителем. По результатам этого мониторинга можно предсказать возникновения проблем с чтением поверхности диска ещё до того, как они реально возникнут, когда ещё есть возможность прочитать важные файлы и сделать копию данных.
Прочитать S.M.A.R.T. состояние винчестера проблемы не представляет — для этого нужно установить пакет smartmontools. Порт для FreeBSD устанавливается из /usr/ports/sysutils/smartmontools/, линуксоиды используют свой пакетный менеджер, а пользователи Windows, не боящиеся командной строки, качают бинарную сборку из сайта проекта. Утилита для чтения S.M.A.R.T. данных называется smartctl, а для мониторинга этих данных и отсылки алертов — smartd.
В строке запуска smartctl указываем '-a', чтобы посмотреть всю доступную информацию S.M.A.R.T., и диск, состояние которого хотим проверить. Вот пример для моего диска:
Итак, что мы здесь видим:
Важно знать, что значение PASSED в строчке
совершенно не значит, что с диском все тип-топ и дальше можно не смотреть. К сожалению, значение FAILED там обычно появляется слишком поздно, когда уже и так понятно, что с винчестером у нас большие неприятности. Чтобы определить проблемы на ранней стадии — необходимо изучать значение отслеживаемых аттрибутов и результаты self-тестов.
Первая важная переменная — Reallocated_Sector_Ct — счетчик перемещенных секторов. В современных дисках используются ECC-суммы для контроля целостности и восстановления данных в секторе. Если сектор устойчиво читается с поврежденной контрольной суммой, он считается сбойным и больше не используется. Вместо него используется другой сектор из специальной зарезервированной под такие проблемные сервера области (этот процесс замены сбойных секторов называется remapping) — число таких замен и отслеживается в данной переменной. Для здорового винчестера оно равно нулю, небольшое (до нескольких десятков) ненулевое значение тоже не представляет проблем. Проблема — это когда это число большое (поврежден не сектор, а участок диска), и очень большая проблема — когда это число устойчиво растет. В последнем случае вероятность того, что те файлы, которые сейчас ещё в состоянии быть прочитанными, перестанут быть таковыми — очень большая! Срочно, немедленно делайте бекап всех важных данных на другой винчестер!
Вторая переменная Current_Pending_Sector — счетчик проблемных секторов, кандидатов на remap. Любое ненулевое значение — это плохо. Такие сектора устойчиво читаются с сильно поврежденной ECC. Впрочем, выбрасывать такой диск пока рано. Вполне возможно, что текущая проблема — единичный случай, случайная флуктуация при записи сектора, которая исчезнет и не будет проявляться, если этот сектор перезаписать. Так действительно бывает — счетчик Current_Pending_Sector может обнулиться (или уменьшиться), если в проблемные сектора записать данные. Как это сделать — тут уже зависит от сноровки ;) Самый простой способ — просто записать весь диск нулями. Правильный способ — по результатам последнего self-теста посмотреть LBA-адресс проблемного сектора (LBA_of_first_error), прочитать содержание этого сектора, и сохранить это содержание обратно:
Если поверхность диска действительно повреждена в этом месте, новое содержание опять будет иметь поврежденную ECC и накопитель сделает remap.
Аттрибут Offline_Uncorrectable — из той же оперы. Здесь отслеживается количество секторов, прочитавшиеся со сбойной ECC, избыточности которой не хватило, чтобы восстановить данные. Перезапись тоже может вылечить, только записывать придется новые данные, старые прочитать скорее всего не удастся.
Другие переменные уже не столь важны, большинство из них просто содержат статистику, типа времени работы диска, кол-во стартов, температуру etc. Остальные могут сигнализировать о поломках, а могут быть результатом недостаточного уровня качества механики диска. Например, в 1.5Т сериях винчестеров Seagate использовались слишком высокие плотности записи, что проявлось в частых незначительных повреждениях ECC (что позволяло исправлять испорченные биты на ходу, без перечитывания) и частых ошибках позиционирования — это приводит к зашкаливанию таких счетчиков как Raw_Read_Error_Rate, Seek_Error_Rate, Head_Flying_Hours и к невысокой скорости работы накопителя в целом.
Следующий важный источник информации — значения self-тестов. Обычно там тишь да гладь, но не всегда:
В данном примере 14 тестов назад была проблема с чтением по смещению 1951639827 (оставалось проверить 10% диска) и 19 тестов назад self-тест был прерван рестартом сервера. Со времени теста 14 прошло уже много времени (он был сделан на момент 16308 часов аптайма) и с тех пор проблем обнаружено не было, так что можно считать, что сейчас с винчестером все в порядке.
Накопитель сам не инициирует self-тесты, это можно сделать той же утилитой smartctl, послав специальную команду, например
Есть несколько типов тестов, они отличаются временем и качеством проверки. Самый простой, это short — он занимает меньше 10 минут, и делает самую общую проверку електроники и механики. Более надежный тест long — он проверяет состояние всей поверхности дисков полностью, на больших обьемах это занимает уже часы. Тест offline тоже делает полную проверку поверхности, но не отображается в списке тестов, а просто обновляет ослеживаемые атрибуты (впрочем, если он выявит ошибки, то они будут добавлены в лог ошибок). При необходимости можно сделать выборочную проверку части секторов, указав диапазон для проверки.
Эти тесты (один за раз) можно запускать на ходу, накопитель будет продолжать работать, выполняя проверку в свободное время. Но выполнение теста уменьшит производительность работы винчестера, так что злоупотреблять этим не стоит. На очень загруженных серверах стоит даже отключать запуст self-тестов.
Ну и ещё одно место для анализа — это лог ошибок. Посмотреть его можно, указав опцию '-l error' (он также выводится при использовании опции '-a' между списком S.M.A.R.T. атрибутов и списком self-тестов). Сюда пишутся все нестандартные проблемы, вот пример:
Разобрать тут что либо сложно, но при необходимости можно ;) Наличие записей в этом логе не обязательно сведетельствует о проблеме с накопителем, бывают разовые случаи, которые больше не воспроизводятся.
Напоследок небольшая ложка дегтя. Несмотря на то, что все современные накопители (и даже SSD) используют S.M.A.R.T. технологию для отслеживания собственного состоянии, могут возникать проблемы с получением этой информации, если используется не поддеживаемый утилитой smarctl контроллер. Только недавно стало возможным читать S.M.A.R.T. статус накопителей подключенных к контроллеру LSI MegaRaid. Компания 3ware в этом плане молодец — никаких проблем, достаточно указать номер диска через опцию '-d 3ware,N'. Для других контроллеров иногда приходится идти на ухищрения, например для винчестеров на контроллере Adaptec 2405 под FreeBSD надо использовать
Также никаких гарантий, что удастся проверить состояние внешнего usb-винчестера, тут уж какой контроллер попадется.
Что ещё остается добавить? Помнится, есть два типа админов — которые ещё не делают бекапы, и которые уже делают бекапы. Видимо, есть и другие два типа пользователей — которые ещё не остлеживают состояние своих винчестеров через smartctl, и которые уже отслеживают ;)
К какому типу относитесь Вы?
Должен заметить, что существуют не только программы, обязательные к установке сразу после операционной системы, но и до! Разумеется, устанавливать такие программы будет некуда, но запустить можно и нужно. Я имею ввиду Memtest86+ — утилиту для тщательного тестирования чипов памяти. Пользоваться компьютером с дефектами в RAM-системе — это подвергать себя огромному риску. И хорошо ещё если компьютер будет просто зависать или сбоить. А если изменение одного бита приведет к незаметному на первый взгляд искажению в бухгалтерской отчетности? Или свежий архив уйдет на диск битым и не подлежащим распаковке, а оригинальные данные будут удалены?
Что ж, допустим, Memtest86+ гонялся всю ночь, пробежал десяток кругов и не обнаружил никаких проблем. Можно ли теперь спать спокойно? Скорее всего, с памятью действительно проблем нет (если было прогнано не меньше десятка кругов, я наблюдал случаи, когда ошибки обнаруживались после 7 чистых кругов). Но что насчет дисков, где хранятся данные? Не ждет ли какой-то из них подходящего случая, чтобы пригласить в гости пушного зверька?
Сведущие люди скажут: «используй RAID-1 (mirror) и будет тебе счастье». С одной стороны, да, дублирование данных действительно помогает уменьшить риск их потери. Но все равно есть ненулевая вероятность того, что все диски в зеркале будут иметь дефекты, что может привести к потере данных. Кроме того, просто установить ОС на raid-массив не достаточно, необходимо ещё и постоянно контролировать его состояние. К сожалению, почему-то не все об этом помнят, и когда возникают проблемы с чтением файлов, оказывается, что raid-массив уже полгода как находится в degraded состоянии (реальный случай).
На самом деле, есть куда более прямой способ контролировать состояние винчестера, чем дожидаться его смерти или вылета из raid-массива. Это S.M.A.R.T. Вкратце — это мониторинг состояния накопителя, который производится самим накопителем. По результатам этого мониторинга можно предсказать возникновения проблем с чтением поверхности диска ещё до того, как они реально возникнут, когда ещё есть возможность прочитать важные файлы и сделать копию данных.
Прочитать S.M.A.R.T. состояние винчестера проблемы не представляет — для этого нужно установить пакет smartmontools. Порт для FreeBSD устанавливается из /usr/ports/sysutils/smartmontools/, линуксоиды используют свой пакетный менеджер, а пользователи Windows, не боящиеся командной строки, качают бинарную сборку из сайта проекта. Утилита для чтения S.M.A.R.T. данных называется smartctl, а для мониторинга этих данных и отсылки алертов — smartd.
В строке запуска smartctl указываем '-a', чтобы посмотреть всю доступную информацию S.M.A.R.T., и диск, состояние которого хотим проверить. Вот пример для моего диска:
# smartctl -a /dev/ada0
smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.1-RELEASE amd64] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green family
Device Model: WDC WD10EADS-00M2B0
Serial Number: WD-WCAV50088887
Firmware Version: 01.00A01
User Capacity: 1 000 204 886 016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Mon Jan 3 22:49:00 2011 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x85) Offline data collection activity
was aborted by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 25) The self-test routine was aborted by
the host.
Total time to complete Offline
data collection: (19980) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 230) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 109 104 021 Pre-fail Always - 7550
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 925
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 2583
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 921
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 242
193 Load_Cycle_Count 0x0032 162 162 000 Old_age Always - 115192
194 Temperature_Celsius 0x0022 113 102 000 Old_age Always - 34
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Aborted by host 90% 2582 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.Итак, что мы здесь видим:
- версия утилиты
- информация о модели жесткого диска — имя серии, код модели, серийный номер диска (может пригодиться, если надо отослать запрос на замену жесткого диска в датацентр, чтобы случайно не заменили рабочий диск), версия прошивки и объем.
- статус накопителя по результатам самодиагностики (в данном случае PASSED) и общая информация об поддерживаемых функциях S.M.A.R.T.
- значения отслеживаемых переменных (может меняться от модели к модели)
- список ошибок (здесь пустой)
- список результатов self-тестов
Важно знать, что значение PASSED в строчке
SMART overall-health self-assessment test result: PASSEDсовершенно не значит, что с диском все тип-топ и дальше можно не смотреть. К сожалению, значение FAILED там обычно появляется слишком поздно, когда уже и так понятно, что с винчестером у нас большие неприятности. Чтобы определить проблемы на ранней стадии — необходимо изучать значение отслеживаемых аттрибутов и результаты self-тестов.
Первая важная переменная — Reallocated_Sector_Ct — счетчик перемещенных секторов. В современных дисках используются ECC-суммы для контроля целостности и восстановления данных в секторе. Если сектор устойчиво читается с поврежденной контрольной суммой, он считается сбойным и больше не используется. Вместо него используется другой сектор из специальной зарезервированной под такие проблемные сервера области (этот процесс замены сбойных секторов называется remapping) — число таких замен и отслеживается в данной переменной. Для здорового винчестера оно равно нулю, небольшое (до нескольких десятков) ненулевое значение тоже не представляет проблем. Проблема — это когда это число большое (поврежден не сектор, а участок диска), и очень большая проблема — когда это число устойчиво растет. В последнем случае вероятность того, что те файлы, которые сейчас ещё в состоянии быть прочитанными, перестанут быть таковыми — очень большая! Срочно, немедленно делайте бекап всех важных данных на другой винчестер!
Вторая переменная Current_Pending_Sector — счетчик проблемных секторов, кандидатов на remap. Любое ненулевое значение — это плохо. Такие сектора устойчиво читаются с сильно поврежденной ECC. Впрочем, выбрасывать такой диск пока рано. Вполне возможно, что текущая проблема — единичный случай, случайная флуктуация при записи сектора, которая исчезнет и не будет проявляться, если этот сектор перезаписать. Так действительно бывает — счетчик Current_Pending_Sector может обнулиться (или уменьшиться), если в проблемные сектора записать данные. Как это сделать — тут уже зависит от сноровки ;) Самый простой способ — просто записать весь диск нулями. Правильный способ — по результатам последнего self-теста посмотреть LBA-адресс проблемного сектора (LBA_of_first_error), прочитать содержание этого сектора, и сохранить это содержание обратно:
dd if=/dev/sda of=sec.bin bs=512 count=1 skip=123456
dd of=/dev/sda if=sec.bin bs=512 count=1 seek=123456Если поверхность диска действительно повреждена в этом месте, новое содержание опять будет иметь поврежденную ECC и накопитель сделает remap.
Аттрибут Offline_Uncorrectable — из той же оперы. Здесь отслеживается количество секторов, прочитавшиеся со сбойной ECC, избыточности которой не хватило, чтобы восстановить данные. Перезапись тоже может вылечить, только записывать придется новые данные, старые прочитать скорее всего не удастся.
Другие переменные уже не столь важны, большинство из них просто содержат статистику, типа времени работы диска, кол-во стартов, температуру etc. Остальные могут сигнализировать о поломках, а могут быть результатом недостаточного уровня качества механики диска. Например, в 1.5Т сериях винчестеров Seagate использовались слишком высокие плотности записи, что проявлось в частых незначительных повреждениях ECC (что позволяло исправлять испорченные биты на ходу, без перечитывания) и частых ошибках позиционирования — это приводит к зашкаливанию таких счетчиков как Raw_Read_Error_Rate, Seek_Error_Rate, Head_Flying_Hours и к невысокой скорости работы накопителя в целом.
Следующий важный источник информации — значения self-тестов. Обычно там тишь да гладь, но не всегда:
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 18492 -
# 2 Extended offline Completed without error 00% 18324 -
# 3 Extended offline Completed without error 00% 18156 -
# 4 Extended offline Completed without error 00% 17988 -
# 5 Extended offline Completed without error 00% 17821 -
# 6 Extended offline Completed without error 00% 17652 -
# 7 Extended offline Completed without error 00% 17484 -
# 8 Extended offline Completed without error 00% 17317 -
# 9 Extended offline Completed without error 00% 17148 -
#10 Extended offline Completed without error 00% 16980 -
#11 Extended offline Completed without error 00% 16812 -
#12 Extended offline Completed without error 00% 16645 -
#13 Extended offline Completed without error 00% 16476 -
#14 Extended offline Completed: read failure 10% 16308 1951639827
#15 Extended offline Completed without error 00% 16141 -
#16 Extended offline Completed without error 00% 15972 -
#17 Extended offline Completed without error 00% 15804 -
#18 Extended offline Completed without error 00% 15637 -
#19 Extended offline Interrupted (host reset) 50% 15467 -
#20 Extended offline Completed without error 00% 15301 -
#21 Extended offline Completed without error 00% 15132 -В данном примере 14 тестов назад была проблема с чтением по смещению 1951639827 (оставалось проверить 10% диска) и 19 тестов назад self-тест был прерван рестартом сервера. Со времени теста 14 прошло уже много времени (он был сделан на момент 16308 часов аптайма) и с тех пор проблем обнаружено не было, так что можно считать, что сейчас с винчестером все в порядке.
Накопитель сам не инициирует self-тесты, это можно сделать той же утилитой smartctl, послав специальную команду, например
smartctl -t long -d 3ware,3 /dev/twaЕсть несколько типов тестов, они отличаются временем и качеством проверки. Самый простой, это short — он занимает меньше 10 минут, и делает самую общую проверку електроники и механики. Более надежный тест long — он проверяет состояние всей поверхности дисков полностью, на больших обьемах это занимает уже часы. Тест offline тоже делает полную проверку поверхности, но не отображается в списке тестов, а просто обновляет ослеживаемые атрибуты (впрочем, если он выявит ошибки, то они будут добавлены в лог ошибок). При необходимости можно сделать выборочную проверку части секторов, указав диапазон для проверки.
Эти тесты (один за раз) можно запускать на ходу, накопитель будет продолжать работать, выполняя проверку в свободное время. Но выполнение теста уменьшит производительность работы винчестера, так что злоупотреблять этим не стоит. На очень загруженных серверах стоит даже отключать запуст self-тестов.
Ну и ещё одно место для анализа — это лог ошибок. Посмотреть его можно, указав опцию '-l error' (он также выводится при использовании опции '-a' между списком S.M.A.R.T. атрибутов и списком self-тестов). Сюда пишутся все нестандартные проблемы, вот пример:
Error 9 occurred at disk power-on lifetime: 18520 hours (771 days + 16 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
60 00 40 ff ff ff 4f 00 1d+01:27:59.818 READ FPDMA QUEUED
ef 03 45 00 00 00 00 00 1d+01:27:59.766 SET FEATURES [Set transfer mode]
00 00 00 00 00 00 00 04 1d+01:27:59.714 NOP [Abort queued commands]
2f 00 01 10 00 00 00 00 1d+01:27:59.646 READ LOG EXT
60 00 40 ff ff ff 4f 00 1d+01:27:56.578 READ FPDMA QUEUEDРазобрать тут что либо сложно, но при необходимости можно ;) Наличие записей в этом логе не обязательно сведетельствует о проблеме с накопителем, бывают разовые случаи, которые больше не воспроизводятся.
Напоследок небольшая ложка дегтя. Несмотря на то, что все современные накопители (и даже SSD) используют S.M.A.R.T. технологию для отслеживания собственного состоянии, могут возникать проблемы с получением этой информации, если используется не поддеживаемый утилитой smarctl контроллер. Только недавно стало возможным читать S.M.A.R.T. статус накопителей подключенных к контроллеру LSI MegaRaid. Компания 3ware в этом плане молодец — никаких проблем, достаточно указать номер диска через опцию '-d 3ware,N'. Для других контроллеров иногда приходится идти на ухищрения, например для винчестеров на контроллере Adaptec 2405 под FreeBSD надо использовать
smartctl -d sat -a -T permissive /dev/pass0Также никаких гарантий, что удастся проверить состояние внешнего usb-винчестера, тут уж какой контроллер попадется.
Что ещё остается добавить? Помнится, есть два типа админов — которые ещё не делают бекапы, и которые уже делают бекапы. Видимо, есть и другие два типа пользователей — которые ещё не остлеживают состояние своих винчестеров через smartctl, и которые уже отслеживают ;)
К какому типу относитесь Вы?