Иди и паши!

С мест докладывают об интересных вещах.

Оказывается Россия будет взращивать 24 стартапа для Микрософт, платить из госбюджета около $5 млн и еще радоваться, что легко отделалась.

“Источник финансирования – средства федерального бюджета на науку“, - теперь понятно, почему для ВУЗов в Федеральном казначействе “нету денег“.

Вобщем, качай, Ваня, нефть и не возникай.

PS. Смотрел тут на днях фильм “Битва за космос” производства “Первый канал” (Россия), BBC (Великобритания), National Geographic (США) и NDR (Германия).

Фильм смотреть можно, но с одной поправкой : американцы не были на Луне.

Джон Линч, (креативный директор “Би-Би-Си Наука”): “Битва за космос” настолько исчерпывающий фильм на тему космической гонки, драматизм которой передан настолько наглядно, что вполне может стать последним фильмом на эту тему. Это незаурядная история, которая заставит прильнуть вас к экрану, и вы будете изумлены, узнав, какой ценой было совершено это величайшее исследовательское путешествие в историю человечества”.

Стив Николсон (конструктор Королев): “Мой герой - гениальный ученый, один из самых выдающихся людей 20-го столетия. Но для меня главное, что он романтик. Он создал спутник! Он так красив, что к нему хочется прикоснуться, когда видишь его сияние”.

Ракета-носитель Р-7 и космический корабль “Союз” Сергея Королева летают до сих пор.

Заметки о бэкапах. Часть 2

Продолжение.

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

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

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

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

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

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

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

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

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

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

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

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

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

Включает:

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

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

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

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