Долгожданный релиз версии 11 нашего флагманского продукта заставил меня снова взяться за перо. Такова цена работы с активно развивающимся софтом – не успеваешь с чувством глубокого удовлетворения закрыть Word, как все написанное начинает устаревать и Сизиф вновь должен толкать свой камень в гору на общее благо.

За время моей работы в Veeam я пережил уже семь крупных апдейтов. Чтобы быть во всеоружии, еще до релиза по каждому я вел конспект, куда записывал все изменения и нововведения. Могу сказать, что по этой нехитрой метрике v.11 побил все рекорды, обогнав даже юбилейную десяточку. Уверен, о новых фичах будет сказано еще многое, а я же продолжу развивать тему этой серии и расскажу, какие изменения следует ожидать с точки зрения ретеншена.

Инженер технической поддержки - многими это словосочетание воспринимается как связанное исключительно с юным возрастом и отсутствием опыта работы. Этакий аналог “свободной кассы”, только в IT.  Вроде как можно полгодика-годик перекантоваться, может, даже денег поднакопить, но потом надо срочно всё бросить и бежать дальше. Вот из-за таких стереотипов многие и не поняли, что при должном усердии это может стать интересной профессией на многие годы, а не просто стартом карьеры в первые месяцы после университета.

Так что да, эта статья скорее для тех, кто начинает - о том, как может быть на самом деле (нежели для прошедших горнило замены картриджей и теперь пугающих этим молодёжь).

Снятие снапшота - именно с этого начинается любой бекап. До тех пор, пока мы не знаем, как сбросить все буфера на диск и привести файлы с данными в консистентное состояние, мы не бекапы делаем, а занимаемся копированием файлов с непредсказуемым содержимым внутри. Понимая важность снапшотов, все вендоры стараются дать нам если не полностью готовую функцию (типа Time Mashine в MacOS), то хотя бы набор ручек, за которые можно подёргать (вроде модуля dm-snap в ядре Linux). 

Но сегодня речь пойдёт про самую распространённую ОС - Microsoft Windows, где эта задача решается с помощью Volume Shadow Copy сервиса, известного в народе под аббревиатурой VSS (Volume Snapshot Service). А нашего внимания он удостоился из-за того, что, несмотря на всю популярность своего материнского корабля, сам он окутан вуалью из тайн и мистических слухов. Давайте уже как-то разберёмся с этой штукой.

В рунете я почти не встречал материалов о том, как писать расширения для MediaWIki. Основной стартовой точкой был и остается официальный сайт платформы, но там процесс расписан не очень дружелюбно по отношению к новичкам. Попробуем же это исправить!

В этой статье я покажу, как написать простейшее расширение для Медиавики, включающее в себя новый метод API, расширение парсера и немного js/css для фронтенда. А чтобы не было скучно, приплетем сюда работу с Google Knowledge Graph.

По мнению абсолютного большинства жителей этой планеты, разработчики это - какие-то зажравшиеся люди, которые сидят в своих уютных креслах, занимаются какой-то фигнёй и получают за это непомерные деньги. Эталонные тепличные условия и голубая мечта, которая выродилась в пренебрежительное “Войти в айти”. Но если предположить, что всё действительно так, как принято считать - и стул удобный, и денег платят много, и работа интересная - то почему же программисты, как и все остальные люди, иногда меняют место работы? Может быть, недостаточно платили? Или кресло было не такое удобное? Что-то же должно побудить человека, у которого всё хорошо (по мнению окружающих), выйти из зоны комфорта и пойти искать новое место работы. И что именно он ищет на этом новом месте? Давайте поговорим об этом. И да, многое здесь может показаться банальным, но почему-то достаточное количество людей предпочитают не брать в расчёт и половину из этих банальностей. Или делают вид, что им всё равно.

В романе Марка Твена «Янки при дворе короля Артура» главный герой попадает, как легко догадаться, в дремучее английское Средневековье. Пользуясь своим современным школьным образованием, он значительно подталкивает технологических прогресс Англии, а заодно и сам с легкостью добивается привилегированного положения. В поезде времени мы, к сожалению, пока не научились пересаживаться из вагона в вагон. Но если бы однажды путешественники во времени всё же появились, можете быть уверены: Джон Ло почти наверняка оказался бы одним из них. Вот только в отличие от героя Твена, Ло положился не на свои знания физики, химии или астрономии. Нет, он перевернул с ног на голову всю экономику Франции, как если бы кто-то, чуть разобравшийся в истории с Wall Street и GameSpot, вдруг провалился в XVIII век и попытался втолковать местному королю про банки, инфляцию для разогрева экономики и акционерные общества. Возможно, этот кто-то так же попытался бы лично разбогатеть за счет финансового невежества окружающих, но у каждого, как известно, свои недостатки.

Эта статья об афере Джона Ло – возможно, самой значимой в экономической истории. На краткий миг Ло стал самым известным, самым ненавидимым и самым влиятельным человеком в мире. Ему удалось создать первый частный банк во Франции, сделать его государственным и провернуть колоссальную авантюру с акциями, разорившую половину богатейших домов Парижа. Так кем же был этот удивительный мистер Ло и как ему удалось провернуть свою аферу?

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

В то же время умение работать с логами - очень ценный и полезный навык. Я бы сравнил работу с логами с поеданием овсянки. Есть овсянку - полезно == уметь анализировать логи - полезно. Ну, а для того, чтобы овсянка стала вкуснее, в нее я добавлю топпинг - интересный сценарий. Чем более загадочной выглядит проблема, тем интереснее становится анализ логов, и ты смотришь уже не просто на строки текста, а распутываешь клубок из улик и доказательств, проверяешь или опровергаешь теории.

Ну что, наливаем чаек, сейчас мы будем расследовать - Детектив с Кластером Hyper-V

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

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

Япония влечет своей необыкновенной культурой, потрясающей природой и развивающимися во все стороны технологиями. И интереснее наблюдать и изучать ее изнутри, не как турист, а как житель. Я провела в Токио год, полный приключений и разнообразных открытий. Я влюбилась в эту страну, но для себя решила, что жить в ней не хотела бы. Прежде всего потому, что лицо и душа страны – это её жители, а познать и подружиться с ними с нашим культурным багажом очень сложно. Раскрою вам несколько полезных вопросов, которые вас заинтересуют, если вы планируете или уже собираетесь переезжать в Японию:

Функция CDP (она же Continuous Data Protection) для многих сейчас видится манной небесной. Ведь она позволяет свести риски потери данных к около-нулевым значениям (RTO и RPO - единицы секунд), при этом не используя тормозящие всё вокруг себя снапшоты, и не зависеть от ограничений классических вариантов репликации. 

Вот об этом мы сегодня и поговорим: что это за магия такая, как она работает и как мы её реализовали в Veeam Backup & Replication v11.

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

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

Общение с людьми всегда было моей профессией и увлечением. Сначала я училась на журналиста, потом работала пиарщиком, после — бизнес-аналитиком в IT. В работе с любой аудиторией важно найти правильный подход и выстроить эффективную коммуникацию. Мой будущий ребенок не стал исключением. Шел пятый месяц беременности, а я еще не знала ни имени, ни пола (на узи он тщательно крутил фиги и отказывался деанонимизироваться), зато успела познакомиться с дивным новым миром, где полыхали дискуссии о преимуществах памперсов, пользе грудного вскармливания и лучших педагогических методиках.  Оказалось, ребенка мало родить, его ещё иногда надо кормить и когда-то отдать в школу. Нужно еще и правильно с ним говорить, играть, развивать и выращивать.  

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

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

VTL (они же Virtual Tape Library, если по паспорту) можно назвать одним из самых странных порождений IT индустрии. Родившись в эпоху расцвета ленточных накопителей как классический софтовый эмулятор настоящего железа, многими они были восприняты как ответ на главный вопрос жизни (Вселенной и всего такого), и теперь одни умудряются продавать их за деньги, а другие использовать в проде и считать, что всё нормально.

Я не буду кричать что первые плохие, а вторых надо гнать из профессии. Нет. Я только лишь предлагаю трезво взглянуть на суть VTL.

Версии Veeam Backup & Replication перевалили на второй десяток — и сегодня вашему вниманию предлагается уже Veeam Backup and Replication v11. Что же его разработчики подготовили на этот раз? Уместить в одной статье описание всех новых и обновленных фич, конечно, нереально — так что я расскажу о самых значимых, а для всего остального есть MasterCard What’s New.



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

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

Помните, как во второй половине 90-х один известный тогда профессор хрипло пел “Бегут года, и грусть, печаль в твоих глазах, а я не знаю что тебе сказать”. Так вот, года действительно бегут, а грусть-печаль в глазах из-за того, что гонка технологий уже достигла таких скоростей, что успеть за ними не может даже самый ловкий мангуст. Правда, некоторые вещи категорически отказываются меняться, и раз уж эта статья из блога компании, занимающейся бекапами, видимо, что-то не меняется в бекапах. А проблема, о которой хочется поговорить сегодня - это выбор сервера, который эти бекапы и будет делать. Все как-то привыкли думать только о размере стораджа, куда их предстоит складывать, а то, что процесс бекапа - это типичная задача обработки большого массива данных, которая жрёт RAM и CPU как не в себя, многие то ли забывают учесть, то ли по неопытности упускают этот момент. Так что сегодня учимся подбирать сервера для бекапов не только по размеру дисков. Или, как говорят зарубежные коллеги: backup server sizing best practices.

И да, в посте будет математика. Целых две формулы. Я предупредил.

Сегодня для вас — перевод статьи Игоря Архангельского про политики хранения резервных копий (проще говоря, ретеншен) в Veeam Backup for Microsoft Office 365.

Сейчас Игорь — инженер команды техподдержки, а до этого он занимался сетевыми технологиями, работая на крупнейших интернет-провайдеров. Там он получил опыт работы с оборудованием от популярных производителей — Cisco, Juniper, Huawei. Эти знания и навыки очень пригодились ему в его нынешней специализации, ведь очень многое (если не все) в решении Veeam Backup for Microsoft Office 365 (VBO365) завязано на передачу данных с использованием интернет-протоколов.

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

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

Приветствую читателей нашего блога в новом, 2021 году и надеюсь, что вы работаете над новыми крутыми проектами и интересными задачами!

Для того, чтобы командная работа оставалась слаженной и эффективной, невзирая на удаленность участников, work from home и т.д., у нас в Veeam уже не первый год используется Microsoft Teams. А в прошлом году популярность этого инструмента, само собой, значительно выросла. Veeam идет в ногу со временем — и сегодня я с удовольствием представляю новую версию Veeam Backup for Microsoft Office 365 (VBO365), которая поддерживает бэкап и восстановление Microsoft Teams.

Признаюсь, что к VBO365 у меня особое, можно сказать, трепетное отношение — ведь этот продукт зарождался практически у меня на глазах, и я помню еще его вот таким крошкой первую бета-версию.
И вот у него уже первый юбилей — версия 5.0. Помимо всего уже известного вам она умеет бэкапить данные о собственно командах (teams), каналах (channels), вкладках (tabs), а также контент и настройки. За поиск внутри бэкапа, экспорт и восстановление необходимой информации отвечает, как вы, наверное, уже догадались, Veeam Explorer for Microsoft Teams.

За подробностями добро пожаловать под кат.

Казалось бы, такое простое действие: взять да восстановиться из бекапа, если где-то сломалось. Текущий уровень развития софта позволяет это cделать буквально в несколько кликов - и вы восхитительны. Возможно, даже никто не заметит, что была какая-то авария.

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

И вот о том, как не овеять себя славой самого могучего специалиста во веки веков, мы сегодня и поговорим. Шесть очевидных и не очень поводов задуматься. И да, при чтении не забывайте поднимать табличку "Сарказм" и помните - всё написанное ниже основано на реальных случаях.