Страницы

вторник, 30 октября 2012 г.

Часть IV. Предварительные меры для восстановления данных. Pre-fail. Saved data.

В связи с переходом к использованию LVM, GPT, RAID технологий для хранения пользовательских данных, настоятельно возникла внутренняя тревога - беспокойство о их сохранности.

Т.к. объем используемых винчестеров превысил 1ТБ, и количество данных сохраняемых на одном винчестере возросло. Возросло так, что даже простое копирование файлов с винчестера на винчестер отнимает день - два и это при подключении по SATA. Правда и при подключении по USB, сроки такие-же. Это "благодаря" миллиону мелких файлов, которые резко снижают производительность копирования, местами до 10 МБ/c, а десятка легко "пролезает" через usb.

Ранее, в части первой, я уже упоминал, о простейших операциях позволяющих повысить шансы на восстановление информации. Это и резервное копирование GPT-разметки дисков, а также твердые копии.

Важную роль для восстановления информации с дисков с программными ошибками играет разнообразная информация о внутреннем устройстве эксплуатируемых файловых систем (lvm, raid), их способ организации хранения.

Следующую важную роль играет хладнокровие пользователя, столкнувшегося с отказом системы хранения данных. У меня например, когда я случайно затираю что-то ценное, резко приливает кровь к голове. Через несколько минут, постепенно проходит. Правда резервные копии имеются, но не всегда доступные (далеко).
В такие моменты, главное не начать, "впопыхах" восстанавливать данные. Я практикую способ, пойти прогуляться, подышать воздухом. Можно на балкон. Т.е. отвлечься и начать думать.

Со временем, после первоначального конфигурирования, посылы, вызвавшие то или иное конфигурационное действие, забываются. Поэтому я практикую "писанину". Конфигурационные файлы обрастают комментариями, веду бортовые журналы дисков (обычный файл на томе). Пишу заметки. Печатаю.

В этой же заметке, я хочу собрать различные программные и конфигурационные ухищрения, позволяющие повысить шансы на восстановление данных с томов, уничтоженных программными средствами. Например, форматирование 2ТБ винчестера.

Эта заметка пополняемая со временем.

Мероприятия по сохранению информации

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

1. Сохранение структуры разметки. Разметка диска меняется очень редко. И даже её, трёхлетняя твердая копия, с данным о границах разделов, может помочь составить первоначальное представление.
Очень важно, иметь на одном листе - идентификационные данные диска и структуру разметки. Дополнительные данные, такие как дата, местоположение диска и др. имеют смысл. Т.к. по прошествии времени, очень много забывается.

2. Структура разметки не дает информации о применявшихся файловых системах на разделах. Эту информацию также надо извлечь заранее и сохранить в понятном виде, распечатать.

3. Для вложенных разметок (LVM) также доступными системными средствами, извлечь и сохранить и распечатать информацию о конфигурации.

4. Составление списка файлов тома. Для редко изменяемых томов хранения, полезным будет составить список всех файлов хранящихся на томе.

5. Составление контрольных сумм файлов тома. Эта операция по длительности может превысить разумные сроки. Возможно выборочное, для особо ценных файлов. Требуется мощный процессор.

6. При разметке дисков, желательно следовать стандартам (см. Часть I).

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

8. Для хранения важных файлов, не следует использовать различные сжимающие программы. Т.к. сжатие данных - это превращение известной структуры файла в неизвестную. А существующие архивы, если это позволяет их содержимое, распаковывать. Например, очень часто файлы пришедшие по электроной почте, через Интернет, упакованы для уменьшения передаваемого объема. Смысла хранить их в таком виде, обычно нет. Они недоступны для поиска (обычно), сложны (невозможны) для восстановления.

9. Построение и настройка системы резервного копирования. Например, RAID-1 тянет за собой покупку 3 дисков, минимум. 2 - в RAID, 1 - для резервной копии. А ещё, он должен быть отлючен, а это внешняя коробка.

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

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

12. Настройка мониторинга дисков по аттрибутам SMART, для выявления на ранней стадии, сбоя.

13. Разделение данных. "Холодные" данные, хранить в дефрагментированном виде. "Горячие" данные, выносить в отдельные диски, массивы, резервы.

14. Исходные коды, также хранить на дефрагментированных томах. Возможно преобразовать корпус текста в формат, наиболее подходящий для восстановления автоматическими средствами. Например, текстовые файлы преобразовать в RTF. RTF - файл, очень хорошо находится на диске, по его специфическим сигнатурам, а текстовые не очень. Хотя текстовые файлы хорошо просматриваются в бинарном виде, а где у них начало - определить сложно, как и конец.

15. Применять файловые системы, с запретом фрагментации. Либо добиваться дефрагментации системными средствами, либо сторонними утилитами.

16. Применять файловые системы, резервирующие свои служебные области, в нескольких местах на диске.

17. Следовать ограничениям применяемых файловых систем и находить их пересекающееся множество, чтобы не иметь проблем с переносом файлов. Очень часто, превышение длины имени файла, приводит к невозможности его копирования из одной точки монтирования (пр. NTFS том), в другую (EXT4).

18. Хорошая практика, у фирмы Apple, при разметке диска, вставлять пустые пространства между разделами, что облегчает их поиск на сыром "диске". Если диск "старый" - обнулить.

19. Защитите данные Ext4 от удаления: chattr +i

20. Не проводить операций с разделами, установками на дисках, хранящих данные. Установщики - программы легко повреждающие целевой диск, даже по неосторожности, по недопониманию, по встроенной логике, не соответствующей вашей логике разметки.

21. Тренируйтесь с копиями данных, в другой системе, а не в системе хранения.

22. Реже обновляйте, дабы не перевести хранилище в состояние "оффлайн". Обновление автоматическое, это да, а вот навыки и особенности конфигурирования сервера забываются и не автоматические.

23. Подбор файловой системы хранилища под задачи. О, это целая тема.

24. Помните, что приход AF (Advanced format) жестких дисков, увеличил единицу хранения диска до 4KB, с одновременным сокращением контрольных данных (ECC-кодов блока) до 1%, против 512 байт старого формата и ~10% кодов восстановления. Единица потери увеличилась в 4 раза, а спообность винчестера справляться с ошибкой уменьшилась в ~10 раз. Следовательно, мероприятия по сохранению данных легли на вышестоящий уровень.



Выводы

- Учёт и репликация


Ресурсы

1. Сравнение файловых систем. http://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D1%8B%D1%85_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC


Мониторинг микросервера с помощью настройки TMUX

Компьютерная жизнь микросервера (HP Proliant microserver) протекает неспешно, с временами переконфигурирования и далее опять неспешно.
Т.к. микросервер работает без монитора, без мыши, без клавиатуры, то соответственно нет привычного графического интерфейса. Остается одна лишь консоль, по ssh-подключению.
И вот эту, простую чёрную консоль, можно превратить в удобнейший рабочий стол, по управлению микросервером.

Консоль - Терминал - Интерфейс командной строки - CLI.


Мультиплексирование терминала - TMUX - terminal multiplexing

Самое большое удобство этой программы в том, что можно на сервере, запустить настроенный tmux, отсоединиться от сервера, и через пару месяцев присоединиться, а tmux-будет работать и всё окружение тоже и вся информация тоже. Но надо постараться настроить и сохранить в скрипт запуска.
TMux практически, аналог приборных панелей, т.н. dashboards. Отображаемая информация зависит от используемых консольных программ.

После настройки, пользователю останется только не забыть способ навигации внутри tmux.

Более того, tmux можно использовать вместо командной оболочки при заходе на сервер. Сразу настроенная среда.

Внутри tmux, можно использовать вместо обычного bash, любую другую оболочку, либо интерпретаторы языков высокого уровня.


Краткий обзор TMUX
Общесистемный конфигурационный файл: /etc/tmux.conf
Пользовательский конфигурационный файл: ~/.tmux.conf
Произвольный конфигурационный файл, задается опцией -f, при запуске tmux.
Руководство (en): man tmux

Запуск: tmux [команда]

Установка в Ubuntu server: $ sudo apt-get install tmux


Префикс по умолчанию, для управления с клавиатуры: ctrl-b

Поддерживаются несколько буферов обмена, мышь.

Сессии tmux

Сессий может быть много. Имена и логическое назначение выбирает пользователь.
Например, сессии - общий мониторинг микросервера (microserver), общий мониторинг сети (network), мониторинг и управление сервисами (services), управление удаленными вебсерверами (webservers), баз данных (database).

В принципе, для любого системного сервиса можно использовать сессию, либо окно внутри сессии.

Система адресации в Tmux

сессия  - [имя сессии]
окно     - [сессия]:[имя окна]
панель - [сессия]:[окно].[номер панели]

примеры:

сессия  - microserver
окна     - microserver:control      microserver:logfiles
панели - microserver-control.0   microserver.logfiles.2



Команды tmux

$ tmux new-session -n [имя окна] -s [имя сессии]

сессия создаётся с окном по умолчанию, для задания имени такого окна используется опция -n. Опция -s задает имя сессии. Опция -d - запуск сессии в фоне (daemon-режим).

$ tmux new-window -n [имя окна] -t [имя сессии] [скрипт]

создается новое окно внутри сессии, например:

$ tmux new-window -a -n logfiles -t microserver
(просто окно, без команды)
опция -a указывает окно делается с индексом следующим за текущим в данной сессии
[скрипт] - командный файл, который будет выполнен во вновь созданном окне.


$ tmux new-window -a -n logfiles -t microserver "top"
(выполниться команда top во вновь созданном окне)

По умолчанию выполняется приглашение оболочки. Если выполнить [скрипт], то окно закроется, чтобы не закрывалась (нужно иногда), надо установить опцию: remain-on-exit = on в конфигурационном файле.
Если не планируется закрывать такое окно, то можно использовать и такую форму запуска.

И другой путь - запускать в окнах стандартную оболочку (фунция по-умолчанию), и исполнять команды в ней, тогда окна не закрываются, пока не набрать exit.

пример:
# tmux send-keys -t network:real.2 "slurm -i home.8" C-m
в сессию network, окно real, панель №2, набрать "slurm -i home.8" и нажать ввод "C-m"


Рабочее окружение на основе TMUX

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

#!/bin/bash
# сервер: microserver, микросервер, n40l
# 30.10.2012

# Сессии
# microserver - общая сессия, для разнообразных работ на сервере
# services - сессия наблюдения за сервисами микросервера
# network - сессия наблюдения за домашней сетью

tmux new-session -d -n control -s microserver
tmux new-session -d -n s-view -s services
tmux new-session -d -n n-view -s network

# В каждой сессии создается свой набор окон, помимо первых окон.
# окна logfiles предназначены для просмотра логфайлов
tmux new-window -a -n logfiles -t microserver
tmux new-window -a -n logfiles -t services
tmux new-window -a -n logfiles -t network

# Делим первое окно (control) в сессии microserver
# По горизонтали на 2 панели, правую панель по вертикали на 2
tmux split-window -dv -p 50 -t microserver:control.0
tmux split-window -dh -p 50 -t microserver:control.1

# Делаем небольшоое окошко командной строки
tmux split-window -dv -p 10 -t microserver:control.2

# Делим второе окно (logfiles) в сессии microserver
# 4 панели - четверти экрана
# Вначале, делим текущее окно пополам, потом появившуюся панель
# с номером 1 пополам, а затем остаток от панели 0 пополам.
tmux split-window -dh -p 50 -t microserver:logfiles.0
tmux split-window -dv -p 50 -t microserver:logfiles.1
tmux split-window -dv -p 50 -t microserver:logfiles.0

# Делаем небольшоое окошко командной строки
tmux split-window -dv -p 10 -t microserver:control.2

# Выбираем окно по умолчанию, в сессии microserver
tmux select-window -t microserver:control


Базовая система навигации TMux

Префикс по умолчанию, для управления с клавиатуры: ctrl-b
Его можно перенастроить в конфигурационном файле (переназначить).

Отсоединение от терминала tmux: ctrl-b d
Присоединение к терминальной сессии: tmux attach-session -t microserver

Переключение между окнами сессии, по номеру: ctrl-b 0, ctrl-b 1


Перемещение между панелями: ctrl-b и стрелки курсора
Показать индексы панелей: ctrl-b q
Также можно выбрать панель по индексу: ctrl-b q 1

Можно изменять размеры панелей: нажимаете ctrl-b, затем отпускаете b, но держите ctrl и стрелками курсора двигаете.

Закрыть окно, панель: набрать exit

Вращение панелей: ctrl-b o, удерживая ctrl
Может быть полезно, когда надо "одним глазом" присматривать за происходящим на панели, но, её размер уменьшить до разумного минимума, а когда возникнет в ней необходимость - повернуть, чтобы она заняла место крупной панели, сделать нужное и повернуть обратно.

Переключение (attach) сессий не выходя из текущей сессии: ctrl-b s


Дополнительный команды навигации см. man tmux

Баги TMUX

Если в TMUX вывести огромный текстовый файл, то TMux перестает реагировать на команды.
Вывод, либо лечить патчами, либо не выводить большие файлы, либо дождаться завершения вывода.


Интересные консольные приложения для TMux


Хвосты файлов - Tail, Multitail

Простейшие средства организации мониторинга (отслеживания изменений) микросервера. Хвосты системных журналов, выведенные в отдельных панелях tmux, отфильтрованные с помощью grep, дают разнообразную информацию администратору-пользователю.
Наблюдение длительных процессов, всё это доступно простому хвосту.

Визулизация траффика по интерфейсу - Slurm

$ slurm -i home.8

Список процессов -Htop

$ htop


Доступность сети - sntop

$ sntop
Конфигурационный файл sntop: /etc/sntoprc
Чрезвычайно полезна вещь, особенно когда сеть достаточно разветвленная, но небольшая. Сеть тестируется с помощью периодического ping.
"Зелененькое хорошо, красненькое плохо".


Именованные конвейеры - Named pipes - байтопровод

Именованные конвейеры - средство межпроцессного взаимодействия в Linux/Unix. Могут быть чрезвычайно полезны в связке с фреймовыми менеджерами и мультиплексированными терминалами.
Изготавливаются командой: mkfifo
Пример позже, а пока можно сказать, что их удобно использовать для связывание вывода и ввода программ.


Фреймовые оконные менеджеры Awesome, XMonad

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


Выводы

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


Ресурсы

-. Официальный сайт TMux. http://tmux.sourceforge.net/
-. Cool unix tools. http://kkovacs.eu/cool-but-obscure-unix-tools-. http://wiki.fornex.com/index.php/Команды_Linux
-. Жизнь в консоли. http://welinux.ru/blog/115/
-. http://debiania.blogspot.ru/2010/05/nohup-dtach-screen-tmux.html
-. Пятерка фреймовых оконных менеджеров. http://help.ubuntu.ru/fullcircle/37/top5_37

-. Awesome в Ubuntu. http://help.ubuntu.ru/wiki/awesome

суббота, 27 октября 2012 г.

Часть III. Перенос системы на другой диск. MBR-to-GPT.

Возникла задача перенести установленную систему Ubuntu Server 12.04 на микросервере, находящуюся на комплектном жестком диске на другой диск, в зарезервированный раздел(ы).

Про разметку дисков микросервера можно посмотреть в заметке о GPT - LVM - RAID - 3TB.

Комплектный жесткий диск (250ГБ), был размечен, в своё время, установщиком Ubuntu Server, в автоматическом режиме, а это таблица разделов MBR, да еще и с логическими разделами. Это непорядок, тем более,сейчас осуществляю переход на GPT, чтобы снять ограничения.

Целевой 3ТБ жесткий диск Seagate ST3000DM001, размечен в современную разметку GPT.  На нём существуют специально выделенные разделы под основную и резервные Linux системы.

Трудности переноса Ubuntu на другой диск (миграция MBR на GPT)

Просто копирование файлов не помогает. В Linux есть специальные файлы и каталоги. Для них специальный подход. Также, т.к. современные Linux системы имеют дело с уникальными идентификаторами GUID, то и для них, - специальных подход.

HP Proliant Microserver N40L имеет обычный BIOS, а не современную систему UEFI. Поэтому, микросерверу для загрузки нужен диск с разметкой MBR.
Комплектный диск был размечен в MBR и нормально загружался. Но для повышения гибкости микросервера, он будет преобразован.
Разметка в MBR на современных дисках, с 4KiB физическими секторами, влечёт падение производительности, из-за устаревших требований MBR разметки - начало раздело кратно 63 сектору.

Т.е. современный компьютер, должен иметь биос с поддержкой GPT разметки (а это UEFI биос), уметь с неё загружаться и должны быть диски, правильно размененные в GPT. А выравнивание, при разметке в GPT, выполнится утилитами, такими как gdisk.
На а в нашем случае - загрузчик, с MBR, будет на флешке, и проблема выравнивания и загрузки с GPT, нас не сильно коснется.

Задача

Перенести систему с комплектного загрузочного диска на 3TБ диск в один из зарезервированных ранее разделов для Ubuntu Linux. Попутно, разделить систему, данные системы и пользовательские данные. После этого, преобразовать комплектный жесткий диск в GPT. Перенести только систему обратно. После этого, создать загрузочный том на маленькой флешке, с загрузчиком GRUB2, для загрузки системы либо с 3TБ диска, либо с 250ГБ.
По максимуму, забыть про MBR и более не размечать диски в ней.

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

Исполнение

Для переноса системы, можно выполнить загрузку с другого носителя, приостановив работу микросервера.Загружаюсь с usb-ssd.
Далее, понадобятся 4 (в моём случае) точки монтирования.Одна укажет путь к корневой системе исходного (250ГБ) диска, вторая - путь к корневой системе целевого раздела 3ТБ диска, третья - путь к разделу home целевого раздела 3 TБ, четвертая - путь к разделу данных.

Перенос будет состоять из нескольких этапов.
1. Форматирование целевого раздела корневой файловой системы (/), в EXT4.
2. Форматирование целевого раздела домашней папки (/home), в EXT4.

. Простое копирование простых файлов корневой файловой системы исходного диска
. Перенос полезных данных из папки /home исходного раздела, в папку на раздел данных. Т.к. сейчас полезные данные, не относящиеся к микросерверу храняться внутри папки /home, в подпапках.
. Простое копирование остатков папки home, в целевой раздел. Перенос данных относящихся к микросерверу на раздел /home на целевом диске.
. Изменение необходимых файлов на целевом разделе: цель: /etc/fstab,
. Создание специальных каталогов и специальных файлов
- Настройка загрузки

Итак, целевой диск, в моём случае 3ТБ: /dev/sda
Раздел корневой системы целевого диска, будущая точка монтирования (/): /dev/sda7
Раздел домашней папки. будущая точка монтирования (/home): /dev/sda8.
Раздел подкачки (swap), будущей системы: /dev/sda4.

Форматирование
Форматирование - очень опасная операция, часто приводящая к случайной порче полезных данных, по невнимательности. На свой страх и риск.

Форматирование 2 разделов, одной строкой, с указанием меток:

# mkfs.ext4 -L two-root /dev/sda7 && mkfs.ext4 -L two-home  /dev/sda8

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

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

Монтирование отформатированных целевых разделов, в точки временного монтирования. Можно примонтировать в путь /mnt/two-root /mnt/two-home, можно в иные места, не суть. Единственно что можно заметить здесь, это использовать короткие имена точке монтирования, дабы не превысить ограничение длины пути в Linux.

# mkdir /mnt/two-root
# mkdir /mnt/two-home
# mount -t ext4 /dev/sda7 /mnt/two-root
# mount -t ext4 /dev/sda8 /mnt/two-home


Перенос корневой файловой системы (корня,root).

Можно пойти несколькими путями. Использовать утилиту tar, утилиту rsync, простое копирование (cp-ax), dump/restore.
Но, при любом способе, надо контролировать следующие условия: права файлов, даты файлов и каталогов, жесткие и мягкие ссылки, именованные каналы, сокеты, точки монтирования, специальные файловые системы.

Точки монтирования (например дисков с пользовательскими данными), должны исключаться из копирования (при переносе корня), либо должны предварительно быть отмонтироваными. Известные точки монтирования: /mnt - /media /home Специальные файловые системы /dev /sys /proc. Но конечный список определятся местными условиями.


Воспользуемся конвейером Linux, чтобы перенести "корень" одной командой, но прежде потренируемся.

Учебный пример: перенос файлов содержащих .backup в имени, в другую папку, посредством утилиты tar (последовательный архив):

# tar -c --exclude=place1 *.backup | tar -x --directory=/mnt/two-home/

здесь опции:
-c - создание архива
--exclude= - исключение объектов по шаблону
*.backup - это файлы которые будут архивироваться
| - символ конвейера (pipe) в Linux/Unix, перенаправление вывода команды слева в команду справа.
-x - извлечение архива
--directory= - смена каталога, на тот куда будет произведено извлечение архива
Работает tar  в каталоге запуска и копирует все файлы с расширением backup.


Выполнив такую команду, мы избегаем формирование огромного файла архива корневой системы (а это лишнее место хранения), а сразу, по мере поступления файлов в архив, разархивируем их в целевой каталог. При этом, не используем сжатия, так что всё работает достаточно быстро.
Если при этом использовать такую известную утилиту NetCat (nc) - то архив можно передать и на другую машину в сети (другой микросервер).

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

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


Рабочий пример микросервера: перенос корневой системы
т.к. у меня 1 раздел, на котором и root и home, то при копировании root, я исключаю home, и копирую потом отдельно.

Прежде чем копировать, надо оценить имеющееся место на целевом разделе.

Всё копирование, делаем из каталога источника, чтобы избежать указания длинных путей.
# cd /mnt/src-root

# tar -cp --exclude=home --exclude=proc --exclude=sys --exclude=dev --exclude=mnt --exclude=media . | tar -x --directory=/mnt/two-root

Также, я отдельной командой скопировал каталог конфигураций etc, были какие-то сложности.
# tar -cp  etc | tar -x --directory=/mnt/two-root

Скопировал содержимое папки home (а не саму папку), в корень будущего раздела /home:

# tar -cp --exclude=backup  home/* | tar -x --directory=/mnt/two-home

Также, я отдельной командой скопировал папку backup из каталога home в другое место

# tar -cp home/backup | tar -x --directory=/mnt/backup


Выяснение UUID:
# blkid | grep sda7
 dev/sda7: LABEL="two-root" UUID="7fd88c8d-6ec2-4142-94ff-b70987654321" TYPE="ext4"
# blkid | grep sda8
 dev/sda7: LABEL="two-home" UUID="7fd88c8d-6ec2-4142-94ff-b71234567890" TYPE="ext4"

Редактирование /etc/fstab на целевом разделе:
# nano /mnt/two-root/etc/fstab

Замена UUID точек монтирования / и /home на полученные на предидущем этапе. Монтирование по уникальному идентификатору раздела, позволяет, например, переставить жесткие диски (а они тут же поменяют имена устройств) и спокойно, ядру, загрузить корневую файловую систему и домашнюю.
Каждая точка монтирования на своей строке, добавить комментарии - дату изменения, метку системы, что делалось.

Раздел подкачки указал просто устройство, т.к. uuid не нашел (раздел не форматированный) - /dev/sda4

Выдержка из fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

proc            /proc           proc    nodev,noexec,nosuid 0       0

UUID=7fd88c8d-6ec2-4142-94ff-b70987654321 /               ext4    errors=remount-ro 0   1

UUID=7fd88c8d-6ec2-4142-94ff-b71234567890 /home           ext4    errors=remount-ro 0   1

# временно указано устройство, а не UUID
/dev/sda4       none    swap    sw      0       0


Создание точек монтирования специальных файловых систем:
# mkdir /mnt/two-root/proc
# mkdir /mnt/two-root/sys
# mkdir /mnt/two-root/dev

Обычные точки монтирования:
# mkdir /mnt/two-roor/media
# mkdir /mnt/two-roor/mnt


В принципе, на этом этапе, всё, можно воспользоваться обновлением загрузчика (update-grub) на текущей запущенной системе, он обновиться, найдет новые системы и пропишет строки запуска и попробовать перезагрузиться в новую систему, используя стартовый носитель (usb-ssd), как загрузчик.
# update-grub
Найден Ubuntu 12.04.1 LTS (12.04) на /dev/sda7
Найден openSUSE 11.4 (x86_64) на /dev/sdc2
Найден Ubuntu 12.04.1 LTS (12.04) на /dev/sde1


Новая сформированная система (резервная копия основной системы микросервера) найдена на /dev/sda7.
Откопался даже эксперимент с OpenSuse на каком-то дискe, про который я уже и забыл :-)
Также откопалась основная система микросервера на комплектном диске /dev/sde1.
Просто загрузчик на новом диске, ещё не знал, про наличие других систем и мог загрузить только свою.


А можно, заняться установкой загрузчика, но с дисками GPT - это нетривиальный процесс. Т.к. на микросервере BIOS, то нужен диск размеченный в MBR - у меня будет флешка.
В микросервере, есть удобная функциональность, стандартный внутренний USB-порт на плате. Туда подключу флеш-накопитель. Размечу его в MBR.
Сделаю несколько разделов.
Первый раздел, выделю для загрузчика. Второй раздел выделю для образа дополнительного загрузочного диска. Третий раздел - либо UDF, либо exFAT. Пока не решил, как будет.

Установка загрузчика GRUB2 на загрузочный том (флешку)

Загрузчику нужно где-то хранить свои файлы. GRUB2 хранит обычно в папке /boot/grub, иногда просто /grub.

Загружаемся в любой системе, желательно поновее (12.10).

Инсталляция загрузчика выполняется командой grub-install, с опциями.

Флешка у меня в этот раз, была /dev/sdf

# fdisk /dev/sde
Диск /dev/sde: 7743 МБ, 7743995904 байт
113 головок, 57 секторов/треков, 2348 цилиндров, всего 15124992 секторов
Units = секторы of 1 * 512 = 512 bytes
Размер сектора (логического/физического): 512 байт / 512 байт
I/O size (minimum/optimal): 512 bytes / 512 bytes
Идентификатор диска: 0x000be372

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sde1              63      392672      196305   83  Linux



Boot раздел флешки (/dev/sde1) был примонтирован в /media/iam/boot.

Выполняем установку загрузчика GRUB2:

# grub-install --boot-directory=/media/iam/boot /dev/sdf

Этим мы меняем поведение установщика и он, вместо текущего корня, устанавливае Grub 2 в указанную директорию (файлы GRUB2, конфигурационный файл, меню и пр.), а в само устройство /dev/sdf прописывает загрузочный boot-sector.

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

# grub-mkconfig -o /media/iam/boot/grub/grub.cfg

Может возникнуть вопрос, почему не update-grub. Update-grub обновляет по умолчанию файл, /boot/grub/grub.cfg, а этот файл находится в корне загруженной системы. А это нам не надо, хотя можно тоже освежить.

Далее, я выключаю микросервер, отключаю диск с которого шла загрузка и включаю микросервер. В BIOS выставляю опцию - загрузки с USB и гружусь.
Если всё правильно, то появиться меню загрузчика и будет список готовых для загрузки операционных систем. Выбираю загрузку установленной настольной системы Ubuntu Gnome 12.10 (на /dev/sdb5).
Также, после перезагрузки проверяю загружаемость микросервера с комплектного диска, с резервной системы на диске /dev/sda7.

Замеченная особенность, загрузочная флешка автомонтируется при запуске графического рабочего стола Gnome Shell. Если её отключить, то перезагрузка не сработает и надо выключить микросервер, чтобы заработало.
В принципе, её можно убрать из автомонтирования, либо не отключать - самое простое.

Соединение GPT и MBR в Hybrid MBR

Технология нестандартная, но используемая. Существенным недостатком является, то что вся настройка (долгая) может легко слететь при любой установке, любой системы. Обычно через время, всё это забывается и благополучно переписывается. Системы проверки корректности структуры разметки, также могут не понять режим Hybrid MBR и исправить ошибку :-)
Существенным плюсом, не требуется флешка для загрузки с GPT дисков.
Если есть желание, то можно потренироваться [см. Ресурсы.1].

Использование rsync для переноса корневой системы

Rsync также может быть использован для переноса корневой системы [см. Ресурсы п. 2].


Как-то так:
# rsync -qaHEAXh --progress --exclude 'home' --exclude 'dev' --exclude 'proc' --exclude 'sys' --exclude 'media' --exclude 'mnt' /mnt/src-root/* /mnt/two-root 
потом и для home.

Часто практикуется синхронизация рабочей копии системы с резервной по расписанию.

Ну и обратная операция, когда всё проверено и работает так как надо, можно приступить к форматированию комплектно диска в GPT и обратный перенос. Файл заметки большой, а команд не так много.
При обратной операции попробую rsync.

Всё.



Ресурсы

1. Hybrid MBR. http://www.rodsbooks.com/gdisk/hybrid.html
2. Перенос Ubuntu на другой винчестер. http://lin.in.ua/articles/2-Debian/4-Opisanie_processa_perenosa_Ubuntu_Debian_na_drygoj_vinchester.html
3. О выравнивании разделов. http://www.linux.org.ru/wiki/en/%D0%92%D1%8B%D1%80%D0%B0%D0%B2%D0%BD%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_%D0%B4%D0%B8%D1%81%D0%BA%D0%B0




пятница, 26 октября 2012 г.

Добавление сетевого принтера. Microserver-network-printer

В Gnome Shell 3.6 продолжаются проблемы у встроенной утилиты добавления принтера, находящейся в "Системные параметры".

Для добавления сетевого принтера во вновь установленном Gnome shell, я использую системный скрипт:
/usr/share/system-config-printer/system-config-printer.py

Alt+F2 и ввести строку.

Это запускает обычный диалог добавления принтера в Ubuntu:



system-config-printer в Gnome Shell 3.6

Принтер легко находится по сети, если задать hostname сетевого принтера.



либо web-страницу (homepage) CUPS:

http://localhost:631

CUPS homepage


Принтер на микросервере

Для добавления принтера в микросервере, надо установить текстовый броузер elinks, либо настройть web-интерфейс CUPS.

Чтобы принтер, HP Color LaserJet CM1015 MFP был принтером на микросервере, надо установить HPLIP (пакет hplip)
Чтобы принтер HP LaserJet 1018 поддерживался, надо установить драйвер Foo2ZJS (пакет foo2zjs)
Чтобы был виртуальный принтер CUPS-PDF, надо установить пакет cups-pdf.


# apt-get install cups cups-pdf hplip foo2zjs

Далее воспользоваться wb-страницей для добавления принтера. Web-страница принтеров, с других компьютеров сразу недоступна. Надо исправить в /etc/cups/cupsd.conf на микросервере.

Установить Port 631 вместо Listen localhost:631
Добавить разрешения вида: Allow 192.168.1.0/255.255.255.0
в секции:
<Location />
  Order allow,deny
  Allow localhost
  Allow 192.168.1.0/255.255.255.0
</Location>
<Location /admin>
  Order allow,deny
  Allow localhost
  Allow From 192.168.1.0/255.255.255.0
</Location>
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
  Allow localhost
  Allow From 192.168.1.0/255.255.255.0
</Location>

Т.е. разрешить компьютерам из локальной сети (192.168.1.0/24), заходить на страницу администрирования.

Для печати из командной строки, надо установить пакет lpr.

# apt-get install lpr

Печатать так:

# cat file | lpr









среда, 24 октября 2012 г.

Часть II. Сравнительная производительность разделов

Предположения оправдываются.
Вот результаты тестирования на диске sda, разделов расположенных в разных местах диска. Напомню, диск Seagate ST3000DM001. режим подключения AHCI. Платформа HP Microserver N40L.
Интересные цифры доступа у некоторых маленьких разделов.
Как, экспериментально выяснилось, синяя линия - чтение, красная - запись, зеленая - доступ в мс. (см. по правой шкале).

Linux раздел (sda5). Будущая основная система

EFI раздел. Начало диска

LVM. Логический том 1TiB на диске sda (внутри LVM разделов №21 и №22)

Раздел sda17 (практически, перед LVM раздеами)

Конец диска, последний раздел







Заметки по теме:


Это продолжение заметки:  http://gimmor.blogspot.com/2012/10/i-gpt-lvm-3tb-raid-microserver.html
и заметки: http://gimmor.blogspot.com/2012/10/3t-hp-proliant-microserver-n40l-seagate.html

Часть I. GPT - LVM - 3TB - RAID на hp microserver


До этого времени, дел с менеждером томов LVM, я не имел, обходился простыми разделами и простыми дисками. По принципу "тик-так". Вышла новая Ubuntu - новый диск, т.к. сил обновлять старый нет. При двух дисках, для настольной системы, плавная миграция раз в полгода, а последнее время и раз в год. Т.к. любые манипуляции на рабочем диске, как то установка новой системы, даже в другой раздел, часто приводят (ли) к сбоям. Мне это не надо, поэтому новая система - новый диск (хорошо забытый старый).
Удивительно то, что нет у меня в доступном обозрении, дисков фирмы WD, все диски - Seagate (большая часть), один Samsung, один Hitachi. Хотя, может быть где-нибудь и завалялся "Западный цифровой".
Seagate-fun.
Надо будет исправить оплошность - повысить разнообразие экосистемы.

Отвлекся.

Главный вопрос

Возник вопрос(ы). Нужен ли мне LVM, что я смогу с ним сделать и не усложнит ли это мне восстановление информации, в случае отказов?

Дополнительные вопросы

Это вопросы, которые меня интересуют до того, как я погружусь в чтение руководств по LVM. Т.е. в этой теме - я чистый лист.
Сразу вопрос, можно ли существующие разделы с данными (по живому) объединить под командой LVM. Или надо их изначально туда включать чистыми и заполнять?

RAID потом LVM, или LVM а потом RAID - вот в чём вопрос

Т.к. были приобретены 2 диска, с прицелом на создание зеркального RAID. то и возник такой вопрос.
А нужен ли RAID-1, его достоинства и недостатки, в применении к моим задачам.
А как файлы хранятся на LVM? Дефрагментированы ли они?


Кое-что о разбиении диска

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

Соображения о разбиении диска

Изначально, я планировал разбить каждый диск, на несколько десятков разделов, применяя GPT, для различного назначения, сделав часть из них зеркальными, часть просто разделами, часть системными, часть резервными.
Я также, планировал обеспечить загрузку диска в различных системах, таких как Linux, Mac OS X, Windows 8 исключительно с целью оперативного получения доступа к хранимым данным. То, что данные сейчас находятся на микросервере, это вель ещё не значит, что они там будут всегда. Хороший образ, иллюстрирующий  идею, - цветок из кинофильма "Leon", который путешествует с главным героем во всех передрягах.

Теперь, к плану добавилась такие вещи, как LVM и RAID. И пришло время продумать всё тщательнее и обстоятельнее, переосмыслить. Ведь любое средство, надо грамотно применить и получить пользу.
LVM концепция - раскрывает множество возможностей по операциям с разделами, да вот выбрать какие нужны и будут полезны - сложно. Идея LVM должна отлежаться в мозгу, наладить связи.


Раздел - это обособление, свой участок, "свои погремушки" и своё собственное командование им.
Раздел - это грануляция,  - уменьшение влияния изменений на целое - систему, совокупность данных и уже только это повышает надежность.
Простейшее разделение - система и данные. В систему вносятся изменения, она обновляется, данные при этом не затрагиваются. Поделим дальше, - выделим раздел для временных файлов, - они постоянно изменяются, а программные файлы редко, - уже выгода, особенно для ssd-дисков, с ограниченным ресурсом изменений. Можно пойти дальше, папку пользователя разбить на разделы, например конфигурационные данные приложений (файлы с точкой), отдельно почтовый раздел, документы, фото и видеоматериалы, а можно сделать разделы по годам, а когда накопиться много лишнего места на них, провести реорганизацию.

В идеале, надо выйти из мысленного ограничения - вся система на одном диске (разделе), и размазать систему по разным дискам и разделам. Чтобы потом не собрать.:-)


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

Разделы можно делать точно в размер CD, DVD, Blu-ray дисков для создания образов и их последующей записи.
Разделы можно создать точно в размер разделов компьютеров домашней сети, что облегчает резервирование данных и создание полных образов восстановления.
Создание раздела определенного согласованного размера, это выгодно. Ведь если подумать, то при двух разных разделах, операция перемещения данных, может включать и операцию преобразования раздела, а это опасная операция.


В эндшпиле, такое разделение системы может свестись к известной операции "copy-on-write", но на уровне разделов. Т.е. вначале скопировал раздел, а потом изменил в нём, а не в исходном. Как SSD поступает с данными, так и пользователь.



Что будет, если выйдет из строя файловая система пару-терабайтного диска с миллионом файлов? Сколько займет времени восстановление? Оно реально? Понадобятся ли (да) ещё диски для создания исходного образа отказавшего тома? Это кажется, что аккуратное обращение - гарантия, но это не так.

Пока единственным плюсом большого тома (проверено на личном опыте), я вижу то, что данные все находятся в известном мне месте, они тут все, и не надо гадать, что они где-то "рассованы" по разным местам.
Минусов правда больше. Большой том - обязательно raid-1 + резервный диск. Итого 3 диска. Иначе чувство не покидает.

С другой стороны, что будет с операционной системой, монтирующей в "угаре автомонтирования",  несколько десятков разделов с разнообразными файловыми системами, внешний жесткий диск? Правда-правда, она отработает? Да?



Можно пойти по пути, - заранее разметить (благо GPT позволяет) нужное количество разделов. Почему заранее? Потому что, любые операции с разделами - опасны для данных и их лучше не делать, а лучше делать пока нет данных. Почему опасны? Потому что затрагивают целое, а на часть. А "ошибки оператора" постоянно случаются.

Можно пойти по пути, - использовать менеджера разделов (пока предполагается LVM, а там посмотрим) и динамически создавать разделы под нужные требования (надеюсь такое возможно).

Кстати, эти пути можно пройти и мысленно и выбрать более подходящий для реализации в текущий реальности.


И ещё раз, операции с разделами - опасны.
Данные должны быть зарезервированы. Поэтому, в старые времена, разделы делались в момент установки систем и не менялись. Однако сейчас, - не старые времена и доступны более гибкие средства, "по потере данных".
Но, главный приоритет - сохранение данных, продолжает оставаться.

Казалось бы, - как рекламируется, простая команда в Ubuntu apt-get dist-upgrade,  а приносит столько несчастья. Да что upgrade, update обыкновенный. Думаю, примеры всем знакомы на личном опыте. Т.к. с желанием обновляться, пробовать новое, сложно совладать, то я просто выделяю отдельную систему (диск, раздел) для этих целей, которая, и тестирование обновлений может выполнить, и удовлетворить чувство.

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

Как показало время, в домашней практике, лучше применять стабильные, редко изменяемые системы. Пусть они не оптимальны, устарелы, вышли из употребления, но работают, привычны, понимаемы.  "Старый теплый свитер". И не перегибать палку с дискетами. Но настало время, рост объемов данных уже превысил возможности старого железа, например USB2.0, в части удобного обращения с данными. Простое копирование двух-терабайтного винчестера отнимает день. Пора переходить на новые скоростные технологии, благо они начали появляться на массовом рынке. В этом нам помогут такие вещи, как Thunderbolt, Infiniband, 10G Ethernet, USB3.0, Sata III и пр.
И ещё, т.к. в домашних условиях сложно применить корпоративные средства управления хранением, то важным факторов организации, как  ни странно, является принтер. Он, позволяет напечатать твердую копию настроек системы, которые помогут в трудный момент. Он, позволяет распечатывать обложки дисков, списки дисков и разделов, липкие метки - всё то, что облегчает ручную организацию данных.
Небольшой учёт оборудования (ведение инвентаря), по таким параметрам, как дата приобретения, позволяет вовремя проводить обновление оборудования и не допускать отказов во второй опасный период, после окончания гарантии.
Бортовой журнал изменений - также упростит восстановление понимания некоторых вопросов, по прошествии времени.
Периодическая диагностика дисков по их smart аттрибутам и сохранения снимков состояния, позволит понять историю и направление изменений.
Всё это, увы, - ручные операции человека. Однако польза, от их наличия - перевешивает.

Можно это всё исключить, но тогда "стук блока головок", "звук пилы" - станут полезным личным опытом.

Как ни странно, но встроенная надежность оборудования, играет существенную роль в сохранности данных. Такие известные и доступные технологии, как память с коррекцией ошибок (ECC), SATA шлейфы с защелками, либо SATA корзины, регулируемое охлаждение, источники бесперебойного питания - снимут много головной боли. Пользу их можно понять двумя путями, на личном опыте и на чужом опыте.


Об онлайн-хранении

Любые сервисы онлайн-хранения, даже этот блог, подвержены одной чрезвычаайно неприятной особенности - Вы их не контролируете. Это как с ЖКХ - тоже сервис. Нравится сервис ЖКХ? Скоро прийдем к такому же, только в компьютерной области.
Стоит завязаться на онлайн-сервис, привыкнуть к нему, так сразу он даст о себе знать, покажет вторую сторону монеты.
Всё может превратиться, в один момент, в черепки. Примут закон - запретить кокретный сервис и приплыли - данные потерялись. Вопли, крики, слёзы. "Ктож знал, ктожзнал"?
А незачем отклоняться от первоначальной идеи Интернета. А поделом.

Доступность данных

Данные накопленные, но находящиеся в архивных файлах, таких как zip,rar, в образах iso, в закрытых образах, недоступны. А ведь они при определенном поисковом запросе вполне могут помочь, что-то прояснить.


Контроль доступа
Знание того, кто, когда и что запросил, добавил, удалил - чрезвычайно ценно.
Журнал доступа - хороший вариант.


LVM. Рекомендация 1

Т.к. для физического тома LVM, выделен специальный код раздела, то надо форматировать жесткий диск, разбивать на разделы и только потом, уже из разделов собирать придуманную конструкцию, будь то raid, lvm.
Иначе, если диск сырой, то Windows легко предложит его отформатировать и можно "случайно", а на самом деле, предсказуемо, нажать "Да".
Т.е. Диск должен быть размечен. Выбор сегодня - GPT.


GPT. Разметка дисков

Т.к. мы имеем дело с дисками, то примем следующее обозначения.

1 MiB - 1024 KiB - (1024x1024) bytes - используется в компьютерной технике.
1 MB - 1000 KB - 1000x1000 bytes - используется при указании емкости современных жестких дисков, blu-ray, карт-памяти. "Маркетинговые мегабайты".

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


GPT система, продолжает придерживаться выравнивания кратного 2, так что при указании размеров, только гибибайты, мибибайты и кибибайты.
Ну и ладно - прояснили.


Можно тренироваться с графической утилитой "Диски", но нам требуется точность разметки, а её обеспечивает утилита командной строки gdisk и калькулятор calc.
если она не установлена, а она не установлена в стандартной Ubuntu, то:
apt-get install gdisk

Размечать придется 2 диска, т.к. система ориентирована на уникальные GUID, то различия в дисках будут именно в этом - в уникальных идентификаторах разделов, т.к. они генерируются при создании.


Программа интерактивная, так что будем нажимать кнопки.

root@microserver:# gdisk /dev/sda
В данном случае, на микросервере, sda - диск в первой корзине, sdb - диск во второй корзине. Но надо чётко отслеживать - какой диск размечается, чтобы защитить ценное.

Есть тактическая особенность, которую приятно использовать - это то, что у жесткого диска, в начале (ближе к центру вращения), скорость доступа выше, выше линейная скорость. Т.е. первые разделы, всегда скоростные.
Ранее, при MBR, я использовал первый раздел под раздел подкачки (swap). Второй под систему, третий резервный, четвертый - домашняя папка.
Сейчас, при GPT, принцип сохраняется, просто увеличивается гибкость по разделам, их числу.

Нам полезны "пара-тройка" команд:

o    create a new empty GUID partition table (GPT)
n    add a new partition
t    change a partition's type code  



Итак, o - создание разметки GPT, n - добавление нового раздела, t - изменение типа раздела, если ошиблись при добавлении.

q    quit without saving changes
b    back up GPT data to a file
w    write table to disk and exit

Для сохранения промежуточных версий GPT-разметки, удобно использовать команду b. Т.е. можно поиграться.
q - выход из программы, без сохранения на диск изменений.

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

Вначале, пойдут системные разделы. Небольшой обзор разделов, можно найти в Википедии [см. Ресурсы п. 5].
Т.к. Linux - основная система, то её разделы пойдут первыми.
А самым первым пойдет системный раздел EFI (ESP).
Назначение ESP раздела подробно описано в спецификации UEFI. Применятся для хранения загрузчиков, драйверов системы UEFI, обновлений прошивки (firmware), efi-утилит.

Для нас, важен размер, формат и местоположение.

Компания Microsoft рекомендует делать системны раздел ESP - первым в таблице разделов.
Также Microsoft требует наличие сразу за ESP разделом, раздела MSR - Microsoft Reserved Partition, объемом 128MiB для дисков более 16GB.
Раздел MSR обязан быть на каждом диске. Размещаться он также может после OEM-разделов, которые следуют за ESP разделом.

Mac OS X также имеет специфические требования к разделу ESP [см. Ресурсы п.8]. Некоторые версии Ubuntu вообще могут удалить существующий ESP раздел. Разные установщики дистрибутивов Linux создают разные размеры ESP.

Формат системного раздела ESP - FAT32, FAT16. Windows предполагает - FAT32. На самом деле, формат определяется спецификацией UEFI и в данный момент выглядит как FAT32.

Выберем формат ESP - FAT32, как максимально совместимый с системами.

Размер. Mac OS X для больших дисков создает ESP раздел объемом 200МиБ.

Также, после каждого раздела создается 128 МиБ свободного места, за исключением ESP.

Таким образом, наиболее сложные ограничения накладывает Mac OS X и Windows. Им и будем следовать.
Также, перед установкой Ubuntu, диск должен быть размечен. Надеюсь, что встроенные утилиты других систем, не испортят всю задумку.
Можно было бы сделать разметку в Mac OSX, но её нет под рукой, поэтому Ubuntu.
И не использовать старые версии Ubuntu и пр. систем, на новом диске.

Итак, цифры: 200MiB - 209715200 байт (409600 секторов по 512 байт), 128MiB - 134217728 байт (262144 по 512 байт).

Можно создавать. Команда o, затем n.

Первый сектор первого раздела выровняем до 2048.Просто нажмем "Enter".
Последний сектор первого зададим так: +200MiB.
Код раздела укажем таким: ef00. Что соответствует ESP, а в терминологии программы gdisk - EFI System.
После выполним команду p и проверим правильность.
Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): много цифр
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860123501 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System


Граница 2048 - это 1 MiB.


Создание OEM раздела, упоминаемого Microsoft, пропустим, т.к. неясен его GUID и размер.

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

Вторым разделом пойдет раздел MSR. Его делаем без промежутка в 128MiB.
Требуемый размер: 128MiB.
Код раздела:
На этом этапе можно выполнить запись на диск, командой w, а потом перезапустить утилиту.
Вывод будет следующий:
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.


Total free space is 5859861357 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved


Базовая структура GPT диска создана.

Остается один вопрос, 128 MiB чистого места оставлять только после разделов Apple, либо после всех разделов? Как-то не могу прояснить этот вопрос, поэтому буду исходит из более строго ограничения - после всех.
В пустоту, а может и в пользу, уйдет около ~ 3GB.
Делается, это так, +128MiB при указании начального сектора любого последующего раздела.

Разделы подкачки (виртуальной памяти на диске)

Раздел подкачки - должен быть кратным степени двойки, совпадать или превышать объем оперативной памяти, желательно, но не обязательно кратно. Можно сделать несколько разделов подкачки. Тут также есть свои рекомендации у разных операционных систем. Я поступлю проще, зарезервирую объем.
Раздел подкачки используется также в режиме hybernation, когда на него сохраняется образ памяти.

Код раздела подкачки (swap) Linux: 8200
Задаем первый сектор, +128MiB, (нажмем ввод), второй сектор: +8GiB.
Итого (команда p - печать таблицы разделов):

Третьим пойдет также раздел подкачки, 8 GiB,также с отступом в 128MiB.
Код раздела подкачки (swap) Linux: 8200
Задаем первый сектор: +128MiB, второй сектор: +8GiB.
Итого (команда p - печать таблицы разделов):

Total free space is 5826306925 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved
   3          935936        17713151   8.0 GiB     8200  Linux swap
   4        17975296        34752511   8.0 GiB     8200  Linux swap

Видно, что стартовый и конечный сектора 3 и 2 разделов разнесены.

Подтверждение вычисляется так: Стартовый сектор - 1 - Конечный сектор предыдущего раздела. Умножаем на размер сектора (512 байт, в данном случае), делим на 1024 и еще раз на 1024. Получаем число 128. 128 MiB.

Записываем структуру на диск. нажимаем w.

Процедура ясна, можно приступать к нарезке.

GPT. Система Linux. Система Mac OS X. Система Windows.

Т.к. диски будут экслуатироваться на сервере, то разделы операционных систем не будут использоваться, под ОС, по крайней мере, в настоящее время. Но они будут.
Первой пойдет система Linux, в начале диска, она будет самая быстрая.
Для неё выделим раздел корневой системы (/), раздел домашних папок (/home), резервный раздел корневой системы, резервный раздел домашних папок. Т.е. при желании, на диск можно будет установить 2 системы, параллельно. Хотелось бы 3, но не надо.

Т.к. разделы в резерве, то их размер сделаем хитрым, кратным размеру однослойного Blu-ray диска.
Точный размер Blu-ray диска, способ его получения, можно посмотреть в заметке: Blu-ray диски в Ubuntu.
Для имеющихся у меня дисков Verbatim - размер 23610MiB.
Незабудим про границы в 128MiB.

Итого 4 раздела по ~25GB - ~ 100 GB. Как раз один диск BD-RE XL = 100GB.


Задаем первый сектор: +128MiB, второй сектор: +23610MiB.
И так повторяем 4 раза.

Итого (команда p - печать таблицы разделов):

Total free space is 5632893805 sectors (2.6 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved
   3          935936        17713151   8.0 GiB     8200  Linux swap
   4        17975296        34752511   8.0 GiB     8200  Linux swap
   5        35014656        83367935   23.1 GiB    8300  Linux filesystem
   6        83630080       131983359   23.1 GiB    8300  Linux filesystem
   7       132245504       180598783   23.1 GiB    8300  Linux filesystem
   8       180860928       229214207   23.1 GiB    8300  Linux filesystem

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

Сохраняемся - команда w. Перзапускаем утилиту.

Система Mac OS X следующая (потенциально следующая).
Для системы Mac OS X нужны следующие разделы: один системный HFS+.
На нём всё, и система. и данные локальных пользователей. Возможно понадобиться еще и раздел Apple RAID. Т.к. Система Mac OS X также обновляется, то понадобиться второй комплект разделов, чтобы следовать процедуре "тик-так".
Код раздела для установки Mac OS X: AF00  Apple HFS/HFS+

Система Windows.
Для системы Windows (7, 8 версии) требуется по отдельному разделу. Т.к. разделы одиночные, то и размер должен быть большим. Однако, существует возможность вынести папку Users на отдельный раздел.
По опыту, для системы Windows 7, будет достаточно около 60 GiB для системы (много программ), без папок пользователя. Также может понадобиться раздел для создания образа системы, а возможно и раздел для резервирования, встроенным средством архивации и восстановления. Т.е. 3 windows-раздела, для одной системы. 2 windows системы - 6 разделов.

Кстати, что ждёт пользователей, займись они разделами в среде Windows, можно прочитать в статье "6 ошибок людей с маленькими разделами"[Ресурсы п.9].

В принципе, да, в Windows 7, я практически следую таким рекомендациям.
Однако, данные нужны в разных системах, и их вынос в отдельные разделы помогает держать их под контролем. Да и объем в 2 TiB, хранить в домашней папке рабочей системы - небезопасно. Очень часто, большая вложенность папок превышает лимиты на длину имени файлов, что приводит к невозможности скопировать такой файл.
Операция резервирования при 2TiB в одной папке, вполне может не закончиться.

К разметке, можно подходить с позиций последующего восстановления данных, т.к. поиск разделов на диске, с затертым оглавлением, вполне по силам утилитам, таким как testdisk. Да и архивный файл GPT разметки, может помощь. А вот с одной огромной файловой системой, такой уверености нет и не будет.

Недостаток обычного разделения диска (например GPT) - невозможность стандартными средствами изменить, объединить, перераспределить разделы, без потери данных.

В принципе, 2 раздела по 100 GB (точно 94440MiB), может хватить, для двух систем, которые редко используется, и в них данные не накапливаются.
Опять же, разделы эти потенциальные. + 2 раздела для полного резервирования, такого же объема.
А выравнивание по объему с диском BD-RE XL 100 GB, даст возможность простого резервирования.

И ещё, т.к. иногда может потребоваться создание образа BD-R диска, а они на сегодняшний момент достигают в размере 128 GB, то и раздел для них должен быть больше - файл то, надо на разделе создавать и хранить Это можно предусмотреть в конце диска.

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

Т.к. ближе к центру диска - быстрее, то первые системы (Mac OS X и Windows) будут первыми двумя следующими разделами.Затем небольшой раздел обмена (см. далее). Затем блок вторых систем, затем блок резервных разделов.

Total free space is 4569121645 sectors (2.1 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved
   3          935936        17713151   8.0 GiB     8200  Linux swap
   4        17975296        34752511   8.0 GiB     8200  Linux swap
   5        35014656        83367935   23.1 GiB    8300  Linux filesystem
   6        83630080       131983359   23.1 GiB    8300  Linux filesystem
   7       132245504       180598783   23.1 GiB    8300  Linux filesystem
   8       180860928       229214207   23.1 GiB    8300  Linux filesystem
   9       229476352       422889471   92.2 GiB    AF00  Apple HFS/HFS+
  10       423151616       616564735   92.2 GiB    0700  Microsoft basic data
  11       616826880       665180159   23.1 GiB    0700  Microsoft basic data
  12       665442304       858855423   92.2 GiB    AF00  Apple HFS/HFS+
  13       859117568      1052530687   92.2 GiB    0700  Microsoft basic data
  14      1052792832      1246205951   92.2 GiB    AF00  Apple HFS/HFS+
  15      1246468096      1294821375   23.1 GiB    0700  Microsoft basic data

Раздел №11 - малый транзитный раздел. Будет отформатирован, скорее всего в UDF, возможно из-под Windows, а пока из под Linux.
Разделы №14 и №15 - разделы для полного резервирования систем Mac OSX и Windows, соответственно.

Графическая утилита "Диски", превращается в длинное окно. Его даже не удалось, сфотографировать, по Alt+PrtScn :-) Баг однако. А нет, 2 бага однако, в двух программах.

14 разделов на диске GPT

Также, можно заметить из таблицы, что стартовые секторы - четные, т.е. разделы выровнены. А конечные - нечетные.


GPT. Разделы обмена данными - транзитные разделы


Основное требование - файловая система доступная на чтение/запись из любой системы, на этом диске.

Сделаем один большой раздел обмена данными между операционными системи, по размеру превышающий размер Blu-ray BD-R XL 128 GB. Чтобы его можно было перенести. Во что его отформатировать?


Сделаем небольшой раздел, для обмена данными, не более 30 GB.
Рассматриваются форматы Fat32, exFAT, UDF предварительно.
Выбран UDF. Уже сделан, под №11.

GPT. Эксперимент с удалением раздела на живом диске

Был отформатирован раздел №11 в файловую систему UDF. Далее был удален раздел №2 (swap). Потом воссоздан, по исходным размерам.
Данные на разделе №11 сохранились.

GPT. Эксперимент с увеличением раздела, за счёт соседнего
Не проводился.


GPT. Ещё разделов, для виртуальных машин
С системными разделами почти закончили, создадим пару разделов для виртуальных машин. Да, по 23610MiB.
Тип этих разделов: 8301 Linux reserved
Ещё нет разделов объемом с двуслойный диск BD-R.
Предположим 2 слоя - (23610*2) = 47220 MiB. У меня пока нет 2-х слойного диска, чтобы проверить. Как прибудет из Японии, так сразу же.

Итого, на данном этапе 18 разделов:

Total free space is 4375708525 sectors (2.0 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved
   3          935936        17713151   8.0 GiB     8200  Linux swap
   4        17975296        34752511   8.0 GiB     8200  Linux swap
   5        35014656        83367935   23.1 GiB    8300  Linux filesystem
   6        83630080       131983359   23.1 GiB    8300  Linux filesystem
   7       132245504       180598783   23.1 GiB    8300  Linux filesystem
   8       180860928       229214207   23.1 GiB    8300  Linux filesystem
   9       229476352       422889471   92.2 GiB    AF00  Apple HFS/HFS+
  10       423151616       616564735   92.2 GiB    0700  Microsoft basic data
  11       616826880       665180159   23.1 GiB    0700  Microsoft basic data
  12       665442304       858855423   92.2 GiB    AF00  Apple HFS/HFS+
  13       859117568      1052530687   92.2 GiB    0700  Microsoft basic data
  14      1052792832      1246205951   92.2 GiB    AF00  Apple HFS/HFS+
  15      1246468096      1294821375   23.1 GiB    0700  Microsoft basic data
  16      1295083520      1343436799   23.1 GiB    8301  Linux reserved
  17      1343698944      1392052223   23.1 GiB    8301  Linux reserved
  18      1392314368      1489020927   46.1 GiB    0700  Microsoft basic data


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


В принципе, я добрался до создания LVM разделов. Но добавлю ещё, пару интересностей.


GPT. Раздел для хранения зеркала текущей системы

Локальный репозиторий (зеркало) текущей установленной системы,  может достигать 150 ГБ и размер растёт. Т.е. раздел для таких данных, используемых только в Linux, имеет смысл поместить в LVM.
Т.к. апгрейд системы, случается ежегодно, то старое зеркало вполне может мигрировать на другие разделы (другие диски). Такие задачи, хорошо укладываются в логику LVM.
Однако и тут можно поработать надо размерами данных, разделить их на бинарные и исходные коды и разнести по разным разделам.


GPT. Раздел для хранения текущей версии ядра Linux

Это вообще, может показаться странным. Однако и на это, есть свои соображения.
Исходные коды ядра сейчас в сжатом виде имеют размер ~ 70-100 MiB.
Т.е. для хранения можно сделать небольшой размер раздела. Как раз размер CD подойдет.
Этот раздел - для души, чтобы не потерять вечную ценность.
Размер у диска CD-R в наличии - 736960512 байт. Его и зададим, но в KiB.
719688KiB.
Код у раздела: 8301 Linux reserverd. Потом найду и изменю на более подходящий для файловой системы ISO9660.
А вот файловую систему, сделаю ISO9660. И с помощью волшебной утилиты xorriso, буду записывать файлы на раздел, сразу в формате ISO9660. Это восхитительная возможность.

# xorriso -dev stdio:/dev/sda19 -blank

А это запись произвольных файлов:

# xorriso -dev stdio:/dev/sda19 -add ./*.log

После этого, раздел можно примонтировать в системе, как обычный CDROM, правда только на чтение.
Существуют опции для задания метки тома, и пр. меток относящихся к формату ISO9660.
# xorriso -dev stdio:/dev/sda19 -volid 1
Стандарт ECMA-119 разрешает только ASCII символы из набора [A-Z0-9_].: "VOL_123". Всего 32 символа.

# xorriso -dev stdio:/dev/sda19 -joliet on -blank

Пополнять его можно автоматически по расписанию.

"Сбросить" раздел можно в файл iso-образа, а потом записать, либо сразу на носитель CD-R в дисководе.

# dd if=/dev/sda19 of=~/sda19-cdr.iso
1439376+0 записей считано
1439376+0 записей написано
скопировано 736960512 байт (737 MB), 24,7701 c, 29,8 MB/c

Видно, что размер образа раздела - совпадает с заданным, при его разметке. И внутри ISO9660.
Скорость небольшая, потому что копируется на usb-ssd диск.
Полученный файл можно примонтировать и просмотреть, всё ли корректно. Особенно имена, даты, метки.

Ну и для полного улёта, такое же счастье доступно для DVD-R. Что даёт ~ 4.7 GB. 4700372992 байт, 4590208KiB.


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

В помощь:
# man xorriso

Пока неизвестно, как раздел такого типа поведет себя в других операционных системах. В Linux, на удивление, всё работает, даже утилита "Диски" показывает, что раздел содержит iso9660. А вот с типом раздела непонятно.
Итого 20 разделов:

Total free space is 4365088733 sectors (2.0 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved
   3          935936        17713151   8.0 GiB     8200  Linux swap
   4        17975296        34752511   8.0 GiB     8200  Linux swap
   5        35014656        83367935   23.1 GiB    8300  Linux filesystem
   6        83630080       131983359   23.1 GiB    8300  Linux filesystem
   7       132245504       180598783   23.1 GiB    8300  Linux filesystem
   8       180860928       229214207   23.1 GiB    8300  Linux filesystem
   9       229476352       422889471   92.2 GiB    AF00  Apple HFS/HFS+
  10       423151616       616564735   92.2 GiB    0700  Microsoft basic data
  11       616826880       665180159   23.1 GiB    0700  Microsoft basic data
  12       665442304       858855423   92.2 GiB    AF00  Apple HFS/HFS+
  13       859117568      1052530687   92.2 GiB    0700  Microsoft basic data
  14      1052792832      1246205951   92.2 GiB    AF00  Apple HFS/HFS+
  15      1246468096      1294821375   23.1 GiB    0700  Microsoft basic data
  16      1295083520      1343436799   23.1 GiB    8301  Linux reserved
  17      1343698944      1392052223   23.1 GiB    8301  Linux reserved
  18      1392314368      1489020927   46.1 GiB    0700  Microsoft basic data
  19      1489283072      1490722447   702.8 MiB   8301  Linux reserved
  20      1490984960      1500165375   4.4 GiB     8301  Linux reserved


Разделы №5-6, №9, №10 - первые системы Linux, Mac OSX, Windows7.
Разделы №7-8, №12, №13 - вторые системы Linux, Mac OSX, Windows7 ( в рамках процедуры обновления "тик-так").
Разделы №11 - раздел для обмена небольшими данными.
Раздел №20 - можно использовать для обмена данными побольше.
Раздел №14, №15 - разделы для полного резервирования дисков систем MacOSX и Windows (байт-в--байт).

GPT. Как хранить пользовательские данные

Как лучше, один раздел LVM ~ 1.5 TB или несколько меньших разделов, в качестве физических томов?
В пользу одного раздела, то, что на нижнем уровне (уровень таблицы GPT), будет четко понятно - один раздел LVM, и что внутри, надо смотреть утилитами LVM. Однако, всё простраство раздела LVM, будет доступно только в Linux и недоступно в других системах.
Да, у Linux - LVM и RAID разделы, у Apple - Apple RAID, у Windows Windows LDM data и  динамические диски. Т.е. те разделы, которые предназначены для хранения данных, надёжного хранения, недоступны из других систем. И если система отказала, ну Вы поняли.
Linux является основной системой и данные будут храниться в ней, но данные для домашних машин под Windows.
Может, пока не поздно, сделать раздел для хранения данных, доступный и в Windows, например 500 ГБ отформатированных NTFS? Или весь свободный объем в NTFS. И пусть линукс мучается с NTFS.
Будет прекрасно, вынул диск из сервера, подключил к настольному компьютеру и получил доступ к данным. Сунул обратно - доступ по самбе. И не обращать внимание на производительность. А?
Такой вариант мне нравиться и я так сделаю, на двух других дисках, меньшего объема.
Тут есть конечно риск, при всех этих движениях, случайно уронить диск, зацепить или физически повредить, или электрически повредить. Т.е. физические манипуляции с дисками заполненными хранимыми данными, не приветствуются.


Кстати, т.к. пока есть 2 незаполненных диска, можно попробовать, на одном диске один подход, на другом - другой. И выбрать подходящий. А варианты разметки сохранять в файлах, и загружать, и экспериментировать.

Возможно, стоит сделать размер LVM тома кратный размеру однослойного blu-ray диска.
То что, будет большой раздел LVM, я уже определился. Т.к. намного проще манипулировать логическими томами, чем напрямую в GPT.

Также должен существовать и большой раздел Linux (пусть и в LVM), размер которого можно изменять динамически. Т.к. файлы могут быть большими.


Посмотрим, какие ограничения возникнут при использовании NTFS в Linux. Первое и главное - непонятен уровень поддержки всех возможностей NTFS. Не получится ли так, что запись из под Linux работает, а в Windows - разрушенная файловая система или с ошибками.

Сделаю разделы LVM (будущие 2 физических тома), каждый по 1 TiB неформатированной емкости. Тибибайт - места достаточно, даже для полного образа Терабайтного диска. Выясниться точно, после форматирования.

Total free space is 70121437 sectors (33.4 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648          673791   128.0 MiB   0C01  Microsoft reserved
   3          935936        17713151   8.0 GiB     8200  Linux swap
   4        17975296        34752511   8.0 GiB     8200  Linux swap
   5        35014656        83367935   23.1 GiB    8300  Linux filesystem
   6        83630080       131983359   23.1 GiB    8300  Linux filesystem
   7       132245504       180598783   23.1 GiB    8300  Linux filesystem
   8       180860928       229214207   23.1 GiB    8300  Linux filesystem
   9       229476352       422889471   92.2 GiB    AF00  Apple HFS/HFS+
  10       423151616       616564735   92.2 GiB    0700  Microsoft basic data
  11       616826880       665180159   23.1 GiB    0700  Microsoft basic data
  12       665442304       858855423   92.2 GiB    AF00  Apple HFS/HFS+
  13       859117568      1052530687   92.2 GiB    0700  Microsoft basic data
  14      1052792832      1246205951   92.2 GiB    AF00  Apple HFS/HFS+
  15      1246468096      1294821375   23.1 GiB    0700  Microsoft basic data
  16      1295083520      1343436799   23.1 GiB    8301  Linux reserved
  17      1343698944      1392052223   23.1 GiB    8301  Linux reserved
  18      1392314368      1489020927   46.1 GiB    0700  Microsoft basic data
  19      1489283072      1490722447   702.8 MiB   8301  Linux reserved
  20      1490984960      1500165375   4.4 GiB     8301  Linux reserved
  21      1500428288      3647911935   1024.0 GiB  8E00  Linux LVM
  22      3648174080      5795657727   1024.0 GiB  8E00  Linux LVM




Остается ~ 33GiB, которые можно потратить на эксперименты с HPA и пр.

GPT. Перенос сформированной таблицы GPT на другой диск

Диск /dev/sdb, размечать в ручную не надо. Есть встроенное средство "репликации". Доступно из расширенного меню, вызываемого по команде x.

Итак,
# gdisk /dev/sda

Вводим x - расширенная функциональность.
Затем выбираем команду r - репликация.
вводим диск: /dev/sdb

Выходим из программы.

# gdisk /dev/sdb
Вводим x - расширенная функциональность gdisk
Затем набираем команду f. Рандомизация GUID. Это создаст на этом диске, разделы с уникальными (это требование GPT) GUID. А структура GPT Таблицы и GUID разделов - всё сохраниться.
Набираем w - запись изменений таблицы на диск.

Для проверки, можно использовать команду i, она печатает подробную информацию о разделе и сравнить GUID раздела двух дисков - они должны различаться.

Всё.
Два диска /dev/sda и /dev/sdb - размечены и готовы.

GPT. Сохранение таблицы разделов. Распечатка твёрдой копии
Что надо сделать обязательно, это воспользоваться командой b - backup, для резервирования GPT разметки дисков /dev/sda /dev/sdb
Полученные файлы сохранить на CD/DVD.
Далее, таблицу надо распечатать, по каждому диску и сохранить в папке конфигураций (обычной канцелярской папке).
Т.к. в системе настроен сетевой принтер, то можно отправить на принтер вывод команд:
# pvdisplay | lpr
# vgdisplay | lpr
# lvdisplay | lpr

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

Даже, при диске выглядящим как "сырой","неформатированный", возможно будет монтировать разделы, просто по их смещениям.

При обращении с разделами, главное, не совершить "ошибки оператора".

GPT. GRUB2 BIOS/GPT boot

У GRUB2 существует хитрая возможность загрузки на компьютере с BIOS, с GPT диском. Но, данная возможность мало совместима с другими операционными системами.
Для GRUB2 создается специальный раздел BIOS Boot partition, в специальном месте.
Нетривиальная настройка, поэтому как-нибудь потом.

LVM. Инсталляция пакетов

LVM будет использовать последней, второй версии.
# apt-get install lvm2


LVM. Оформление тибибайтных разделов в качестве физических томов

Для первого диска: /dev/sda
 # pvcreate /dev/sda21
  Writing physical volume data to disk "/dev/sda21"
  Physical volume "/dev/sda21" successfully created

# pvcreate /dev/sda22
  Writing physical volume data to disk "/dev/sda22"
  Physical volume "/dev/sda22" successfully created


successfully - успешно

Для второго диска: /dev/sdb
# pvcreate /dev/sdb21
# pvcreate /dev/sdb22

Для просмотра списка физических томов:

# pvdisplay
  "/dev/sda21" is a new physical volume of "1,00 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sda21
  VG Name              
  PV Size               1,00 TiB
  Allocatable           NO
  PE Size               0  
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               Здесь будет GUID физического тома
  
  "/dev/sda22" is a new physical volume of "1,00 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sda22
  VG Name              
  PV Size               1,00 TiB
  Allocatable           NO
  PE Size               0  
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID              
Здесь будет GUID физического тома  
  "/dev/sdb21" is a new physical volume of "1,00 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb21
  VG Name              
  PV Size               1,00 TiB
  Allocatable           NO
  PE Size               0  
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID              
Здесь будет GUID физического тома
   "/dev/sdb22" is a new physical volume of "1,00 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb22
  VG Name              
  PV Size               1,00 TiB
  Allocatable           NO
  PE Size               0  
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID              
Здесь будет GUID физического тома  


LVM. Включение физических томов (разделов) в группу томов

Группа томов (volume group - VG).
Как лучше, объединить физические тома (быв. разделы) одного диска в одну группу, а другого в другую.
Или, в одну группу объединить разделы (/dev/sda21 и /dev/sdb21), а во вторую (/dev/sda22 и /dev/sdb22).

Или, все 4 физических тома в одну группу? И тогда, это аналог JBOD, одного большого небезопасного 4 тибибайтного пространства. Вполне может возникнуть и такая потребность.

Или "крест-на-крест".

Воспользуюсь первым вариантом, т.к. расширение идет, за счет физического тома группы, т.е. за счёт раздела на том же диске.
# vgcreate microserver-vg-one /dev/sda21 /dev/sda22
# vgcreate microserver-vg-two /dev/sdb21 /dev/sdb22
Для просмотра существующих групп томов:
# vgdisplay


 --- Volume group ---
  VG Name               microserver-vg-two
  System ID            
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2,00 TiB
  PE Size               4,00 MiB
  Total PE              524286
  Alloc PE / Size       0 / 0  
  Free  PE / Size       524286 / 2,00 TiB
  VG UUID              
Здесь GUID группы томов  
  --- Volume group ---
  VG Name               microserver-vg-one
  System ID            
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2,00 TiB
  PE Size               4,00 MiB
  Total PE              524286
  Alloc PE / Size       0 / 0  
  Free  PE / Size       524286 / 2,00 TiB
  VG UUID              
Здесь GUID группы томов


LVM. Создание логических томов

Логический том будет выглядеть обычным блочным устройством, которое можно форматировать в любую файловую систему.

Создаётся, логический том, командой lvcreate.
Обязательно указываются опции размера и группы томов.

# lvcreate -L 500GiB microserver-vg-one
# lvcreate -L 500GiB microserver-vg-two

Можно еще опцию -n, для задания имени логического тома указать.
С учётом того, что служебная информация, уменьшит результирующий объем.
Если бы знать точно, размер служебной информации, чтобы получить чистое форматированное пространство объемом 500GiB.

# lvdisplay
  --- Logical volume ---
  LV Path                /dev/microserver-vg-two/lvol0
  LV Name                lvol0
  VG Name                microserver-vg-two
  LV UUID                stGh15-9r1u-5hUQ-0c3q-fIVm-aVDk-cSJmsE
  LV Write Access        read/write
  LV Creation host, time
ubuntu, 2012-10-24 16:00:00 +0400
  LV Status              available
  # open                 0
  LV Size                500,00 GiB
  Current LE             128000
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1
  
  --- Logical volume ---
  LV Path                /dev/microserver-vg-one/lvol0
  LV Name                lvol0
  VG Name                microserver-vg-one
  LV UUID                dStTWg-YzsT-vuhX-oQpO-KQG2-9HAy-kL71Kn
  LV Write Access        read/write
  LV Creation host, time ubuntu
, 2012-10-24 15:59:53 +0400
  LV Status              available
  # open                 0
  LV Size                500,00 GiB
  Current LE             128000
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0


Из простых операций с LVM всё.


LVM. Экспорт/Импорт

Да, ещё. Т.к. тома создавались под графической операционной системой, то прежде чем их использовать на микросервере, надо их отключить от этой системы (деактивировать) и потом подключить в микросервере (активировать).
Вот уже и возникло, серьёзное ограничение доступности данных. А ну как, система незагружается, как тогда деактивировать тома?
И на этот вопрос, ответ: надо активировать группу томов при загрузке, и деактивировать при выключении.
Деактивация при выключении vgchange -an
Активация при загрузке: vgchange -ay

Отмонтируем файловые системы, расположенные на логических томах, которые примонтированы:
Используется команда: umount


# vgchange -an microserver-vg-one
# vgchange -an microserver-vg-two

После загрузки микросервера

Можно посмотреть видны ли часть LVM:
root@microserver:# vgscan
root@microserver:# vgdisplay

root@microserver:# vgchange -ay 

Отформатировать логические тома:
# mkfs.ext4 /dev/microserver-vg-one/lvol0
# mkfs.ext4 /dev/microserver-vg-two/lvol0

Примонтировать и использовать:
# mkdir /mnt/disk500GiB-1 /mnt/disk500GiB-2
Тестовое монтирование:
# mount -t ext4 /dev/microserver-vg-one/lvol0 /mnt/disk500GiB-1
# mount -t ext4 /dev/microserver-vg-two/lvol0 /mnt/disk500GiB-2

Не забыть про права пользователей, для доступа новой системе.


LVM. Возможности по работе с логическими томами

Изменение размера
Изменение размера логического тома. Состоит из двух частей - изменение размера логического тома LVM, за счет места в группе томов и изменение размера файловой системы.

Файловые системы ext3, ext4 поддерживает увеличение раздела "на лету", без демонтирования.
# man resize2fs

Самый больной вопрос, что будет с пользовательскими данными, при изменении размеров?


LVM. Резервирование данных с задержкой

Есть интересная идея, резервировать логический том LVM, с некоторой задержкой по времени. Длительность задержки - это параметр, его можно настроить вплоть до недели, месяца.
Основная польза - это нераспространение (задержка распространения) негативных изменений на резервную копию, чем страдают все "зеркала". Это, даёт потенциальную возможность оперативного предотвращения, при наличии соответствующих знаний и плана восстановления, а также вовремя замеченных негативных изменений. А можно "прохлопать".


LVM. Снимки состояния

Снимки состояния, "снапшоты" - очень полезная вещь, для резервирования постоянно изменяющихся данных.
Снижает производительность "на запись".

GPT. HPA - Host protected area

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

Продолжение будет в Части II.


Ресурсы

1.  http://xgu.ru/wiki/LVM
2. Управление логическими томами. http://www.ibm.com/developerworks/ru/library/l-lvm2/
3. http://xgu.ru/wiki/raid
4. Параметры влияющие на производительность программного raid. http://romanrm.ru/mdadm-raid
5. Таблица разделов GUID. http://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUID
6. EFI system partition. http://en.wikipedia.org/wiki/EFI_System_partition
7. Windows & GPT FAQ. http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx
8. Secrets GPT. http://developer.apple.com/library/mac/#technotes/tn2166/_index.html
9. 6 ошибок людей с маленькими разделами. http://www.outsidethebox.ms/13005/
10. MSR - Microsoft Reserved partition.  http://en.wikipedia.org/wiki/Microsoft_Reserved_Partition
11. Выпуски NTFS-3G. http://www.tuxera.com/community/release-history/
12. Область (раздел) HPA. http://en.wikipedia.org/wiki/Host_Protected_Area
13. Подсистема хранения данных в ОС Linux. LVM. http://www.ibm.com/developerworks/ru/edu/os_architecture_course3/section13.html