И опять про бэкапы

Знаковый опрос на тему «Кто должен делать бэкап 1С«?

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

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

Ввиду того, что средний системный администратор (СА) — существо либо ленивое, либо занятое, бэкапы он не тестирует. Это справедливо для большинства компаний из сектора SMB (малый/средний бизнес).

Кроме того, СА может не делать бэкапы, придумывая следующие оправдания:

  1. Нет достаточного места под резервные копии / нет выделенного сервера под резервные копии;
  2. Нет системы автоматизированного создания резервных копий (СРК — система резервного копирования);
  3. Нет времени на проверку резервных копий (либо некуда восстанавливать), а раз так — зачем их нерегулярно делать;
  4. Отсутствует лицо, заинтересованное в создании резервных копий или целостности данных;
  5. Просто влом.

Как правило, все пять причин/проблем находятся лишь в голове у СА. Люди, принимающие решения, ничего о них не знают. Ведь находятся же деньги на оплату труда специалистов по восстановлению информации с мертвых дисков (или приложений). Это следствие косноязычия ИТ — оно не умеет говорить с людьми.

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

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

Лично я считаю, что:

  • СА обязан иметь бэкапы инфраструктурных данных (например, AD);
  • При возможности, иметь последний бэкап пользовательских данных. При невозможности создания такого бэкапа по объективным причинам — уведомить об этом свое руководство и предложить решение!

Общее направление к обоснованию резервных копий.

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

1) Нет места под резервные копии / нет выделенного сервера.

Как так — воскликнете вы! Ведь новый терабайтный жесткий диск стоит 100$. Да и в серверах есть еще незанятые жесткие диски. Вон, на контроллере домена свободно 20 гигабайт, на почтовом — еще 200. Бэкапь туда, место кончится — тогда и поговорим. Зачем тебе нужен выделенный сервер?

Обоснование первого пункта (и инфраструктуры резервного копирования вообще) стоит начинать не с жестких дисков и с серверов, а с определения списка информационных ресурсов и их объема. После этого мы находим лиц в менеджменте компании, которые заинтересованы в целостности этих ресурсов и согласовываем с ними планы по резервному копированию. Например, базы бухгалтерии надо архивировать раз в день, хранить последние 7 ежедневных бэкапов, 4 еженедельных и 12 ежемесячных. В результате, у нас есть 23 резервных копии, которые теоретически позволят нам восстановить определенные данные на состояние до года назад. Если нужна 100% восстанавливаемость всех данных, храним последние 365 копий. В результате, от сервисов мы придем к необходимому объему, требуемому под бэкапы. Кроме того, в выборе ресурсов для резервирования должен участвовать человек от ИТ. Это позволит гарантировать, что мы не забудем про резервные копии для контроллеров домена, например.

Так что там с жесткими дисками? Все просто — если мы не хотим, чтобы внезапно кончилось место на почтовом сервере / контроллере домена и службы встали, то нужны отдельные жесткие диски! Если не хотим, чтобы бэкапы бухгалтерии за последний год канули в лету вместе с жестким дисков, то настраиваем дополнительно архивацию на другие носители или внедряем рейд-массив. Под «если не хотим» я подразумеваю, «если не хочет заинтересованное лицо».

Если:

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

то нам нужен выделенный сервер под хранение резервных копий.

Если нам нужно создание отчуждаемых архивов данных, смотрим в сторону DVD-дисков или ленточных накопителей. Если раньше стоимость хранения на них была низкой по сравнению с HDD, то сейчас жесткие диски по стоимости мегабайта находятся рядом! Выбор между DVD и лентами сделать просто — если нужна:

  • автоматизация процесса архивации;
  • высокая частота сброса данных на съемный носитель;
  • объем данных для архивации велик (>10GB)

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

2) Нет программного обеспечения для автоматического создания резервных копий.

3) Нет времени на проверку резервных копий.

На самом деле, такое бесплатное программное обеспечение есть 😉

Это NTBackup для Windows 2003 Server и Windows Server Backup для Windows 2008 Server. Другие приложения (Exchange, SQL, Oracle), как правило, имеют свои средства автоматизации резервного копирования. Тут есть несколько своих проблем:

  • Разнообразные интерфейсы систем резервного копирования (СРК) с различным функционалом. Для настройки и мониторинга работы СРК тратится много времени, особенно, если счет серверов идет на десятки;
  • Не всегда есть контроль целостности созданных бэкапов;
  • Нет автоматизированной системы по восстановлению бэкапов!

К примеру, сравним MS DPM 2010 и Symantec Backup Exec 2010. Первый — автоматизированная система по созданию резервных копий. Второй — АС по созданию и восстановлению резервных копий. То есть вы можете не только автоматизировать процесс создания резервной копии, но и ее восстановления для тестирования резервных копий. Я не говорю, что DPM не умеет восстанавливать данные. Я говорю о том, что он не умеет делать этого автоматически.

Возьмем другой популярный продукт — Veeam Backup and Replication. Летом обещают запустить новую версию, а также весчь под названием SureBackup. Обещанный функционал — возможность автоматизированного тестирования — восстанавливается ли это письмо, база SQL из бэкапа. А также — восстанавливается ли набор виртуальных машин или нет…

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

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

4) Отсутствует лицо, заинтересованное в  создании резервных копий или целостности данных.

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

5) влом.

Это единственная проблема, которую решать должен либо сам СА, либо его руководство с помощью системы мотивации / замены персонала.

Выводы

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

Как правильно внедрить у себя инфраструктуру резервного копирования:

  • тщательно проанализировать потребности бизнеса. Ради бэкапа 2 гигабайтов данных никто в здравом уме миллионы не тратит. Делать бэкап только базы AD можно на жесткий диск своего ПК. Для этого — провести диалог либо с начальником службы ИТ, либо с директором предприятия, подготовив табличку с сервисами. Постараться донести мысль, что хотя бы одна резервная копия любых данных всегда должна быть. Исключение — каталоги с фильмами и музыкой;
  • проработать несколько вариантов инфраструктур, различающихся по стоимости. Для каждого варианта составить краткую выкладку по возможностям и тому, как это подходит под ваши потребности. Вариант типа «подключить в свою рабочую станцию два жестких диска, сетевую карточку на гигабит» всерьез рассматривать не стоит;
  • Предложить эти варианты на выбор.
  • Если желания бизнеса никак не совпадают с его возможностями, то…

любое действие на ваш выбор.

Good luck!

Запись опубликована в рубрике Статьи с метками . Добавьте в закладки постоянную ссылку.

14 комментариев: И опять про бэкапы

  1. Александр говорит:

    Одно но.
    Не задача СА продумывать политику бакапов и предлагать бизнесу.
    Самому СА бакапы не нужны. Они нужны бизнесу. Значит в первую очень должен заботиться о наличии бакапах руководитель СА.

  2. A.Vakhitov говорит:

    Согласен. Это задача руководителя — продумать политику и доказать ее руководству.
    Хотя, если руководитель вышел не из ИТ, он может не знать про бэкапы ничего. Соответственно, если СА тоже пустит вопрос на самотек, в случае глобального сбоя могут уволить обоих.
    Кроме того, руководитель может сказать: «Семен Семеныч, у тебя 30 серверов. Бэкапь их друг на друга — место же есть…»

  3. Mister Nobody говорит:

    Заботится о бэкапах должен специалист/инженер по защите информации, так это его функция. В соответствии со справочником «Квалификационный справочник должностей руководителей, специалистов и служащих»
    Брать тут
    http://s-talker.boom.ru/Variety/etkc.htm

  4. Anton Zhbankov говорит:

    В 95% случаев специалисты по защите информации ака безопасники ограничиваются драконовскими парольными политиками, вездесущими логгерами и запретами флэшки. Иными словами, конфиденциальностью информации. То ли им неинтересны доступность и целостность, то ли для большинства безопасников это невообразимо сложно.

  5. romx говорит:

    > Если нам нужно создание отчуждаемых архивов данных, смотрим в сторону DVD-дисков или ленточных накопителей.

    Ну вот опять. «Когда в руке молоток — все вокруг кажется гвоздями».
    Сегодня задача «отчуждаемых архивов» решается совсем иными способами, чем во времена лент.
    Это широко распространенная зашоренность мышления: «А вот если нам надо наш бэкап для устойчивости к катастрофам увезти в резервный центр, вот ленту мы просто вынем из библиотеки, а как мы вынем диск из дисковой полки? Не-е, поэтому лента!»

    Например это сегодня делается удаленной репликацией на _другую_ дисковую систему.
    Это раньше, во времена царя гороха, когда кроме лент ничего не было, WAN-линк на мегабит могли себе позволить только транснациональные корпорации. Сегодня проще «отчуждаемый архив» проще уже сразу делать на удаленную систему. Или сразу, или репликой с локального NAS, на который они быстро делаются локально, а потом всю ночь льются на удаленный NAS.
    Вот вам и отчудаемый архив. Просто надо перестать дуать в терминах «молотка».

    Канал в 10 мегабит это уже практически «домашние» каналы.
    Допустим, для простоты, по каналу 10 mbit/s передается мегабайт в секунду. В ночи, допустим, 6 часов. За пару часов завершилось локальное копирование, и началась репликация. за 6 часов канал перекачает около 20 гигабайт.
    Это не считая дедупликации и компрессии.
    20 гигабайт данных это очень дофига, с учетом инкрементальности самого процесса,

  6. Mister Nobody говорит:

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

  7. Андрей Вахитов говорит:

    2Антон: навряд ли сложно. Не отождествляют себя безопасники с ответственными за бэкап/рестор потому, что привыкли мыслить узко, защищать данные только от внешних угроз. А бэкапы нужны для защиты от внутренних.
    2Romx: с отчуждаемыми — абсолютно согласен. В контексте подразумевалась еще и организация архивов, но я не расшифровал.
    2Nobody: думаю, такой функционал нужен, скорее, бизнесу. На восстановление оперативных данных уходило как можно меньше времени. Пользователю-то что, там народ, зачастую, в Excel отсортировать строки не может.

  8. Dim-soft говорит:

    а кто/что умеет дедуплицировать через wan желательно free

    к вопросу кому нужен backup

    у меня в одной организации база 1С бекапиться по сети на 2 сервера в два офиса с удалением 10-15 км

    за 2 года ни разу ни один пользователь/програмист 1С не спросил резервную копию 🙂

  9. Андрей Вахитов говорит:

    Да тьма решений по дедупликации есть. Вот парочка, что недавно вспоминал:
    -Citrix Netscaler (вроде бы так);
    — EMC Avamar.
    Есть как аппаратные, так и программные решения.
    Хотя…
    Citrix — вроде больше по сжатию, EMC — дедупликация.

  10. Dim-soft говорит:

    я про free для малого бизнеса
    не надо говорить про авамар 🙂

  11. Андрей Вахитов говорит:

    Дедупликация и фри — пока несовместимые понятия.

  12. Dim-soft говорит:

    например
    на первом сервере сравниваем сегоднящний backup со вчерашним
    и если дельта много меньше чем сам файл то на второй сервер посылаем только дельту.

  13. Андрей Вахитов говорит:

    Ну это уже есть 😉
    Называется инкрементальные бэкапы

  14. Dim-soft говорит:

    🙂 я в курсе, вопрос как софт осознает что есть дельта:
    1) архивный бит в атрибутах сменился
    2) покластерная проверка
    и тд
    при этом получатель копии на чтение не доступен 🙂
    вот это интересно (хотя может я опять велосипед изобретаю — может кто то уже изобрел ?)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *