Редактирование: UNИX, весна 2008, 06 семинар (от 18 июля)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

= Организация системы резервного копирования =

* '''Докладчик:''' Илья Слепнёв
* '''Аудиозапись:''' http://esyr.org/lections/audio/uneex_2008_summer/uneex_seminar_08_07_18.ogg

Почему важно об этом говорить, почему нельзя просто написать в cron'е скрипт, который будет копировать всё вы одну большую помойку, из который всё потом будем доставать. Да, если машин немного (50) и их количество не увеличивается, то да, так можно делать.

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

Что такое всё хорошо?
* Надо следить, что всё бэкапится правильно
* Следить, чтобы это было в разных датацентрах

В итоге овзн. такая полуэнтерпрай система, из известных Аманда и Бакула. Дальше будет рассказ о бакуле.

Есть у нас сервер, у сервера есть неск. файловых хранилищ, на каждом по 10-15 терабайт. Вот у нас два сервера в одном датацентре, два в другм. Предположим, у нас есть два датацентра

Что такое бэкап, зачем он нужен и какие цели.

[[Изображение:Uneex seminar 08 07 18 file dump architecture.png|thumb|240px|Файловая помойка]]
Не совсем понр. фраза по поводу самписных скриптов. Потому что для клиентв нек-рых даатцентров предв. решение: вместо стороннего ПО предл. большой зашаренный диск, который всем доступен, бъём с н-ным количеством терабайт. Для системного адм. одного сервера на порядок проще взять и бъед rsync+logrotate или орг. дампы, которые туда будут выливаться. Причём это прще и для адм. бэкапа этого датацентра. поск. ему достаточно обесп. квоту и доступ к ресурсу. Например, такая схема была у голдентелекома. Если взять орейлевскую книжку, то там начало идёт с такой схемы, поск. она проста и решает 90 процентов. На ст. случаев выявляется много инт. проблем. В бакуле проблема следующая: сделать бэкап прблемы не составляет. Осн. проблема --- эти данные восст. в нужный момент и в нужное время. Один из моментов, связанных с бакулой --- в бакуле на этапе восст. бэкап восст. с теми же правами и в тоже окруж, откуда он брался. Если польз. полностью утерял данные, или проихошла потеря БД бакуловской, то пароли и зашифр. данные предст. подв. камень. Простая вещь --- как обезопасить пользвателя, чтбы сисадмин бэкапного сервера не мог данные прочитать. В бакуле это предусм., но при потере всех данных возн. проблема.

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

В случае, если кончается мест на сторадж-демоне, то ...

[[Изображение:Uneex seminar 08 07 18 bacula architrecture.png|thumb|240px|Архитектура Bacula]]
Что из себя предст. бакула: есть директори, есть файл-демоны, есть сторадж. В директори хранится то, что и как бэкапить, все настрйки. Когд приходит время чт-то забэкапить, он созд.э запись в sql-таблице, он собщ. файл-демону, который имеет только адрес директора и пароль, директр даёт ему адрес сторджа, после чего файл-демон открывает сокет и льёт сжатый поток. В итоге на сторадже данные лежат.

При этом что важно: эти бэкапы лежат в виде томов. Это всё пошло с ленточных времён, поск. когда том заполнился, его меняют.

[[Изображение:Uneex seminar 08 07 18 full incremental backup.png|thumb|240px|Полный и инкрементный бэкап]]
Есть у каждого пользователя хранилища, пользователь с айлами рабтает. Какие-то файлы меняются, какие-то нет. Но польз. всегда инт. сохр. данных. Если файл испортился, то должна быть служба, куда можн прити и запросить файл. Есть схема полного бэкапа, когда бэкапится всё не задумываясь. Есть условно 4 среза и говрится, что бэкап сохр. на 4 дня. Понятно, что 4 дня мало и отжирает это места много. Кроме того, для малоисп. данных  обнруживается, что они испорчены, небыстро.

Есть схема инкр. бэкапа, которая исп. команду dump -loop, кторый помечает ыайлы как архивные и бэкапит птом только изм. Вторая схема --- rsync, и копируется только новые файлы. В этом случае есть фуллбэкап, и есть инкр. бэкапы, места надо меньше, глубину можно делать больше. Но тут возн. проблема, чо когда нам нужен файл, то надо просмотреть много бэкапов, чтбы получить нужную ревизию. Для лент очень плохо.

[[Изображение:Uneex seminar 08 07 18 hanoi tower backup architecture.png|Схема бэкапа "Ханойская башня"]]
Дальше начинется лирика по поводу минимизации количества исп. томов, осн --- ханйская башня.

В бакуле исп. diff-backup, когда инкременталы делаются от последнего фулла и надо всего две ленты. Места под это надо больше, чем incr, и меньше, чем full.

На случай пожара бэкапы вывозятся.

Про аманду.

[[Изображение:Uneex seminar 08 07 18 client server.png|thumb|240px|Клиент-серверная архитектура]]
После тго, как определились с бэкапом: расписание, чт бэкапить, реглмаент, посчитали сервера... И вот если они ломанулись все в час ночи, то стало плохо, и это реальная проблема файлопомойки. Именно оттуда пошёл переход к центр. схеме бэкапа, когда это перевдится на классич. схему клиент-сервер. И первой имплементацией этого была аманда. Она сост. из клиента на сервере, и сервера, кторый знает всех клиентов и бэкапит в соотв. место. И бакул очень сильно перекрывалась с амандой, пока они не выделили стораджи. Эта схема чем хороша и плоха: мы сразу ушли на центр. систему упр. бэкапов, можно управлять нагр. канала, орг. смену носителей... Одн. с этим возн. две проблемы. Первая проблема организационная: если мне как клиеннту надо восст. файл, то я обр. к адм. сервера "дай мне этот файл". Суть закл. в тм, что за восст. файла тв. админ сервера. Клиент потерял возм. взять нужный файл нужнй даты. Ммент второй: если не хватает стораджа, чего делать? Здесь взн. проблема, поск. настр. клиеннта и сервера взимосвязаны. И третья проблема: ... rmt+mt. Здесь есть одн проблема: сами ленты явл. однопоточными, и это знчит, что если один сервер нчинает наливать данные, то он начинет наливать на дну.  Соотв, для ускорения либо надо их лить в неск. лент. При этом разносится хрнилище и по объёму, и по скрости. Но каждая настройки этой связи делается ручками.

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

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

В бакуле псле каждого событие выдаётся сообщения мессадж-демону, который уже по опр. првилам что-то делает. В чстности, это небх. для ситуации: не всегда мы копируем только файлы: у нас есть БД, svn, которые надо подготвки бэкапа. Это подготовка на клиенте. И если на клиенте проихошла ошибка, то админ центр. сервера ничего делать не мжет, может администратор файл-демона, и ему надо посылать сообщения.

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

В случе бакулы появилась bacula console. Что она представляет? Н клиенте и любм месте человек может зпустить bacula console, подкл. к директору и вып. действия. Сервера можно разбить по группам, указать, кто что можно делать. Это всё хорошо скриптуется, и можно, например, написать скрипты, кторый проеряют, забэкапился контрольный файл, или скрипт для восст. файлов. При восст. директор разворчивает в памяти расп. файлов

Есть такая штука, как скорость восставновления. У нас есть сервер, и есть проблема, что 150 гигабайт данных надо восст. в течение 10 минут. По-хорошему, ткие данные бэкапить не над, их надо реплицировать. В том единственном случае, когда такое случилось, надо было остановить все бэкаплящиеся процессы, и за полчаса он это развернул.

Юрий: что надо юэкапить, что нет: файлы делятся на взм. их доступа без системы бэкапа. Если установка сервера на freebsd занимает 20 минут, то смысла бэкапить систему нет. Тчно так же настройки в системе контроля версий. П поводу файлов разрботчиков палка о двух концах: как только разработчики узнали, что их файлы не бэкапятся, а бэкапится svn, то в дереве svn стали бэкапиться такие вещи, как full_dump.sql.gz. Пэому сост. реком. чт можно бэкапить, что нельзя, то решается в каждом случае кждый сам.

Имея sql-ную бзу данных ...

Чтобы спать спсокйно администратору бэкапа, то пишется питновский скриптик, кторый делае на директорах select по бд, в ...

Собираются переходить на другую схему, когда ...

[[Изображение:Uneex seminar 08 07 18 bacula bugs.png|thumb|240px|Проблемы с Bacula]]
На сторадж-демонах есть тома,раньше это были ленты, сейчас просто файлы, и определяется политика того, сколько таких файлов, скольк в них файлов, какой размер, и как происходит ротация. К схеме бэкапа надо подходить внимательно. Была токая дасадная ошибка: фуллбэкап начинался на начале стораджа, и там уже есть предыдущий бэкап, и когда делл следующий и не сделался, то нет ни придыдущего фуллбэкапа, ни текщего. Для решения этого делали отдельные сторадж-демоны для фулл и инкрементал бэкапов, и сторадж фуллбэкапов имел место на три-четыре фуллбэкапа, и при сбе фуллбэкапа мжно восст. файл двухнедельной давности, что лучше, чем ничего. Второе: проблема была связана с тем, что если при конце места для бэкапов, то начинал писать в нпчало и затирался фуллбэкап. Есть ещё один момент: под бакулу файлдемон есть под windows, есть одна прблема, которую в 2.4 не устранили, говорят, что появляется она в win-клиенте, дело в тм, что имена в utf-8, пэтому база должна быть в utf-8, и есть проблема с mysql,  поск. подкл. с кодировкой по умолч.,

Если взять орейлевскую книжку, то там половина --- бэкап файлов, половина --- бэкап БД. В бакуле это упрощен до скриптв, before_backup и after_backup.

(рассказ про backup mysql)

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

Ещё один аспект: регулярные тренировки по восстанвлению.

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

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

Файл-директор по своей установке это прост. вещь. Конф. файл занимает 4 строчки, поэтому плодить коеф. файлы для 10 серверов мжно делать на бакуле.

Если есть Kerberos. Трудоёмксть поднятия kerberos-сервера на порядок выше, даже если он много для чего пригождается.

У аманды есть большая роблема --- расписание. В бакуле директор может следить за расп. У директора может быть настройка, сколько одновременно конкурир. заданий могли быть на сторадже. Суть в том, что расп. можно сделать дост. чётким. В аманде сист. сост. расп. сложнее, птому что там расп. явл. вычисляемым. То есть, если начинает одно на другое наползать, то всё. В случае же бакулы, если concurrent стоит 1, то пока один не освободит ресурс, другой его не займёт.

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

Если мы говорим о OS-продукте бэкапа, то бакула самая достойная. Единственное --- осторожность с скриптами before и after, и вторе --- кириллические имена файлов.

[[Изображение:Uneex seminar 08 07 18 ntp architecture.png|thumb|240px]]
Ещё одна мелочь, за кторой надо следить --- время на дирекоре, поск. если оно сбивается, то у файл-демонов оно при коннекте будет сконф. по директору. В зщиту бакулы --- не тльк она так обх. со временем.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://libesyr.so/wiki/UN%D0%98X%2C_%D0%B2%D0%B5%D1%81%D0%BD%D0%B0_2008%2C_06_%D1%81%D0%B5%D0%BC%D0%B8%D0%BD%D0%B0%D1%80_%28%D0%BE%D1%82_18_%D0%B8%D1%8E%D0%BB%D1%8F%29

Редактирование: UNИX, весна 2008, 06 семинар (от 18 июля)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 2: / Строка 2: @@
 * '''Докладчик:''' Илья Слепнёв
-* '''Информация  семинаре:''' http://uneex.ru/Events/Backups
 * '''Аудиозапись:''' http://esyr.org/lections/audio/uneex_2008_summer/uneex_seminar_08_07_18.ogg
-* '''Фотографии:''' http://esyr.org/photo/uneex/080718/
 Почему важно об этом говорить, почему нельзя просто написать в cron'е скрипт, который будет копировать всё вы одну большую помойку, из который всё потом будем доставать. Да, если машин немного (50) и их количество не увеличивается, то да, так можно делать.
-Когда данных много, то возникают задачи переноса данных. Если есть несколько датацентров, то есть желание, чтобы бэкапы были в разных датацентрах. Если есть какие-то скрипты, то при переезде задействуются два человека: ответственный за скрипты и тот, кто переводит сервер. Поэтому возникла задача, чтобы в скриптах просто указывается адрес, и дальше всё хорошо.
+Когда данных много, то возникают задачи переноса данных. Если есть несколько датацентров, то есть желание, чтобы бэкапы были в разных датацентрах. Если есть какие-то скрипты, то при переезде задействуются два человека: тветственного за скрипты и того, кто переводит сервер. Поэтому взникла задача, чтобы в скриптах просто указывается адрес, и дальше всё хорошо.
 Что такое всё хорошо?
@@ Строка 37: / Строка 35: @@
 Есть схема инкр. бэкапа, которая исп. команду dump -loop, кторый помечает ыайлы как архивные и бэкапит птом только изм. Вторая схема --- rsync, и копируется только новые файлы. В этом случае есть фуллбэкап, и есть инкр. бэкапы, места надо меньше, глубину можно делать больше. Но тут возн. проблема, чо когда нам нужен файл, то надо просмотреть много бэкапов, чтбы получить нужную ревизию. Для лент очень плохо.
-[[Изображение:Uneex seminar 08 07 18 hanoi tower backup architecture.png|thumb|240px|Схема бэкапа "Ханойская башня"]]
+[[Изображение:Uneex seminar 08 07 18 hanoi tower backup architecture.png|Схема бэкапа "Ханойская башня"]]
 Дальше начинется лирика по поводу минимизации количества исп. томов, осн --- ханйская башня.