Как просмотреть раздел внутри раздела или kpartx в деле

Вот бывает беда. Сделал ты виртуальную машину. Скормил ей в качестве раздела lvm-том. И на тебе, внутренние потроха тебе не видны. А почему так? А просто, ну не знает udev о том, что вот внутри вот этого блочного устройства(который является раздел) есть таблица разделов, которою тоже надо представить в виде блочных устройств. И беда часто подкрадывается не заметно. Например сделал ты бэкап lvm-тома (очень хитрая штука этот lvm-snapshot). И вот надо бы данные с него перекинуть, но частично. Или же выкорчевать шифрованный раздел из нутра. В общем задач напридумывать можно дофига, а чаще они сами приходят и предлагают себя решить.

Вот собственно с помощью чего это можно посмотреть
apt-get install kpartx

допустим /dev/sata-vol/virt1-root корневой раздел нашей виртуальной машины. На нем какие-то свои разделы.

kpartx -l /dev/sata-vol/virt1-root # покажет как будут связаны эти разделы с текущим /dev
kpartx -a /dev/sata-vol/virt1-root # свяжет эти разделы, и они станут доступны

P.S.: вот таким простым и не хитрым способом мы увидим внутренности нашего раздела.

debian и lvm

С начала ещё раз о разделах.

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

Есть второй косяк за разделами, не возможность online(на лету) расширения раздела, если нет свободного места перед следующим разделом. Ну к примеру.

sda1 - 10 Гигов

свободно 20 Гигов

sda2 - 40 гигов

sda3 - 60 гигов

свободно 50 Гигов

В данном случае, по быстрому sda1 увеличить можно только на 20 Гигов, sda3 на 50 Гигов, а sda2 в обломе. Т.е. если понадобится больше место для sda2, то придется двигать разделы. Эта операция явно не на 10 минут и сервер будет в простое. Т.е. приятных тебе выходных. А ты как думаешь, в рабочее время что ли?

Вот по этому-то с разделами такая давняя вражда у многих. И со вторым косяком тебе ни какой райд не поможет.

Как разбивать диски или что я делал не так.

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

Что я люблю использовать в этом деле.
1. Это LVM, о нем я расскажу чуток позже, но штука крайне полезная, особенно когда надо расширять дисковое пространство.
2. Мозг. Да бывало не использовал.

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

Что хорошего в этих подходах.
В первом - не заморачиваемся. Один раздел подо всё. Но с другой стороны в случае каких-либо ошибок на разделе приготовьтесь, что ждать проверки при 2-4 Тб, вам придется очень долго. И  бэкап целого раздела, в таком случае, это что-то с чем-то.

Много всяких разделов - муторно обслуживать, постоянно надо следить за пространством. Но в случае lvm бывает удобно. Надо поднять виртуалку - нате отдельный раздел. Надо ограничить папки пользователей - для каждого пользователя свой раздел на тцать гигов(хотя есть и квоты для этого дела). В общем гибкость есть в этом деле.

Что лучше? В общем ситуация тут такая. Когда места много и система стабильна разницы то и нет. Но, когда мы подходим к лимиту места, вот тут-то и появляется разница.
Ну например. У нас такая схема. Перечисляю каталоги у которых отдельные разделы(partitions)
/var/www # каталог для веба
/var/db # каталог для БД
/var/mail # каталог для почты
/var/log  # каталог логов
/ # корневой каталог

Например мы взяли и что-нибудь скачали в /root и практически под завязку забили корневой раздел(так делать не стоит, но иногда бывает, бэкап пишется в сеть, а сетевая шара смонтированная в раздел /root/backups отпала, вот и пишет он в корень). В случае если у нас один раздел на всё, то у нас скорее всего быстро отпадут логи, откажет БД на запись, и веб-сервер перестанет нормально функционировать, а также почта упадет. Т.е. сервер получил авто-dos(denial of service). Что не очень приятно. А вообще даже и катастрофично может быть. В случае когда под эти сервисы будут выделены отдельные разделы, то забивание корневого раздела это не беда.
Важно то, что если раздел сервиса почты вдруг переполнится, то БД не упадет и веб будет жить. Т.ч. в серверном варианте я за этот метод.

А по скольку каждому отдавать? Тут всё зависит от вас. И не читайте best-practice, где кто-то говорит 5.43Гига хватит под этот каталог, это бред, т.к. человек не знает вашей задачи. И ... беда, в начале вопрос сколько места и куда решить практически не возможно. В этом и вся загвоздка для начинающих. Место нужно сказать сейчас, а конкретно как оно будет на самом деле, хрен его знает. По этому часто и выбирают всё на одном разделе.

Вот например есть у меня самба, с хранением профилей подоконных пользователей.
В начале я выдал на профили 40 Гб, на шару 60Гб. И уже через 2 года места для профилей не осталось. И это при 10 пользователях. На самом деле всё место сожрали только 3 пользователя. А думал, что места хватит на 5 лет :) (Оптимист хренов). Спустя шесть лет(в сумме 8 лет) могу сказать, что профили пользователей весят в сумме 80Гиг, шара и хомяки (жарг. - домашние папки) весят 80Гиг. Вот такая беда. А раздел в начале был один на всех - 100 Гиг (Хардянки были по 120 Гигов в RAID1).

Так как же побороть страх перед множеством разделов? Вот об этом в следующем посте про LVM, тут он нам будет другом.

Бэкап. От слов к делу прошу любить и жаловать backup-manager

В общем ситуация такая. Бэкап может быть комплексным, а может быть и простым.
Есть много всяких программ для бэкапа. Есть платные, есть бесплатные. Смотреть мы будем в сторону бесплатных. Есть такая вещь как bacula, она сложная, но очень гибкая. О ней как-нибудь позже. А сейчас представлю тебе виновника этого поста backup-manager.
Устанавливаем:
apt-get install backup-manager
Он задаст пару вопросов и в общем ответив на них бэкап заработает.
Я правда всё равно потом правил немного конфигурационный файл.

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

backup-manager умеет работать с mysql, умеет дампить subversion, естественно работать с файлами, а так же с pipe. Ну и делать полные  и инкрементальные бэкапы. А также кидать всё это дело на amazon S3 или по ssh куда-нибудь, немного с rsync умеет работать.

У меня на сервере как раз subversion, www, mysql.

Вот пример настроек которые я изменил в файле /etc/basckup-manager.conf

# Где хранить бэкап
export BM_REPOSITORY_ROOT="/root/backup" # правда это сетевая шара.

# кто владелец файлов

export BM_REPOSITORY_USER="root"

export BM_REPOSITORY_GROUP="root"

# какие типы архивов надо будет делать, какие укажешь в ту секцию затем и лезь писать 

# настройки, за исключением tarball-incremental, т.к. он использует значения из tarball

export BM_ARCHIVE_METHOD="tarball-incremental mysql svn"

# Какие директории сохранять, etc - оно понятно. Не ленитесь сохранять конфиги.
# Хотя так же не ленитесь их записывать где-нибудь в инете.
# /var/www - директория с веб-проектами.
# /srv/trac - директория с trac проектами, хоть они и веб, но я вынес их отдельно
export BM_TARBALL_DIRECTORIES="/etc /var/www /srv/trac"

# промежуток между полными бэкапами.
export BM_TARBALLINC_MASTERDATETYPE="weekly"


# какие БД дампить, через пробел или все как у меня. Тут, что вам нужнее.
export BM_MYSQL_DATABASES="__ALL__"

# логин и пароль на доступ к БД

export BM_MYSQL_ADMINLOGIN="root"

export BM_MYSQL_ADMINPASS="password" # пароль я естественно поменял.

# Тут касательно svn репозитариев. Через пробел  

export BM_SVN_REPOSITORIES="/srv/svn/repo1 /srv/svn/repo2 /srv/svn/repo3"

Бэкап и как его есть.

Много чего я слышал про бэкап, и сам в молодости много чего не правильного про это дело говорил.
А давай подумаем что такое резервирование данных (в простонародье бэкап). В самом понятии всё заложено, это процедура создания и хранения запасной и в достаточной степени актуальной информации.
Т.е. если информация не актуальна через год, то смысла хранить нам эту информацию нет.
Если информация вообще не актуальна, то и хранить её нет смысла. Ну к примеру, у вас есть софт (к примеру firefox v2.1) и доступ к месту где всегда можно скачать нужную версию софта (ну торрент к примеру), то зачем вам в бэкап этот софт? Через какой-то промежуток времени, этот софт будет не актуален, а достать его будет легко. Т.е. нам с тобой нет нужды хранить хорошо доступную информацию.
Т.е. храним только то, что нужно и что нельзя найти из вне. И складируем эту информацию согласно актуальности.
Актуальность информации вещь сложная. Вот пример из моей рутины:
Есть небольшая база бухгалтерии. Средняя такая фирмочка.
Заранее известно, что месячный объем данных вбивается за неделю (такое часто бывает даже в средних фирмах). Т.е. если мы профукаем месячные данные, то у нас вычтут ЗП бухгалтера за 2 недели. Что не мало в принципе. Если профукаем недельные данные, то взбучку и премия долой. Если данные за 1-2 дня, то коробка вина и бутылка конфет - наше спасение. Т.е. необходимый срок резервирования - 1 или 2 дня. Так же стоит помнить, что у бухов красный месяц календаря бывает 4 раза в году (точнее 4.5). Т.е. в определенное время нам просто необходимо иметь резерв квартальных данных. Если что случится и не будет данных, то в задний проход швабру без вазелина - считай, что просто повезло и молись за такое везение.
А к чему я это все? Да к тому, что график и количество резервирования данных надо планировать для любой информации, и планирования это спасет от перерасхода места . А принцип "места много - влезет", отпадает по двум причинам:
1. Места всегда мало # я вот сейчас даже подумать боюсь, как я жил на 40Mb(я не ошибся именно сорок метров) винте.
2. Бэкап имеет место разрастаться со временем. # я тут новость не открыл
3. Принцип разумной достаточности никто не отменял # можно для маленькой фирмы и библиотеку ленточную купить, только вот дорого и не нужно.

Если в голове ещё стоит вопрос "А нафига оно мне надо", то вспомни про швабру без вазелина  и, представь, как она тебя ожидает. А я, пока ты будешь в ужасе изгонять швабру из своего мозга, расскажу тебе реальную историю:
    Некто П. обратился ко мне с "не работает ноут, я тут винду переставил, а данных нет. Верни, а то там фото и видео моего ребенка, жена мне яйца отрежет!" Причем по его виду я уже понял, что не шутит, и по мозгу она ему уже хорошо шлиф-машинкой прошлась. Данные я восстановил и его это спасло. Дал ему дельный совет, что и как делать. Через пол-года он снова обратился ко мне, только случай был хуже. А бэкапов он не делал. Что стало с его мозгом и с ним самим, я умолчу. Но поверь мне, я бы этого врагу своему не пожелал.

Дальше нам бы посмотреть, что нужно для бэкапа. А для него самое важное - место.

Надо понимать, что копию какой-нибудь одной вещи надо держать несколько. В разных временных рамках и прочее. Почему так, а многое, что может произойти. К примеру умышленный долгосрочный саботаж. Резкое изменения структуры данных. Систематические ошибки при обновлении ПО Т.е. мы попросту с тобой можем быть не готовы при одной единственной актуальной копии. Вот тут-то нас райды всякие и не спасают. Потому как это не резервное хранение данных. Ну а раз копий может быть несколько - к примеру 5 штук полных копий, то и данных будет в 5 раз больше. Значит места нужно не мало.

А теперь о железяках всяких.
Часто люди считают, что рейд спасет отца "русской демократии". Но не стоит забывать, что эта технология призвана сохранять работоспособность системы в случае смерти одного или нескольких хардов, но ни как не защищает нам от порчи информации посредством шаловливых ручек. А что есть на рынке, а на рынке в общем есть два варианта:
Ленты или харды. Другого в общем и нет.
У каждого варианта свои плюсы и минусы:
Ленты - физически и химически достаточно устойчивы (+). Цена достаточно дороговата, линейная запись и чтение (т.е. если надо обратить в середину данных, то прокрутить придется до середины) (-). Использовать кроме как в бэкапе сложно (-). Нужно спец. оборудование - стример (магнитофон :) ), иногда библиотека. Библиотека - это штука которая может менять кассеты в стримере и складировать в необходимом порядке кассеты(-). Оборудование не из дешевых и если объемы у нас маленькие, то не для нас (-). Ленты можно считывать на оборудовании других компаний, лишь бы стандарт подходил (+). Долгий срок хранения (+)
Харды - хранилище с хардами, простые харды. Можно взять салазки и записывать всё как на ленту. Записал на хард, вытащил старый, вставил новый. Унес старый и поехало по новой.
Плюс хардов - большая емкость, чем у ленты за туже стоимость (+). Нет необходимости в спец. оборудовании(+). Можно использовать не только для бэкапа(ну вот не хватает 500Gb харада, купил на  2 Тэра, 500 гиговый можно пристроить) (+). Не устойчив к физическим воздействиям, падения или окунуть в лужу. Если сгорит управляющая плата, то сложно с её заменой (-). Гарантийный срок годности, т.е. положить на 15 лет хард на полку не очень получится  (-).

Есть правда третий способ, о нем в следующей статье.

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

И надо помнить, что хранить данные надо начинать уже с момента настройки системы.

P.S.: когда случится твой epic fail, ты меня поймешь. В не зависимости, есть ли у тебя бэкап или нет, только твой зад кажет кто ты на самом деле.