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

Представим что у нас есть виртуальная машина на LVM разделе, внутри которой так же есть LVM разделы. К примеру CentOS, при установке, по умолчанию, создает LVM-based разделы, за исключением /boot.

Задача:

добраться до данных в этих разделах с родительской машины.

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

Первая часть тут.

Подарили мне на работе на день рождения HP N36L Microserver за непонятные заслуги, чем весьма меня озадачили вопросом о наилучшем его применении. Так-то я давно мечтал заменить старенький HP DC4200 на что-то более компактное и, главное, с большим количеством места под жёсткие диски. Но больше смотрел на башенные корпуса, в которые можно было бы насовать пару-тройку корзин на пять 3.5”HDD. А тут такая оказия.

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

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

К счастью, решить большинство этих проблем в Linux может технология LVM. Она создаёт дополнительную абстракцию — логические тома, которые видны в системе, как обычные разделы, однако реально ими не являются. Эта технология очень полезна для серверов, однако и на домашних компьютерах она приходится очень к месту. Я больше не думаю, какого размера диск выделить под систему, чтобы какой-нибудь texlive не забил бы всё место, но и чтобы лишние 5 — 10 гигабайт не пропадали просто так. LVM имеет ряд существенных преимуществ, значительно упрощающих жизнь:

• Логические тома LVM больше не привязаны к физическому местоположению. В рамках LVM вообще не существует такого понятия, как порядок логических томов.
• Размер логических томов можно увеличивать прямо на лету, а у отмонтированных томов можно кроме того легко уменьшать размер, не выходя из системы.
• При необходимости можно размазать логические тома по нескольким физическим жёстким дискам, таким образом увеличив доступное место. При этом система всё так же будет видеть только один логический том, хотя размер его будет превышать доступные размеры жёстких дисков. Можно провести и обратную операцию, удалив жёсткий диск из LVM, таким образом освободив его для другого использования.
• LVM поддерживает механизм снапшотов — мгновенных копий файловой системы тома. Это может очень пригодиться для создания бекапов.
• Есть ещё масса плюсов, о которых можно почитать в специализированных статьях про LVM.

Имеем: высоконагруженый MySQL сервер с таблицами объёмом десятки Гбайт.

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

Условия: процедура бекапа не должна ни коим образом сказаться на производительности MySQL во время проведения оной.

Отличительные особенности данного метода от десятков других:

• Используется снапшот LVM (Linux) для снятия снимка ФС, что позволяет избежать заметных на глаз локов таблиц
• Используется gpg для шифрования бекапа на лету
• Используются возможности IO шедулера CFQ (Linux) для присвоения высокого IO приоритета процессу mysqld и низкого процессу бекапа (tar)
• Используется бекап прямо в пайп, что позволяет еще более снизить нагрузку от бекапа на диск

Ваш MySQL даже не заметит что его бекапают, даже на высоких нагрузках и больших объемах

Вступление

Недавно мне потребовалось перенести несколько сайтов различных клиентов на нормальный выделенный сервер (не виртуальный). Я давно выбирал, где лучше арендовать сервер и выбором стала немецкая компания Hetzner Online и ее тарифный план DS 3000 (AMD Athlon 64 X2 4200+/2Gb DDR/2x160Gb HDD — как выяснилось потом — на сервере оказалось два винчестера по 320Гб).

Но мне не хотелось всех размещать на одном сервере. Поэтому было решено сделать виртуальные машины на базе технологии XEN (к тому же в придачу к серверу на ТП DS 3000 Hetzner Online бесплатно выдает 6 IP-адресов, которые очень удобно будут смотреться для отдельных проектов). В Сети можно найти много информации по теме настройки и самого XEN'а на Debian'e и настройки роутинга на нем, поднятии виртуалок на LVM (lvm дает большее быстродействие, чем виртуалки на базе image-файлов), даже в вики самой фирмы была информация об этом (но на немецком — Google Translate нам в помощь). Но. Было одно «Но». Она вся была разрозненная и кусками. Я нигде не смог найти толкового пошагового руководства для настройки «от» и «до».

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

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

Немножко о работе с soft'овым RAID (mdadm) и LVM, возможно при наличии кучи свободного времени ЭТО превратится в какую-то приличную статью… а пока, лишь куча команд с краткими комментариями.

Итак, однажды мне потребовалось больше места под виртуалбоксовую папку…

Задача

Когда диски были маленькие, а Интернет большой, владельцы частных FTP-серверов сталкивались со следующей проблемой:
На каждом жестком диске создавалась папочка Video или Soft, и получалось так, что добавив новый жесткий диск, приходилось делать на нем папочки Video2, Soft2, etc.
Задача поменять жесткий диск на диск большего объема приводила к тому, что данные нужно было куда-то переносить, все это происходило нетривиально и с большими downtime'ами.
Разработанная нами система в 2005 году позволила собрать надежный и быстрый массив в 3 терабайта, масштабируемый, расширяемый, в режиме онлайн, добавляя диски или целые сервера с дисками.
Цена всего решения составляла 110% от стоимости самих дисков, т.е. по-сути, бесплатной, с небольшим overhead.

Вот примерная схема устройства нашего хранилища: