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

Как вы помните, предыдущее обновление Veeam Backup & Replication 9.5 Update 3 увидело свет в декабре 2017 года. С тех пор производители платформ и приложений, с которым работает решение, также выпустили ряд новых версий – разумеется, Veeam был обязан их поддержать, с чем успешно справились наши инженеры.

Сегодня я представлю вашему вниманию новинку – Update 3a (такой номер был назначен потому, что до конца этого года планируется еще серьезное обновление, это будет уже Update 4).
За подробностями добро пожаловать под кат.

Всем привет! В этом посте я расскажу о том, как доставлять информацию о результатах действий из Veeam Backup & Replication v9.5 в MS Teams. Описанный в посте способ будет работать не только в этом, но и в любом другом мессенджере — потребуется только организовать доставку сообщений, используя профильный API.

Недавно мой коллега Дейв Каула выложил для всеобщего пользования скрипт для установки Veeam Backup & Replication, который он использовал при демонстрации продукта в своей лаборатории. Скрипт может быть полезен тем, кто планирует развертывание решения, например, в тестовой среде или в сценарии «всё на одной машине».

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

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

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

Настоящий админ может спать спокойно лишь тогда, когда у него всё бэкапится, мониторится и дублируется. Или когда он работает в хорошей команде, где всегда можно свалить вину на другого.
Так получилось, что я в своей работе использую в основном продукты Microsoft и могу сказать, что компания серьезно подходит к резервированию своих сервисов: Active Directory, Exchange DAG, SQL Always On, DFSR и т.д. Как и везде, здесь есть как весьма изящные и удачные реализации, так и явно неудобные и тяжелые. Для сервиса печати тоже есть решение, но для него необходима кластеризация на базе Hyper-V. А хотелось простого решения “из коробки”, не требующего дополнительных финансов. За основу была взята Windows 2012 R2, но скорее всего та же схема без проблем будет работать на любых серверных версиях, начиная с Windows 2008, и даже клиентских ОС от Vista и выше (привет любителям экономить бюджет!). Кому интересно — прошу под кат.

В предыдущем нашем посте мы поделились своими измерениями производительности гипервизора после установки патчей против уязвимостей Meltdown и Spectre. Сегодня же пришло время поговорить о производительности хранилища данных.

Недавно мы запустили новый сервис управления политиками резервного копирования клиентов — Veeam Managed Backup. В его основе используется портал Veeam Availability Console. О функциональных возможностях портала Veeam уже рассказывал. Кратко напомню основные:

1. Для клиента – мониторинг заданий и инфраструктуры РК, получение информации по биллингу;
   
2. Для провайдера – управление резервным копированием клиентов: конфигурация, мониторинг и обслуживание.
   

В своей статье я хочу рассказать о том, как работать в портале и настраивать Managed Backup для виртуальных сред. Но сначала кратко о том, чем хорош сервис Veeam Managed Backup. Он позволяет передать на аутсорсинг весь процесс резервного копирования, даже если ресурсы находятся на площадке клиента. В сервисе используется модель лицензирования за ВМ с включенной услугой Veeam Cloud Connect.

Что это означает для клиента? Во-первых – возможность получить дополнительную копию бэкапа своей ВМ в облаке сервис-провайдера без переплаты за лицензии Veeam Cloud Connect. Оплачивается только место на СХД под резервные копии (Cloud Connect Backup) или репликацию (Cloud Connect Replication).  Во-вторых – оплата по факту использования лицензий, то есть гибкость в затратах по сравнению с лицензией типа Perpetual License.

Но вернемся к порталу Veeam Cloud Connect: первый шаг к настройке управляемого резервного копирования — создание учетной записи клиента.

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

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

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

Однако, уже давно существуют инструменты для решения задачи. Главное правильно применить Unix way и командные файлы. И самый простой вариант — заархивировать файлы в один архив и отправить его в онлайн-хранилище, используя командную строку. Для ускорения работы задача делится на 2 этапа — сначала создается и отправляется в онлайн-хранилище полный архив, потом по мере необходимости создаются инкрементные архивы, что дает скорость. Шифрование архивов обеспечивает безопасность данных.

Всем известно, что резервное копирование затевается для того, чтобы можно было восстановить работу системы после сбоя или повреждения данных. Конечно, здесь важна скорость — ведь чем быстрее происходит восстановление, тем меньше простои и убытки для бизнеса. Для ситуаций, когда необходимо максимально быстро возобновить работу виртуальной машины, инженеры Veeam и разработали функциональность мгновенного восстановления Instant VM Recovery. Она весьма популярна среди пользователей, и сегодня мы предлагаем вашему вниманию несколько полезных советов для планирования соответствующей инфраструктуры.

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

В статье «СХД Infortrend — альтернатива А-брендам. Обзор и тестирование» мы описали функционал и производительность одной из самых популярных на тот момент SAN Infortrend — DS 3012T. К преимуществам СХД Infortrend, по итогам прошлой статьи, мы отнесли поддержку классических Enterprise-дисков (не брендированных) и обеспечение работы SATA-дисков в 2-контроллерных системах. Эти факты делают данные системы хранения уникальными, т.к. используя SATA SSD Enterprise, можно построить бюджетную систему хранения с высокими показателями производительности и отказоустойчивости.

В этой статье мы рассмотрим 24-дисковую модель SAN 2000-ой серии, и уделим больше внимания интерфейсу управления Infortrend SANWatch.

Сегодня мы представляем гостевой пост от Илии Карина.

Добрый день, Хабр! Меня зовут Илия Карин (Iliya_karin). Я занимаюсь всеми вопросами в области системноного администрирования в крупной компании более 7 лет. Спасибо коллегам из Veeam за возможность рассказать здесь немного о моем опыте.

Недавно Veeam совместно с PureStorage выпустил плагин интеграции для Veeam Backup & Replication 9.5 с массивами компании PureStorage. И если вы являетесь счастливым обладателем лицензии Veeam Backup & Replication Enterprise Plus, то нет ни одной причины не делать резервные копии инфраструктуры из снапшотов стораджа.

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

С момента публикации трёх прошлых частей я получил несколько отзывов от людей, которые, никогда не пользовавшись linux, по предложенным инструкциям смогли успешно «поднять» свои домашние сервера. Я не собирался делать дополнение по обновлению софта, предполагая, что есть хорошая база, отталкиваясь от которой каждый сможет вполне самостоятельно, при наличии времени и желания, актуализировать свой веб-сервер и облачный движок. Однако, после того как я занялся этим сам, как всегда появились некоторые моменты, освещение которых может помочь новичку сэкономить время. И я решил написать эту «дифференциальную» часть, отступив от принципа «всё в одной статье». Поэтому, в первую очередь, этот материал будет интересен тем, кто достаточно подробно ознакомился с тремя предыдущими статьями и/или положил их в закладки. Использование нового программного обеспечения делает неверными некоторые ранее изложенные инструкции и четвёртая часть будет содержать только обновление подобной информации.

Если изложить кратко, то новый сервер мы строим на Debian 9 вместо 8, SQL меняем на открытую MariaDB, а PHP 5 на более быстрый PHP 7. Движок Nextcloud обновится с версии 11 до 13. Так же я упомяну как немного походим по граблям — сначала вдоль, а потом и поперёк.

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

Предупреждаю сразу — для бэкапа вам потребуется Linux, или хотя бы виртуалка с ним. При наличии рук можно и на Mac OS, и может даже можно на том огрызке, что нынче встроен в Windows — но я ничего не гарантирую.

Поехали!

Чем хороши большие JBOD’ы?

Новый JBOD Western Digital на 102 диска по 12ТБ получился мощным. При разработке этого JBOD были учтены предыдущий опыт с двумя поколениями 60-дисковых полок.
Data102 получился на редкость для таких гигантов сбалансированным по объему и производительности.

Зачем же нужны такие большие дисковые корзины, когда в мире растет популярность гиперконвергентных систем?

Что-то давненько мы не писали про наш флагманский продукт. Исправляемся, тем более что подоспела еще одна порция полезных советов от ребят из Veeam Support Team. Сегодня с вами снова мой коллега Евгений Иванов, теперь уже из Бухареста, куда он был призван в качестве наставника для румынской команды технической поддержки.

В ходе своей работы Евгений со товарищи собрали приличную коллекцию «граблей», на которые чаще всего наступают начинающие пользователи при развертывании и настройке Veeam Backup & Replication. А чтобы вы не повторяли их ошибок, Женя разъясняет, как всё сделать правильно.
Итак, добро пожаловать под кат.

Несколько лет назад, при выборе первого хранилища для дома, я смотрел в сторону «коробочных решений» по причине не особой осведомлённости в построении системы хранения на базе открытого ПО и обычного ПК. В тот раз выбор пал на 2-дисковую NAS — Shuttle KD20. Хранилище было компактным и тихим. RAID1 обеспечивал необходимую надёжность, а потребности в высокой производительности и расширенном функционале на тот момент не было. Этот NAS проработал почти 4 года, пока в один прекрасный момент не накрылась линия питания вентилятора. Диски раскалились до 60 градусов и чудом выжили. Я запаял вентилятор напрямую к материнке, но стал подбирать вариант на замену. В качестве второй NAS я выбрал 4-дисковую Synology. Задачи оставались те же, поэтому в функционал DiskStation Manager (DSM) я особо не вникал. Это продолжалось до тех пор, пока я не решил установить домашнее видеонаблюдение на несколько каналов. Не смотря на то, что Synology имеет собственный сервис видеонаблюдения, я остановился на Macroscop — была потребность в расширенном функционале и серьёзной аналитике. На своё счастье, я обнаружил в DSM новый пакет Virtual Machine Manager — гипервизор, с помощью которого я создал виртуальную машину и установил на неё Windows и Macroscop. На запись система работала нормально, встроенный Pentium 1,6 ГГц с трудом, но успевал отрабатывать задачи СХД и виртуальной машины. Но как только активировалась какая-либо аналитика — сервис отваливался по перегрузке процессора. В результате, я был вынужден начать поиски отдельного бюджетного Windows-девайcа с адекватной производительностью для реализации сервера видеонаблюдения, так как Synology необходимого уровня стоит недёшево. В тот самый момент я в очередной раз наткнулся в сети на статьи, посвящённые установке DSM на обычное железо и мой проект XPenology начался…

Продолжение истории о похождениях отдельной задачи в ISPsystem. Рассказывает руководитель разработки Александр Брюханов. Первая часть здесь.



Лучшее — враг хорошего

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

«Незнание не освобождает…» или почему Ransomware продолжает процветать

Привет, Хабр! Сегодня мы хотим рассказать о результатах любопытного опроса, который компания Acronis провела в сети в марте 2018 года. Оказалось, что злоумышленники, делающие ставку на Ransomware, поступают логично – абсолютное большинство не готовы к таким нападениям и объем ущерба продолжает расти.



Под катом – подробная информация и статистика, а также результаты опроса.

История о том, как в ISPsystem разрабатывали решение для резервного копирования. Рассказывает руководитель разработки Александр Брюханов.



Все пользователи делятся на три группы:
те кто не делает бэкапы,
те, кто их уже делает,
и те, кто проверяет сделанные.

Кого-то мой рассказ просто повеселит, а кто-то в нем узнает себя. Это история про то, как оно было в ISPsystem 15 лет назад, как и почему менялось, к чему пришло. В первой части расскажу, как мы начали разрабатывать решение для бэкапов виртуальных серверов.

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

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

Чтобы помочь организациям справиться с этими проблемами, компания Veeam недавно выпустила новое решение Veeam Availability Orchestrator для автоматизации управления работы с репликами ВМ при переключении на резервную площадку. (Первая версия решения поддерживает виртуальные машины на платформе VMware vSphere.) Подробнее о новинке читайте под катом.