Продолжаем серию публикаций о возможностях бэкапирования с помощью Bareos. В этой статье пойдет речь о резервном копировании VM ESXi средствами Bareos.

Предыдущие посты: «Бэкап с помощью Open Source решения — Bareos»

Для резервного копирования виртуальных машин VMware ESXi зачастую применяют такие средства как Veeam или же скрипт ghettovcb. В этой статье мы рассмотрим способ резервного копирования виртуальной машины средствами Bareos 16.2, а именно будем использовать один из плагинов позволяющего расширить функционал Bareos — vmware-plugin. В 16-й версии изменено расположение конфигурационных файлов, теперь каждый ресурс (pool, client, job и т.д.) распределены по своим директориям, добавлена мультиязычность для web UI, улучшена работа плагина MySQL, более подробную документацию можно просмотреть тут.

Только что вышла новая версия Veeam Availability Suite 9.5 — комплексного решения для резервного копирования и восстановления данных после сбоев. Сегодня вашему вниманию предлагается краткий обзор новых возможностей Veeam Backup & Replication в этой версии:

• Поддержка Windows Server 2016, Hyper-V 2016 и последних серверных приложений на этой платформе
• Повышение производительности Veeam Backup & Replication
• Улучшения в области резервного копирования данных
• Улучшения в области восстановления данных
• Улучшения в области работы с магнитными лентами
• Улучшения в области работы с СХД
• Улучшения в работе с облачными инфраструктурами
• Новое в поддержке приложений

Рассмотрим эти новинки более подробно, для чего добро пожаловать под кат.

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


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

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

Существует два стандартных решения данной ситуации:

1. Анализ журналов (если таковые ведутся), чтобы из них понять что было изменено.
2. Восстановление данных из резервной копии.

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

Поэтому мне хотелось бы предложить простой и эффективный способ с использованием дополнительного инструмента.

Приличный блог в наше время – почти необходимость для всякого работника интеллектуального труда, коих принято непочтительно именовать «креаклами». Если вы хипстер, креативный дизайнер, самозанятый фотограф-бомбила и так далее, то одним фейсбуком вы точно не отделаетесь; нужен собственный сайт, а на сайте собственный блог, где вы выкладываете по вечерам своё крео и селфи, как вы там сидите в «Жан-Жаке» после трудового дня, все такие в клетчатых лосинах и со стаканом сельдереевого смузи. Потеряете пару записей – и всё, плакал креатив, прощай, настроение!

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

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

В предыдущей статье из этой серии рассказывалось о процедуре бэкапе физических и виртуальных контроллеров домена (DC). Сегодня поговорим об их восстановлении.
Сразу скажу, что этот пост не является руководством по восстановлению Active Directory. Его задача — рассказать о том, что необходимо учитывать при восстановлении AD или конкретного контроллера домена из резервной копии, а также показать, как можно выполнить эти действия с помощью решений Veeam.

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

Бэкапы нужно иметь. Желательно, в нескольких местах.

Я думаю, что каждый администратор Veeam Backup & Replication замечал в консоли управления кнопку «Add Service Provider». На Хабре есть несколько хороших статей, которые демонстрируют, как использовать эту кнопку по назначению и как начать складывать бэкапы Veeam не только у себя, но и в облако, предоставленное сервис-провайдером.

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

Как-то появилось у меня несколько персональных проектов, которые требовали относительно много дискового места — около 2TB. Подходящих VPS не нашлось (мало кто предлагает много HDD места), поэтому я взял выделенный сервер у OVH, поставил там ESXI 5.5 с бесплатной лицензией и всё работало.

Через некоторое время, с развитем проектов, я стал настраивать админские фишки — мониторинг, бэкап, и выяснил, что оказывается сервер, в котором мне обещали Soft RAID, и на который хостер (OVH) накатил свой образ ESXI — без RAID! То есть просто 2 диска. Ну да, теперь вот я знаю, что ESXI не поддерживает Soft RAID, только Hard. Стало неуютно. Да и 2TB стало не хватать. В общем взял я себе сервер побольше, с аппаратным RAID и поставил туда ESXI 6.0.

И возникло две задачи, решение которых я тут опишу:

1. Перенести виртуальные машины (некоторые из которых около 1TB) с одного сервера на другой с минимальным оффлайном
2. Делать регулярные бэкапы

Скажу сразу, что обе эти задачи легко решаются, если есть хотя бы минимальная платная лицензия ESXI. Дело в том, что «родной» Backup API в бесплатной версии ESXI выключен. Поэтому приходится находить другие пути.

С платной лицензией есть вариант миграции через vCenter. Ещё есть бесплатная версия Veeam Backup, которая позволяет делать бэкапы и переносить виртуальные машины с одной системы на другую и при этом не требуется их останавливать. Но с бесплатной лицензией ESXI, текущая версия — Veeam 9 — не работает вообще.

Бэкапы нужно проверять.

В качестве вступления простая история из бурной молодости. Всем знакома ситуация, когда ресурсов нет, а хранить резервные копии нужно. В свое время для хранения резервных копий своих систем, использовалось два диска объемом по 500GB. Как можно было догадаться, при использовании RAID-1, полезное пространство ограничивалось теми самыми 500GB, чего катастрофически не хватало. Было принято решение использовать Linux LVM, тем самым получить 1000GB пространства, в ущерб надежности.

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

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

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

Тем, кому интересно как Veeam проверяет свои резервные копии, прошу под кат.

Все большее число пользователей переходит на Microsoft Office 365, и, естественно, желает быть уверенным в сохранности данных при работе с облачным решением. На первый взгляд кажется, что если письма лежат в облаке, то они автоматически надежно защищены от сбоев и потерь, однако по факту это не так. На самом деле вам предоставляется отказоустойчивость почтового сервера, но не резервное копирование писем. Ведь если, например, вирус, запустившийся на стороне пользователя, зашифрует письма в облаке, то восстановить их просто так не получится. Поэтому мы и решили сделать продукт, который бы позволял хранить резервные копии писем локально. Инструмент же для восстановления содержимого почтовых ящиков уже имелся в наличии – это Veeam Explorer for Microsoft Exchange, который успешно прошёл проверку временем.

Итак, сегодня я представляю вам новый Veeam Backup for Microsoft Office 365, который планируется к выпуску в 4м квартале этого года.
UPD: Релиз состоялся 29 ноября, почитать описание на русском языке и скачать пробную версию можно тут.

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

Сергей Бурладян (Avito)

Всем привет, меня зовут Сергей Бурладян, я работаю в «Avito» администратором баз данных. Я работаю с такими системами:



Это наша центральная база 2 Тб, 4 сервера — 1 мастер, 3 standby. Еще у нас есть логическая репликация на основе londiste (это из Skytools), внешний индекс sphinx’а, различные выгрузки во внешние системы — такая, как DWH, допустим. Еще у нас есть собственные наработки в области удаленного вызова процедуры, xrpc так называемая. Хранилище на 16 баз. И еще такая цифра, что наш бэкап занимает 6 часов, а его восстановление — около 12-ти. Мне хотелось бы, чтобы в случае различных аварий этих систем простой нашего сайта занимал не более 10-ти минут.

Пришло время рассмотреть все мифы и узнать где правда в вопросах дедупликации для массивов данных.



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

У нас недавно был праздник — вышел в релиз True Image 2017, над которым мы работали целый год. Изменений очень много, но первое, что бросается в глаза, – это «казуальный» минималистичный дизайн. Если наши первые релизы были инструментами продвинутых пользователей и сисадминов, то последние несколько лет мировая популярность продукта такова, что бэкапят им очень и очень разные люди. В том числе те, кто не особо отличает монитор от системного блока.

Поэтому наш подход – сохранить весь старый добрый хардкор, гибкость настроек и множество нетривиальных инструментов, но сделать упор на упрощение интерфейса.


Все настройки на месте

Ещё в этом релизе мы научились делать локальный бэкап iOS и Android на ваш десктоп, бэкапить профиль Facebook (спасибо пользователю Маша Ведро), поработали с архитектурой архива и так далее. Расскажу про основные фичи и сложности в их разработке.

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

Файловая система Resilient File System (ReFS) является рекомендованной для Windows Server 2016, и ее новыми возможностями не преминули воспользоваться наши разработчики. Чему же было уделено особое внимание в новой версии Veeam Backup & Replication, и каковы результаты? Весьма положительны: применение ReFS в репозиториях резервных копий существенно повышает надежность хранения данных, значительно ускоряет операции по-блочного слияния инкрементов на СХД, а также позволяет хранить больше точек восстановления — за счет использования ссылок на идентичные блоки данных.

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

Данная статья предназначена конечно не для админов, а скорее для веб-разработчиков, у которых на сервере неспешно наполняется БД небольшого объема. И вроде бы данные туда так и поступают — неспешно и небольшие, и ничто не предвещает беды, но все равно как-то не по себе. А вдруг завтра случится микроколлапс внутри данного конкретного сервера или данной конкретной хостинг-компании. И везде мерещатся злые хакеры и боты.

В общем, чтобы спать спокойно, нужно обеспечить периодическое сохранение содержимого БД вне рабочего сервера на случай, если по каким-то причинам доступ к содержимому сервера будет утерян. Для тех, кто (как и я) не дорос еще до репликаций БД на отдельных серверах, мой ответ — отправляйте дампы по почте.

Microsoft Active Directory является стандартом в инфраструктуре, где требуется аутентификация пользователей и централизованное управление. Почти невозможно представить себе, как системные администраторы справлялись бы со своей работой без этой технологии. Однако использование Active Directory не только приносит большую пользу, но и налагает большую ответственность, требуя значительного времени и понимания процессов работы. Поэтому я предлагаю вашему вниманию несколько cтатей, которые расскажут, как успешно выполнять бэкап и восстановление Active Directory с помощью решений Veeam. В частности, я поясню, как Veeam помогает делать копии контроллеров домена (DC) или отдельных объектов AD и при необходимости восстановить их.

А начну я с того, что в сегодняшнем посте расскажу о возможностях бэкапа физических и виртуальных контроллеров домена, предоставляемых Veeam, и о том, что необходимо помнить во время бэкапа. За подробностями — под кат.

Очередная приятная новость от команды разработчиков Microsoft Azure. Если кто-то из читателей, кто уже использует сервис резервного копирования в Azure ARM портале, то они могли заметить, что управление политиками резервного копирования чрезвычайно затруднено. Действительно, вам давалась возможность выбора существующей или создания новой политики, только при добавлении нового сервера в Recovery Services Vault.


Теперь все изменилось. Буквально сегодня команда Microsoft Azure добавила функцию работы с политиками резервного копирования в отдельную оснастку портала Azure Resource Manager.

Будь я работником макаронной фабрики, то сейчас ломал бы голову над тем, куда девать этак 500 упаковок макарон по полкило штука. К счастью, когда начальство решает премировать сисадмина “натурой”, получение в подарок фургона сухого пайка не грозит, хотя имеются неплохие шансы стать обладателем нескольких десятков килограмм откровенного лома. Однако в этот раз мне повезло – в качестве корпоративного подарка я получил пару новеньких WD Re 2004FBYZ на 2 терабайта каждый, и блок питания Thermaltake Smart DPS G 750W. Вот только что делать с дисками? Ставить в домашний комп – слишком расточительно даже для меня, все-таки Enterprise Class, да и нужды особой нет. Куда практичнее на их основе собрать NAS. Разумеется, не какую-нибудь файлопомойку, а высоконадежное хранилище – эдакий “черный ящик” для критически важных данных. Плюс к этому, можно совместить приятное с полезным – раз уж принято решение целиком перевести инфраструктуру на “умные” БП (а именно так Thermaltake позиционирует линейку Smart DPS), неплохо бы воочию увидеть, как это работает.

Но есть одна загвоздка – на данный момент фирменное приложение существует только под Windows. Для корпоративного ЦОДа эта операционная система хороша, но для домашнего файлового хранилища ужасна и крайне нерентабельна. Посему, я решил сделать два поста. В этом мы поднимем NAS на основе Windows Server 2008 r2 (убедившись, что “окошки” и “домашний NAS” – понятия несовместимые), и посмотрим, на что способна DPS G App 2.0. Во втором же соберем бюджетный NAS на основе NAS4Free, создав по-настоящему надежную систему.

В нашем предыдущем посте Microsoft Azure StorSimple: простой доступ к гибридному облаку. Часть 1 мы рассказали вам, почему Microsoft StorSimple является оптимальным решением для тех, кто только начинает работу с гибридным облачным хранилищем. Компании, заключившие соглашения Enterprise Agreement с возможностью использования Microsoft Azure, смогли получить доступ к виртуальной версии уже в марте: виртуальный массив Microsoft StorSimple. Его также можно использовать в среде VMware и Hyper-V. Мы предлагаем вам небольшой экскурс из серии вопрос-ответ по данному решению.

Для кого виртуальный массив StorSimple станет идеальным решением?

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

Его преимущества очевидны. Данное решение является:

• адаптивным
• экономически выгодным
• чрезвычайно гибким
• легким в управлении

А также:

• предоставляет ряд ключевых характеристик и вариантов применения, включая работу в облачной среде Microsoft Azure.