santa_claus_rpm: (Default)
Продолжение. 

Решение организационных вопросов

Примечание. Оргвопросы придется отработать на 100%, проверено на практике.

Распределение обязанностей:

  • Кто разрабатывает, согласовывает планы копирования, восстановления.
  • Каким образом эти планы доводятся до исполнителей.
  • Каким образом, кем утвержден план резервирования, архивирования и восстановления. Примечание. Лучше если это будет директор.
  • Если создание копий происходит автоматически, то кто обрабатывает сообщения об ошибках во время копирования.
  • Кто делает резервные копии, если назначенный исполнитель отсутствует (находится в отпуске и т.п.).
  • Если исполнитель вынужден, по какой-либо важной причине, контролировать процесс копирования во вторую смену, то кто вместо него будет работать на следующий день.
  • Кому исполнитель должен доложить о неудачном копировании. Какие еще действия в связи с этим предпринять.
  • Кто заменяет исполнителя в то время как он вынужден расследовать проблемы копирования или в это время он занимается восстановлением.
  • Если копирование завершилось неудачно из-за отказа аппаратной части, и какое время потребуется для ремонта, замены – то кто будет взаимодействовать с продавцом техники.
  • Несут ли пользователи ответственность за копирование и архивирование информации с их собственных ПК. Где это прописано.

     

santa_claus_rpm: (Default)
Продолжение.

На данном этапе мы уже различаем резервное копирование и архивирование.

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

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

Введем еще одно понятие в контексте организации резервного копирования.

Информационный ресурс – информация в электронном виде, включающая в себя как прикладное так и системное ПО.
Например, сервер СУБД.

Основные цели разработки

  • Получить на выходе план резервного копирования, архивирования и восстановления системного программного обеспечения.
  • План резервного копирования, архивирования и восстановления прикладного программного обеспечения.
  • План восстановления информационного ресурса bare-metal (с нуля, на голое железо) включающий в себя следующие этапы:
  • первоначальная установка операционной системы сервера из инсталляционных файлов;
  • настройка операционной системы сервера, в т.ч. запуск и настройка необходимых системных сервисов
  • создание групп и пользовательских учетных записей;
  • установка СУБД из инсталляционных файлов;
  • настройка параметров СУБД;
  • установка прикладного ПО из инсталляционных файлов;
  • создание в прикладной задаче всех пользовательских учетных записей;
  • восстановление баз данных из архивных и/или резервных копий;
  • запуск системы и проверка ее работоспособности; Для этого желательно знать как система работает в нормальном, исправном состоянии.
  • проверка целостности прикладных баз данных. Как проверить ? Во-первых, встроенными средствами СУБД. Во-вторых, встроенными средствами прикладного программного обеспечения. В-третьих, по косвенным признакам. Например, если это ПО для биллинга, то сумма на начало периода, обороты, сумма на конец периода. Либо количество записей, еще какой-нибудь признак.
    Контрольная сумма файла, например.

Основные причины по которым необходимо наличие плана восстановления bare-metal (т.е. с нуля) следующие:

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

Основные этапы разработки

Разработка процедур резервного копирования, архивирования и восстановления информационных ресурсов состоит из следующих основных этапов:

Определение приемлемых и не приемлемых потерь данных

Включает:

  • классификацию информационных ресурсов по степени важности. Для классифицированных данных проще разработать адекватную процедуру резервного копирования и архивирования.
    Примечание. Вы не сможете пропустить этот пункт и будете вынуждены постоянно к нему возвращаться, если упустили вначале. Так что лучше отработать его сразу и первым, т.е. так как написано.
  • выявление данных, которые необходимо дублировать (реплицировать) немедленно, как только они изменились (обычно это особо важные данные)
  • если возможно, необходимо оценить ущерб от потери данных в денежном эквиваленте.
    Примечание. Обычно так везде советуют так называемые “специалисты” по ИБ, по информационной безопасности то есть, я их называю - бездельниками от ИТ. Если у вас их нет, то тем лучше. Так вот просто забейте на этот пункт. На сегодняшний день, как и два года назад, когда я только начинал писать эти “заметки”, не было и нет нормальной процедуры определения ущерба и скорее всего не будет.
    Вместо того, чтобы заниматься ерундой, чем обычно и заняты “специалисты” по информационной безопасности, просто выполните пункт: классификация информационных ресурсов по степени важности.
  • определите какие ресурсы требуют резервного копирования, а какие – архивирования. Возможно, что нет необходимости выполнять резервное копирование и архивирование некоторых информационных ресурсов. Возможно, что достаточно выполнять резервное копирование, и не выполнять архивирование некоторых информационных ресурсов. В чем разница, читайте здесь.
  • определите, или хотя бы оцените, допустимое время восстановления; Это в часах.
  • определите требуемый режим доступности информационных ресурсов (круглосуточно 365 дней в году; в рабочее время с 09:00 до 18:00 в рабочие дни или по какому-либо другому расписанию).
    Обычно big boss требуют 24×7x365, но так не бывает. На этом этапе не спорьте, но выбивайте под это как можно больше ресурсов, пригодится.

Планы полного резервного копирования информационного ресурса в целом

Включают в себя:

  • По возможности резервное копирование всех файловых систем сервера в целом. Типичная ошибка в некоторых ситуациях: делать копии отдельно системных данных и отдельно прикладных, пользовательских данных, в результате восстановления из таких копий можно получить в целом рассогласованную систему.
    Примечание. Это спорный момент, но что-то в этом есть. Определите сами делать это или нет.
  • Однако, в дополнение к полной копии, все-таки необходимо иметь и отдельную архивную копию баз данных, прикладного ПО, исходных текстов прикладного ПО (если есть).
  • Имеются ли особые условия создания резервных и архивных копий (например, все пользователи информационного ресурса должны прекратить работу, сервер должен быть переведен в однопользовательский режим, должна быть остановлена или выгружена соответствующая СУБД, некий раздел должен быть перемонтирован в режиме read-only и т.п.).
  • Разрабатываемая процедура копирования должна иметь как можно большую степень автоматизации. Иначе, если процедура копирования во многом зависит от соблюдения исполнителями определенных правил, которые нельзя реализовать автоматически, то со временем их будут нарушать.
    Примечание. Это - 100%

Profile

santa_claus_rpm: (Default)
santa_claus_rpm

October 2011

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526 272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 22nd, 2017 08:41 am
Powered by Dreamwidth Studios