Pull to refresh
  • by relevance
  • by date
  • by rating

Вебинар DataLine «Строим Disaster Recovery: чек-лист по процессам и инструментам» 18 марта

DataLine corporate blogBackupData storageData storagesCloud services

На вебинаре поговорим, с чего начать создание DR внутри компании, как это продавать бизнесу и выбрать адекватные инструменты.

Подробности и регистрация
Total votes 10: ↑10 and ↓0 +10
Views307
Comments 0

Disaster Friendly arcitecture

Lumber room
Все нижеизложенное целиком и полностью навеяно статьей на сайте Радар О'Рейли.

Если в кратце, то на прошлой неделе M$ начали закрытое бета-тестирование нового сервиса Vine, предназначенного для мониторинга и оповещения в случае катостроф и нештатных ситуаций. Планируется что это будет мультиплатформенный (в понимании M$) сервис, позволяющий оставаться на связи с некоторой группой людей в случае нештатной ситуации или для повседневной жизни.
Сервис представляет из себя mashup из LiveMesenger, FaceBook, LinkedIn и позволяет делать групповые оповещения и отслеживать местонахождение участников (через специальный клиент).
Так же планируется интеграция с твиттером, вэб-интерфейс и клиенты для «Не виндовс» :-).
Посмотрим, во принципе может получиться вполне приличная коммуникационная платформа, только подозреваю что в случае на самом деле серьезных проблем толку от нее будет ровно 0.
В случае каких-либо техногенных катастроф информационная инфраструктура страдает сильнее всего: если каналы связи и оказываются не поврежденными то получают серьезную перегрузку (помните отключение электричества в Москве?).
В любом случае нужно смотреть на это ближе, подписался на участие в бэта-тестировании, жду приглашения. Если пришлют и удастся посмотреть — расскажу подробнее.
Total votes 2: ↑2 and ↓0 +2
Views163
Comments 4

NetApp Metrocluster

NetApp corporate blog


В 2007 году, консалтинговое агентство Forrester провело опрос 250 IT-специалистов, с целью оценить риски аварий для IT, как внутри датацентра, так и вне его, например риски природных аварий и катастроф.

После обработки и публикации результатов стало понятно, что привычное средство обеспечения отказоустойчивости в виде, например, традиционного «дублирующего, избыточного контроллера и RAID» может защитить всего от 31% всех возможных отказов.

На графике вы видите также такие IT-дизастеры как отказы электропитания (" — что случилось с вашим электричеством? — Оно моргнуло." ), проблемы с ПО ("…и будет закрыто"), человеческие ошибки ("как ты сказал имя тома, который надо было размонтировать и грохнуть?"), ошибки сетевых настроек (" — а какой интерфейс использовать? — попробуй eth0."), а также и разнообразные природные (и не очень) катаклизмы, такие как пожары, наводнения и так далее.

Таким образом становится ясно, что традиционные средства защиты работоспособности данных защищают его, увы, недостаточно, сколько бы «девяток» вам ни обещали в рекламе. И когда стоимость потери или простоя данных становится весьма существенной, встает вопрос поиска решения, обеспечивающего большую надежность, чем решения традиционные.
Читать дальше →
Total votes 23: ↑20 and ↓3 +17
Views15.3K
Comments 59

Сайт, на котором можно вылечить поврежденный файл. Видео-демонстрация OfficeRecovery Online

«OfficeRecovery» corporate blog
OfficeRecovery начинает серию публикаций о восстановлении поврежденных данных. Вашему вниманию предлагается видео, демонстрирующее лечение испорченных файлов посредством веб-браузера в системе OfficeRecovery Online. Видео снабжено русскими субтитрами.

В качестве примера взят поврежденный файл Word. Аналогичным способом на сайте можно починить файлы десятков других типов: Microsoft Office, PDF, графику и многие другие.



Желающие попробовать сайт в действии могут до 1 октября воспользоваться кодом OFFICERECOVERY*HABR на странице просмотра демо-результатов, появляющейся в процессе восстановления:
https://online.officerecovery.com/ru/
Total votes 22: ↑7 and ↓15 -8
Views26.1K
Comments 8

OfficeRecovery представляет веб-API для восстановления поврежденных файлов

«OfficeRecovery» corporate blogAPI
Recovery mode
Предлагаем вниманию программистской общественности бета-версию веб-API для восстановления поврежденных файлов: https://online.officerecovery.com/ru/api/

По ссылке доступен архив с документацией и примерами использования, реализованными на php. Также есть возможность оценить возможности API на основе работающего примера.

В качестве ядра для восстановления файлов используется сервис OfficeRecovery Online (см. пост с описанием и видео). Взаимодействие происходит на основе GET/POST http запросов, обмен данными основывается на формате XML.

Функциональность API:
  1. Загрузка поврежденного файла для восстановления.
  2. Получение статуса и прогресса восстановления.
  3. Получение ссылок на демонстрационный и полный результат восстановления, либо сообщение об ошибке, если файл не удалось восстановить.
Подробности
Total votes 4: ↑4 and ↓0 +4
Views2.1K
Comments 0

Работа с Intelligent Disaster Recovery в Symantec Backup Exec

System administrationServer AdministrationData recovery
Я хочу рассказать об особенностях работы с компонентом Intelligent Disaster Recovery, входящем в состав Symantec Backup Exec Этот компонент обеспечивает быстрое восстановление после сбоев и позволяет при своевременно сделанном бэкапе быстро поднять машину из состояния «чистое рабочее железо» в состояние «все работает».
Эта статья – о работе с IDR, встречающихся проблемах и способах их решения и известных мне подводных камнях.
Картинка для привлечения внимания


О том, как работает IDR в штатном режиме, какие возникают ошибки и как их победить.
Total votes 13: ↑9 and ↓4 +5
Views13.6K
Comments 8

Системы хранения данных: как медленно, но верно они отвязываются от железа

КРОК corporate blog

Авария в первом дата-центре и автоматический перезапуск сервисов в другом

Виртуализация — одна из моих любимых тем. Дело в том, что сейчас можно практически полностью забыть про используемое железо и организовать, например, систему хранения данных в виде «логического» юнита, который умеет взаимодействовать с информацией по простым правилам. При этом все процессы между виртуальным юнитом и реальным железом в разных ЦОДах лежат на системе виртуализации и не видны приложениям.

Это даёт кучу преимуществ, но и ставит ряд новых проблем: например, есть вопрос обеспечения консистентности данных при синхронной репликации, которая накладывает ограничения на расстояния между узлами.

К примеру — скорость света становится реальным физическим барьером, который не даёт заказчику поставить второй ЦОД дальше 40-50, а то и меньше, километров от первого.

Но давайте начнём с самого начала — как работает виртуализация систем хранения, зачем оно всё надо, и какие задачи решаются. И главное — где конкретно вы сможете выиграть и как.
Читать дальше →
Total votes 35: ↑31 and ↓4 +27
Views47K
Comments 42

All-flash массив HP и еще 10 больших изменений в системах хранения 3PAR (часть1)

Hewlett Packard Enterprise corporate blog
Сегодня в компании HP прошел большой анонс в департаменте систем хранения данных, этой информацией я хочу поделиться. Были анонсированы модели систем хранения среднего класса, оптимизированные на работу с флэш-носителями – HP 3PAR StoreServ 7450, а также был расширен функционал текущих систем 7000 / 10000.

HP 3PAR StoreServ 7450


Практически любая система хранения, представленная сейчас на рынке, поддерживает накопители SSD.
Традиционно, требования высокой производительности от дисковой подсистемы достигалось добавлением большого количества вращающиеся шпинделей, как правило с минимальной утилизацией их объема (рис1).
Использование SSD накопителей позволило сократить число вращающихся шпинделей, подняв при этом производительность массивов данных.


Рис.1 Достижение высокой производительности в массивах традиционного типа и в современных массивах

Подробности
Total votes 10: ↑8 and ↓2 +6
Views13.3K
Comments 10

Моя работа — ждать IT-катастрофы

Билайн Бизнес corporate blogInformation Security


Лучшее, что может случиться, — это если результаты того, что я делаю, никогда и никому не пригодятся.

Можно сказать, что я профессиональный параноик: моя задача — разрабатывать планы действий на случай чрезвычайных ситуаций и обучать людей грамотно реагировать в таких случаях. Зачем это нужно? Довольно просто — чтобы в случае непредвиденных ситуаций всегда была страховка.

Вот, например, знаете что будет, если землетрясение уничтожит основной московский ЦОД?


  1. Сработает автоматика и перебросит часть сервисов на другие ЦОДы. Всё то, что было active-active, продолжит работу (это базовые функции сети, вроде звонков и SMS).
  2. Затем включается базовый сценарий реакции. Сразу после происшествия формируются команды восстановления из специально обученных людей на объекте, имеющих подготовку по всем аспектам работы этого объекта. Например, из инженера на смене, охранника, системного администратора и так далее. Они бросают все свои текущие дела и занимаются только восстановлением.
  3. В течение первых 10 минут «бронзовая» команда восстановления анализирует ситуацию. На 11-й минуте руководитель команды докладывает команде более высокого уровня («серебряной», как правило, не присутствующей на объекте), например, главному инженеру и руководителю подразделения.
  4. «Серебряная» команда принимает решение на своём уровне. В нашем случае проблема явно особенно важная, поэтому команда связывается с «золотой» командой — руководителями самого высокого уровня. На принятие решения о том, что ситуация является чрезвычайной, уходит ещё 10 минут (это очень быстро). В течение ещё 5 минут активируются составленные нами планы аварийного восстановления.
  5. Руководители «бронзовых» команд собирают людей и идут восстанавливать, что могут, на месте. Параллельно собирается кризисный комитет, включающий известных специалистов, описанных в плане на этот случай.
  6. Далее кризисный комитет взаимодействует с HR, PR, безопасниками и другими службами. В частности, совершенно точно PR к этому моменту будет остро нуждаться в информации — абоненты уже полчаса без мобильного интернета, нужно выступить с данными о сроках восстановления.
  7. Разворачивается резервная точка. В течение 20-30 минут восстанавливается инфраструктурный слой. Затем идет восстановление СУБД и там, где надо, восстановление из архива с ленты. Далее — восстановление приложений (от получаса до дня).
  8. Параллельно в течение первого часа проверяется, как всё переехало.
  9. Затем появляются детальные отчёты. План аварийного восстановления заканчивается, и мы снова «засыпаем» до следующей ситуации.
Читать дальше →
Total votes 212: ↑201 and ↓11 +190
Views83.4K
Comments 73

Hello, Russia!

Acronis corporate blog
В компьютерном мире начинать принято с мантры «Hello, world!», но мы на свой страх и риск решили нарушить этот акт инициации ввиду уважительных причин. На этот самый world и так пишется много всякого маркетингового материала, а тут мы решили рассказать исключительно русскоязычной аудитории о накипевшем наборе технологий, из которых мы собираем наши продукты и сервисы.
Подробнее...
Total votes 50: ↑31 and ↓19 +12
Views18.2K
Comments 40

Детальный ликбез про корпоративный бэкап, как сравнивать системы + пара практических советов

КРОК corporate blog

Cистема резервного копирования может работать вот так

Чем корпоративный бэкап отличается от домашнего?
Масштаб — инфраструктуры до петабайта. Скорость – тысячи транзакций в секунду, поэтому, например, нужно уметь забирать бэкап из базы данных на лету, не останавливая запись. Зоопарк систем: рабочие машины, мобильные телефоны и планшеты, профили людей в «облаке», копии баз данных CRM/ERP, все это на разных ОС и в тяжелых разветвленных системах.

Ниже я расскажу про решения от IBM, EMC, CommVault, Symantec и то, что они дают как бизнесу в целом, так и IT-отделу. Плюс о некоторых подводных камнях.

Давайте посмотрим на эти особенности бэкапа в обычных российских компаниях. В том числе таких, которые бэкапятся только на случай изъятия оборудования.
Читать дальше →
Total votes 29: ↑25 and ↓4 +21
Views54.1K
Comments 25

NetApp 7-Mode: Недокументированные возможности или делаем DR из SnapVault

System administrationIT InfrastructureData recoveryBackupData storage
В продолжение статьи о парадигме резервного копирования NetApp, хочу рассказать о недокументированной возможности преобразования «архивных копий» в «резервные» для серии FAS. Отличительной чертой СХД компании NetApp серии FAS является то, что они все унифицированы. Унифицированность не только в том, что одно устройство предоставляет доступ хостам как по блочным, так и по файловым протоколам, но и по способу применения. Системы FAS используются для виртуализации, для Data Compliance, для хранения архивных копий, для построения Disaster Recovery решений и т.д. Одна и та же СХД может выполнять сразу множество функций. Так для каждой функции не нужно держать одно «специализированное» устройство, а в случае если срочно понадобится «запасная» СХД, её всегда можно «перепрофилировать» из того что есть, к примеру из СХД для архивации данных. Благодаря этой универсальности нет необходимости переобучаться под каждую из этих задач ведь операционная система, командная строка и все принципы настройки одни и те же для всех FAS систем.

В этой статье я расскажу как построенное решение «Архивация данных на NetApp» переделать в решение «Disaster Recovery».

С точки зрения бизнеса Disaster Recovery и архивирование отличаются тем, что:
  • Архивирование (SnapVault) — решение предназначено для длительного хранения и защиты данных от изменений, для последующего восстановления их туда, откуда они были скопированы (или в другое место).
  • Disaster Recovery (SnapMirror) — хранение данных на резервном сайте, для переключения на него (и соответственно изменения данных), в случае катастрофы.


Поясню на примере: когда у вас есть хотя бы две СХД с настроенной репликацией SnapMirror, в такой схеме одна из них играет роль источника (primary), а вторая роль приемника (Secondary). В случае аварии, при разрыве репликации (командой break, а не просто разрыв линка), принимающая (Secondary) система переведёт реплицируемое зеркало из режима read-only в режим read-write. Т.е. это инструмент для создания решения «Переключение на запасную площадку в случае аварии» (Disaster Recovery). Логично, чтобы обе системы были плюс-минус одинаковой производительности, чтобы обеспечить все переключённые узлы с одного сайта на другой, должным уровнем производительности.



В то время, как SnapVault предназначен для архивирования на резервную (Secondary) систему, чтобы потом из неё восстановить все данные обратно на первичную систему или вообще на третью систему. Стоит отметить, что для задач архивирования очень важно хранить данные в неизменённом состоянии все время. В данном случае вторичная система, куда складываются все архивы, может быть любой модели. Здесь логично иметь самую дешевую модель NetApp FAS с медленными и дешевыми дисками большего объема. К примеру, FAS2554 или FAS2520.
Как перевести SnapVault в SnapMirror
Total votes 5: ↑5 and ↓0 +5
Views5K
Comments 28

SnapProtect 10 SP2: новые возможности

System administrationIT InfrastructureData recoveryBackupData storage
В продолжение темы о ПО SnapProtect: Архитектура резервного копирования на системах NetApp FAS, эта статья посвящена новым возможностям SnapProtect. Софт SnapProtect объединяет высокоскоростные Snapshot NetApp и репликацию на ленту, для уменьшения времени простоя и потери данных. Это единая консоль управления, создания и каталогизации, управления консистентными, с точки зрения приложения, snapshot в инфраструктуре, обеспечивая жизненный цикл хранения disk-to-disk-to-tape (D2D2T).



Эта схема резервного копирования выполнена в соответствии с парадигмой резервного копирования для систем NetApp FAS: основные и резервные данные расположены на СХД, а резервные копии выполняются на основе Hardware Assistant Snapshot, взаимодействуя с приложениями создавая, таким образом, Application Consistent Backup.
Новые возможности
Total votes 12: ↑10 and ↓2 +8
Views3.3K
Comments 0

Парадигма резервного копирования NetApp

IT InfrastructureData recoveryBackupData storageData storages
В этом посте я хотелбы рассмотреть подход к резервному копирования данных на СХД NetApp серии FAS.


Архитектура резервного копирования

WAFL


И начну я издали — со снепшотов. Технология снепшотов впервые была изобретена (и запатентирована) в 1993 году компанией NetApp, а само слово Snapshot™ является её торговой маркой. Технология снепшотирования логически проистекала из механизмов работы файловой структуры WAFL. Почему WAFL не файловая система смотрите здесь. Дело в том, что WAFL всегда пишет новые данные «в новое место» и просто переставляет указатель на содержимое новых данных в новое место, а старые данные не удаляются, эти блоки данных, на которые нет указателей, считаются высвобожденными для новых записей. Благодаря этой особенности записи, «всегда в новое место», механизм снепшотирования был легко интегрирован в WAFL, из-за чего такие снепшоты называют Redirect on Write (RoW). Подробнее про WAFL.
Читать дальше →
Total votes 5: ↑4 and ↓1 +3
Views12.3K
Comments 41

Катастрофоустойчивость: DR для малых предприятий, энтузиастов и прочих гиков с помощью Microsoft Azure

Microsoft corporate blogMicrosoft Azure
Recovery mode
Всем доброго времени суток!

На носу Новый Год, наконец-то начал падать качественный снег в белокаменной…
Но это все лирика, а из интересного в облачно-техногенной сфере сегодня я хотел бы рассказать Вам про новые возможности нашего публичного облака Microsoft Azure в области катастрофоустойчивости и резервирования нагрузок. Для более детального и подробного рассказа милости прошу под кат!



Читать дальше →
Total votes 20: ↑14 and ↓6 +8
Views4.8K
Comments 1

Проект Dual ETL или как мы строили Disaster Recovery для Greenplum

TINKOFF corporate blogSQLBig Data
В этой статье я хочу рассказать про ещё один этап развития DWH в Тинькофф Банке.

Ни для кого не секрет, что требования к наличию Disaster Recovery (далее DR) в современных бизнес информационных системах относятся к категории «must have». Так, чуть более года назад, команде, занимающейся развитием DWH в банке, была поставлена задача реализовать DR для DWH, на котором построены как offline, так и online процессы банка.



Читать дальше →
Total votes 11: ↑10 and ↓1 +9
Views11.3K
Comments 9

Использование Microsoft Azure в качестве резервного ЦОД-а

Microsoft corporate blogMicrosoft Azure
Высокую доступность виртуальных машин (ВМ) Hyper-V можно обеспечить разными способами. Один из таких способов, Hyper-V Replica, позволяет реплицировать критические для бизнеса компании ВМ в другое физическое расположение, например, в резервный ЦОД. В этом случае мы реализуем катастрофоустойчивое решение, и даже потеря всего ЦОД-а не приведет к потере ВМ. Но много ли компаний могут позволить себе иметь резервный ЦОД? А если его нет, но устойчивость к сбоям на уровне площадки все же необходима? Сервис Azure Site Recovery недавно был обновлен таким образом, что теперь вы можете настроить реплику ваших ВМ прямо в облако Microsoft, используя Microsoft Azure в качестве «резервного ЦОД-а». Здесь можно посмотреть, как это выглядит. Мы дальше рассмотрим возможные сценарии и реализацию одного из них.
Читать дальше →
Total votes 16: ↑12 and ↓4 +8
Views8.5K
Comments 1

SDS от NetApp: ONTAP Select

SAN
ONTAP Select это логическое развитие линейки Data ONTAP-v, т.е. Software Defined Storage. Софт ONTAP (Операционную систему или прошивку по-народному, если хотите) можно использовать на специализированной аппаратной плтформе FAS или в виде виртуальной машины: в публичных облаках или на комодити оборудовании.
Два последних варината называют ONTAP for Cloud и ONTAP Select соответственно.

Как и предшественник ONTAP Select, этот продукт, который живёт в виде виртуальной машины и полностью опирается на традиционный RAID контроллер, установленный в вашем сервере. Поддерживаются NAS (CIFS, NFS) и IP SAN (iSCSI) протоколы и отсутствует поддержка FCP. В документах NetApp можно встретить внутренее название ONTAP Select — sDOT, это одно и тоже.

Из ожидаемых новшеств:
  • Поддержка High Avalability
  • Поддержка кластеризации до 4 нод
  • Максимальный полезный объем 400 ТБ (по 100ТБ на ноду в 4х нодовом кластере)

На ряду с High Availability и кластеризацией по-прежнему поддерживаются однонодовые конфигурации.

Читать дальше →
Total votes 8: ↑8 and ↓0 +8
Views6.2K
Comments 27

Все умрут, а я останусь: репликация и послеаварийное восстановление в облако с помощью Veeam Cloud Connect Replication

DataLine corporate blogIT InfrastructureVirtualizationCloud computingData recovery
Tutorial
» Работаем с гибридным облаком: VMware vCloud Connector, часть 1
» Работаем с гибридным облаком: VMware vCloud Connector, часть 2

В первых двух частях мы посмотрели, как построить гибридное облако с помощью VMware vCloud Connector. Сегодня поговорим об авариях и о том, как с помощью ресурсов облачного провайдера восстанавливать “упавшую” внутреннюю инфраструктуру. Разбирать тему будем на примере Veeam Cloud Connect Replication — инструмента, помогающего настраивать репликацию виртуальных машин и запускать реплики в облаке сервис-провайдера.

Для опытов нам понадобятся: своя виртуальная инфраструктура и внешние облачные ресурсы на базе VMware, Veeam Backup and Replication не ниже версии 9.


Читать дальше →
Total votes 13: ↑12 and ↓1 +11
Views8.3K
Comments 2

GitLab PostgreSQL postmortem

PG Day'17 Russia corporate blogServer AdministrationDatabase AdministrationBackupData storage
31 января 2017 года у GitLab случилась авария, связанная с эксплуатацией СУБД PostgreSQL, в результате которой часть данных была удалена, а проект был остановлен на время восстановления. Прошло уже несколько месяцев, и было очень много написано на эту тему, а сам GitLab представил исчерпывающий некролог, в котором рассказал, что произошло, какие предпринимались меры для восстановления и какие меры будут предприняты для предотвращения подобных аварий. Очень занимательное чтиво, рекомендуем его прочесть даже тем, кто далек от Постгреса.



В комментариях к нашему интервью с Алексеем Лесовским, некоторые представители сообщества, шутя, высказали претензию, что мы упомянули про аварию GitLab, но в итоге так и не провели подробный разбор полетов. Мы решили исправиться и попросили Алексея написать небольшой «разбор полетов». Основной целью этой публикации является детальный анализ некролога, выделение ключевых моментов, попытка проанализировать их и предложить рекомендации, как следовало бы действовать в подобной ситуации. И, конечно же рассмотрим меры, которые команда GitLab планирует предпринять для предотвращения таких инцидентов в будущем.
Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views9.2K
Comments 1
1