Бэкап

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

Все началось с того, что сервер статистики контактного центра заказчика (на тот момент ещё потенциального) сбросил все пользовательские сессии и перестал отвечать на запросы. Соответственно к нему подкатили тележку с монитором и перезагрузили. Это обычно надо делать раз в 90 дней по инструкции от вендора, но тут это не делалось больше 500 дней. В общем, сервер отметил юбилей аптайма.

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

Но после накатывания бэкапа система просто легла.

В этот момент нас позвали отмечать день рождения сервера. Без него не работала балансировка нагрузки на операторов внутри КЦ.

Что это была за система?

Система Avaya Call Management System (CMS). Это кусок колл-центра, который собирает статистику по звонкам, операторам, нагрузке исторические и реал-тайм данные. На этом же сервере каждое утро собираются отчёты о работе. В реальном времени сервер говорит, какие операторы сейчас в каких статусах находятся, какие звонки обрабатываются, сколько звонков висит в очереди. В целом система нужна, чтобы следить за группами операторов, за колл-центром, чтобы правильно распределять нагрузку, потому что можно переносить операторов из ненагруженных линий в нагруженные и так далее. Обычно там просто сидят супервизоры и следят за всем происходящим. Прямых аналогов нет, обычно используются самописные решения или же всё вообще делается вручную. Аваевскую систему выбирают за надёжность и многофункциональность.

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

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

Первый день пятница

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

Приезжаем на место (напомню, что сервер лёг и удалённого доступа нет), подключаемся с монитором и клавиатурой, ещё раз смотрим, как система не стартует.

Я подключился не сразу. Когда подключился увидел, что диск переполнился ошибками из-за проблем бэкапа. Некоторые сервисы не стартовали почистили логи, стартовали руками.

У нас условно есть три части системы: железный сервер, который входит в ПАК, поставляемый сразу с софтом в виде чёрного ящика от вендора, CMS и база данных. Бэкапы CMS (конфигураций) и базы делаются в разные места.

ОК, система запустилась, но только база пустая данных никаких нет.

Уже дальше мы узнали и историю про юбилей, и про рестарт, и про всё остальное. Вообще-то для серверов такого класса нормально работать месяцами и годами без перерыва, но у Аваи есть регламент. Там в зависимости от нагрузки системы перезагрузка делается раз в 90 или раз в 180 дней. Очевидно, что регламент пять-шесть раз уже не соблюли. Это тоже нормально, до этого места инструкции дочитывают далеко не все, а если дочитывают, то считают, что это перестраховка вендора. Потому что это и есть перестраховка вендора.

Итак, у нас на руках железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базjq Informix от IBM + пакет CMS от вендора. Решение продаётся как программно-аппаратный комплекс, то есть всё там как поставил вендор, так никто и не трогал.

Бэкапы БД делались. Итерации были по 180 дней, бэкапирование настроено в планировщике системы. Логи бэкапов никто особо не читал, консистентность не проверяли, назад до этого юбилея сервака накатывать не пытались.

Складировались бэкапы прямо на этот же сервер.

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

Дальнейшее исследование

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

К утру мы всё ещё думали, что справимся быстро (в КЦ уже начались проблемы). Решили не трогать бренную земную оболочку сервера, а сразу снять с него образ и развернуть на виртуалке. Это стандартная процедура и для форензики, и для восстановления чего-то, где может посыпаться дальше диск, и вообще очень удобно в конечном итоге в плане не навреди ещё.

Сначала мы развернули виртуалку на стенде прямо у заказчика и начали препарировать там. Фактически Авая сделала больше, чем должна была, подарив лицензию на виртуальную систему. Ну, точнее, заказчику. Выяснили, что бэкап встаёт с ошибкой устройства, но в остальном норм, правда, система пустая. Довольно быстро стало понятно, что бэкап битый полностью.

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

Откатили виртуалку из снапшота на начальное состояние (до бэкапа системы) и пробуем использовать только бэкап базы. Он восстанавливается удачно, но там нет данных.

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

В лаборатории

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

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

Вручную с таблицы перенесли данные в базу данных и скормили всё это нашей виртуалке.

То есть в итоге оставили систему в рабочем режиме со старыми данными, руками настраиваем всё то, что не удалось восстановить из бэкапа системы (пользовательские учётки, коннекторы к другим системам, скрипты).

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

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

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

Выводы

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

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

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

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

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

Я не буду говорить о себе, а расскажу чужую историю. Все имена в ней выдуманные, а совпадения случайны. Её главный герой человек по имени Савелий. И, по случайному совпадению, он админ, как и я.

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

Из этой статьи вы узнаете об эволюции взглядов Савелия: как с усложнением инфраструктуры менялся его подход к бэкапам и к каким выводам он пришёл. Я рассказывал об этом на прошлогоднем HighLoad++, а сегодня делюсь текстом по мотивам доклада.

Глава 1, в которой Савелий полагается на систему управления конфигурациями

Наш Савелий жил-поживал и продолжал изучать материалы по Linux даже на работе. И однажды он узнал, что существуют системы управления конфигурациями: Ansible, Puppet, Chef и им подобные. Они избавляют от ручной работы при подготовке сервера ко вводу в эксплуатацию.

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

Со временем инфраструктура проекта усложнилась.

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

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

Сервисы также изменились: их стало больше, появились связи и зависимости.

Савелий долго наблюдал за ситуацией, и ему всё нравилось. Всё работало хорошо и без сбоев. В конце концов он подумал: а зачем вообще бэкапы? Ведь теперь всё просто: машина упала поднял другую реплику, считал с мастера и всё поедет дальше.

Так Савелий отказался от бэкапов.

Глава 2, в которой появляется карта расположения сервисов

Савелий работал в компании не один, с ним было много программистов. Один из них Аристофан был его добрым другом.

Однажды, работая с базой данных, Аристофан случайно сделал дроп.

Савелий хороший админ. Когда он настраивал репликацию, то следил за отставанием от мастера. Точнее он его не допускал.

Поэтому, как только дроп приехал на мастер, он разъехался по всем репликам. Данных больше не осталось.

Что тут сказать: такое бывает не только в сказках.

После этого Савелий задумался. Нет, не о дружбе с Аристофаном, а о том, что бэкапы всё же нужны. И о том, что такое правильный бэкап.

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

1. Он должен находиться в стороне и не должен быть подвержен изменению.

2. Он обязательно должен восстанавливаться.

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

После того как Савелий сформулировал эти правила, появился другой вопрос. Как правильно поступать: по старинке бэкапить сервер целиком или же делать именно сервисные бэкапы?

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

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

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

Процесс восстановления в таком случае мог пойти по двум сценариям:

1. Восстановить весь бэкап сервера и потом взять нужные данные. Минусы:

   1. увеличение нагрузки на сеть;

   2. увеличение нагрузки на устройство хранения;

   3. увеличение времени на выборку нужных данных из общей кучи.

2. Выбрать вручную только те данные, которые нужно восстановить. Минусы:

   1. увеличение времени на выборку нужных данных из общей кучи;

   2. высокая вероятность того, что будут выбраны не все данные и процедуру придётся повторить (опять-таки потраченное время).

Как видно, оба варианта имеют существенные недостатки.

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

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

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

Вывод, к которому пришёл Савелий, прост: современным бэкапам современную оркестрацию.

Глава 3, в которой Савелий понимает, что серверы созданы не только для того, чтобы их бэкапить (а голова не только для того, чтобы в неё есть)

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

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

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

Минусы:

• формирование инкрементального бэкапа на клиенте в некоторых случаях более затратно с точки зрения ресурсов, так как нужно вычислять разницу было-стало;

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

Плюсы:

• экономия ресурсов сети, так как по ней передаётся не весь объём данных, а лишь те, которые изменились;

• экономия места в хранилище.

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

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

В общем, Савелий молодец.

Глава 4, в которой появляется devel

Жили серверы Савелия долго и счастливо. Но пришла новая беда: стало невозможно выкатывать изменения сразу в боевое окружение. Было создано devel-окружение, которое нужно было поддерживать и бэкапить. Оно было точной копией продакшен-окружения, но располагалось на виртуальных машинах.

Проблема была в том, что devel это территория разработчика, вотчина Аристофана. Но Савелий понимал, что рано или поздно Аристофан придёт к нему с вопросом, а есть ли у него бэкап данных за какой-то день.

Выходит, только Аристофан может знать, что нужно бэкапить, а что можно выкинуть. И несёт за это ответственность.

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

Как Савелий организовал процесс бэкапа виртуальных машин:

1. На момент начала бэкапа виртуальной машины на ней не должно быть снапшотов.

2. Если на виртуальной машине есть снапшот, сделанный вручную Аристофаном, то:

   • не удалять снапшот;

   • не выполнять бэкап;

   • сообщать об этом Аристофану и уточнять, нужен ли ему ещё снапшот, и действовать в зависимости от его ответа.

3. По окончании бэкапа удалять временный снапшот.

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

Почему Савелий не бэкапил виртуалки с базами данных? На самом деле всё просто: теперь он всегда бэкапит все инстансы с базами данных. По умолчанию. Потому что он помнит прекрасную историю про дроп. А на машинах с базами данных ничего ценного, кроме самих данных в базе (для всего остального есть Puppet!), нет.

Глава 5, в которой появляются отличия бэкапа базы данных от бэкапа сервиса

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

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

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

Поэтому Савелий разрешил Аристофану:

• включать и выключать бэкап;

• менять параметры утилит бэкапа;

• менять расписание бэкапа.

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

• устройство хранения может стать узким местом, так как сеть не резиновая (источников много, а устройство хранения -- одно)

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

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

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

Глава 6, в которой Савелий не может жить без уведомлений

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

Но всё оказалось не так просто.

Савелий решил проверить по метрикам, как ведёт себя сервис. Когда приходит бэкап, не начинает ли он, например, отвечать медленнее?

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

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

Последствия этого:

• тратится место в хранилище;

• потребляются ресурсы сети;

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

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

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

Всё сделано, все бэкапится. Савелий научился выявлять пересечения и составлять расписание.

Однако наш герой не мог спокойно спать, потому что не был уверен в том, что с тем, что он забэкапил, всё нормально: можно это достать и что-то с этим сделать.

Как об этом узнать?

Глава 7, в которой необходимо проверять бэкап

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

Шаг 1

Проверяется статус: бэкап завершился со статусом ОК или произошла ошибка. Если ошибка, то разбираемся почему. Если ОК, переходим к следующему шагу.

Шаг 2

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

Шаг 3

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

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

Шаг 4

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

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

Глава 8, в которой появляется реализация бэкапов с помощью Bareos

Как в каждой правильной сказке, в конце Савелий должен был изобрести свою систему бэкапов, которая удовлетворяла бы всем его требованиям. На этом можно было бы закончить историю словами И жили они долго и счастливо!, но не тут-то было. Жизнь не сказка: работа сама себя не сделает, как и система бэкапов по щелчку из воздуха не появится.

На момент выбора решений было не то чтобы очень много:

• коммерческие системы резервного копирования (чаще всего на них не хотят тратиться);

• AMANDA;

• Bacula;

• возможно, было что-то ещё, но про это уже никто не помнит.

Савелий решил действовать по хардкору: начал использовать Bacula, а позже Bareos (форк Bacula). Он никогда не искал лёгких путей.

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

Совет 1

Используйте virtual changer (VC). Это не какой-то конкретный инструмент, а целый класс утилит.

Для примера представьте набор сервисов, который мы бэкапим в два пула. Один пул называется SOMETHING-full, второй SOMETHING-incremental. В этом случае можно бэкапить данные в два пула и не переживать о том, что пачка заданий, ожидающих полного бэкапа, встанет в очередь, пока не закончатся инкрементальные бэкапы. Это довольно часто бывает нужно.

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

Совет 2

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

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

Совет 3

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

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

Второй вариант писать меньше заданий на одну кассету: например, не больше одного. В конечном итоге занимаемое бэкапом место совершенно одинаково при любом подходе.

Совет 4

В Bareos много собственных параметров и крутилок. Крутить можно всё что угодно. Основное, на что Савелий обращает внимание:

• параметры, которые относятся к Maximum Volume Jobs и Concurrent Jobs, как раз для настройки количества заданий на кассете;

• параметры, которые касаются block size и file size, влияют на скорость записи бэкапа, если их можно откуда-то линейно быстро читать и быстро писать;

• параметры, которые дадут чуть больше гарантий того, что будет корректная цепочка бэкапов Max Full Interval;

• параметры, которые остановят выполнение задачи, если нет подходящей кассеты Max Wait Time;

• параметры Spool Attributes и Spool Data относятся больше к ленточному бэкапу, чем к файловому, но Савелий считает, что имеет смысл их тоже покрутить.

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

Совет 5

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

• Full: два последних успешных бэкапа (делается один раз в неделю);

• Incremental: всё до самого старого Full (делается один раз в сутки).

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

Если нужно хранить дольше, то с этим нужно что-то делать, например бэкапить базы или сервисы дополнительно в другие пулы. Но более правильным решением будет использование copy job (migration, если не хочется занимать в два раза больше места), которая заберёт то, что уже лежит в системе хранения, положит в другой пул и оно будет там жить столько времени, сколько нужно.

Совет 6

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

Нужно искать другие варианты решения, например:

• бэкапиться снапшотом;

• делать бэкап через pipe.

Или рассмотреть вариант не бэкапить Bareos по классической схеме File daemon -> Storage daemon, а придумать другую систему, которая будет заливать необходимые файлы в хранилище. Если выбран такой вариант, то его стоит обозначить как задачу с пустым fileset в Bareos. Нужно это для того, чтобы сведения обо всех бэкапах находились в одном месте.

Совет 7

Те, кто работал с Bareos и Bacula, прекрасно знают, что настройки пула, хранилища, кассеты, ретеншена можно раскидать по таким разным местам, что другой человек не сможет во всём этом разобраться. Поэтому Савелий рекомендует договориться с коллегами о том, где и как будут располагаться те или иные настройки, где и в каких местах какие секции конфигов будут находиться, и задокументировать это.

Совет 8

Проверяйте базу Bareos: bareos-dbcheck в помощь. Обратите внимание на DB backend: MySQL, PostgreSQL. Как минимум стоит принять во внимание мнение разработчиков по данному вопросу, чтобы потом не удивляться.

Совет 9

Собирайте логи и метрики: в Elasticsearch, InfluxDB, Prometheus на ваш вкус. Они помогут ответить на кучу вопросов, а при построении бэкапа они возникнут абсолютно точно.

Приблизительно такие графики можно строить, собирая различные метрики:

Данный график показывает, как в течение определённого отрезка времени происходит запись в разные пулы.

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

Также будут видны попытки что-то ресторить.

Там, где график идёт вверх и скорость увеличивается, меняли параметр read ahead. В данном случае это изменение стандартного read ahead для блочного устройства.

Можно увидеть, какое количество данных поминутно, по часам сливается в бэкап-систему.

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

Начало работ:

Окончание и результаты работ:

Работы, завершённые с ошибками:

Выводы

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

Как бы ни менялся мир вокруг, какие бы технологии ни появлялись, данные это основная ценность проекта. Поэтому кто бы когда бы и что бы ни говорил, бэкапы нужны всегда. Бэкапы важны!

Савелий умеет расставлять приоритеты и точно знает, что недостаточно сделать бэкап. Тут-то всё очень просто скопировал и забыл. Важно уметь бэкапы восстанавливать. За восстановлением данных не приходят каждый день/неделю/месяц, но, если пришли, необходимо эти данные предоставить. Восстановление данных из бэкапа это очень важная (если не важнейшая) составляющая системы резервного копирования. Пожалуйста, уделяйте этому процессу достаточно внимания!

Не надо бояться экспериментировать. Хотя Bareos по своей сути довольно консервативен, всегда можно прикрутить что-то сбоку, чтобы сделать возможным и эффективным его использование в современных инфраструктурах. Рано или поздно всё точно получится. Савелий смог и вы сможете!

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

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

В облаках ИТ-ГРАД и #CloudMTS мы развернули сразу три сервиса резервного копирования: на базе Veeam, Acronis Infoprotect и Commvault. С их помощью можно собрать решение под любую задачу. Под катом поговорим о причинах появления такого разнообразия и разберем, какие задачи пользователь может решать с помощью того или иного сервиса.

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

Veeam

Veeam стал первым внедренным нами сервисом резервного копирования данных в рамках IaaS. Сейчас порядка 70% наших клиентов пользуются именно им. С его помощью можно бэкапить как инфраструктуру в облаке, так и локальные площадки.

Резервное копирование IaaS

Самый джентльменский сервис в нашем пуле базовый бэкап на Veeam. Это простое решение всё из коробки, не требующее дополнительных настроек. При подключении услуги всем ВМ клиента автоматически назначается единая политика резервного копирования:

• ежедневная инкрементная резервная копия;

• еженедельная полная копия;

• срок хранения 14 дней.

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

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

Если базового бэкапа мало, можно перейти на Veeam Self-Service и управлять всеми задачами резервного копирования и восстановлением через веб-портал самообслуживания, интегрированный с vCloud Director

Через портал Self-Service можно настраивать:

• наименования заданий, количество точек восстановления и глубину хранения;

• график запуска заданий, количество попыток выполнения и время между попытками, окно для резервного копирования;

• ВМ/vApp, которые нужно бэкапить в рамках конкретного задания;

• папки и файлы, который нужно включить или исключить из заданий;

• уведомленияи многое другое.

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

Резервное копирование с площадки клиента

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

1. C помощью Veeam Cloud Connect Backup, если у клиента уже есть сервер Veeam Backup & Replication не ниже версии Enterprise в рамках собственной инфраструктуры.

   VCC позволяет бекапить:

   • физические серверы с ОС Windows и Linux;

   • виртуальные машины на базе VMware и Hyper-V;

   • рабочие станции на Windows и Linux.

2. С помощью Veeam Agent, если сервер Veeam B&R отсутствует. Агенты также позволяют бэкапить физические сервера, ВМ и клиентские машины, но только с Windows.

Дополнительные фичи

Если на стороне клиента есть Veeam B&R, можно реализовать DR-сценарии. Veeam Cloud Connect Replication позволяет быстро переключаться как на уровне отдельных виртуальных машинам, так на уровне всей площадки. После активации реплик в облаке запустятся копии ВМ, соответствующие по состоянию последним репликам.

Для кого подходит: Veeam Enterprise Manager позволяет закрыть сразу множество типовых клиентских задач: полноценная интеграция сервиса резервного копирования с облаком, копирование с площадки клиента в облачный репозиторий, DR и т.п. Это весьма практичное и универсальное решение, которое подходит подавляющему большинству заказчиков.

Тем не менее, Veeam не позволяет осуществлять кроссплатформенную миграцию и в рамках агентского бэкапа ОС поддерживает только Microsoft Windows.

Acronis Infoprotect

При всей своей гибкости и универсальности решение Veeam подходит не всем заказчикам. Если в крупном и среднем сегменте его использование оказывалось выгодным, то небольшим компаниям требовалась альтернатива с хорошим соотношением цена/качество. Мы проанализировали запросы таких клиентов и добавили в свой пул решение Acronis Infoprotect.

По возможностям копирования БД и приложений продукт Acronis близок к описанному выше Veeam. Однако Acronis Infoprotect:

• дешевле;

• без агента бэкапит ВМ множества платформ (VMware, Hyper-V, Virtuozzo, KVM, RHEV, Citrix XenServer, Nutanix AHV, Oracle VM при наличии доступа к гипервизору);

• в рамках агентского бэкапа работает не только с Windows, но и с Linux и macOS;

• умеет защищать от вредоносного ПО (в т.ч. от майнеров и вымогателей) выявляет нетипичную активность, блокирует попытки изменения файлов и автоматически восстанавливает их, если что-то повредить удалось;

• поддерживает кроссплатформенную миграцию.

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

Кроссплатформенная миграция

Очень часто клиенты после некоторого времени использования нашего облака в качестве площадки для хранения данных переносили к нам свою инфраструктуру. На такой случай в арсенале Acronis имеется одна полезная функция Universal Restore. С ее помощью можно переводить физические серверы в облачные или мигрировать между разными гипервизорами. Для миграции заказчику достаточно сделать резервную копию и восстановиться в облаке.

Commvault

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

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

Отдельно стоит рассказать о том, с чем умеет работать Commvault:

• базы данных: Oracle, Microsoft SQL, MySQL, IBM DB2, MongoDB, PostgreSQL, Cassandra, DB2, Documentum, Hadoop, Informix, SAP for HANA, SAP MaxDB, SAP for Oracle, SQL Server, Sybase.

• ОС (в рамках агентского бэкапа): Windows, Linux, Mac, Unix, FreeBSD, Solaris, NetWare;

• платформы: VMware, Hyper-V, Azure Stack, OpenStack-KVM, Citrix XenServer, Huawei FusionCompute, Nutanix AHV, Oracle, Red Hat Virtualization;

• приложения: Microsoft: Exchange, Active Directory, SharePoint, Office 365, Skype for Business; Lotus: Notes Database/Document, Domino; SAP; EMC Documentum, Cloud Apps.

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

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

Сравним функционал и возможности всех рассмотренных сегодня продуктов.

Итог

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

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

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

Если у компании уже есть сервер Veeam Backup and Replication резервные копии для большей надежности могут дополнительно храниться в облаке провайдера. Либо они полностью перенесены в облачный репозиторий для минимизации трат на закупку оборудования для локального хранения бэкапов.

Полнофункциональный продукт на основе Veeam Enterprise Manager подойдет среднему и крупному бизнесу с серьезными бэкап-запросами, уже перенесшего инфраструктуру в облако провайдера.

Решение на базе Commvault это дорогой серьезный продукт, ориентированный на большие компании со специфическими требованиями к организации резервного копирования.