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

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



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

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

    Мы было подумали про центральную инсталляцию одной большой железки, но ситуация осложнялась тем, что каналы от магазинов ограничены 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. Давайте, говорит, посмотрим, заработает ли. Потому что вендоры говорят: у нас поддержка Амазона, Ажура и Гугл.клауд, а заработает ли это решение с нами, никто не знает.

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



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



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

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

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

    Итог


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

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

    Ссылки


    КРОК Облачные сервисы

    107,00

    Облачная IaaS-платформа собственной разработки

    Поделиться публикацией
    Комментарии 22
      +2
      Скажите, а какая ваша ответственность за утрату бэкапа\файла не по вине заказчика?
        +5
        Полагаю, что ответственность такая же как и у всех производителей устройств хранения информации, т.е. никакой
          +1
          Производитель железа может похерить только одну версию, остальные лежат в оффлайне в надежном месте. А вот держать все яйца в одном облаке, на мой взгляд довольно рисковано. Одно неверное движение и все бэкапы исчезли.
            +1
            Производитель железа может похерить все яйца находящиеся на СХД и при возможных претензиях сослаться на то что вы яйца должны периодически бэкапировать разными решениями — на ленту, асинхронно, синхронно, рейд т.к. в соглашениях с производителем железа прописан отказ от ответственности за ваши яйца, а тем более за манипуляции вашего персонала с вашими яйцами
              0
              Я не про производителя схд в облаке, а про ленточку которую поменяли софт. Проблемы железа теперь не проблемы заказчика, хотелось бы понять какая ответственность берется на себя провайдером услуги.
                +1
                Ну, например, могут написать в ленту Роскомнадзора в Твитере.
                Во время следующих веерных блокировок.
        0
        Помнится у Veeam была поддержка работы с S3. Или тут смысл в том, что DD умеет отдавая данные в облако, не делать регидрацию?
          0
          1) у Veeam дедупликация только в рамках одной сессии, у Netbackup настоящая дедупликация между всеми бэкапами
          2) Netbackup хранит данные в S3 именно в дедуплицированном виде без регидрации
          3) передаются только измененные данные с учетом дедупликации
            0
            При работе с дедуп хранилками, типа датадомена, veeam сам ничего не дедуплицирует, отдавая это на откуп конечного хранилища. Во всяком случае настройки меняются автоматически в зависимости от сторы. Но это так, лирика )
            А вот хранение в облаке без регидрации это удобно, не знал.
          0
          10 лет хранить. А как проверять, хранятся ли данные в действительности? Ведь был прецедент потери файлов в Амазоне.
            0
            Обычно у компаний с такими сроками хранения есть внутренние регламенты периодического восстановления своих старых бэкапов как для проверки целостности данных, так и для проверки того, что процесс в целом рабочий. Еще в самом ПО резервного копирования можно verify процесс запустить.
              0
              А сколько это будет стоить для S3 это во-первых (скачать), и что делать если бэкап пропадёт? Или за 10 лет заблокируют амазон опять.
                0
                Данные в нашем S3 могут пропасть при следующих условиях:
                1) три ЦОД одновременно выйдут из строя, что крайне маловероятно
                2) заказчик сам удалит свои данные в S3, что тоже случайно сделать нельзя
                  0
                  habr.com/post/262043 — вот статья, которую я имел ввиду. Данные с S2 снапшотились на S3. Сломалось всё, причины достоверно неизвестны.
              0
              Объясняю: есть требование регулятора, под него написан внутренний регламент, который диктует, что бекапы хранятся 10 лет. В действительности очень сомневаюсь, что через 10 лет эти данные вообще будет куда восстанавливать. В общем регулятор счастлив, магазин счастлив, интегратору заплатили за 10 лет — он тоже счастлив.
                0
                восстанавливаются, был опыт с DLT80 восстановления бэкапа 12 летней давности. Хорошо на складе остались приводы и контроллер со старым сервером.
                  +1
                  , интегратору заплатили за 10 лет — он тоже счастлив
                  Это вряд ли. Ему будут платить 10 лет, скорее всего)
                  В действительности очень сомневаюсь, что через 10 лет эти данные вообще будет куда восстанавливать.
                  работаю в конторе, в которой больше лет и бекапы данных клиентов храним за дольше лет. Точнее даже так, бекапы храним, пришлось даже из старого формата все данные выдрать и в новые переделать, а данные периодически даже приходится доставать и выдавать по требованию клиентов. Так что все зависит от целей и отраслей данных бекапов. В торговле это, скорей всего, просто ради возможности тщательных проверок. У нас — по причинам важности (для людей) данных…
                0
                В какой-то момент они устарели. Но бюджета было ровно на новую версию ленточной библиотеки. В этот момент заказчик появился у нас на пороге с энной суммой и спросил, можно ли что-то придумать в её рамках.

                Использовать запись на Blu-ray диск, также можно писать сначала в облако, а потом на диск большого объема?
                  0
                  При записи на последовательные устройства чтения не будет дедупликации данных локально в регионах. Также не будет оптимизации траффика при передаче в центральный офис. Еще вопрос с ценой обслуживания устройств типа Optical Librarу. Нет смысла гонять траффик сначала в облако, а потом обратно в ЦОД заказчика.
                  0
                  А потом придет Ransomware и теплые ламповые кассеты, которые физически отключены от остальной инфраструктуры станут снова востребованными.
                    0

                    Красиво. А что по деньгам поддержки? За облако надо каждый месяц платить. В DD дисков докупить чтобы основное производство не стало. Порядок интересен. Стало дороже или нет и на сколько.

                      0

                      Люблю такие истории — сам обслуживал, сам предложил опции, сам сравнил все ваианты и выбрал наиболее интересный. Тоже себе.


                      Какие сценарии от ваших конкурентов рассматривал клиент? Почему выбрана реализация S3 именно вашей компании?


                      Зачем все 10 лет держать на S3 без отчуждения? Какой фактор репликации? С redundancy это по определению не может быть дешевле ленты…

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

                      Самое читаемое