Резервное копирование на кассеты

в 6:43, , рубрики: Dell EMC, Veeam, Блог компании КРОК Облачные сервисы, бэкапы, виртуализация, защита данных, облако, хранение данных

Есть сеть примерно из 90 очень крупных магазинов по России. Каждый магазин бэкапится на ленточную библиотеку (ниже на фото — ЗИП). Дальше они берут кассеты и везут их на машине в архив.

Резервное копирование на кассеты - 1

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

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

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

Нашёлся Data Domain

При изучении инфраструктуры оказалось, что в центральном офисе уже установлен Dell EMC Data Domain. Правда, для их офисных задач. И в офисе игрушкой давно и успешно пользуются. Они знают, как с ней работать, она совместима с их ПО бэкапа и прочно вписана в инфраструктуру. Теперь — уточнение задачи: есть магазины, ленты, деньги. Локально их надо хранить в магазине до трёх месяцев, дальше не в магазине данные должны быть доступны до 10 лет по ряду показателей. Это нужно по требованиям регулятора и внутренним политикам.

Есть пожелания не заморачиваться с лентами. Требований по скорости особо нет. Но очень хотелось бы минимизировать количество ручных операций админа и уменьшить вероятность невосстановления. С лентой это, увы, случается. Одна лента сломалась — копии хана, потому что избыточности нет.

Наш вариант

Решили предложить рассмотреть альтернативы лент: перенос бэкапов в S3-совместимое хранилище. Понятное дело, можно встать в Амазон, MS-облако, к нам в публичное облако — куда угодно, где есть объектные хранилища с определёнными SLA. А можно взять и смонтировать прямо в офисе небольшое частное облако. Именно такое решение есть у Dell EMC: можно привезти железки в офис и получить инсталляцию облака. А Dell EMC — уже привычный вендор, поэтому вопросы интеграции сильно легче, чем во всех других случаях.

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

По просьбе заказчика сделали сравнительный анализ стоимости: Dell EMC на площадке, наше облако КРОК и MS.

Dell EMC ECS — большая закупка, там надо продлевать поддержку, размещать в серверной и ЦОДе. Мы рассматривали в горизонте 10 лет, и получалось дороже из-за того, что минимальная конфигурация сильно избыточна и потому стоит, как крыло от самолёта, а заплатить надо сразу плюс потом продлевать поддержку (за доллары, которые непонятно сколько будут стоить через 3–5–7 лет) и держать в уме даты end of sale и end of support. MS-хранилище с той же степенью резервирования дороже. Особенность нашего S3 — автоматически раскидывать данные на три географически разделённые площадки. У MS тариф на геораспределённость выше.

В итоге заказчик посмотрел и попросил пилот в нашем S3. Давайте, говорит, посмотрим, заработает ли. Потому что вендоры говорят: у нас поддержка Амазона, Ажура и Гугл.клауд, а заработает ли это решение с нами, никто не знает.

Смысл в том, чтобы класть «горячие» данные на хранилище, а потом сгружать старые копии с хранилища в облако в том же формате, что они лежат на хранилище.

Резервное копирование на кассеты - 2

Мы делали тестирование Dell EMC Data Domain. У них заявлено, что они могут перекладывать свои копии с себя на S3. Dell EMC DD заработал, их поддержка нам с огромным энтузиазмом помогла, потому что инженер на той стороне прям радовался этой задаче, говорил: классная история с Veeam!

Резервное копирование на кассеты - 3

Дальше мы столкнулись с тем, что у Dell ЕМC есть особенность: так сделано, что данные сначала складываются на 14 дней на железку и только потом могут быть выгружены в облако. Инженеры говорят, это зашито глубоко, и это логика разработчиков: эти два цикла хранения прописаны чуть ли не в хардкоде. Больше — можно, меньше — никак. Считается, что две недели — это время хранения, когда юзер хочет восстановиться.

Если данные уже перенесены в облако — мы их вернули обратно, из них восстановились, и они снова 14 дней лежат, прежде чем уехать.

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

Итог

  • Veeam собирает бэкапы со всех объектов магазина и отдаёт в Data Domain, как обычно. Про S3 он ничегошеньки не знает.
  • Инстансы Data Domain дедуплицируют трафик на местах и при необходимости могут передавать реплики в центральный офис.
  • Cloud Tier встроен в дата-домен, она автоматически переносит данные в S3 в наших дата-центрах.
  • Когда юзеру нужно что-то вытаскивать из бэкапа, он стучит в Veeam. Veeam стучит в свою систему записи, система записи стучит в свой «диск» (физический или S3) и достаёт копию. Всё довольно красиво интегрировано.

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

Ссылки

Автор: EKorotkikh

Источник


* - обязательные к заполнению поля