Поиск файлов

Прежде, чем вы приступите к восстановлению данных, вы, как правило, знаете имена нужных файлов или хотя бы их части. rdiff-backup в своих архивах хранит файлы, не изменяя их имён, поэтому для того, чтобы определить наличие/отсутствие файла в архиве, вы можете использовать традиционные UNIX-утилиты, например find. Например:

$ find /media/backups/var/log -iname 'messages*'
/media/backups/var/log/messages.2.gz
/media/backups/var/log/messages.1
/media/backups/var/log/messages.3.gz
/media/backups/var/log/messages
/media/backups/var/log/messages.4.gz
/media/backups/var/log/rdiff-backup-data/increments/messages.2012-03-07T00:02:17Z.diff.gz
/media/backups/var/log/rdiff-backup-data/increments/messages.2012-03-06T02:42:01Z.diff.gz

Обзор инкрементов

Поскольку rdiff-backup выполняет инкрементное копирование, при регулярном архивировании часто изменявшиеся в прошлом файлы будут иметь несколько версий. Чтобы получить информацию об имеющихся в архиве инкрементах файлов/каталогов, воспользуйтесь ключом --list-increments:

$ rdiff-backup --list-increments /media/backups/var/log
Found 2 increments:
    increments.2012-03-06T02:42:01Z.dir   Tue Mar  6 02:42:01 2012
    increments.2012-03-07T00:02:17Z.dir   Wed Mar  7 00:02:17 2012
Current mirror: Wed Mar  7 20:17:18 2012

Как видим на примере, каталог /media/backups/var/log имеет две предыдущие версии версии (2 increments) и одну текущую (current mirror).

Форматы времени

Прежде, чем рассматривать дальнейшие функции rdiff-backup, необходимо понимать, как утилита понимает штампы времени. Здесь всё достаточно просто. Определять время в rdiff-backup можно следующими способами:

• при помощи слова «now», которое является синонимом текущего времени;
• используя целое число, определяющее время в формате UNIX time;
• при помощи строки в формате, предложенном в W3 Date and Time Formats, например «2012-01-25T07:00:00+02:00»;
• используя временные интервалы и суффиксы  s, m, h, D, W, M и Y, соответствующие секундам, минутам, часам, дням, неделям, месяцам и годам. В этом случае значение времени вычисляется путём вычитания указанного интервала из текущего времени. Также, вы можете комбинировать интервалы, например: «1h25m» или «5W3D». Только не забывайте, что при использовании этого формата rdiff-backup «думает», что в любом месяце ровно 30 дней, а в любом году ровно 365 дней;
• при помощи даты в формате YYYY/MM/DD, YYYY-MM-DD, MM/DD/YYYY, или MM-DD-YYYY определяющей  полночь указанной даты относительно текущего часового пояса;
• используя целое число с суффиксом «B», которое определяет количество «сессий назад» rdiff-backup. Например, «0B» означает время создания последнего архива, а «5B» означает 5й по счёту архив относительно последнего.

Получение списка изменявшихся файлов

Часто бывает необходимо получить список файлов, которые модифицировались за определённый промежуток времени. Например, следующая команда выведет список файлов, которые менялись за последние два дня:

$ rdiff-backup --list-changed-since 2D /media/backups/etc

Получение списка файлов на определённый момент времени

Следующая команда выводит список всех файлов в архиве, которые в нём содержались 3 версии назад, включая также файлы, которые были удалены в последующих версиях:

$ rdiff-backup --list-at-time 3B /media/backups/etc

Сравнение архива и текущего состояния файлов

Следующая команда выведет все файлы, которые были изменены в каталоге /etc с момента его последней архивации в каталог /media/backups/etc:

$ rdiff-backup --compare /etc /media/backups/etc

То же самое, но с указанием версии архива:

$ rdiff-backup --compare-at-time 3B /etc /media/backups/etc

Получение статистической информации об архиве

После завершения сессий архивации rdiff-backup создаёт в каталоге архива специальный файл rdiff-backup-data/session_statistics*, содержащий разнообразную статистическую информацию о результатах сессии. Утилита предлагает специальную опцию --calculate-average, при помощи которой вы можете получить общее представление об архиве, например:

$ rdiff-backup --calculate-average /media/backups/etc/rdiff-backup-data/session_statistics*
--------------[ Average of 4 stat files ]--------------
ElapsedTime 7.49 (7.49 seconds)
SourceFiles 2177.0
SourceFileSize 21157087.25 (20.2 MB)
MirrorFiles 1633.0
MirrorFileSize 15826670.75 (15.1 MB)
NewFiles 544.0
NewFileSize 5264292.0 (5.02 MB)
DeletedFiles 0.0
DeletedFileSize 0.0 (0 bytes)
ChangedFiles 36.5
ChangedSourceSize 10237590.5 (9.76 MB)
ChangedMirrorSize 10171466.0 (9.70 MB)
IncrementFiles 36.25
IncrementFileSize 6761.75 (6.60 KB)
TotalDestinationSizeChange 5337178.25 (5.09 MB)
Errors 0
-------------------------------------------------------

Восстановление данных их архива

Поскольку rdiff-backup хранит файлы «как есть», то в случае нечаянного удаления нужного каталога/файла вы можете просто скопировать его обратно из архива обычной командой cp:

$ cp -a /media/backups/etc/nginx /etc/nginx

В более сложных ситуациях вам уже понадобится утилита rdiff-backup. Следующая команда выполняет восстановление данных из из последней версии архива, расположенного на удалённой системе:

$ rdiff-backup --restore-as-of now backup@my-server.com::/var/backups/etc /etc

Или то же самое, с короткой версией опции:

$ rdiff-backup -r now backup@my-server.com::/var/backups/etc /etc

Естественно, если вам нужна версия архива постарше, вам необходимо это указать:

$ rdiff-backup -r 2012-03-06T02:37:21 backup@my-server.com::/var/backups/etc /etc

или

$ rdiff-backup -r 3B backup@my-server.com::/var/backups/etc /etc

Если же вам нужно восстановить отдельный файл, то укажите нужную версию из каталога increments:

$ rdiff-backup /media/backups/var/log/rdiff-backup-data/increments/messages.2012-03-06T02:42:01Z.diff.gz ~/restored/messages

Удаление старых версий

При всей своей экономичности, утилита rdiff-backup не может бесконечно долго хранить инкрементные версии архивов хотя бы потому, что место на диске не бесконечно. Да и, как правило, иногда нет особого смысла хранить все изменения за последние 20 лет. На этот случай у rdiff-backup имеется специальная опция --remove-older-than, которая указывает программе вычищать устаревшие данные, которые старше определённого времени. Например, мне вполне достаточно хранить изменения за последний месяц:

$ rdiff-backup --remove-older-than 1M /media/backups/etc/

Кому-то может показаться удобным хранить данные лишь последних N сессий:

$ rdiff-backup --remove-older-than 20B /media/backups/etc/

rdiff-backup — приложение написанное на Python, обладает большой гибкостью и довольно простое в обращении. Может работать как локально, так и поверх rsync/ssh, предоставляя возможность оптимально использовать каналы передачи данных в случае удалённых бекапов. Среди основных плюшек rdiff-backup можно выделить следующие возможности.

• Инкрементное копирование, позволяющее восстановить любой файл, удалённый до последней операции бэкапа. То есть, вы можете восстановить файл, который был удалён хоть год назад, при том что резервное копирование у вас выполняется, скажем, два раза в день.
• Сохранение всей информации о файлах. Восстанавливая файл из архива rdiff-backup, вы получите его в таком виде, в каком он был на момент занесения в архив, включая таймштампы, права доступа, владельцев и т. п. Помимо всего прочего, rdiff-backup корректно управляется с жёсткими и символическими ссылками, файлами устройств и FIFO. При этом утилита корректно будет вести себя в различных операционных системах, использующих разные типы файловых систем.
• Эффективное использование дискового пространства. Используя алгоритм rsync, утилита rdiff-backup сохраняет только изменения файлов, а не все файлы целиком. То есть, ваша БД весом в пару десятков гигабайт не будет каждый раз копироваться целиком, съедая пространство на диске. Будут копироваться только изменения.
• Эффективное использование каналов передачи данных в случае сетевых бэкапов само-собой вытекает из предыдущего пункта.
• «Прозрачное» хранение данных. rdiff-backup хранит бэкапы в точно таком же виде, в каком файлы находились на диске, не прибегая ни к каким хитроумным форматам. То есть, например, если вам понадобиться восстановить последний бэкап, не используя при этом rdiff-backup, вы сможете просто скопировать нужные файлы обратно на место.
• Автоматическое определение типов файловых систем позволяет утилите избавить вас от полного понимания всех тонкостей её настройки в зависимости от типа используемых ФС и ОС.

Установка

В современных Linux-дистрибутивах rdiff-backup имеется в репозиториях, так что с её установкой у вас не должно возникнуть проблем. В случае же, если вы используете что-то другое, посетите главную страницу проекта, с которой можно скачать исходные коды.

Локальное резервное копирование

Под «локальным» или «удалённым» здесь и далее понимается получатель резервной копии. Сперва давайте рассмотрим самый простой способ запуска утилиты:

$ rdiff-backup <источник> <получатель>

Эта команда, как понятно из описания, выполнит резервное копирование из <источник> в <получатель>.  Обратите внимание, что в качестве получателя необходимо указывать либо пустой, либо несуществующий каталог, иначе rdiff-backup вежливо вам откажет, что правильно.

В режиме по умолчанию rdiff-backup довольно молчалива, и не надоедает диагностическими сообщениями до тех пор, пока не столкнётся с ошибкой. Регулировать разговорчивость утилиты можно при помощи короткой опции '-v' или её длинного аналога '--verbosity'. Значение опции может принимать значения от 0 до 9 (по умолчанию оно равно 3). Например, уровень 4 перед началом процедуры копирования выведет вам сводку опций работы утилиты:

$ rdiff-backup -v 4 /var/log ~/log.backup
Using rdiff-backup version 1.2.8
Unable to import win32security module. Windows ACLs
not supported by filesystem at /var/log
escape_dos_devices not required by filesystem at /var/log
-----------------------------------------------------------------
Detected abilities for source (read only) file system:
  Access control lists                         On
  Extended attributes                          On
  Windows access control lists                 Off
  Case sensitivity                             On
  Escape DOS devices                           Off
  Escape trailing spaces                       Off
  Mac OS X style resource forks                Off
  Mac OS X Finder information                  Off
-----------------------------------------------------------------
Unable to import win32security module. Windows ACLs
not supported by filesystem at log.backup/rdiff-backup-data/rdiff-backup.tmp.0
escape_dos_devices not required by filesystem at log.backup/rdiff-backup-data/rdiff-backup.tmp.0
-----------------------------------------------------------------
Detected abilities for destination (read/write) file system:
  Ownership changing                           On
  Hard linking                                 On
  fsync() directories                          On
  Directory inc permissions                    On
  High-bit permissions                         On
  Symlink permissions                          Off
  Extended filenames                           On
  Windows reserved filenames                   Off
  Access control lists                         On
  Extended attributes                          On
  Windows access control lists                 Off
  Case sensitivity                             On
  Escape DOS devices                           Off
  Escape trailing spaces                       Off
  Mac OS X style resource forks                Off
  Mac OS X Finder information                  Off
-----------------------------------------------------------------
Backup: must_escape_dos_devices = 0
Starting mirror /var/log to log.backup

В то время как девятый уровень будет сообщать о каждом шаге:

$ rdiff-backup -v 9 /var/log ~/log.backup
...
Tue Mar  6 04:50:07 2012  Processing changed file wtmp.1
Tue Mar  6 04:50:07 2012  Regular copying ('wtmp.1',) to log.backup/rdiff-backup.tmp.121
Tue Mar  6 04:50:07 2012  Writing file object to log.backup/rdiff-backup.tmp.121
Tue Mar  6 04:50:07 2012  Copying attributes from ('wtmp.1',) to log.backup/rdiff-backup.tmp.121
Tue Mar  6 04:50:07 2012  Setting time of log.backup/rdiff-backup.tmp.121 to 1330553626
Tue Mar  6 04:50:07 2012  Renaming log.backup/rdiff-backup.tmp.121 to log.backup/wtmp.1
Tue Mar  6 04:50:07 2012  Copying attributes from () to log.backup
Tue Mar  6 04:50:07 2012  Setting time of log.backup to 1330980760
Tue Mar  6 04:50:07 2012  Touching log.backup/rdiff-backup-data/extended_attributes.2012-03-06T04:50:07+02:00.snapshot
Tue Mar  6 04:50:07 2012  Touching log.backup/rdiff-backup-data/access_control_lists.2012-03-06T04:50:07+02:00.snapshot
Tue Mar  6 04:50:08 2012  Writing mirror marker log.backup/rdiff-backup-data/current_mirror.2012-03-06T04:50:07+02:00.data
Tue Mar  6 04:50:08 2012  Cleaning up
Tue Mar  6 04:50:08 2012  Touching log.backup/rdiff-backup-data/error_log.2012-03-06T04:50:07+02:00.data
...

Удалённое резервное копирование

Этот тип копирования выполнить настолько же просто, как и локальное. Всё, что меняется — это формат указания источника/получателя. Также на удалённой системе должна быть установлена rdiff-backup и работать SSH-сервер. Например следующая команда:

$ rdiff-backup -v 5 /var/log backup@my-server.com::/var/backups/log.host123

1. установит соединение с сервером my-server.com при помощи SSH;
2. запустит на сервере rdiff-backup в режиме --server;
3. выполнит передачу файлов с локальной системы серверу my-server.com в каталог /var/backups/log.host123

То же самое будет работать и в обратном направлении, т. е., если вам необходимо выполнить копирование удалённых файлов в локальную систему, просто поменяйте местами источник с получателем в опциях утилиты:

$ rdiff-backup -v 5 backup@my-server.com::/var/log /var/backups/logs-my-server.com

Получение информации о результатах копирования

Обычно многословный вывод команд требуется в период отладки и написания сценариев, не более. Для ежедневного мониторинга результатов работы утилиты желательно иметь лишь краткую сводку. Для этого rdiff-backup предлагает отдельную опцию '--print-statistics':

$ rdiff-backup --print-statistics /var/log ~/log.backup
Warning: Access Control List file not found
--------------[ Session statistics ]--------------
StartTime 1331003360.00 (Tue Mar  6 05:09:20 2012)
EndTime 1331003385.71 (Tue Mar  6 05:09:45 2012)
ElapsedTime 25.71 (25.71 seconds)
SourceFiles 139
SourceFileSize 7006201 (6.68 MB)
MirrorFiles 339
MirrorFileSize 16991862 (16.2 MB)
NewFiles 65
NewFileSize 1504824 (1.44 MB)
DeletedFiles 265
DeletedFileSize 12116918 (11.6 MB)
ChangedFiles 74
ChangedSourceSize 5501377 (5.25 MB)
ChangedMirrorSize 4874944 (4.65 MB)
IncrementFiles 404
IncrementFileSize 2136990 (2.04 MB)
TotalDestinationSizeChange -7848671 (-7.49 MB)
Errors 0
--------------------------------------------------

Включение исключение файлов

«Не все йогурты одинаково полезны» — гласит народная пословица. Это же касается и файлов при резервном копировании. Часто-густо в копируемых каталогах попадаются файлы, размер которых весьма немаленький, а смысла включать их в бэкап нет. Здесь у rdiff-backup (как, впрочем и у всех остальных утилит подобного рода) предусмотрены свои возможности. Используя опцию '--exlude', вы можете исключать отдельные файлы и каталоги:

$ rdiff-backup --exclude /proc / backup@my-server.com::/var/backups

Эту опцию можно использовать сколько угодно раз:

$ rdiff-backup --exclude /proc --exclude /mnt --exclude /tmp / backup@my-server.com::/var/backups

Иногда проще указать то, что нужно скопировать, вместо того, что НЕ нужно. Следующая команда скопирует, например, /usr/local/bin, пропустив при этом /usr/bin:

$ rdiff-backup --include /usr/local --exclude /usr / backup@my-server.com::/var/backups

Обратите внимание, что при множественном использовании опций '--include' / '--exclude' их приоритет зависит от порядка появления в команде.

rdiff-backup позволяет использовать шаблоны подобные тем, которые используются в rsync: '**' эквивалентны любому пути, а '*' — любому пути без завершающего слеша. Так, например, следующая команда скопирует /usr/local и /var, но пропустит всё остальное:

$ rdiff-backup --include /usr/local --include /var --exclude '**' / /backup

Обратите внимание на кавычки. Они нужны, поскольку большинство оболочек обрабатывают звёздочки как спецсимволы, превращая их в маски.

Пример чуть посложнее:

$ rdiff-backup --include '**txt' --exclude /usr/local/games --include /usr/local --exclude /usr --exclude /backup --exclude /proc / /backup

Эта команда скопирует все файлы, имена которых заканчиваются суффиксом 'txt'. Обратите внимание: будут скопированы также все txt-файлы также из каталогов, /usr/local и /backup, поскольку первый --include имеет более высокий приоритет.

Вообще, утилита rdif--backup предлагает довольно богатый набор опция для фильтрации файлов, перечислять который в полном объёме нет смысла, поскольку всё «уже украдено до нас» в man-странице приложения. Тем, кто ещё туда не заглядывал, скажу что вы можете фильтровать файлы на основе регулярных выражений, типе самих файлов (символически/жесткие ссылки, сокеты, устройства, FIFO и т. п.), а также на основе файловых списков включений/исключений, при чём сами файловые списки можно передавать через stdin.

Получение информации об использовании памяти

Думаю, всем известна программа free, но на всякий случай, для тех, кто ещё не в курсе. При помощи команды free можно получить информацию об используемой/свободной памяти в вашей системе, в том числе и swap:

$ free
             total       used       free     shared    buffers     cached
Mem:       2062064    1493344     568720          0      82672     526624
-/+ buffers/cache:     884048    1178016
Swap:      1951740      59396    1892344

Или же более человечный вариант вывода:

$ free -m
             total       used       free     shared    buffers     cached
Mem:          2013       1669        343          0         86        624
-/+ buffers/cache:        959       1053
Swap:         1905         58       1847

Ну и конечно же, стоит упомянуть традиционные top и htop:

Получение информации об аппаратной части

Если вам необходимо получить информацию об установленных платах, не открывая корпус компьютера, можно воспользоваться утилитой dmidecode, предназначенной для извлечения различного рода данных об установленном железе. Чтобы получить данные об установленной памяти, необходимо попросить dmidecode вывести информацию только 17 типа DMI:

# dmidecode --type 17
dmidecode 2.9
SMBIOS 2.5 present.

Handle 0x002D, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x002B
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 72 bits
    Size: 1024 MB
    Form Factor: DIMM
    Set: None
    Locator: DIMM0
    Bank Locator: BANK0
    Type: DDR2
    Type Detail: Synchronous
    Speed: Unknown
    Manufacturer: Manufacturer0
    Serial Number: SerNum0
    Asset Tag: AssetTagNum0
    Part Number: PartNum0
Handle 0x002F, DMI type 17, 27 bytes
Memory Device
    Array Handle: 0x002B
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 72 bits
    Size: 1024 MB
    Form Factor: DIMM
    Set: None
    Locator: DIMM1
    Bank Locator: BANK1
    Type: DDR2
    Type Detail: Synchronous
    Speed: Unknown
    Manufacturer: Manufacturer1
    Serial Number: SerNum1
    Asset Tag: AssetTagNum1
    Part Number: PartNum1
...

Информацию о контроллере памяти можно получить, указав типы DMI 5 и 6:

# dmidecode --type 5,6
dmidecode 2.9
SMBIOS 2.5 present.

Handle 0x0008, DMI type 5, 24 bytes
Memory Controller Information
    Error Detecting Method: 64-bit ECC
    Error Correcting Capabilities:
        None
    Supported Interleave: One-way Interleave
    Current Interleave: One-way Interleave
    Maximum Memory Module Size: 1024 MB
    Maximum Total Memory Size: 4096 MB
    Supported Speeds:
        70 ns
        60 ns
        50 ns
    Supported Memory Types:
        DIMM
        SDRAM
    Memory Module Voltage: 3.3 V
    Associated Memory Slots: 4
        0x0009
        0x000A
        0x000B
        0x000C
    Enabled Error Correcting Capabilities:
        None

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
    Socket Designation: DIMM0
    Bank Connections: 0 5
    Current Speed: 160 ns
    Type: ECC DIMM
    Installed Size: 1024 MB (Single-bank Connection)
    Enabled Size: 1024 MB (Single-bank Connection)
    Error Status: OK
Handle 0x000A, DMI type 6, 12 bytes
Memory Module Information
    Socket Designation: DIMM1
    Bank Connections: 0 5
    Current Speed: 162 ns
    Type: ECC DIMM
    Installed Size: 1024 MB (Single-bank Connection)
    Enabled Size: 1024 MB (Single-bank Connection)
    Error Status: OK
...

А указав тип DMI 16, можно получить краткую информацию о пределах возможностей подсистемы управления памятью, установленной на материнской плате:

# dmidecode --type 16
dmidecode 2.9
SMBIOS 2.5 present.
Handle 0x002B, DMI type 16, 15 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 8 GB
    Error Information Handle: Not Provided
    Number Of Devices: 4

Для Linux существует несколько утилит, при помощи которых можно получить интересующую вас информацию о жёстких дисках, установленных в системе. В первую очередь я рекомендую вам  hdparm, утилиту с интерфейсом командной строки, умеющую среди всего прочего извлекать огромное количество разнообразной информацию из  подсистемы драйверов дисков Linux.

hdparm

Эта утилита устанавливается по умолчанию в большинстве современных Linux-дистрибутивов и требует root-привилегий для работы. Чтобы получить информацию об устройстве, откройте терминал и запустите hdparm с ключом -I, передав путь к интересующему вас устройству:

# hdparm -I /dev/sda
ATA device, with non-removable media
	Model Number:       SAMSUNG HD321KJ
	Serial Number:      S0MQJ9DQ103691
	Firmware Revision:  CP100-12
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
Standards:
	Used: ATA-8-ACS revision 3b
	Supported: 8 7 6 5
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  268435455
	LBA48  user addressable sectors:  625142448
	Logical/Physical Sector size:           512 bytes
	device size with M = 1024*1024:      305245 MBytes
	device size with M = 1000*1000:      320072 MBytes (320 GB)
	cache/buffer size  = 16384 KBytes (type=DualPortCache)
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Recommended acoustic management value: 254, current value: 0
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	    	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	    	Automatic Acoustic Management feature set
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	64-bit World wide name
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	Segmented DOWNLOAD_MICROCODE
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	    	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	   *	SMART Command Transport (SCT) feature set
	   *	SCT Long Sector Access (AC1)
	   *	SCT LBA Segment Access (AC2)
	   *	SCT Error Recovery Control (AC3)
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
Security:
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	112min for SECURITY ERASE UNIT. 112min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50000f009b103691
	NAA		: 5
	IEEE OUI	: 0000f0
	Unique ID	: 09b103691
Checksum: correct

lshw

Утилита lshw предназначена для получения информации об оборудовании (не только дисковом), установленном в системе, и умеет выводить полученные данные в приятном глазу TXT-формате, HTML или XML. В современных Linux-дистрибутивах программа по умолчанию не всегда устанавливается, так что перед её использованием установите её, используя штатный менеджер пакетов.

Чтобы при помощи lshw получить информацию о дисковых устройствах, выполните следующую команду:

# lshw -class disk -class storage
  *-storage               
       description: SATA controller
       product: MCP65 AHCI Controller
       vendor: nVidia Corporation
       physical id: a
       bus info: pci@0000:00:0a.0
       logical name: scsi0
       logical name: scsi1
       version: a3
       width: 32 bits
       clock: 66MHz
       capabilities: storage pm msi ht ahci_1.0 bus_master cap_list emulated
       configuration: driver=ahci latency=0 maxlatency=1 mingnt=3
       resources: irq:44 ioport:c080(size=8) ioport:c000(size=4) ioport:bc00(size=8) ioport:b880(size=4) ioport:b800(size=16) memory:f9efc000-f9efdfff
     *-disk
          description: ATA Disk
          product: SAMSUNG HD321KJ
          physical id: 0
          bus info: scsi@0:0.0.0
          logical name: /dev/sda
          version: CP10
          serial: S0MQJ9DQ103691
          size: 298GiB (320GB)
          capabilities: partitioned partitioned:dos
          configuration: ansiversion=5 signature=ea89ea89
     *-cdrom
          description: DVD-RAM writer
          product: DVD RW AD-7200S
          vendor: Optiarc
          physical id: 1
          bus info: scsi@1:0.0.0
          logical name: /dev/cdrom
          logical name: /dev/cdrw
          logical name: /dev/dvd
          logical name: /dev/dvdrw
          logical name: /dev/scd0
          logical name: /dev/sr0
          version: 1.04
          serial: [
          capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
          configuration: ansiversion=5 status=ready
        *-medium
             physical id: 0
             logical name: /dev/cdrom

Если вас интересует лишь информация об установленных дисках в системе, вы можете воспользоваться следующей командой:

# lshw -short -C disk
H/W path    Device      Class       Description
===============================================
/0/a/0      /dev/sda    disk        320GB SAMSUNG HD321KJ
/0/a/1      /dev/cdrom  disk        DVD RW AD-7200S

 GNOME Disk Utility

Пользователи GNOME могут обратиться за помощью к специализированной GUI-утилите, позволяющей кроме получения информации об установленных устройствах, оперировать дисковыми разделами и выполнять ряд тестов устройств. Запустить утилиту можно из меню GNOME или из командной строки:

$ palimpsest

Пример информации о диске:

Пример вывода информации SMART:

smartctl

При помощи утилиты smartctl вы можете получить подробную информацию о состоянии здоровья ваших устройств, поддерживающих SMART. Пример вывода информации о SATA-устройстве:

# smartctl -d ata -a -i /dev/sda
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model:     TOSHIBA MK5061GSYF
Serial Number:    71XXXYYZ
Firmware Version: MF000D
User Capacity:    500,107,862,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Fri Feb 24 05:27:29 2012 IST
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:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      (  36)	The self-test routine was interrupted
					by the host with a hard or soft reset.
Total time to complete Offline
data collection: 		 ( 120) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No 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: 	 ( 136) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.
SMART Attributes Data Structure revision number: 128
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       1650
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       34237
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       120
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       42
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       23
193 Load_Cycle_Count        0x0032   099   099   000    Old_age   Always       -       13971
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       39 (Lifetime Min/Max 21/48)
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       3536073
200 Multi_Zone_Error_Rate   0x0032   100   100   000    Old_age   Always       -       9143982
240 Head_Flying_Hours       0x0032   099   099   000    Old_age   Always       -       28415
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       741418060
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       450708673
254 Free_Fall_Sensor        0x0032   100   100   000    Old_age   Always       -       0
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  Short offline       Interrupted (host reset)      40%       343         -
# 2  Short offline       Completed without error       00%       186         -
# 3  Short offline       Completed without error       00%        71         -
# 4  Short offline       Completed without error       00%         0         -
# 5  Short offline       Completed without error       00%         0         -
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.

Источник: CyberCiti.Biz

Лучший способ научиться чему-то — это сделать самостоятельно. В качестве подопытного кролика было решено взять Debian 6.0.3, оказавшуюся под рукой и не шифровавшей домашние каталоги пользователей. На ней весь процесс и производился. Если у вас в качестве ОС используется нечто совсем далёкое, гарантий, что процесс настройки будет таким же — никаких.

Как это работает

Для организации защиты ваших персональных данных в Ubuntu разработчики предпочли eCryptfs — файловую систему, работающую «поверх» любой другой обычной ФС и прозрачно шифрующую/дешифрующую содержимое файлов. Криптографические метаданные eCryptfs хранит в заголовках каждого файла, таким образом вы можете без проблем переносить любой файл между различными системами. Всё это счастье реализовано на уровне ядра Linux, обеспечивая хороший уровень производительности по сравнению с FUSE-шифрованием (например, EncFS).

Установка

Всё, что нужно для работы eCryptfs, во всех современных Linux-дистрибутивах имеются по умолчанию «из коробки». Если же ядро Linux вы собирали самостоятельно, то удостоверьтесь, что в вашей сборке присутствует необходимый модуль:

# modprobe ecryptfs && lsmod | grep ecryptfs

Далее, для работы с eCryptfs нам понадобятся userspace-инструменты, которые в Debain/Ubuntu легко устанавливаются из пакета:

# apt-get install ecryptfs-utils

Монтирование eCryptfs

Чтобы лучше понять и увидеть на практике, как работает eCryptfs, смонтируем какой-нибудь каталог и посмотрим, что происходит в реальности. Для начала создадим пустой каталог, который будем шифровать:

# mkdir /mnt/ecryptfs-demo

Теперь смонтируем созданный каталог используя eCryptfs:

# mount -t ecryptfs /mnt/ecryptfs-demo/ /mnt/ecryptfs-demo/

Обратите внимание, что исходным и целевым каталогом команде mount указан один и тот же каталог. Это несколько «нетрадиционно» для операции монтирования, однако вполне допустимо и удобно. Если вас это запутывает, вы можете использовать разные точки с более осмысленными именами, вроде:

# mount -t ecryptfs /mnt/plaintext/ /mnt/encrypted/

После ввода команды вам необходимо ввести пароль для ключа шифрования:

Passphrase:

Введите пароль, не забывая о том, что его утеря будет означать невозможность получения данных! После ввода пароля вам будет предложено выбрать алгоритм шифрования, с по-умолчанию выбранным AES:

Select cipher:
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)
 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:

Далее вам необходимо выбрать размер ключа:

Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]:

Значением следующей опции вы разрешаете или запрещаете доступ к файлам, которые не были зашифрованы при помощи eCrypfs:

Enable plaintext passthrough (y/n) [n]:

Шифровать или нет имена файлов:

Enable filename encryption (y/n) [n]:

Далее вы увидите сводку выбранных опций (их можно использовать в опциях монтирования в будущем):

Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=8f9887d2339cafb0

Если вы впервые монтируете и/или сигнатура этого монтирования не сохранена в кэше, то вас вежливо предупредят о том, что вы могли ввести пароль неверно:

WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Если всё ок, можно подтверждать монтирование:

Would you like to proceed with the mount (yes/no)? : yes

Чтобы избежать в будущем появления вышеуказанного предупреждения, вы можете добавить сигнатуру монтирования eCryptfs в файл:

Would you like to append sig [8f9887d2339cafb0] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? : yes

Если всё прошло успешно, вы получите соответствующее сообщение:

Successfully appended new sig to user sig cache file
Mounted eCryptfs

Теперь скопируем что-нибудь в смонтированный каталог:

# cp /etc/passwd /mnt/ecryptfs-demo/

Посмотрим его содержимое и размер:

# cat /mnt/ecryptfs-demo/passwd
...

# file /mnt/ecryptfs-demo/passwd
/mnt/ecryptfs-demo/passwd: ASCII text
# ls -l /mnt/ecryptfs-demo/passwd
-rw-r--r-- 1 root root 911 Feb  7 01:18 /mnt/ecryptfs-demo/passwd

Теперь отмонтируем eCryptfs и посмотри, как изменился наш файл:

# umount /mnt/ecryptfs-demo/

# file /mnt/ecryptfs-demo/passwd
/mnt/ecryptfs-demo/passwd: data
# ls -l /mnt/ecryptfs-demo/passwd
-rw-r--r-- 1 root root 12288 Feb  7 01:18 /mnt/ecryptfs-demo/passwd

Заглянув же вовнутрь файла, вы увидите там лишь двоичные данные.

pam_ecryptfs

Ещё одной довольно интересной и полезной штукой, идущей в поставке eCryptfs, является PAM-модуль pam_ecryptfs. Вызывается этот модуль во время логина пользователя и работает следующим образом. Если в домашнем каталоге обнаруживается файл ~/.ecryptfs/wrapped-passphrase, а также файл ~/.ecryptfs/auto-mount то модуль pam_ecryptfs расшифровывает содержимое файла ~/.ecryptfs/wrapped-passphrase, используя пароль пользователя. Далее расшифрованное содержимое используется в качестве пароля при монтировании каталога ~/.Private в точку ~/Private. Таким образом, пользователю не нужно дополнительно монтировать каталог с личными зашифрованными данными, всё происходит автоматически. Для того, чтобы модуль работал, он должен быть соответствующим образом объявлен в /etc/pam.d/common-auth:

auth    required        pam_ecryptfs.so unwrap

и в /etc/pam.d/common-session:

session optional        pam_ecryptfs.so unwrap

Зашифрованный персональный каталог Private

Чтобы пользователям было сухо и комфортно при самостоятельном создании Private-каталогов, разработчики включили в поставку eCryptfs специальный shell-скрипт ecryptfs-setup-private, который делает всю работу по подготовке персонального шифрованного хранилища:

1. создаёт каталоги  ~/.Private и ~/Private;
2. шифрует пароль монтирования и сохраняет его в ~/.ecryptfs/wrapped-passphrase;
3. позволяет настроить опции автомонтирования/размонтирования и т. п.

Работает сценарий очень просто и при запуске в режиме «по умолчанию» не требует никаких дополнительных параметров:

$ ecryptfs-setup-private

На следующий запрос введите ваш пароль, который используете при аутентификации в системе:

Enter your login passphrase:

После вам будет предложено ввести пароль, который будет использоваться при монтировании. Если не заполнять это поле, то пароль будет сгенерирован автоматически:

Enter your mount passphrase [leave blank to generate one]:

Очередное напоминание для забывчивых:

************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
  ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************

создание файлов, каталогов и тестирование:

Done configuring.
Testing mount/write/umount/read...
Testing succeeded.

И, наконец, сообщение о том, что теперь достаточно перевойти в систему, чтобы начать пользоваться благами цивилизации:

Logout, and log back in to begin using your encrypted directory.

Заново авторизуйтесь с системе и посмотрите, смонтировался ли каталог ~/.Private:

$ mount | grep Private
/home/ashep/.Private on /home/ashep/Private type ecryptfs (ecryptfs_sig=1ed127ee6eb43a05,ecryptfs_fnek_sig=2f5ceedfd83a052d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

Всё отлично, самое время проверить работоспособность нашего нового хранилища:

$ echo "Hello, world" > ~/Private/hello.txt
$ ls -l ~/.Private/
total 12
-rw-r--r-- 1 ashep ashep 12288 Feb  7 03:14 ECRYPTFS_FNEK_ENCRYPTED.FWYjLCvTq1c39ETk7I99JlZPttqOZToCEDxsV7hasxemXl1ISz2J-43cKk--

Теперь, когда вы выйдите из системы, модуль pam_ecryptfs автоматически размонтирует точку ~/Private, таким образом оставив ваши данные в зашифрованном каталоге ~/.Private. Если вы не хотите, чтобы каталог ~/Private монтировался и/или размонтировался автоматически, удалите соответственно файл ~/.ecryptfs/auto-mount и/или ~/.ecryptfs/auto-umount.

Также имейте ввиду, что сценарий ecryptfs-setup-private принимает ряд опций, при помощи которых вы можете управляет его поведением:

$ ecryptfs-setup-private --help

Usage:

/usr/bin/ecryptfs-setup-private [-f|--force] [-w|--wrapping] [--nopwcheck] [-n|--no-fnek]
  [-u|--username USER] [-l|--loginpass LOGINPASS]
  [-m|--mountpass MOUNTPASS]

 -f, --force      Force overwriting of an existing setup
 -w, --wrapping   Use an independent wrapping passphrase,
                  different from the login passphrase
 -n, --no-fnek    Do not encrypt filenames; If this flag is
                  omitted, and the kernel supports filename
                  encryption, then filenames will be encrypted
 -u, --username   Username for encrypted private mountpoint,
                  defaults to yourself
 -l, --loginpass  Login/Wrapping passphrase for USER,
                  used to wrap MOUNTPASS
 --nopwcheck      Do not check the validity of the specified
                  login password (useful for LDAP user accounts)
 --noautomount    Setup this user such that the encrypted private
                  directory is not automatically mounted on login
 --noautoumount   Setup this user such that the encrypted private
                  directory is not automatically unmounted at
                  logout
 -m, --mountpass  Passphrase for mounting the ecryptfs directory,
                  defaults to randomly generated 16 bytes
 -b, --bootstrap  Bootstrap a new user's entire home directory
                  Generates a random mount passphrase, which
          will be wrapped when the new login passphrase
          is set. SHOULD ONLY BE CALLED FROM 'adduser'.
 --undo           Provide instructions on how to undo an
                  encrypted private setup
   Be sure to properly escape your parameters according to your
   shell's special character nuances, and also surround the
   parameters by double quotes, if necessary.

Полное шифрование домашнего каталога

Идея хранения критически-важных данных в отдельном каталоге очень даже недурна собой, но не лишена очевидного недостатка. А именно: вы обязаны постоянно выбирать, что нужно шифровать, а что не нужно. Ну, или хранить вообще всё в Private-каталоге, что, мягко-говоря, не очень удобно. Вместо того, чтобы выделять отдельный каталог, не лучше ли зашифровать вообще весь домашний каталог? Именно это и предлагает вам Ubuntu при установке, и именно eCryptfs она для этого использует!

Если вы при установке выбрали опцию, показанную на скриншоте в начале статьи, то вы уже являетесь счастливым защищённым от врага пользователем. Если же это не так, но вам очень хочется спрятать от чужих глаз свои данные в случае чего и вы уже поняли, что eCryptfs — это именно то, что вам нужно для этого, то нет проблем!

Основная загвоздка при полном шифровании домашнего каталога состоит в том, что необходимо «вынести» каталог с зашифрованными данными за пределы точки монтирования. Разработчики Ubuntu решили проблему очень просто:

# ls -l /home/ashep/.Private
lrwxrwxrwx 1 ashep ashep 30 2011-12-07 04:44 /home/ashep/.Private -> /home/.ecryptfs/ashep/.Private

То есть, в домашнем каталоге находится лишь символическая ссылка, следуя которой, eCryptfs монтирует нужный каталог. При этом, точка монтирования переопределена в файле ~/.ecryptfs/Private.mnt и указывает на домашний каталог пользователя, т. е., в данном случае, на /home/ashep. Гениально и просто!

Чтобы избавить вас от необходимости перемещать файлы и настраивать вручную все пути и символические ссылки, разработчики предлагают shell-сценарий ecryptfs-migrate-home, который проделает всю «грязную» работу за вас. Также разработчики предупреждают о том, что этот сценарий может сделать ваши данные недоступными, если вдруг что-то пойдёт не так, поэтому обязательно сделайте резервную копию перед тем, как будете запускать скрипт! Также перед запуском убедитесь, что в системе установлены утилиты rsync и lsof, а также в том, что на разделе, где находится /home, имеется достаточно свободного места.

Сценарий необходимо запускать от root, передав в качестве параметра логин пользователя, который «мигрирует». Пользователь не должен находится в системе, а также от его имени не должно быть запущено ни одного процесса.

# ecryptfs-migrate-home -u ashep

INFO:  Checking disk space, this may take a few moments.  Please be patient.
INFO:  Checking for open files in /home/ashep

************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
  ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************

Done configuring.

INFO:  Encrypted home has been set up, encrypting files now...this may take a while.

========================================================================
Some Important Notes!

 1. The file encryption appears to have completed successfully, however,
    ashep MUST LOGIN IMMEDIATELY, _BEFORE_THE_NEXT_REBOOT_,
    TO COMPLETE THE MIGRATION!!!

 2. If ashep can log in and read and write their files, then the migration is complete,
    and you should remove /home/ashep.81yFQbNJ.
    Otherwise, restore /home/ashep.81yFQbNJ back to /home/ashep.

 3. ashep should also run 'ecryptfs-unwrap-passphrase' and record
    their randomly generated mount passphrase as soon as possible.
 4. To ensure the integrity of all encrypted data on this system, you
    should also encrypted swap space with 'ecryptfs-setup-swap'.
========================================================================

Если всё пройдёт успешно, то, как требует сценарий, мигрировавший пользователь должен войти в систему до перезагрузки. Также обратите внимание, что скрипт оставляет копию незашифрованных данных в отдельном каталоге (в приведённом примере это /home/ashep.81yFQbNJ), который необходимо удалить после того, как пользователь определит, что всё прошло успешно.

Теперь, когда мигрировавший пользователь войдёт в систему, его домашний каталог будет смонтирован следующим образом:

$ mount | grep Private
/home/ashep/.Private on /home/ashep type ecryptfs (ecryptfs_sig=d8324d90c49de223,ecryptfs_fnek_sig=c4c68e3df79abc0a,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

при этом ~/.Private является символической ссылкой на каталог за пределами домашней папки:

$ ls -l /home/ashep/.Private
lrwxrwxrwx 1 ashep ashep 30 Feb  7 03:48 /home/ashep/.Private -> /home/.ecryptfs/ashep/.Private

Всё, что нужно для того, чтобы осуществить задуманное, это добавить переменную GRUB_SAVEDEFAULT  в файл /etc/defaul/grub и установить её значение равным true:

GRUB_SAVEDEFAULT=true

После чего сообщить Grub о том, что по умолчанию мы хотим загружать именно последнюю выбранную ОС:

GRUB_DEFAULT="saved"

и обновить конфигурацию:

# update-grub2

Всё! Теперь в 98% случаев можно наслаждаться собственной ленью выбирать ОС для загрузки :) И да, не забудьте, что если каталог /boot вашей системы расположен на RAID, LVM или файловой системе ZFS, то Grub, по определённым причинам,  не сможет сохранять ваш последний выбор.

Давно подумываете о приобретении новенького телевизора в гостиную? Тем, кто собрался купить LED-телевизор Philips, будет не лишним посетить каталог интернет-магазинов, чтобы выбрать подходящую модель по низкой цене.

Расширение массива, которое можно проводить для всех уровней RAID, кроме нулевого, состоит из двух (трёх для RAID 4/5) этапов: добавления нового устройства, расширения массива (и, для RAID 5/6, расширения файловой системы). Обо всём по порядку.

Добавление нового устройства

Допустим, у нас имеется массив RAID-5 общей ёмкостью 16GiB, состоящий из трёх устройств, ёмкостью по 8 GiB каждое:

#  mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Tue Jan 31 17:23:21 2012
     Raid Level : raid5
     Array Size : 16774144 (16.00 GiB 17.18 GB)
  Used Dev Size : 8387072 (8.00 GiB 8.59 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Tue Jan 31 17:28:43 2012
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : debian-test0:0  (local to host debian-test0)
           UUID : a1f02ec1:81276abd:595fe0f9:8c9b3bd0
         Events : 48
    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       3       8       48        2      active sync   /dev/sdd

и к нему понадобилось добавить новый диск, находящийся за файлом /dev/sde, ёмкостью также 8 GiB. На устройстве /dev/md0 в данный момент у нас расположена файловая система ext4, размеров 16 GiB. Целью добавления нового устройства является увеличение размера файловой системы.

Добавить новое устройство к массиву очень просто:

# mdadm --add /dev/md0 /dev/sde
mdadm: added /dev/sde

Посмотрим на состояние массива:

# mdadm --detail /dev/md0
...
    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       3       8       48        2      active sync   /dev/sdd
       4       8       64        -      spare   /dev/sde

Как видим, диск /dev/sde добавился как запасной, то есть, он зарезервирован для массива на случай выхода из строя одного из дисков, и не используется. Теперь. когда в массиве есть свободное (неактивное) устройство, можно расширить массив:

# mdadm --grow --raid-devices=4 --backup-file=/root/md0_growing.backup /dev/md0
mdadm: Need to backup 3072K of critical section.

Обратите внимание на опцию --backup-file. Значением этой опции является путь к файлу, в который записываются критически-важные данные, пока массив расширяется. Содержимое этого файла пригодится вам в случае, если вдруг в момент расширения массива процесс будет внезапно прерван отключением питания сервера или чем-то подобным. Логично этот файл сохранять на диске, который не является частью расширяемого массива :)

Посмотрим на состояние массива теперь:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Tue Jan 31 17:23:21 2012
     Raid Level : raid5
     Array Size : 16774144 (16.00 GiB 17.18 GB)
  Used Dev Size : 8387072 (8.00 GiB 8.59 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Tue Jan 31 17:47:10 2012
          State : clean, recovering
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

 Reshape Status : 14% complete
  Delta Devices : 1, (3->4)

           Name : debian-test0:0  (local to host debian-test0)
           UUID : a1f02ec1:81276abd:595fe0f9:8c9b3bd0
         Events : 102
    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       3       8       48        2      active sync   /dev/sdd
       4       8       64        3      active sync   /dev/sde

Как видим, ёмкость массива осталась (пока) прежней, количество активных устройств увеличилось, как мы и просили, статус массива сменился на recovering, поскольку драйвер md занялся перестроением массива:

Reshape Status : 14% complete
Delta Devices : 1, (3->4)

После того, как процесс расширения будет завершён, посмотрим на размер массива:

Array Size : 25161216 (24.00 GiB 25.77 GB)

чего мы, собственно, и ожидали. Однако, как обстоят дела с файловой системой?

# mount /dev/md0 /mnt/md0
# df -h /dev/md0
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0               16G  172M   15G   2% /mnt/md0

Как видно, файловая система осталась прежнего размера, поскольку ей ничего неизвестно о наших операциях с массивом.

Расширение файловой системы

Чтобы изменить размер файловой системы ext2/¾, необходимо воспользоваться утилитой resize2fs, которая умеет изменять размер ФС на лету, если у вас ядро >= 2.6. Вызванная без параметров, утилита расширит файловую систему до максимально возможного размера:

# resize2fs /dev/md0
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/md0 is mounted on /mnt/md0; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/md0 to 6290304 (4k) blocks.
The filesystem on /dev/md0 is now 6290304 blocks long.

Умножив 6290304 блока на 4 KiB, получим 25162416 KiB или же 24 GiB, что соответствует размеру массива.

# df -h /dev/md0
Filesystem            Size  Used Avail Use% Mounted on
/dev/md0               24G  172M   23G   1% /mnt/md0

Задачей logwatch является избавить вас от необходимости создавать велосипеды в области автоматического анализа лог-файлов. Являясь модульной по своей архитектуре, утилита предоставляет вам возможность легко (если знаете Perl) расширять перечень анализируемых типов лог-файлов. Перечень же типов лог-файлов, которые logwatch умеет анализировать «из коробки», впечатляет: начиная от /var/log/messages и заканчивая логами CISCO-оборудования. Результаты анализа утилита группирует и помещает в отчёт, который может как выводиться в stdout, так и отправляться электронной почтой. Формат отчёта предлагается в двух вариантах: plaintext или HTML, при этом вы можете регулировать уровень детализации отчёта исходя из собственных потребностей.

Установка

Установить утилиту можно либо из исходников, либо же пользуясь штатным менеджером пакетов, благо logwatch присутствует в репозиториях всех популярных дистрибутивов. В Ubuntu/Debian утилита легко устанавливается командой:

# apt-get install logwatch

В процессе установки из пакета в Debian/Ubuntu logwatch автоматически не создаёт нужного ей для хранения временных файлов каталога /var/cache/logwatch, и вам необходимо сделать это самостоятельно:

# mkdir /var/cache/logwatch

Файлы конфигурации logwatch по умолчанию находятся в /usr/share/logwatch, и если вы намерены редактировать какой-либо из них, то делать это нужно не с оригинальным файлом, а с его копии, размещённой в каталоге /etc/logwatch.

Настройка

Основной файл конфигурации logwatch находится в /usr/share/logwatch/default.conf/logwatch.conf и прежде, чем редактировать, скопируйте его:

# cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/

Файл logwatch.conf очень хорошо само-документирован и настолько прост, что у вас не должно быть сложностей с его исправлением.  Среди опций, обычно затрагиваемых при конфигурации, можно отметить следующие:

• LogDir — путь к каталогу, в котором программа будет искать файлы, обычно это /var/log;
• TmpDir — путь к каталогу, в котором утилита будет размещать временные файлы. По умолчанию это /var/cache/logwatch, который мы с вами создали ранее;
• Output — указывает программе метод вывода отчёта. Может быть: stdout (в поток стандартного вывода), mail (почтовым сообщением) или file (в файл);
• Format — определяет формат отчёта. Может иметь значение text или html;
• MailTo — определяет адрес получателя отчёта, если Output = mail;
• MailFrom — определяет адрес отправителя отчёта, если Output = mail;
• Filename — задаёт путь к файлу отчёта, если Ouput = file;
• Archives — используется для указания утилите необходимости анализа не только текущих лог-файлов, но и архивных (например messages.1, messages.2.gz и т. п.). Принимает значения Yes или No;
• Range — за какой период времени отбирать анализируемые сообщения: All, Today или Yesterday;
• Detail — определяет уровень детализации отчёта. Может принимать как числовые значения от 0 (минимум детализации) до 10 (максимум). Также можно использовать синонимы: Low, Med и High, которые соответственно равны числовым 0, 5 и 10;
• Service — этот параметр указывает программе имя службы, логи которой необходимо анализировать. Может иметь значение All или имя службы (имя файла из каталога /usr/share/logwatch/scripts/services/). Если необходимо анализировать логи более одной службы, но не всех, то опцию Service следует определить несколько раз с указанием имён нужных служб, по одной за раз. Если же необходимо анализировать лог-файлы всех служб, кроме некоторых, то необходимо сначала определить Service = All, а затем перечислить мена ненужных служб, предварив их знаком «минус», например: Service = «-zz-network»;

Настраиваемые параметры анализатора для каждой службы  можно найти в /usr/share/logwatch/default.conf/services, а пути размещения лог-файлов каждой службы — в /usr/share/logwatch/default.conf/logfiles. Обычно значений параметров, определённых в этих файлах, достаточно для корректной работы, если в вашей системе все файлы хранятся в каталогах по умолчанию и имеют стандартные имена. Если же у вас в системе некоторые файлы расположены в специфических местах, то вам следует указать logwatch, где их искать. Рассмотрим на примере лог-файлов Apache, конфигурация для которого расположена в файле /usr/share/logwatch/default.conf/logfiles/http:

########################################################
#   Define log file group for httpd
########################################################

# What actual file?  Defaults to LogPath if not absolute path....
LogFile = httpd/*access_log
LogFile = apache/*access.log.1
LogFile = apache/*access.log
LogFile = apache2/*access.log.1
LogFile = apache2/*access.log
LogFile = apache2/*access_log
LogFile = apache-ssl/*access.log.1
LogFile = apache-ssl/*access.log

# If the archives are searched, here is one or more line
# (optionally containing wildcards) that tell where they are...
#If you use a "-" in naming add that as well -mgt
Archive = archiv/httpd/*access_log.*
Archive = httpd/*access_log.*
Archive = apache/*access.log.*.gz
Archive = apache2/*access.log.*.gz
Archive = apache2/*access_log.*.gz
Archive = apache-ssl/*access.log.*.gz

# Expand the repeats (actually just removes them now)
*ExpandRepeats
# Keep only the lines in the proper date range...
*ApplyhttpDate

Как видим, logwatch использует опцию LogFile для определения маски имён лог-файлов, и опцию Archive — для маски архивов. Обратите внимание, что маски файлов указываются относительно каталога, определённого в опции LogDir основного файла конфигурации.  Допустим, у вас есть отдельный каталог для хранения логов Apache, скажем, для отдельного домена. В этом случае необходимо скопировать файл /usr/share/logwatch/default.conf/logfiles/http.conf в /etc/logwatch/conf/logfiles и добавить в него несколько строк:

LogFile = apache2/mydomain.com/access.log
LogFile = apache2/mydomain.com/access.log.1
Archive = apache2/mydomain.com/access.log.*.gz

Запуск

После того, как файлы конфигурации готовы и проверены, достаточно лишь запустить утилиту:

# logwatch

и приступить к анализу полученной информации. Естественно, анализом лог-файлов стоит заниматься как можно чаще, поэтому обычно запуск logwatch осуществляют по расписанию, а многие дистрибутивы автоматически добавляют запуск logwatch в ежедневное расписание планировщика. Например, в Ubuntu/Debian:

$ ls -l /etc/cron.daily/*logwatch*
-rwxr-xr-x 1 root root 268 Mar  4  2011 /etc/cron.daily/00logwatch

Удачного вам анализа!

Чтобы получить подробную информацию, а также узнать, в каком состоянии находится массив, можно воспользоваться опцией --detail из режима misc утилиты mdadm. Ниже предоставлен пример вывода для массива RAID-1, состоящего из трёх дисков, который мы создавали в предыдущей заметке:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jan 12 12:24:16 2012
     Raid Level : raid1
     Array Size : 8387572 (8.00 GiB 8.59 GB)
  Used Dev Size : 8387572 (8.00 GiB 8.59 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Jan 20 04:09:29 2012
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

           Name : debian-test0:0  (local to host debian-test0)
           UUID : a51bea1f:59677b56:1a4a2cbe:8a258729
         Events : 196
    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd

Как видим, все три устройства являются активными и синхронизированными, иными словами всё хорошо. Теперь давайте представим (к сожалению, у меня нет возможности физически сломать одно из устройств, входящих в рассматриваемый массив), что один из дисков вышел из строя (вспомним, что для RAID-1/5/6 это допустимо). В случае «железных» проблем драйвер md автоматически пометит диск как сбойный и исключит его дальнейшее использование в массиве; в нашем же тестовом случае мы сделаем это программно. Итак, сделаем устройство /dev/sdc сбойным:

# mdadm --fail /dev/md0 /dev/sdc
mdadm: set /dev/sdc faulty in /dev/md0

И посмотрим, что изменилось:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jan 12 12:24:16 2012
     Raid Level : raid1
     Array Size : 8387572 (8.00 GiB 8.59 GB)
  Used Dev Size : 8387572 (8.00 GiB 8.59 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Jan 20 04:26:25 2012
          State : clean, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : debian-test0:0  (local to host debian-test0)
           UUID : a51bea1f:59677b56:1a4a2cbe:8a258729
         Events : 198

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       0        0        1      removed
       2       8       48        2      active sync   /dev/sdd
       1       8       32        -      faulty spare   /dev/sdc

Первое, что видим: массив стал неполным (degraded). хотя и продолжает функционировать (clean) :

State : clean, degraded

Сразу же оцениваем ситуацию. Вместо трёх активных устройств у нас осталось всего два:

Active Devices : 2
Working Devices : 2

и один диск сбойный:

Failed Devices : 1

В самом конце mdadm любезно предоставляет подробную информацию об устройствах, входящих массив, отметив что второй по счёту диск был удалён:

0       8       16        0      active sync   /dev/sdb
1       0        0        1      removed
2       8       48        2      active sync   /dev/sdd

а после — информацию об удалённом диске:

1       8       32        -      faulty spare   /dev/sdc

Из всего становится понятно, что наш RAID-1 работает на двух дисках и что надо-что-то решать с вышедшим из строя устройством. Прежде всего, его необходимо отключить от массива:

# mdadm --manage --remove /dev/md0 /dev/sdc
mdadm: hot removed /dev/sdc from /dev/md0

Далее уже по обстоятельствам. Первым делом стоит изучить содержимое логов ядра и попытаться определить причину сбоя. Причины могут быть разные, начиная от проблем с интерфейсным кабелем или питанием, до полного выхода диска из строя. Если физически с диском всё порядке и ошибка была вызвана, например, некачественным кабелем, то после её устранения и подключения диска, необходимо вернуть его в массив:

# mdadm --manage --re-add /dev/md0 /dev/sdc
mdadm: re-added /dev/sdc

Если всё в порядке, драйвер md тут же приступит к операции восстановления массива до «полного» состояния путём синхронизации данных на вернувшийся диск:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jan 12 12:24:16 2012
     Raid Level : raid1
     Array Size : 8387572 (8.00 GiB 8.59 GB)
  Used Dev Size : 8387572 (8.00 GiB 8.59 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Jan 20 04:57:37 2012
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 3% complete

           Name : debian-test0:0  (local to host debian-test0)
           UUID : a51bea1f:59677b56:1a4a2cbe:8a258729
         Events : 206
    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      spare rebuilding   /dev/sdc
       2       8       48        2      active sync   /dev/sdd

И, в случае успешного восстановления, массив вернётся к своему нормальному состоянию, которое было приведено в начале заметки.

Если же устройство, которое вышло из строя, к жизни вернуть не представляется возможным, то после замены его новым, вместо опции --re-add следует использовать опцию --add:

# mdadm --manage --add /dev/md0 /dev/sdc
mdadm: added /dev/sdc

Мониторинг

Вопрос, который возникает в первую очередь: а как, собственно, администратору узнать о том, что с массивом что-то неладно? Не заглядывать же постоянно в логи системы! Для целей мониторинга и оповещения о событиях, среди режимов работы утилиты mdadm предусмотрен режим monitor, позволяющий в качестве средств оповещения использовать как традиционный syslog, так и отправку уведомлений почтой. В этом режиме утилита, как правило, работает в режиме демона и запускается init-сценария во время старта системы.

В частности в Ubuntu/Debian запускающий сценарий называется mdadm и по-умолчанию включён. Если вы хотите получать уведомления не только в syslog, но и электронной почтой, добавьте исправьте строку в /etc/default/mdadm:

DAEMON_OPTIONS="--syslog"

на

DAEMON_OPTIONS="--syslog --mail root@localhost"

и перезапустите демон:

# service mdadm restart
Stopping MD monitoring service: mdadm --monitor.
Starting MD monitoring service: mdadm --monitor.

Тем, кому необходимо запускать mdadm в режиме монитора из собственных сценариев или же в целях тестирования, можно воспользоваться командой:

# mdadm --monitor --scan --syslog --mail root@localhost

Если же нужно, чтобы mdadm запустилась в режиме демона и не занимала консоль, просто добавьте опцию --daemonize:

# mdadm --monitor --scan --syslog --mail root@localhost --daemonize

Сама по себе идея не нова и используется многими, кто ощущает необходимость в структурном хранении необходимых, но не слишком часто используемых знаний. Кто-то хранит, как и я, всё на отдельных шпаргалках, дополняя и распечатывая их по мере необходимости, кто-то размещает подобные шпаргалки прямо на рабочем столе. Да много вариантов может быть, если проявить смекалку.

Недавно наткнулся в Сети на неплохую подборку частых полезностей, которую можно распечатать и использовать в настольном варианте, чем радостно делюсь с читателями. Блог автора, на всякий случай: http://freeworld.posterous.com. Также есть устаревшая онлайн-версия, для тех кому вдруг не подходит PDF-вариант.

Ещё одна шпаргалка размером с простыню, но весьма структурированная и мегаполезная есть здесь. На стену в полном объёме не вывесишь, но деражть на рабочем столе в виде PDF — вполне.

Для почитателей же «настольных» вариантов шпаргалок существует масса разнообразных обоев. Из интересных полезняшек, найденных в Сети, хочу поделиться популярной обойкой с коллекцией команд UNIX/Linux, разбитых по категориям:

небольшой подборкой памятной информации для убунтоидов:

и коллекцией шорткатов для пользователей Ubutu Unity:

Специально для защитников авторских прав: обои найдены в Сети и точное авторство каждого из них установить сейчас уже трудно, да и не вижу смысла. Гугл в помощь! ;)

Сборка массива вручную

Для сборки ранее созданного массива вам понадобится режим assemble утилиты mdadm. Допустим, наш ранее созданный массив имел конфигурацию RAID-1 и состоял из трёх устройств: /dev/sdb, /dev/sdc и /dev/sdc, и был создан командой:

# mdadm --create --raid-devices=3 --level=raid1 /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Вспомним, что сразу после создания массива, утилита mdadm автоматически активирует его, то есть собирает и делает доступным через блочное устройство /dev/mdX. Если же вы остановите активный массив при помощи команды (предварительно размонтировав файловые системы, располагающиеся в массиве):

# mdadm --stop /dev/md0

или же просто перезагрузите систему, то для того, чтобы опять активировать массив, вам необходимо его собрать. Зная, на каких устройствах хранятся элементы массива, можно произвести его сборку:

# mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Обратите внимание, что мы не указываем уровень конфигурации RAID, поскольку об этом утилита mdadm узнаёт из суперблоков элементов массива. Если всё прошло успешно, вы получите сообщение:

mdadm: /dev/md0 has been started with 3 drives.

Вспомним, что проверить состояние массива можно в файле /proc/mdstat:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (auto-read-only) raid1 sdb[0] sdd[2] sdc[1]
      8387572 blocks super 1.2 [3/3] [UUU]
          resync=PENDING
unused devices: <none>

Автоматическая сборка массива

Ещё одним преимуществом, которое даёт использование суперблоков (а точнее постоянных суперблоков, смотрите ниже), является возможность «автосборки» массива, когда вам не нужно перечислять устройства, входящие в состав массива. mdadm отыщет их самостоятельно:

# mdadm --assemble --scan
mdadm: /dev/md/0 has been started with 3 drives.

Как видим, утилита без особых трудностей и посторонней помощи отыскала все нужные устройства и собрала их, активировав массив /dev/md/0.

Автоматическая сборка массива во время загрузки системы

В старые-добрые времена, когда арбузы на деревьях были совсем ещё зелёные, системным администраторам приходилось вручную описывать массивы и их компоненты в специальном файле /etc/raidtab, чтобы драйвер md мог разобраться что к чему. Подход вроде бы традиционный и практичный, однако что делать, если RAID-массив необходимо собрать раньше, чем смонтирована ФС, на которой располагается файл /etc/raidtab (ситуация типична для случаев, когда необходимо загрузить систему, расположенную на RAID-массиве)? Выход был найден: были придуманы постоянные суперблоки (Persistent Superblocks).

Постоянные суперблоки располагаются на каждом устройстве, входящем в массив и содержат в себе всю необходимую информацию для того, чтобы драйвер md смог собрать массив. Иными словами файл конфигурации /etc/raidtab просто «перенесли» прямо в область суперблоков. Таким образом, когда ядро загружает драйвер md, у того есть возможность тут же собрать массив, просканировав доступные в системе блочные устройства на предмет наличия постоянных суперблоков. Например, предлагаю взглянуть на фрагмент файла /var/log/dmesg с системы в которой сконфигурирован массив, рассматриваемый в примерах выше:

[    5.022639] md: bind<sdc>
[    5.026939] md: bind<sdd>
[    5.029737] md: bind<sdb>
[    5.060274] raid1: raid set md0 active with 3 out of 3 mirrors
[    5.060503] md0: detected capacity change from 0 to 8588873728

В следующей статье мы рассмотрим основы мониторинга программных RAID-массивов.

Программный RAID является прекрасным бюджетным решением, однако если речь идёт о больших объёмах данных, повышенной отказоустойчивости и безопасности хранения данных, лучше использовать иные решения, например массив хранения DELL MD3220 или ему подобные. Поддержка SATA и SAS накопителей со скоростью передачи до 6 гигабит на порт, горячая замена дисков, одновременная поддержка до восьми серверов, а также создание до 128 моментальных копий — всё это повысит надёжность и скорость работы вашей инфраструктуры хранения данных, а также заметно снизит количество головной боли.

Метаданные md

Каждое устройство в RAID-массиве md может содержать метаданные (не путайте с метаданными файловых систем), иногда называемые суперблоком (superblock). Информация из суперблоков на устройствах, входящих в массив, позволяет драйверу md корректно заново собирать массив после его остановки. Особенностью суперблока является то, что данных хранимые в нём, содержатся в процессорно-независимом формате, то есть вы можете свободно перемещать RAID-массив между различными платформами.

Массивы без метаданных

Наличие суперблоков является крайне желательным в большинстве случаев, однако есть ситуации, когда лучше их не использовать:

• в предыдущих версиях драйвер md поддерживал только линейные (linear) и RAID-0 конфигурации, в которых суперблок не использовался, поскольку в данных случаях это не критически-важный момент. Вы можете пересобрать такой массив, включив использование суперблоков, но md поддерживает работу и без них из соображений обратной совместимости;
• являясь прозрачным слоем поверх устройств, предназначенным для тестирования массивов, псевдо-уровень RAID FAULTY не нуждается в суперблоках;
• поскольку MULTIPATH-массивы для md представляют всего одно устройство, смысла в использовании суперблока попросту нет;
• в некоторых случаях выгоднее не использовать суперблоки в RAID1-массивах.

Режимы работы mdadm

Утилита mdadm, речь о которой шла в предыдущей заметке, имеет 9 основных режимов работы. В повседневной жизни обычно требуются только первые три, в то время как остальные пригодятся в случае восстановления массива после сбоев или изменения его параметров.

• Режим Create предназначен для создания массивов, размещая суперблоки на каждом устройстве;
• в режиме Assemble утилита mdadm выполняет сборку массива из компонент, созданных ранее. Компоненты для сборки могут быть как указаны вручную, так и найдены автоматически. Обычно необходимость в этом режиме работы mdadm возникает у сценариев загрузки системы;
• режим Monitor используется для наблюдения за изменением состояния устройств массива. Поскольку в конфигурациях Linear и RAID0 не может быть spare (запасных), fault(сбойных) и missing (потерянных) устройств, то для таких конфигураций режим Monitor работать не будет, ибо нечего отслеживать;
• в режиме Build утилита mdadmможет выполнять сборку массива из устройств, не содержащих суперблоков. При работе с массивами такого типа для mdadm нет разницы между созданием нового массива или сборкой существующего, поскольку у неё нет возможности определить, инициализировались ли уже указанные устройства или нет. Пользуйтесь этим режимом только в том случае, если вы абсолютно уверены  в том, что вы делаете;
• режим Grow используется в случаях, когда вам необходимо расширить или каким-либо образом реорганизовать ваш массив. На сегодняшний день можно расширять массив путём изменения размера составных устройств в массивах RAID ¼/5/6 и количества активных устройств в массивах RAID1;
• режим Manage предназначен для выполнения разнообразных операций, вроде добавления запасных или удаления сбойных устройств;
• команды режима Misc предназначены для выполнения «всяких-разных» операций, которые не вошли в предыдущие режимы;
• режим Incremental Assembly позволяет добавлять или удалять одно устройство в/из массива;
• в режиме Auto-detect утилита просит ядро Linux активировать автоматически определённые массивы.

Планирование массива

Прежде чем создавать массив, естественно, нужно определиться, из чего он будет состоять. Обратите внимание, что для mdadm устройством является не обязательно физическая «железка». Это может быть любое блочное устройство, т. е. даже дисковые разделы. На данном этапе предположим, что у нас имеется три одинаковых жёстких диска одинакового размера: /dev/sdb, /dev/sdc и /dev/sdd, из которых мы и создадим наш первый массив.

Создание массива

В общем случае новый RAID-массив создаётся  следующим образом:

# mdadm --create --raid-devices=<n> --level=<level> <md-device> <block-device-1> ... <block-device-n>

где:

• n — количество устройств, входящих в массив;
• level — уровень RAID, один из: linear, raid0, raid1, raid4, raid5, raid6, raid10 или multipath (опций на самом деле больше, многие из которых являются синонимами, но пока что опустим их, дабы не загромождать статью);
• md-device — путь к файлу блочного устройства, которое будет представлять массив;
• block-device-1 ... block-device-n — компоненты массива устройства.

Linear

Как уже говорилось, в этом режиме компоненты массива последовательно «склеиваются» и в массивах такого типа нет избыточной информации для восстановления данных в случае чего. Данный тип массива может пригодиться вам, если необходимо «слепить» из нескольких небольших разделов и/или дисков один раздел большой ёмкости, а надёжность хранения данных вас не особо заботит. В случае с нашими тремя дисками команда создания linear-массива будет выглядеть так:

# mdadm --verbose --create --raid-devices=3 --level=linear /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Если всё прошло успешно, mdadm сообщит вам об этом и автоматически активрует массив:

mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

Не забывайте, что если хотя бы одна из компонент массива выйдет из строя, вы потеряете весь массив!

RAID-0

Если у вас есть два или более устройств примерно одного размера, вы можете создать RAID-0-массив:

# mdadm --verbose --create --raid-devices=3 --level=raid0 /dev/md0 /dev/sdb /dev/sdc /dev/sdd
mdadm: chunk size defaults to 512K
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

Так же, как и в случае с linear-массивом, в RAID-0 не создаётся информация для восстановления, так что если хотя бы одна из компонент массива выйдет из строя, вы потеряете весь массив!

RAID-1

Вот, собственно, здесь начинается RAID в буквальном (redundant, не забыли?) смысле этого слова. Представим, что у нас имеется два диска, которые мы хотим объединить в зеркало. Нет ничего проще:

# mdadm --verbose --create --raid-devices=2 --level=raid1 /dev/md0 /dev/sdb /dev/sdc

Одной очень приятно «фишкой» md является возможность иметь т. н. spare (запасные) устройства, которые могут автоматически подключаться ядром в случае выхода из строя компонент массива. Именно в RAID-1 можно начинать пользоваться этой возможностью, поскольку для двух предыдущих уровней эта функция не поддерживается по понятным причинам. Допустим, необходимо создать такой же массив, как мы только что создали, но при этом нужно указать системе, что имеется один запасной диск /dev/sdd, который необходимо ввести в строй взамен вышедшего, если вдруг такое произойдёт. Делается это при помощи опции --spare-devices, передав ей количество запасных устройств, а также пути к их файлам:

# mdadm --verbose --create --raid-devices=2 --level=raid1 /dev/md0 /dev/sdb /dev/sdc --spare-devices=1 /dev/sdd

Чтобы узнать, в каком состоянии находится синхронизация данных между устройствами массива, необходимо взглянуть на содержимое файла /proc/mdstat:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdd[2](S) sdc[1] sdb[0]
      8387572 blocks super 1.2 [2/2] [UU]
      [=>...................]  resync =  6.2% (524224/8387572) finish=4.4min speed=29123K/sec

Из содержимого приведённого примера видно, что синхронизация закончена на 6.2%, идёт на скорости 29123К/сек и должна закончиться приблизительно через четыре с половиной минуты. Синхронизация выполняется системой в фоновом режиме в то время, когда сама система простаивает. То есть, влияние синхронизации на скорость работы системы сведено к минимуму.

RAID-4/5/6

При наличии трёх и более дисков, вы можете создать массив уровня RAID-4/5.

# mdadm --verbose --create --raid-devices=3 --level=raid5 /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Конечно же, на этих уровнях никто не отменял возможности использовать запасные диски:

# mdadm --verbose --create --raid-devices=3 --level=raid5 /dev/md0 /dev/sdb /dev/sdc /dev/sdd --spare-devices=1 /dev/sde

А если у вас в запасе есть 4 и более дисков, можно позволить себе RAID-6:

# mdadm --verbose --create --raid-devices=4 --level=raid6 /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde

или

# mdadm --verbose --create --raid-devices=4 --level=raid6 /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde --spare-devices=1 /dev/sdf

Состояние массивов

Узнать, в каком состоянии находятся массивы и их компоненты, можно из содержимого файла /proc/mdstat, как мы это делали в разделе о создании массива RAID-1. Подробнее о том, что можно извлечь из инофрмации,хранящейся в этом файле, мы поговорим в следующих статьях.

Создание разделов и файловых систем, монтирование

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

# fdisk /dev/md0

и/или файловую систему:

# mkfs.ext4 /dev/md0p1

смонтировать её:

# mount /dev/md0p1 /mnt/raid0

и пользоваться на здоровье ;)

Что дальше

В следующей заметке мы рассмотрим процесс сборки массива из существующих компонент, а также настройку его автоматической сборки при загрузке системы.

Пока сисадмины настраивают RAID-массивы, офис не стоит на месте, и копировальная техника то и дело требует дозаправки. Качественная заправка картриджей Canon и других известных производителей — в сервисном центре ОРСЕР. Любые работы, связанные с принтерами и копирами, качественно и в срок!

Драйвер ядра

Первое, с чего необходимо начать, это с проверки наличия драйвера md в ядре вашей системы. Именно драйвер md (аббревиатура от Multiple Devices) занимается управлением всем Software RAID хозяйством в Linux и без его присутствия в системе работать ничего не будет.

md поддерживает: 1 (mirror — зеркалирование), 4 (разделение данных между несколькими дисками, плюс отдельный диск для хранения данных чётности), 5 (то же, что и RAID-4, но данные чётности разпределяются между всеми дисками массива), 6 (то же, что и RAID-5, но количество данных чётности удвоено) и 10 (mirror из нескольких stripe-массивов) уровни RAID, то есть все уровни, которые используются на сегодняшний день.

Кроме всего прочего md поддерживает так называемые псевдо-RAID уровни (то есть, массивы, не содержащие избыточной информации для восстановления): RAID0 (stripe) — разделение данных между несколькими дисками), LINEAR — последовательно объединённые диски, MULTIPATH — набор из нескольких интерфейсов к одному и тому же устройству, а также FAULTY — предназначенный для тестирования уровень поверх одного устройства, в котором могут эмулироваться сбои и ошибки в работе.

Обо всём перечисленном и даже больше мы поговорим с следующих статьях, а теперь самое время проверить, как обстоят дела в поддержкой программного RAID в вашей системе.

Драйвер md в системе может быть как частью ядра, так и динамически-загружаемым модулем. При написании этой заметки использовалась Debian 6 с ядром «из коробки» со всеми необходимыми модулями:

# ls -1 /lib/modules/2.6.32-5-686/kernel/drivers/md
...
faulty.ko
linear.ko
md-mod.ko
multipath.ko
raid0.ko
raid10.ko
raid1.ko
raid456.ko
raid6_pq.ko
...

Если вы собирали ядро самостоятельно или набор «стандартных» модулей вашего дистрибутива отличается, то вам необходимо пересобрать ядро соответствующим образом.

После того, как все необходимые модули готовы, попробуем загрузить основной модуль драйвера md:

# modprobe md_mod

В случае, если вы не получили никаких ошибок в процессе загрузки модуля, в файловой системе /proc должен появится файл /proc/mdstat, содержащий информацию ос состоянии RAID-массивов в вашей системе. Пока в системе нет ни одного массива, содержимое этого файла будет таким:

# cat /proc/mdstat
Personalities :
unused devices: <none>

Утилита mdadm

Как можно догадаться из названия утилиты, её предназначение — управление md-устройствами. Набор функций, выполняемых этой утилитой настолько огромен, что является темой отдельных статей. Таким образом, знакомиться с возможностями этой утилиты мы будем по ходу событий, на практике.

Если вы используете один из популярных дистрибутивов Linux, то с установкой mdadm проблем быть не должно. Так, например, в Debian/Ubuntu:

# apt-get install mdadm

в Gentoo:

# emerge mdadm

в RedHat/CentOS:

# yum install mdadm

Те же, кто любит или по каким-то другим причинам вынужден собирать ПО из исходников, может получить последнюю версию исходных кодов mdadm и скомпилировать утилиту самостоятельно.

На этом всё. Ваша система готова к созданию и работе с программными RAID-массивами. В следующей заметке мы рассмотрим режимы работы утилиты mdadm, узнаем что такое метаданные в понимании драйвера md, как и где они могут располагаться, а также создадим свой первый RAID0-массив.

В предыдущих заметках мы выяснили, что одни уровни RAID нацелены на увеличение производительности, другие — на повышение надёжности хранения данных за счёт добавления избыточности. Существуют также некоторые базовые уровни RAID, которые пытаются решать обе задачи одновременно, однако у них получается не совсем хорошо, поскольку в их реализации больше уделено внимания избыточности, нежели производительности. Через какое-то время стало очевидно, что используя любой из базовых уровней RAID, не удастся достичь «всего и сразу». Именно поэтому люди придумали использовать одновременно сразу несколько уровней RAID, объединяя их в один, что позволило достичь лучшего соотношения «надёжность/производительность».

В следующих нескольких статьях мы с вами рассмотрим дальнейшее развитие концепции RAID, которая подразумевает объединение нескольких уровней RAID в один и называется «вложенный RAID», иногда называемый «гибридный RAID».

Причины, по которым был придуман и используется вложенный RAID, остаются теми же: стремление повысить надёжность хранения и/или производительность обработки данных. Обычно вложенный RAID используется там, где нужно максимально сбалансировать показатели надёжности и производительности. Изначально вложенный RAID разрабатывался как средство повышения производительности избыточных RAID, таких как RAID-1 или же для повышения надёжности производительных RAID, таких как RAID-0.

Вложенный RAID можно представить в виде приготовления блюда. Например, вы берёте RAID-1, затем добавляете к нему RAID-5, смешиваете получившееся с RAID-0 для повышения производительности и получаете готовое «блюдо». Чуть позже мы с вами ещё вернёмся к этой метафоре, когда будем рассматривать технические подробности реализации программного RAID под Linux.

Вложенные уровни RAID обычно обозначаются набором цифр, а не одиночной цифрой, как это принято в базовых уровнях RAID. Чаще всего вложенный RAID помечается двухразрядным числом и записывается как «RAID-X+Y» или «RAID-XY» (в случае использования двух уровней), где X и Y — уровни базовых RAID, которые использовались при построении вложенного уровня. Например, вложенный уровень может записываться как «RAID-10». В этом случае X=RAID-1, а Y=RAID-0. В описанной схеме нумерации вложенных уровней RAID первое слева число, X — это номер нижнего уровня. Таким образом, в приведённом примере записи RAID-10, на нижнем уровне будет находится RAID-1.

Вторая слева цифра в двухзначном номере вложенного RAID определяет номер верхнего уровня. В случае с RAID-10, где нижним уровнем является RAID-1, верхним уровнем становится RAID-0. Таким образом, RAID-0 работает поверх RAID-1 (производительность поверх надёжности).

Порядок следования цифр в номере гибридного RAID, как вы уже поняли, очень важен. RAID-X+Y это не тоже самое, что RAID-Y+X. RAID-Y+X строится, начиная с RAID-Y внизу, заканчивая RAID-X наверху. В RAID-X+Y всё строится с точностью, но наоборот: X — снизу, Y — сверху.

Вы можете подумать, что RAID-10 и RAID-01, должно быть, одинаковы в плане показателей производительности и надёжности. В какой-то степени это предположение истинно, эти два гибридных уровня действительно имеют примерно одинаковые характеристики. Однако между ними обнаруживается огромная разница в случаях, когда дело доходит до выхода гибридного массива из строя. Речь идёт о количестве дисков, с которых необходимо считать и на которые нужно произвести запись в процессе регенерации. В последующих заметках мы с вами рассмотрим этот момент.

Ну и напоследок. Вы вовсе не обязаны ограничиваться двумя базовыми уровнями при построении гибридного RAID. Вы можете строить настолько глубокий вложенный RAID, насколько позволит программное и/или аппаратное обеспечение, которое вы используете. Так что, никто не мешает вам соорудить что-нибудь наподобие RAID-XYZ.

В следующей статье мы рассмотрим принцип построения и работы RAID-0+1.

Источник: linux-mag.com

Всем поклонникам популярной мобильной платформы от Apple посвящается. Большая коллекция приложений для iPhone и iPad, обзоры популярных приложений, бесплатные игры. Всё это — на сайте appinside.ru!

Файловые системы, как правило, состоят из двух частей:

1. метаданных, т. н. данных о данных;
2. самих данных.

Первый пункт звучит довольно забавно: «данные о данных», однако он является ключевым моментов в работе файловых систем. Если быть более точным, метаданные содержат информацию о данных, хранящихся на диске, таких как имена файлов, время их создания, права доступа и так далее. Роль метаданных крайне важна, поскольку без них файловая система представляла бы из себя лишь набор байт, в котором невозможно было бы определить что и где физически находится на диске.

Индексный дескриптор

В общем случае в файловых системах операционных систем *NIX с каждым файлом и каталогом связан соответствующий дескриптор — inode, который обычно обозначается целым числом и в котором хранятся метаданные. Происхождение термина «inode» точно неизвестно. Из статьи на Википедии, согласно словам Дениса Ритчи, одного из первых разработчиков UNIX-систем:

Честно говоря, я мало об этом знаю. Это был всего лишь термин, который мы начали использовать. 'Индекс', как я полагаю, использовался из-за несколько необычной структуры файловой системы, хранившая информацию о доступе к файлам в плоском (двумерном) массиве на диске, а вся информация об иерархии каталогов хранилась отдельно. Таким образом, и-номер являлся индексом в этом массиве, и-нод — выбранным элементом массива. (Приставка 'и-' использовалась в первой версии руководства; со временем дефис перестали употреблять).

Каким образом создаются дескрипторы и вообще, создаются ли они, зависит от реализации конкретной файловой системы. Некоторые файловые системы создают дескрипторы в момент создания файловой системы, в результате располагая фиксированным количеством индексных дескрипторов, то есть фиксированным пределом количества файлов, хранящихся в ФС.  Так, например, работает файловая система Ext-3. Таким образом получается, что вы в какой-то момент не сможете создать файл, даже если свободного пространства на диске будет достаточно. Такое случается крайне редко, но, тем не менее, не исключено. Если, используя такую файловую систему, вам понадобиться больше индексных дескрипторов, вам придётся заново создавать ФС, средств увеличить количество inode без потери данных нет.

Одним из способов обойти вышеописанное поведение ФС являются экстенты и/или динамическое выделение индексных дескрипторов. Такие системы могут динамически расширяться и/или увеличивать количество inode.

Индексные дескрипторы не являются чем-то мистическим, они являются частью Linux. Вы можете увидеть их присутствие, например при помощи команды 'ls -i':

laytonjb@laytonjb-laptop:~/Documents/FEATURES/STORAGE088$ ls -il
total 1024
8847368 -rw-r--r-- 1 laytonjb laytonjb 115020 2011-04-24 07:33 Figure_1.png
8847366 -rw-r--r-- 1 laytonjb laytonjb  39200 2011-04-24 07:38 Figure_2.png
8847361 -rw-r--r-- 1 laytonjb laytonjb  30691 2011-04-24 07:40 Figure_3.png
8847367 -rw-r--r-- 1 laytonjb laytonjb  28835 2011-04-24 07:42 Figure_4.png
8847363 -rw-r--r-- 1 laytonjb laytonjb 115103 2011-04-24 07:43 Figure_5.png
8847362 -rw-r--r-- 1 laytonjb laytonjb 125513 2011-04-24 07:44 Figure_6.png
8847365 -rw-r--r-- 1 laytonjb laytonjb  77831 2011-04-24 07:44 Figure_7.png
7790593 -rw-r--r-- 1 laytonjb laytonjb  15632 2011-04-26 19:40 storage088.html
8847364 -rw-r--r-- 1 laytonjb laytonjb    183 2011-04-24 07:33 text1.txt
3089319 drwxr-xr-x 2 laytonjb laytonjb   4096 2011-04-24 07:54 TRIM_WORKS
5554211 -rw-r--r-- 1 laytonjb laytonjb 449110 2011-04-24 07:52 trim_works.tar.gz

Числа в первом столбце и есть номера inode. Также обратите внимание на каталог "TRIM_WORKS”, который тоже имеет номер inode, связанный с ним.

Linux, которая в большинстве реализаций является POSIX-совместимой ОС, требует обязательного наличия атрибутов файла, располагающегося на ФС, в частности:

• размер файла в байтах;
• идентификатор устройства;
• идентификатор владельца файла;
• идентификатор группы-владельца файла;
• режим доступа к файлу, определяющий кто и какой доступ имеет к файлу;
• дополнительные системные и пользовательские флаги, которые дополнительно могут ограничивать доступ к файлу и его модификацию;
• таймштампы, отражающие время модификации индексного дескриптора (ctime, changing time), время модификации содержимого файла (mtime, modification time) и время последнего доступа к файлу (atime, access time);
• счётчик для учёта количества жёстких ссылок на файл;
• указатели на физические блоки диска, в которых хранится содержимое файла (об этом ниже).

Любая POSIX-совместимая Linux ОС должна хранить указанную информацию в индексных дескрипторах или же быть способной представлять эту информацию так, будто бы она хранится в них. Например, ReiserFS не использует традиционные inode. Вместо этого для хранения метаданных в ReiserFS используется комбинированное B±дерево, к роли ключей которого выступают универсальные идентификаторы объектов. Однако при запросе информации ReiserFS предоставляет её в POSIX-совместимом виде.

Структура указателя индексного дескриптора

Согласно POSIX, в файловой системе есть элемент, называемый inode pointer structure — структурой указателя индексного дескриптора. Как говорилось выше, inode хранит метаданные, включая список блоков на диске, в которых располагается непосредственно содержимое файла. Структура указателя индексного дескриптора используется для извлечения списка дисковых блоков, ассоциированных с файлом.

Согласно описанию с Википедии, эта структура хранит 11 или 13, а в самых современных ФС — 15 указателей. Назначение этих указателей следующее:

• 12 указателей используются для хранения номеров блоков, содержащих непосредственно данные файла, и называются прямыми указателями;
• один одиночный косвенный указатель. Этот указатель указывает на блок прямых указателей, хранящих данные файла;
• один двойной косвенный указатель. Указывает на блок одиночных косвенных указателей;
• один тройной косвенный указатель. Указывает на блок двойных косвенных указателей.

Чтобы вышеописанное было проще понять, взгляните на иллюстрацию, взятую с Википедии:

На рисунке выше вы можете видеть прямые, одиночные косвенные и двойные косвенные блоки. Тройные косвенные блоки одним уровнем глубже двойных.

Заключение

Концепция inode является фундаментальной частью *NIX , а также других ОС. По своей сути смысл inode является очень простым для понимания — это всего лишь метаданные о данных. То есть, он хранит полезную информацию о данных, хранящихся на диске. Такой информацией является, например, идентификатор владельца файла, идентификатор его группы-владельца, права доступа к файлу, а также различные временные штампы. Таким образом, когда вы используете, например, команду 'ls', она извлекает информацию о метаданных файлов и каталогов из их индексных дескрипторов.

Некоторые файловые системы, например Ext3, создают все индексные дескрипторы в момент создания файловой системы. Такой подход может быть не совсем удачным, поскольку вы не сможете создавать новые файлы в случае, если все доступные inode будут использованы, даже если на диске достаточно места. Чтобы избежать подобных ограничений, можно использовать файловые системы вроде Ext4 и XFS, которые создают индексные дескрипторы по мере необходимости.

Понимание назначения inode может оказаться весьма полезным для читателя. Вооружённые даже базовыми знаниями об inode, вы сможете лучше оценивать возможности различных файловых систем при выборе подходящей для вашей задачи.

Источник: linux-mag.com

Давно ищете хорошего сотрудника в свой бизнес и уже соврешенно сбились с ног? Подобрать и подготовить хорошего продавца для вас смогут в агенстве «Фрегат». Кстати, тем, кто ищет хорошую работу, тоже будет полезно обратиться в агенство.