Рубрика «аварийное восстановление»
Сервис для Active Restore или история одного индустриального проекта в Иннополисе
2019-12-11 в 6:10, admin, рубрики: acronis, аварийное восстановление, Блог компании Acronis, вирусы, Иннополис, разработка, разработка под windows, резервное копированиеПривет! Меня зовут Роман, и я хочу рассказать сегодня о том, как мы в университете Иннополис разрабатывали тестовый стенд и сервис для системы Acronis Active Restore, которая скоро должна стать частью продуктовой линейки компании. Всех, кому интересно, как строятся взаимоотношения университета с индустриальными партнерами, приглашаю проследовать под кат.
Аэростаты Loon обеспечивают аварийное подключение к сети и интернет в Перу после землетрясения магнитудой — 8,0
2019-06-17 в 5:12, admin, рубрики: 5G, loon, LTE, LTE Advanced, lte антенна, lte технология, аварийное восстановление, аварийные ситуации, Блог компании ua-hosting.company, воздуховоды, Разработка систем связи, связь, связь и телекоммуникации, сотовая связь, Стандарты связиКак вы уже знаете (с предыдущей статьи), компания Loon уделяет особое внимание обеспечению связи по всему миру с помощью атмосферных шаров. Полезная во время стихийных бедствий, компания Alphabet вновь продемонстрировала универсальность своего подхода, быстро обеспечив LTE связь после землетрясения магнитудой 8,0 в Перу, когда все хотели знать о состоянии и благополучии своих близких.
26 мая 2019 года сильное землетрясение обрушилось на отдаленный регион Перу — Амазонку. Благодаря существующему коммерческому тестированию и работе с Telefónica по обеспечению доступа к мобильному интернету в районах с недостаточным уровнем доступности, компания Loon смогла обеспечить связь в течение 48 часов.
В воскресенье утром в регионе произошло землетрясение магнитудой 8,0. По просьбе правительства Перу и Tefónica мы быстро перенаправили группу воздушных шаров в пострадавшую зону. Ранним утром во вторник прибыли первые воздушные шары и начали обслуживать LTE пользователей, находящихся внизу. Скоро прибудет еще больше шаров.
Обеспечение доступности данных и сервисов: показатели RPO, RTO и планирование SLA
2017-05-10 в 6:02, admin, рубрики: DR, HA, RTO, sla, аварийное восстановление, бекап, Блог компании «Veeam Software», Восстановление данных, высокая доступность, кластер, отказоустойчивость, резервное копирование, репликация, системное администрирование, цодСегодня я постараюсь разъяснить, что такое концепция доступности данных с точки зрения ИТ-специалиста, будь то ИТ-администратор, системный интегратор, консультант по внедрению и т.д. Надеюсь, что эта статья будет полезна читателям при составлении экономического обоснования на внедрение соответствующих программных иили аппаратных решений, а также соглашений об уровне обслуживания (SLA) – а кому-то поможет сделать эти документы более убедительными.
Для начала в качестве «узелков на память» сформулирую два постулата, с которыми многие, уверен, довольно хорошо знакомы:
- RPO (recovery point objective) – допустимая потеря данных. Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) защиту своих данных от потери выше приемлемого уровня.
- RTO (recovery time objective) – допустимое время восстановления данных Любая информационная система должна обеспечивать (внутренними ли средствами, или сторонними) возможность восстановления своей работы в приемлемый срок.
Часто эта пара показателей отображается в виде одномерного графика вдоль оси времени.
Но в таком одномерном графике нет самого главного, на что ориентируется бизнес – денег! О том, как рассчитывать RTO и RPO, исходя из требований бизнеса, я расскажу под катом.
Фривольное клонирование ОС MS Windows XP – Server 2003 своими руками, средствами GNU-Linux
2014-12-03 в 10:01, admin, рубрики: ACHI, grub4dos, hal.dll, linux, SATA, sysprep, Windows XP, аварийное восстановление, загрузочный носитель, загрузчик, клонирование операционной системы, копирование операционной системы, системное администрированиеОбъяснительная записка
Публикую журналированный результат работы по обеспечению себя универсальным живучим образом установленной операционной системы (далее ОС) Windows XP SP3.
Он понадобился для ускорения процесса установки системы на компьютеры клиентов, пожелавших непременно пользоваться этой привычной версией окошек вопреки разглагольствованиям относительно поддержки, активации и прочих маловажных юзеру моментов.
Почему это нужно?
Что отличает данный материал от распространенных статей на тему клонирования ОС? Ограничения, поставленные передо мною жизнью и самим собой. Перечислю их:
1) ОС должна устанавливаться и работать на разделах произвольных размеров;
2) ОС должна исправно загружаться, будучи установленной на любой тип носителя, поддерживающий загрузку (оснащенный MBR*);
3) ОС должна функционировать на различных вариантах аппаратно-зависимого уровня (HAL**);
4) Образ ОС должен занимать минимум места на носителе для ускорения его переноса, дооснащения, переборки;
5) Образ ОС должен включать в себя необходимый набор установленного и настроенного лучшим образом ПО (вариант «система под ключ»);
6) Все манипуляции по приготовлению образа и по его развертке должны производиться штатными средствами GNU/Linux***. Смысл: разобрать по косточкам принцип работы имеющегося ПО для клонирования ОС;
7) Носителем образа ОС может быть сервер в сети, USB-накопитель (твердотельный либо винчестер), оптический или жесткий магнитный диск;
8) Носитель образа ОС должен быть оснащен средствами диагностики и ремонта ПО компьютера;
9) Желательно процесс клонирования ОС сделать максимально доступным ради хорошей повторяемости без урезания надежности результата;
10) Команда dd, безусловно, хороша, вот только неохота возиться с пустым пространством, нулями и отсутствием четкого вывода текущего действия. Кроме того, раздел, в который будет установлен клон, должен быть произвольным (см. п. 1).
Вне рассмотрения:
1) Юридические моменты установки неподдерживаемой ныне ОС;
2) Активация неактивируемой ныне официально ОС;
3) Целесообразность производимых действий. Не задротствакрасноглазия ради, но токмо волею пославших меня юзеров. Пославших за попытку убедить в кошерности использования свежего свободно-распространяемого программного обеспечения на их дуболомных машинах;
4) Подробности типовой установки ОС Windows XP и доп. ПО на компьютер, за исключением разбивки диска;
5) Подробности метода сетевого клонирования: рассмотрю в дальнейшем, сейчас такой нужды не имею.
Кому это нужно?
Работа ориентирована на удовлетворение запросов конечных пользователей. Статья написана для системных администраторов, желающих перенять приобретенный мною опыт и знания и воспользоваться нижеописанным способом. Отсюда подробности, которые могут не понравится торопливым людям. Объем текста, на мой взгляд, чудовищный для легкого восприятия, но я иначе не могу: надо донести каждый мой шаг.
Конструктивная критика приветствуется; особенно ценны предложения по совершенствованию способа, а также теория, обосновывающая замечания.
Дата написания статьи — 2 декабря 2014 года, посему будущим поколениям шлю свой привет, а насколько сохранится актуальность материала для вас — не ведаю.
Добро пожаловать, %username%, под отрезок.
Читать полностью »
Планирование аварийного восстановления. Часть третья — заключительная
2014-06-30 в 13:46, admin, рубрики: аварийное восстановление, инфраструктура, ит-инфраструктура, системное администрирование, управление проектами, метки: аварийное восстановление, инфраструктура, системное администрированиеСоотносим потребности бизнеса с его возможностями
В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:
- ИТ-сервисах, критичных для бизнеса компании,
- Текущем времени восстановления их работы в случае сбоя,
- Минимально достижимых сроках аварийного восстановления,
- Необходимых ресурсах для их достижения.
И все бы ничего, если бы не ограниченные финансовые возможности организации, не позволяющие приобрести все необходимые резервы для оперативного восстановления. По этой причине заключительная задача планирования аварийного восстановления – поиск баланса между потребностями и финансовыми возможностями бизнеса, и закрепление его в виде соглашения об уровне обслуживания (Service Level Agreement – SLA) в части устранения возникающих инцидентов.
Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:Читать полностью »
Планирование аварийного восстановления. Вторая часть
2014-06-18 в 15:27, admin, рубрики: аварийное восстановление, системное администрирование, управление проектами, метки: аварийное восстановление, системное администрированиеГотовимся к любым падениям
Это продолжение цикла публикаций, посвященных вопросам планирования аварийного восстановления. В предудущей статье речь шла об определении зоны планирования и нахождении точек отказа, которые могут приводить к сбоям в работе пользовательских сервисов. Следующий шаг – опираясь на информацию о точках отказа определить минимально возможные сроки устранения инцидентов, которые могут обеспечить технические специалисты при наличии всех необходимых ресурсов.
Собственно, необходимые ресурсы будут в дальнейшем предметом торга с руководством компании, помогая найти баланс между инвестициями в информационные технологии, временем простоя и потерей данных в случае сбоя. Но это потом, а пока нам нужно определить какие сроки восстановления мы в принципе можем выжать из ИТ-инфраструктуры в случае сбоя. Поехали:Читать полностью »
Планирование аварийного восстановления. Часть первая
2014-06-09 в 11:46, admin, рубрики: аварийное восстановление, системное администрирование, управление проектами, метки: аварийное восстановление, системное администрированиеОпределяем места, где стоит подстелить соломку
Отказы в работе информационных систем – события, которые невозможно исключить полностью. Вне зависимости от причин случившегося сбоя, в момент его возникновения на системного администратора ложится груз ответственности по оперативному восстановлению работоспособности не только ИТ-систем, но и бизнеса в целом.
В цикле из трех коротких статей я постараюсь доступно описать процесс формирования плана аварийного восстановления, который позволяет перевести задачи по восстановлению работоспособности систем в разряд заранее согласованных с руководством мероприятий, имеющих свой график, ресурсы и бюджет.
В первой статье речь пойдет об определении зоны планирования, или поиске тех инфраструктурных элементов, отказ в работе которых негативно влияет на частоту пульса системного администратора. Итак, по порядку:Читать полностью »
Беспечное отношение к данным: сколько стоит ваш бэкап?
2014-01-17 в 5:23, admin, рубрики: usb hdd, аварийное восстановление, Блог компании Acronis, Inc, бухгалтерия, бэкап, вирусы, Восстановление данных, диски, Накопители, потеря данных, радар, Софт, утечка данных, метки: usb hdd, аварийное восстановление, бухгалтерия, бэкап, вирусы, диски, накопители, потеря данных, радар, утечка данныхПривет. Ответьте себе на один простой вопрос: давно ли вы в последний раз делали резервную копию данных своего компьютера? На Хабре, конечно, отношение “забэкапленных” пользователей и “незабэкапленных” чуть отличается от среднего по миру (в лучшую, разумеется, сторону), но всё равно показатель далёк даже от 50%. Так что вопрос “давно ли вы делали бэкап”, скорее, риторический: хорошо если встроенные в ОС средства восстановления после сбоев были настроены и занимались каким-то своим резервным копированием, полный бэкап всех критических, чувствительных или просто важных данных делают всё ещё очень и очень редко. И это при копеечной стоимости (и внушительных объёмах) современных жёстких дисков.
Почему пользователи беспечно относятся к своим данным? Ответ, на самом деле, простой:
Читать полностью »
Резервная площадка в облаке с использованием vSphere Replication
2013-07-16 в 7:01, admin, рубрики: аварийное восстановление, Блог компании ИТ-ГРАД, виртуализация, ИТ-ГРАД, Облачные вычисления, облачные сервисы, резервное копирование, репликация, метки: аварийное восстановление, виртуализация, ИТ-ГРАД, облачные сервисы, резервное копирование, репликация 
Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки – его можно успешно использовать в качестве резервной!