При перераспределении разделов жесткого диска на ноутбуке, я, по невнимательности, совсем не оставил свободного места под раздел с файловой системой NTFS. Система на тот момент стояла Linux Mint 18, хотя, по сути, это не имеет значения. После перераспределения места, я ужаснулся. При попытке примонтировать этот раздел, мне выдавало ошибку:

Проводим проверку работоспособности плана восстановления после аварии.



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

У большинства предприятий есть (ну, или хотя бы должен быть) план восстановления после аварии. Аналогичный план должен быть у оператора дата-центра. Любой из подобных объектов подвержен влиянию внешних факторов — полностью исключить вариант аварии нельзя. Даже, казалось бы, самые защищенные объекты могут все же попасть в очень неприятную ситуацию, о чем мы как-то уже писали.

Соответственно, DRP-план (disaster-recovery plan) должен помочь компании быстро выйти на предшествующий аварии рабочий уровень. Обычно в таком плане описываются действия сотрудников в случае аварии. При составлении такого плана цель обычно — сведение к минимуму последствий аварии с обеспечением возможности вернуть контроль над решением критически важных задач, используя заранее определенные ресурсы. Но план — планом, а будет ли он работать? Для проверки этого стоит провести «учебную тревогу».

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


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

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

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

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

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

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

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

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

В статье содержатся 5 вопросов и ответов по следующим темам:

1. Очистка mbr флешки в Windows
2. Конвертирование ISO-файла в гибридный ISO-файл (только Linux)
3. Создание загрузочной флешки с сохранением изменений (Linux, Windows, Mac OS X)
4. Создание мультизагрузочной флешки (Windows)
5. Восстановление таблицы разделов и загрузчика mbr (Hiren's BootCD).

Продолжаем публикацию серии статей, написанных коллегой для корпоративного блога и посвященных резервному копированию и восстановлению контроллеров домена и собственно 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 — не работает вообще.

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

У компании Hewlett Packard Enterprise флагманским решением для резервного копирования является HPE Data Protector. Этот продукт имеет солидную, почти 30-летнюю историю. Разработанный компанией Apollo в 1987 году под названием Omniback Network Backup System, после вхождения Apollo в состав Hewlett-Packard в 1989-м, он долгое время развивался и в 2002 году получил новое название ― HP Data Protector. Несмотря на почтенный возраст продукта, компания HP, а сейчас ― Hewlett Packard Enterprise, постоянно работает над его совершенствованием, отражая в нем все технологические изменения, происходящие в мире программного обеспечения и в ИТ-индустрии в целом.



Вкратце расскажем об основных возможностях Data Protector, сделав акцент на наиболее важных и полезных нововведениях, реализованных разработчиками в последние годы.

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

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

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

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

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

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

Яндекс, как и любая другая большая интернет-компания, хранит много, а точнее очень много данных. Это и пользовательские данные из разных сервисов, и намайненные сайты, и промежуточные данные для расчёта погоды, и резервные копии баз данных. Стоимость хранения ($/ГБ) — один из важных показателей системы. В этой статье я хочу рассказать вам про один из методов, который позволил нам серьезно удешевить хранилище.

В 2015 году, как вы все помните, сильно вырос курс доллара. Точнее, расти-то он начал в конце 2014-го, но новые партии железа мы заказывали уже в 2015-м. Яндекс зарабатывает в рублях, и поэтому вместе с курсом выросла и стоимость железа для нас. Это заставило нас в очередной раз подумать о том, как сделать, чтобы в текущий кластер можно было положить больше данных. Мы такое, конечно, делаем регулярно, но в этот раз мотивация была особенно сильной.

Каждый сервер кластера предоставляет для нас следующие ресурсы: процессор, оперативную память, жёсткие диски и сеть. Сеть здесь — более сложное понятие, чем просто сетевая плата. Это ещё и вся инфраструктура внутри дата-центра, и связность между разными дата-центрами и точками обмена трафиком. В кластере для обеспечения надёжности применялась репликация, и суммарный объём кластера определялся исключительно через суммарную ёмкость жёстких дисков. Нужно было придумать, как обменять оставшиеся ресурсы на увеличение места. Кстати, если после поста у вас останутся вопросы, которые бы вы хотели обсудить лично, приходите на нашу встречу.

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

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

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

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

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

А также:

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

» Работаем с гибридным облаком: VMware vCloud Connector, часть 1
» Работаем с гибридным облаком: VMware vCloud Connector, часть 2

В первых двух частях мы посмотрели, как построить гибридное облако с помощью VMware vCloud Connector. Сегодня поговорим об авариях и о том, как с помощью ресурсов облачного провайдера восстанавливать “упавшую” внутреннюю инфраструктуру. Разбирать тему будем на примере Veeam Cloud Connect Replication — инструмента, помогающего настраивать репликацию виртуальных машин и запускать реплики в облаке сервис-провайдера.

Для опытов нам понадобятся: своя виртуальная инфраструктура и внешние облачные ресурсы на базе VMware, Veeam Backup and Replication не ниже версии 9.

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

• Новые возможности Veeam Backup & Replication v 9.5
• Veeam Agent for Windows (ранее – Veeam Endpoint Backup) и Veeam Agent for Linux
• Консоль Veeam Availability Console
• Новинка: Veeam Backup for Office 365
• Новинка: Veeam Availability Orchestrator
• Платформа Veeam Availability Platform for the Hybrid Cloud
• И немного о версии Veeam Backup & Replication v10

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