Резервное копирование *

Наверное, уже все слышали, что в соответствии с вступившим в силу Федеральным законом от 21 июля 2014 г. № 242-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях" необходимо организовать хранение и обработку персональных данных в России. Тема, конечно же, коснулась почти всех зарубежных финансовых организаций, представленных у нас в стране. Колесо завертелось и волею судьбы мы выиграли на исполнение проект одного зарубежного банка по созданию ИТ-инфраструктуры под миграцию его информационных систем (ИС) в Россию. Сорри, контракт включает NDA, поэтому назвать банк не можем. Но можем рассказать, как все это мы реализовали, какое решение предложили, архитектуру, СПД, какие вендоры – в общем, весь наш опыт передаем ниже.

Сегодня мы поговорим о продукте, который вызывает довольно неоднозначное мнение в профессиональном сообществе — Microsoft Data Protection Manager. Под катом вы найдёте первую часть из серии статей, в которой мы погрузимся в историю.

Настройка резервного копирования уверенно занимает одно из важнейших мест в деятельности администратора. В зависимости от задач резервного копирования, типов приложений и вида данных резервное копирование может осуществляться с помощью различных инструментов, таких как rsync, duplicity, rdiff-backup, bacula и других, коих существует огромное множество.

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

Давно уже ребята задают вопросы, как организовать резервное копирование в облако, при этом не тратя много сил, времени и лучше всего бесплатно. Поводом для написания статьи послужил очередной диалог на эту тему. По итогами долгой переписки с коллегами, объяснения теории и перебора вариантов практической реализации, я решил написать об этом. Все просто как пять пальцев, но часто спрашивают КАК.

Резервное копирование в облако — тема уже давно не новая. Каждый выбирает своего облачного провайдера, свои инструменты для копирования и пр. Вендоров много, здесь мы рассмотрим именно Google Cloud Platform. Мы все реализуем самыми простыми скриптами, без покупки софта, покупки дисковых хранилищ и прочего.

Уже в третий раз прошла конференция, посвящённая доступности данных — VeeamON. В этом году её посетило около 3500 человек, а всё действие происходило в городе Новый Орлеан, что в штате Луизиана, который, в свою очередь, находится в США.

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

Чего здесь не будет

Пересказов анонсов, пресс-релизов и историй о том, как мы все здорово заживём в ближайшем будущем, и тому подобного. Кому интересно — все маркетинговые материалы крайне легкодоступны, и заниматься их пересказом мне видится весьма сомнительным занятием.

Что здесь будет?

Впечатления от города и мысли, так сказать, «цыганщина».

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

Так случилось в одной из больниц, где рентгеновский кабинет оснащен современным оборудованием, и стоимость одного только рентгеновского аппарата превышала 100 000$. Важный момент, что при реконструкции кабинета в расчет бралась только закупка непосредственно самого оборудования. Всякие «излишества» в виде ПК врача-рентгенолога и реализации системы хранения данных пациентов в этот расчет не вошли, и больнице было предложено за собственные средства приобретать все остальное, что необходимо для работы кабинета.


рис. 1

Собственных средств больницы хватило лишь на приобретение ПК для врача-рентгенолога с единственным жестким диском Seagate Constellation CS ST3000NC002-1DY166 емкостью 3 Тб. Первоначально планировалось это использовать как временное решение, а далее, когда появятся «свободные деньги», реализовать планы по созданию системы резервного копирования.

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

Думаю найдется очень мало системных администраторов, которые не выполняют резервное копирование тех или иных данных. Эта заметка будет полезна (надеюсь) для тех, кто пользуется таким программным продуктом как Cobian Backup. А в особенности тем, у кого резервное копирование осуществляется не в одном месте, или даже в разных городах.

Как вы уже поняли из заголовка, я хочу поделиться с Вами маленьким скриптом, который позволяет отправлять что-то (в моем случае кусочек log файла) в telegram.

Для тех кто задается вопросом почему именно Telegram, ведь Cobian Backup умеет оправлять сообщения на почту — объясню свою точку зрения. Telegram — это популярный развивающийся месенджер, который использует огромное количество людей. На мой субъективный взгляд — это удобнее, чем почтовый клиент. Так же этот способ был опробован на ооооочень плохом интернете — все работает. Причем отправка через email в одинаковых условиях не срабатывала.

В одной маленькой софтверной компании хранение данных было организовано следующим образом: сервер, в котором обыкновенные SATA накопители средствами linux (mdamd) организованы в несколько массивов RAID 1, каждый из которых являлся хранилищем для одного из направлений разработки. Данный вариант при минимальных затратах относительно надежен, если за ним подобающим образом присматривать. Но системный администратор решил, что нет нужды регулярно проверять состояние массивов, и занимался иными делами. В июне 2017, получив жалобы о невозможности прочитать данные от пользователей одного из массивов, обнаружил, что собственно массива уже давно нет, и что на один из накопителей запись прекратилась в августе 2015, а второй с актуальными данными при попытке монтирования подвешивает ОС. Резервная копия за пределы сервера последний раз была сделана в ноябре 2016 года.


рис. 1

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

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

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

В этой статье мы хотим рассказать о примере реального внедрения Zimbra Open Source Edition и Zextras Suite для европейского провайдера SaaS услуг, который специализируется на предоставлении услуг государственным, образовательным и медицинским учреждениям. Они предоставляют собственные облачные решения и обслуживают больше 21000 почтовых ящиков для более чем 200 различных доменов. Для модернизации ИТ инфраструктуры, желая предоставлять конечному пользователю высокотехнологичные и безопасные продукты, обеспечить надежную мобильную синхронизацию, управлять хранением файлов и предоставлять мультиаренду, было решено внедрить Zimbra Open Source Edition и полный комплект зимлетов Zextras Suite.

КДПВ, ради хайпа, а не флейма.

Моя попытка облегчить муки в процессе резервного копирования хотя бы на чуть-чуть. Какие требования были мной выдвинуты и как я их реализовал.

Офис небольшой торговой компании был размещен на цокольном этаже жилого дома, построенного в семидесятые годы прошлого века. За время своего существования дом изрядно обветшал, но продолжал эксплуатироваться с незначительными косметическими ремонтами. Компания хоть и сетовала на неподобающее состояние труб и сантехнического оборудования, но не торопилась за свой счет заниматься решением этих проблем, полагая, что грядущий капитальный ремонт уменьшит их потенциальные издержки. Но, как показали дальнейшие события, не стоит полагаться на голый экономический расчет без учета рисков.

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

Ущерб был нанесен стенам, полам, мебели, бумажной документации и оргтехнике. Наиболее пострадавшими оказались компьютеры, которые находились в серверной-админской и оставались включенными круглосуточно. Накопители, которым пришлось работать, будучи погруженными в горячую воду, представляли собой весьма печальное зрелище.


рис. 1

Всем привет! У всех нас есть данные, которые хочется держать под контролем. Мы не хотим потерять к ним доступ и не хотим, чтобы доступ был у кого-то ещё. Где хранить такие данные? Я считаю, что Sia может стать идеальным местом для этого и расскажу, почему.

Совсем недавно по планете прокатились волны WannaCry и его клонов. А сама проблема шифровальщиков стоит перед системными администраторами уже более 10 лет. Рано или поздно – но все внедренные и реализованные меры по защите от шифровальщиков не помогают и все-таки находится пользователь, который открывает письмо, вложение и получает полный «букет». Также много «приятных и увлекательных» часов получает системный администратор.

И тут то все четко начинают понимать, что нужны резервные копии (много, разных, в разных местах). Т.е. правило 3-2-1, придуманное и описанное Peter-ом Krogh-ом, весьма желательно выполнять. Данная статья – пример, который помогает сделать реальным выполнение данного правила на «коленке» — без покупки дорогостоящего оборудования (в условиях жесткой экономии).

Беда пришла откуда не ждали… У клиента завис процесс “Касса”, так что не смог снять процесс через Диспетчер задач. Рабочее место “Касса” — одновременно сервер всей системы.

Клиент принял решение ресетнуть через кнопку.

В итоге умерла DB. FireBird 2.5

Предыстория

Решение Acronis Backup версии 11.5/11.7 было выпущено более 5 лет назад и, хотя данный продукт до сих пор успешно защищает данные по всему миру, он уже успел морально устареть и назрели объективно необходимые изменения, требующие принципиально новых подходов. Несмотря на то, что платформа Acronis Backup 12, удовлетворяющая новым веяниям, была выпущена уже около года назад, её редакция «Advanced» всё это время оставалась на версии 11.7, что привносило проблемы совместимости и сложности одновременной поддержки очень разных архитектурных решений. Наконец-то настал момент, когда вся линейка продуктов Acronis Backup будет доступна на единой платформе. Данная статья посвящена выпуску Acronis Backup 12.5 и, собственно, что же нового было добавлено в этой версии.

Напомним, что решение Acronis Backup 12.5 поставляется в двух вариантах: стандартном (Standard) и расширенном (Advanced), доказало свою эффективность как полномасштабная система резервного копирования для гибридных сред. Простой и удобный веб-интерфейс обеспечивает надежное резервное копирование и восстановление физических, виртуальных и облачных серверов из любой точки мира.

Сегодня я хочу в одном посте обобщить информацию о пяти самых популярных freeware утилит компании Veeam, которые будут полезны в повседневной работе администратора как физических, так и виртуальных сред VMware vSphere и Microsoft Hyper-V. Итак в этом посте собрана информация о:

• Veeam Backup Free Edition для VMware и Hyper-V
• Veeam ONE Free Edition для VMware и Hyper-V
• Veeam Agent для Windows Free Edition
• Veeam Agent для Linux Free Edition
• Набор элементов Visio для VMware, Hyper-V и Veeam

Добро пожаловать под кат.

В этом посте обещал подробнее остановиться на истории с тестированием резервных копий. Сегодня как раз об этом. Чтобы обойтись без неприятных сюрпризов и в без того волнительные моменты потери данных, резервные копии нужно тестировать. Далее речь пойдет не про проверку целостности файлов резервных копий (проверка контрольной суммы блоков данных в файле бэкапа), а о полноценном тестовом восстановлении, когда проверяем работоспособность того, что у нас восстановилось.

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

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

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

Для нетерпеливых: в конце получился полноценный аппарат с актуальной версией загрузчика U-Boot, Debian Jessie и OpenMediaVault на борту.

Как мы уже рассказывали, на прошлой неделе, в пятницу, 12 мая более чем 75000 компьютеров на Windows по всему миру пострадали от атаки червя-вымогателя, известного как WannaCry, WCry или WanaCrypt0r 2.0. Данная атака была довольно хорошо спланирована киберпреступниками и осуществлена в пятницу прямо перед выходными на крупные телекоммуникационные и транспортные компании, правительственные и правоохранительные органы, больницы и образовательные учреждения.

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



В комментариях к нашему интервью с Алексеем Лесовским, некоторые представители сообщества, шутя, высказали претензию, что мы упомянули про аварию GitLab, но в итоге так и не провели подробный разбор полетов. Мы решили исправиться и попросили Алексея написать небольшой «разбор полетов». Основной целью этой публикации является детальный анализ некролога, выделение ключевых моментов, попытка проанализировать их и предложить рекомендации, как следовало бы действовать в подобной ситуации. И, конечно же рассмотрим меры, которые команда GitLab планирует предпринять для предотвращения таких инцидентов в будущем.