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

Если кто-то еще не слышал, то сообщаем: в уходящем году компания Veeam Software реализовала поддержку резервного копирования и восстановления виртуальных машин на платформе Nutanix Acropolis Hypervisor (AHV). Для этого был разработан специальный компонент инфраструктуры Veeam Backup – вспомогательный прокси-сервер (proxy appliance), который получил красивое имя собственное Veeam Availability for Nutanix AHV.

Он представляет собой виртуальный модуль, позволяющий бэкапить и восстанавливать ВМ на кластерах Nutanix AHV, задействуя возможности Veeam Backup & Replication. Решение функционирует на уровне гипервизора: без внедрения агентов в гостевую ОС создает бэкап ВМ на уровне образа, по состоянию на текущий момент времени (включая ОС, данные приложений и пр.) и сохраняет в репозиторий Veeam.

Из этих бэкапов затем можно восстанавливаться по любому сценарию: восстанавливать всю ВМ целиком либо отдельные диски, файлы, объекты приложений. Поддерживается и восстановление в облако Microsoft Azure, и экспорт дисков, и мгновенное восстановление в ВМ на платформе Hyper-V.

Всех заинтересовавшихся прошу под кат.

Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR
• Тестирование решения, определение оптимальных настроек и режимов работы
• Запуск решения в промышленную (коммерческую) эксплуатацию

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

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

Месяц с небольшим тому назад компания Microsoft объявила о выходе новейшей версии Windows Server 2019. Однако после GA (general availability) были обнаружены серьезные недостатки, как и в Windows 10 October 2018 Update (оно же 1809) – установка обновления приводила к потере данных (файлы из My Documents жестоко удалялись, так что их нельзя было восстановить из Windows.old). Производитель был вынужден отменить релиз до устранения проблемы. И вот наконец-то 13 ноября починенная версия увидела свет.

Наряду с этим следует вспомнить, что скоро Microsoft завершит поддержку SQL Server 2008 R2 и Windows Server 2008 R2.

Естественно, что у пользователей возникает множество вопросов по переходу на новые системы:
Переезжать ли в облако Microsoft Azure? Как безопасно повысить функциональный уровень домена? Переходить ли на Azure SQL? Может, надо виртуализировать Windows Server 2008 R2 или перенести в Azure? Надо ли мигрировать на новейший Hyper-V?

Миграция на новую платформу нужна, чтобы обеспечить для критически важных приложений, работающих в ЦОД, наличие системы, поддерживаемой вендором. Поэтому важно, чтобы миграция прошла без сюрпризов. Пользователям Veeam повезло — у них есть хорошие способы минимизировать риски при подобных операциях, чтобы, как говорится, “7 раз отмерить, 1 раз отрезать”.

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

Всем привет! Я работаю в Veeam над проектом Veeam Agent for Linux. С помощью этого продукта можно бэкапить машину с ОС Linux. «Agent» в названии означает, что программа позволяет бэкапить физические машины. Виртуалки тоже бэкапит, но располагается при этом на гостевой ОС.

Вдохновением для этой статьи послужил мой доклад на конференции Linux Piter, который я решил оформить в виде статьи для всех интересующихся хабражителей.

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

Всех заинтересовавшихся прошу под кат!

Иногда может захотеться странного. Вот вроде бы лежит себе видеокамера стандарта MiniDV и лежит. Есть не просит. А что если взять и записать на её кассеты вовсе даже не видео, а, скажем, файлы. Запись-то всё равно цифровая. Пусть объём кассеты всего лишь около 13 ГБ (под данные получилось занять около 9.5 ГБ), пусть скорость чтения 3.5 МБ в секунду, но ведь получится простой домашний стример. Так сказать, “стример для бедных”. Почему бы не отправить на несколько кассет, скажем, какие-либо важные файлы. Просто так, на всякий случай. Попробуем!

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

Несмотря на надежность современных центров обработки данных, для критически важных объектов необходим еще один уровень резервирования, ведь вся IT-инфраструктура может выйти из строя из-за техногенной или природной катастрофы. Для обеспечения катастрофоустойчивости приходится строить резервные ЦОДы. Под катом наш рассказ о возникающих при их объединении (DCI — Data Center Interconnection) проблемах.

Мои замечательные коллеги из отдела технической поддержки пишут не только вредные, но также и полезные советы и рекомендации по настройке Veeam Backup & Replication. С момента публикации статьи для начинающих пользователей ее автор, Евгений Иванов, продолжая трудиться вместе с румынской командой в Бухаресте, перешел с поста старшего инженера на должность тим-лида. Но технико-литературное поприще Евгений не оставил, за что ему большое спасибо!
Новая статья Жени содержит рекомендации для уже опытных специалистов по работе с Veeam Backup & Replication, перед которыми стоит задача наиболее эффективно использовать ресурсы инфраструктуры резервного копирования. Впрочем, статья будет полезна и тем, кто только планирует установку и настройку нашего продукта.


Оптимизация распределения нагрузки в теплые ламповые времена

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

Итак, как наверняка все знают, совсем недавно 1-2 октября в Москве в “Инфопространстве” прошёл DevOpsConfRussia2018. Для тех кто не вкурсе, DevOpsConf — профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации.

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

О чём мы рассказывали? Митап был на тему “Бэкапы в Kubernetes”.

Скорее всего услышав это название, многие скажут: “А зачем бэкапить в Kubernetes? Его не нужно бэкапить, он же Stateless”.

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

• Windows кластер с Windows Server 2012 r2 под капотом и неким количеством нод. Для удобства в моей лабе их всего две. Возникает законный вопрос: а зачем ставить кластер на кластер? Объясню чуть ниже.
• К кластеру по iSCSI зацеплено три диска: кворум, диск с базой (базами), диск для логов. Можно больше, можно меньше, тут кому как нравится. Иногда нравится так: два локальных диска (один для системы, второй для установки самого SQL), диск для кворума, совмещённый диск для root и system database, диск для базы, диск для логов, диск для TempDB и диск для Backups. Системщики говорят, что так тоже правильно. Но я считаю, что сколько у вас будет дисков — совершенно никакой роли не играет. Если именно у вас работает, значит вы правы и молодец.
• На каждой ноде установлен инстанс SQL, понимающий, что он часть SQL кластера, а Windows кластер видит роль SQL Server.

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

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

Автор пользуется стеком django/uwsgi/nginx, виртуальным выделенным сервером под управлением GNU/Linux, но содержание статьи почти не зависит от конкретных технологий.

Казалось бы, тема избитая – про резервное копирование сказано и написано многое, поэтому нечего изобретать велосипед, просто бери и делай. Тем не менее, каждый раз, когда перед системным администратором web-проекта встает задача настроить бэкапы, для многих она повисает в воздухе большим вопросительным знаком. Как правильно собрать бэкап данных? Где хранить резервные копии? Как обеспечить необходимый уровень ретроспективы хранения копий? Как унифицировать процесс резервного копирования для целого зоопарка различного ПО?

Да, я тоже бываю дебилом. Но такого я от себя не ожидал. Вроде бы «не первый год замужем». Вроде бы читал кучу умных статей об отказоустойчивости, избыточности и т.п., что-то разумное когда-то написал даже сам тут. Свыше 10 лет являюсь CEO хостинг-провайдера работающего под брэндом ua-hosting.company и предоставляющего услуги хостинга и аренды серверов в Нидерландах, США, а буквально неделю назад и в Великобритании (не спрашивайте, почему название ua, ответ можете найти в нашей автобиографической статье), предоставляем клиентам решения различной степени сложности, иногда такой, что даже сами затрудняемся разобраться в том, что сотворили.

Но блин… Сегодня я превзошёл сам себя. Мы сами себе полностью снесли сайт и биллинг, со всеми транзакциями, данными клиентов об услугах и прочим и в этом виноват был я, я сам сказал «удаляй». Некоторые из Вас уже заметили это. Это случилось сегодня, в пятницу в 11:20 по восточному североамериканскому времени (EST). Причём наш сайт и биллинг размещены были не на одном сервере, и даже не в облаке, мы ушли из облака дата-центра 2 месяца назад в пользу нашего собственного решения. Всё это размещалось на отказоустойчивом гео-кластере из двух виртуальных серверов — нашего нового продукта, VPS (KVM) c выделенными накопителями, НЕЗАВИСИМЫХ VPS, которые располагались на двух континентах — в Европе и в США. Один в Амстердаме, а другой в Манассасе, под Вашингтоном, тем, что D.C. В двух надёжнейших дата-центрах. Контент на которых постоянно и в реальном времени дублировался, а отказоустойчивость основана на обычном кластере DNS, запросы могли приходить на любой из серверов, любой выполнял роль MASTER, и в случае недоступности брал на себя задачи второго.

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

Входит и выходит, замечательно выходит...

Приложения, которые работают в облаке, защищены только в определенной степени. Для полной защиты данных, которые генерируются облачными приложениями, вам потребуется резервное копирование в другое облако (cloud-to-cloud backup).

По данным Forrester, расходы на услуги публичного облака вырастут к 2020 году до 236 млрд. долларов США. Это тенденция, усиливается увеличением количества приложений, размещенных в облаках.

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

Итак, почему мы видим необходимость в создании cloud-to-cloud копии?

Предлагаю вашему вниманию перевод статьи моего коллеги Andrew Zhelezko о применении интегрированного решения для хранения резервных копий на базе продуктов Veeam, StarWind и Azure.

Многие компании по сей день используют для своих сервисов ленточные библиотеки, однако всё большую популярность завоёвывают облачные хранилища, которые обеспечивают уверенную и стабильную работу систем резервного копирования. И наряду с поддержкой распространенных виртуальных ленточных библиотек Veeam теперь позволяет работать с библиотекой StarWind VTL для Microsoft Azure Blob Storage. Это отличная возможность для тех, кому требуется недорогое и надежное облачное хранилище для безопасного размещения в нем резервных копий данных. Пользователи такого интегрированного решения смогут реализовать гибкие политики хранения данных: например, держать в обычной инфраструктуре бэкапы 1-2 недели, а затем перемещать их в долгосрочное облачное хранилище Microsoft Azure Blob Storage. В этой статье я кратко расскажу о том, как настроить интеграцию.

Все больше организаций переходит к использованию облачного Microsoft Office 365, и Veeam продолжает обеспечивать для них защиту данных – наши решения работают 24х7, а разработчики следуют календарю релизов и обновлений. Так, когда многие наши читатели были на отдыхе в разгар летнего сезона, в свет вышла новая версия Veeam Backup for Microsoft Office 365. В ней реализована поддержка резервного копирования и восстановления данных не только облачного Exchange, но также SharePoint и OneDrive. Кроме того, с версией 2.0 была выпущена и бесплатная редакция решения – Veeam Backup for Microsoft Office 365 Community Edition. Обо всех новинках я расскажу под катом.

К нашему огромному удивлению на хабре не оказалось ни одного материала про замечательный Open Source-инструмент для резервного копирования данных ­— Borg (не путать с одноимённым прародителем Kubernetes!). Поскольку уже более года мы с удовольствием используем его в production, в этой статье я поделюсь накопленными у нас «впечатлениями» о Borg.

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

— А у нас есть какой-нибудь снимок за январь, ближе к февралю?
— Сейчас посмотрим… Да, есть! Сейчас откроем.

Бывает так, что есть среднее время жизни тестовой базы, есть согласованное всеми заинтересованными время жизни снэпшотов, но какая-то из сред слишком долго «засиживается» на своём снимке, который никак не удаляется… а потом он оказывается полезен коллегам. И минус на минус даёт плюс.

Обычно для любых систем, в которых может что-то происходить, требуется формировать бэкапы. А если она ещё и развивается и дорабатывается, то где-то также разворачивать среды разработки и тестирования. Причём для бэкапов и сред тестирования, которые работают, по сути, с теми же данными, нужно немало места. А ещё эти среды надо как-то приводить к актуальному состоянию. И всё это требует аппаратных и временных ресурсов.

В нашем случае, эти потребности покрыли Oracle ZFS Storage Appliance и серверы Oracle / Sun, которые фактически слились в одну экосистему с Exadata, появившейся незадолго до них.

Рассуждать о том, что сайт должен быть доступен всегда — моветон и банальность, но 100% доступность, хотя и является обязательным требованием, чаще всего по-прежнему недоступный идеал. Сейчас на рынке существует масса решений, которые обещают максимальный uptime или предлагают решения для его увеличения, но их применение мало того, что не всегда помогает, в некоторых случаях даже может привести к увеличению рисков и снижению доступности проекта. В этой статье мы пройдемся по классическим ошибкам, которые с которыми мы постоянно сталкиваемся. Большинство проблем — элементарные, однако люди допускают их вновь и вновь.