(Проблема, по всей видимости, чрезвычайно экзотическая, но в плане «как оно внутри устроено» достаточно познавательная.)

Вот, допустим, работает у вас приложение, написанное на Эрланге (ну, скажем, тот же ejabberd). Давно работает, хорошо работает, но в один прекрасный день вы пытаетесь запустить управляющий скрипт (ejabberdctl, соответственно), а он вам выдает «nodedown» или еще что-нибудь страшное в этом духе, мол, не отзывается никто. При этом само приложение прекрасно отзывается на все клиентские запросы и слыхом не слыхивало о том, что оно down. По внезапному наитию вы запускаете epmd -names и — о, ужас! — получаете пустой список.

Программы на Эрланге используют для связи между собой нотацию node@host, физически же каждый узел (читай — системный процесс) открывает для этого случайный высокий порт. Задача сервиса epmd — связать между собой логическую адресацию по имени и физическую адресацию по номеру порта. Своего рода аналог DNS, с той разницей, что без реестра epmd кластер на Эрланге разваливается на кучку отдельных глухонемых узлов — что у нас только что по какой-то загадочной причине и произошло. Можно, конечно, начать искать виновных, но сначала все-таки неплохо бы поднять систему на место.

Что в такой ситуации делать? Можно, конечно, просто насильно перезапустить приложение, но, с одной стороны, клиенты отвалятся, с другой, такой красивый uptime жалко… Вот если б можно было как-нибудь восстановить реестр на живой системе, а?..

0. Intro.

Ситуация следующая. Есть винт на 160Гб. На нем 2 раздела — 40Гб и 120Гб. С целью установки убунты как второй системы была произведена разбивка 120Гб -> 100+10+2+8.

Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.

Итоги

1. При загрузке системы выводится сообщение MBR helper not found;
2. fdisk показывает один большой 160Гб диск.

Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.

Практически любой начинающий Cisco-вод рано или поздно оказывается в ситуации, когда на руках имеется маршрутизатор с напрочь забытым или неизвестным, чужим паролем. Лично я, будучи преподавателем курсов Cisco, встречаюсь с этой ситуацией очень часто после лабораторных работ. Ученики строят топологию, настраивают пароли на доступ, играются с сеткой и… забывают стереть файл конфигурации перед уходом. Само собой, до следующей лабораторной работы все успешно забывают свои пароли. По непонятной мне причине, Cisco не уделяет этой теме достаточно внимание в своём учебном материале, а документация на офф-сайте зачастую пугает новичков. Этот недостаток я и хотел бы сегодня устранить.

TWRP это загрузчик recovery mode (режима восстановления). Этот режим используется для создания резервных копий вашего устройства или восстановления из резервной копии.

Начну с сути идеи — куча одинаковых компов, на них требуется установить ОС Windows XP с одинаковым набором программ. Первая мысль — настроить один эталонный компьютер, снять с него образ жесткого диска и развернуть на остальных компьютерах.

Acronis не подходил по «религиозным соображениям» компании.

Поискав DIY решение, наткнулся на замечательную вещь ntfsclone из пакета ntfsprogs.

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

Не секрет, что в AD есть операции которые возлагаются лишь на один домен-контроллер в лесу, именуемый мастером операции. Например в AD только один контроллер назначается первичным хранителем схемы каталога.

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

За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.

OfficeRecovery начинает серию публикаций о восстановлении поврежденных данных. Вашему вниманию предлагается видео, демонстрирующее лечение испорченных файлов посредством веб-браузера в системе OfficeRecovery Online. Видео снабжено русскими субтитрами.

В качестве примера взят поврежденный файл Word. Аналогичным способом на сайте можно починить файлы десятков других типов: Microsoft Office, PDF, графику и многие другие.



Желающие попробовать сайт в действии могут до 1 октября воспользоваться кодом OFFICERECOVERY*HABR на странице просмотра демо-результатов, появляющейся в процессе восстановления:
https://online.officerecovery.com/ru/

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

Есть два способа такого гранулярного восстановления, когда полный откат системы не производится: "универсальное" (не зависящее от конкретного приложения, осуществляемое через восстановление всей системы в тестовую лабораторию или «песочницу») и "специализированное" (разработанное для конкретного приложения, позволяющее извлечь объекты данных конкретного приложения прямо из файла(-ов) данных приложения без необходимости запуска приложения (со всеми зависимыми компонентами) в «песочнице»).

Состоялся выпуск новой версии Veeam Backup & Replication 6.5 для VMware и Hyper-V. Версия содержит более 50 усовершенствований, большая часть которых вошла и в бесплатную версию продукта. Наиболее интересные и важные среди них:

• E-Discovery и гранулярное восстановление объектов Exchange сервера
• Восстановление из снимков дисков HP SAN
• Поддержка vSphere 5.1 и Windows Server 2012 Hyper-V
• Обеспечение корректности IP пакетов соединений при передаче резервных копий через WAN

Рассмотрим их подробнее:

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

Предыстория

Переустановил ОС Win7, установил skype (6-й), привычно скопировал всю папку профиля из старого:
%AppData%\Roaming\Skype\мой_профиль\
в новое место.

Запускаю скайп и вдруг он виснет на автовходе. После повторного запуска вижу приглашение войти. Вхожу — все контакты на месте, а сообщений — практически нигде нет. Только в некоторых групповых чатах сохранились. Вся личная переписка, коей скопилось немало — исчезла. Проделал N(^k) попыток копировать базу данных, удаляя файлы блокировок, is-corrupt и прочие. Скайп ругается, что с базой проблемы, затем просит перезайти — после чего сообщений нет.
Погуглив, нашел хабро-посты про экспорт сообщений, угон аккаунтов и т.п. Ага, значит sqlite! Это обнадёживает.

В ходе проведения презентаций о бэкапах и восстановлении баз данных SQL Server, обычно задаются два типа вопросов. Первые задаются прямо по ходу презентации из зала, вторые задаются уже после, в приватной беседе. Эти, «приватные» вопросы, зачастую более интересны и я попробую дать ответы на наиболее сложные и интересные из них, вместо того чтобы писать ещё одну статью о том как вы должны делать бэкапы, или почему вы должны делать бэкапы, или даже почему вы должны проверять свои бэкапы (но вы и вправду должны проверять свои бэкапы).

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

1. Взаимосвязь процедур обновлений продуктивной системы и процесса ее резервного копирования
2. Тестирование восстановления из резервных копий
3. Взаимодействие бэкап-процесса с элементами сетевой инфраструктуры продуктивной сети
4. Документирование процедуры восстановления после сбоев

Новость одним абзацем: rescue initrd (специальный комплект из ядра и initrd) теперь автоматически конфигурируется на ipv4/ipv6 адреса, назначенные облачному серверу и автоматически же запускает ssh-сервер после загрузки.

Как это устроено?

Обычно загрузка виртуальной машины выглядит так: с загрузочного диска виртуальной машины (с его загрузочного раздела) читается grub.cfg/grub.lst, из него выбирается ядро и initrd. Domain builder (специальное приложение, которое создаёт домен при старте виртуальной машины, кладёт туда ядро/initrd, фомирует start page с настройками и добавляет памяти) это ядро загружает и запускает домен.

Дальше ядро уже загружается как в обычном сервере — запускается скрипт инициализации в initrd, который подготавливает корневую файловую систему, делает туда pivot_root (переключение корневого каталога) и запускается уже настоящий init, который читает inittab, запускает систему инициализации system-v или upstart, systemd, кому уж что больше нравится.

В новой версии Veeam Backup & Replication v7, которая будет выпущена уже через пару месяцев, будет встроен WAN акселератор, специально оптимизированный под передачу резервных копий через WAN. Когда вы делаете копирование бэкап файлов за пределы офиса, вы значительно увеличиваете надежность системы хранения данных, однако одновременно сильно увеличиваете нагрузку на свой WAN канал, что выражается, прежде всего, в значительном увеличении времени резервного копирования. WAN акселератор позволяет эффективнее передавать данные даже через медленные соединения за счет применения следующих алгоритмов работы:

1. передача только измененных данных (все данные разделяются на блоки, и через WAN передаются только измененные блоки)
2. глобальный кеш блоков данных (то есть кеш, охватывающий все имеющиеся виртуальные машины), позволяет передавать хеши ранее переданных блоков, вместо данных самих блоков
3. сжатие сетевого трафика и дедубликация данных с переменной длиной блока
4. мультипоточные параллельные TCP/IP соединения для увеличения скорости передачи данных и другие TCP/IP оптимизации под соединения с большим временем отклика, характерным для WAN сетей
5. автоматическое возобновление прерванных соединений

Одним из главных приоритетов современного резервного копирования, особенно в системах 24x7, является минимизация воздействия на производительность продуктивной сети. Хорошим вариантом решения, отвечающего этому приоритету, является создание дисковых снапшотов СХД на аппаратном уровне, так как оно не требуют вовлечения в этот процесс гипервизора, а алгоритм создания самих снапшотов оптимизирован разработчиками СХД на уровне аппаратуры.

NetApp — компания, относящаяся к лидерам на рынке СХД, обладает одной из самых передовых технологий в области дисковых снапшотов. Эта технология позволяет NetApp предоставлять пользователям своих СХД эффективную, экономичную по ресурсам хранения и, в общем случае, незначительно влияющую на производительность продуктивной системы технологию защиты данных от сбоев. Особая сила NetApp всегда заключалась в программной части СХД — операционной системе ONTAP, которая предлагает пользователям полнофункциональную платформу хранения данных, а также в технологии создания снапшотов, на которой базируются хорошо масштабируемые технологии защиты данных, такие как SnapMirror (репликация между NetApp СХД) и SnapVault (резервное копирование данных).

Это здорово, когда у системного администратора есть время освоить и попробовать все сценарии восстановления Active Directory с помощью средств самой операционной системы. Однако в большинстве случаев этого лишнего времени нет и нужно решение, а не набор статей в msdn и нагугленных скриптов.

Какой же программный продукт выбрать для восстановления Aсtive Directory?

Для ответа на этот вопрос нужно сначала определиться со списком сценариев для восстановления.

Как можно догадаться из названия продукта, столпами реализуемой в Veeam Backup & Replication стратегии защиты данных являются «2-в-1»: резервное копирование и репликация, реализованные в рамках одного продукта.

Достоинством механизма резервных копий является возможность отката на различные точки восстановления в прошлом, механизм же репликации позволяет получить минимальный показатель времени восстановления системы после сбоя — этим она особенно ценна для современных ЦОД. Сегодня я расскажу о новых возможностях репликации, которые увидят свет с выходом (уже в ноябре!) новой версии Veeam Backup & Replication 8.0.

Предыстория

Несколько недель назад я стал обладателем ноутбука HP Pavilion p170nr c предустановленной Windows 8.1. Поскольку я заядлый линуксоид — было решено устанавливать основной, рабочей системой Ubuntu, но и оставить Windows для игрушек и чего-нибудь капризного, вроде обновления биос. Жадность тоже сыграла свою роль — за 8-ку то, по сути, деньги заплачены.

Подождите, подождите. Я же не написал в заголовке «Как обойтись без резервного копирования». Обойтись без резервного копирования нельзя, об этом знает любой первокурсник. А вот навсегда забыть о резервном копировании — это, пожалуй, мечта любого ИТ-менеджера. Но мечта эта до сих пор казалась несбыточной. Потому что даже если на вашем предприятии прекрасно налажено резервное копирование, вы вспомните о нем сразу после большого отказа, и далеко не добрым словом. Вы скажете не что-нибудь вроде «Как же здорово, что у нас каждую ночь работает бэкап», а скорее: «Сколько часов прошло после бэкапа?»

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