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

С выходом Veeam Backup & Replication v8 пользователи принялись тщательно изучать новые функциональные возможности продукта. А поскольку «на вкус и цвет товарища нет», то каждый находит какие-то милые сердцу фичи лично для себя, причем это могут быть совсем скромные, «но оч-чень полезные подарки», то есть новые опции, которые сразу не бросаются в глаза, но над которыми кропотливо трудились разработчики. Так подобралась «великолепная восьмерка», может быть, не слишком нашумевших, но весьма полезных фич Veeam Backup & Replication v8. Мой сегодняшний рассказ про аутентификацию с использованием сертификата при доступе к гостевой ОС виртуальных машин под управлением Linux.

После прочтения статьи «Фривольное клонирование ОС MS Windows XP / Server 2003 своими руками, средствами GNU/Linux» возникло естественное желание дополнить ее в соответствии с реалиями конца 2014 года.

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

MBR, таблица разделов и сигнатура диска

Начнем с копирования данных. Какие же данные нам нужно скопировать? Для Windows XP это MBR (446 байт в начале диска, основная таблица разделов и завершающая сигнатура 55AAh), данные о расширенных разделах и собственно данные системного раздела Windows. Для Vista и Windows 7 добавляется еще и 100-мегабайтный системный раздел (GPT не рассматриваем). При этом нужно помнить, что первый раздел в Windows XP по-умолчанию начинается с сектора 63, а в Windows Vista/7 — с сектора 2048. Естественно, все операции мы будем проводить на незапущенной Windows, загрузившись с System Resque CD.

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

А вот появилось обновление — два новеньких SSD, было решено во время переноса системы заодно перейти на btrfs.
Всё отлично — RAID0 для данных RAID1 для метаданных средствами файловой системы, сжатие на лету, корень в одном суб-томе (subvolume), домашняя папка в другом, веб-сайты в третьем. Всё это грузится прямо с UEFI в Linux EFI stub без GRUB и других загрузчиков, работает быстро и удобно.
И вот дошло дело до снимков (snapshot), их я хотел использовать для резервных копий суб-томов средствами всё того же драйвера btrfs.

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

Решение принято — новому инструменту быть!

Введение

Это краткая пошаговая инструкция для начинающих: как изменить уже работающую систему резервного копирования на базе Bacula. Такая работа поможет Вам понять взаимосвязи элементов конфигурации bacula.

В современных дистрибутивах GNU/Linux установленная из пакетов Bacula нередко уже настроена для резервного копирования конфигурации ОС. Если у Вас bacula не настроена предварительно, возьмите полное руководство (см. «Литература»).

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

Разбираемся под катом.

В одном из наших предыдущих постов “Оптимальная архитектура хранения резервных копий виртуальной инфраструктуры” мы уже говорили о базовых принципах организации хранения резервных копий виртуальной среды. Продолжая тему, публикуем обзор специализированной СХД с дедупликацией данных ExaGrid EX21000E, предназначенной как раз для хранения копий. Один из плюсов хранилища в том, что оно работает практически с любым ПО для бэкапов. На фоне конкурентов с диаметрально противоположным подходом, ExaGrid явно выделяется демократичностью в вопросах совместимости и глубокой интеграцией со сторонним ПО.

Всегда приятно, когда привычное ПО запускается с новой железкой, и нет необходимости приобретать нечто «особенное», а потом тратить время на дополнительные настройки. Коллеги из StorageReview решили проверить, насколько этот тезис применим к Veeam Backup & Replication и ExaGrid EX21000E. А мы, в свою очередь, предлагаем вам познакомиться с новым хранилищем от ExaGrid в нашем переводе. Добро пожаловать за подробностями и выводами под кат.

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

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

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

С 6 по 8 октября в Лас-Вегасе (США) прошла первая международная конференция Veeam по вопросам резервного копирования и защиты данных в виртуальных средах – VeeamON (анонс на Хабре), собравшая около 1200 гостей из более чем 50 стран.

Забегая вперед, скажу, что первый опыт оказался весьма удачным и уже на 100% известно, что VeeamON станет ежегодным событием.

В этом году на конференции анонсировали выпуск двух новых продуктов, одним из которых стал уже известный аудитории GT и Хабра Veeam Availability Suite v8. Вторая новинка носит «взрывной» характер – это Veeam Endpoint Backup FREE, бесплатный инструмент для резервного копирования данных физических машин – ноутбуков и настольных ПК – на базе ОС Windows.

Чем еще запомнится первая конференция для администраторов виртуальных инфраструктур? Пока свежи воспоминания, и не отпускает джетлаг (11-часовая разница во времени все-таки не шутка), проведу для вас репортаж с места событий и постараюсь передать атмосферу мероприятия.

Следуй за белым кроликом!

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

Уже прошло больше недели с того момента, как в городе греха Лас-Вегасе закончилась трёхдневная конференция компании Veeam, на которой руководство компании делилось планами на будущее, обсуждались текущие проблемы мира виртуализированных данных, их хранения, обработки и обеспечения бесперебойной доступности, читались технические доклады и было много других интересных событий свойственных любой хорошей конференции от лидера отрасли.
Но среди прочего, я бы хотел особенно выделить анонс нового продукта — Veeam Endpoint Backup с припиской Free. Единственной задачей этого приложения будет бекап физических машин.



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

В конце августа я описал в статье бюджетное решение расширения архива для NVR/DVR, но недавно ко мне в руки попал Zyxel Keenetic и еще один 5-ти дисковый DAS CFI-B8253JDGG. Существует масса разных реализаций раздачи «сетевых шар» в локальной сети, но удалось получить, что-то средне-бюджетное и защищенное.

Многие «фичи» в решениях Veeam добавлены по запросам пользователей – так, например, в Veeam Backup & Replication появилась поддержка записи бекапов на ленту и плагин для платформы Kaseya. Недавно было реализовано еще одно пожелание, о котором и пойдет речь далее – Veeam Backup & Replication Add-on for LabTech.
Кстати, к моему удивлению хабропоиск выдает нулевой результат по запросу «LabTech», поэтому раскрою тему и расскажу, что это такое, для кого и с чем его едят.

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

Поэтому я задумался о системе восстановления файлов. Резервное копирование на машине проводится автоматически раз в неделю, что позволяет не терять данных, однако при частом изменении документов это не спасает. Издание еженедельное, полос немного — каталог с файлами вёрстки текущего выпуска занимает 1-2 гб. У нас не имеется отдельного файлсервера, все данные хранятся на моей машине, и используется по сети еще двумя ПК. Собственно, все карты мне в руки.

«Ты суслика видишь? Нет? А он есть!»

Аналогичная ситуация вполне возможна и с бесконтрольным ростом числа виртуальных машин (Virtual Machine Sprawl) — до определенного момента мы не считаем, что такая проблема имеет место быть в нашей инфраструктуре, а на самом деле она есть, просто не показывает себя в натуральную величину.

А в чем, собственно, дело?

Проблема бесконтрольного увеличения поголовья виртуальных машин довольно типична для быстро растущих виртуальных инфраструктур. Начинается всё с вполне резонного стремления того или иного подразделения компании работать со своими специализированными приложениями на выделенных серверах. Разумеется, благодаря виртуализации они получают такую возможность. А теперь, уважаемые читатели, сотрудники IT-отрасли, разработчики и тестировщики, прикиньте хотя бы приблизительно, сколько виртуальных машин вы засетапили, скажем, за последние полгода? А сколько из них было позабыто и позаброшено после успешного релиза?

Получается, что чем больше виртуализация проникает в рабочую среду и помогает решать производственные задачи, тем больше «виртуальных отходов» появляется в этой самой среде (как, впрочем, почти при любом производстве). Это-то и приводит к проблеме бесконтрольного роста количества виртуальных машин (VM sprawl).

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

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

В январе этого года компания Backblaze впервые опубликовала статистику использования дисковых накопителей в своих серверах. Backblaze предоставляет услугу дешёвого облачного бэкапа и поэтому закупается недорогими HDD потребительского класса, которые в 2-2,5 раза дешевле, чем HDD класса Enterprise. За четыре года собрана большая статистика по надёжности дисков Seagate, Hitachi и Western Digital.

Пришло время сентябрьского обновления статистики.

Предыстория

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

Причин для создания новой архитектуры было несколько, и, соответственно, ею решалось сразу несколько задач:

1. Обеспечить масштабируемость до инфраструктур любых размеров — для этого можно создать нужное количество “прокси-серверов” (серверов, которые выполняют задания резервного копирования), между которыми можно оптимально распределять рабочую нагрузку.
2. Повысить надёжность процесса резервного копирования и исключить проблему «единой точки отказа». Даже если один прокси-сервер упадет, задачу за него завершит другой.
3. Уменьшить нагрузку, которую операции резервного копирования оказывают на производственную инфраструктуру – благодаря использованию описанного в настоящей статье механизма.
4. Снять головную боль «Как же оптимально составить расписание для нескольких заданий?» – теперь можно настроить их параллельное выполнение.
5. Автоматически следить за свободным местом на хранилище и заблаговременно предупреждать о приближении порогового значения

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

Не так давно в рамках тестирования продуктовых линеек EMC мне довелось поработать с их решением EMC Avamar Virtual Edition. Этим опытом я и хочу поделиться с вами в этой публикации.

В статье Копирование разделов жёсткого диска средствами GNU/Linux: как обойтись загрузочной флешкой там, где раньше нужен был Акронис, я посоветовал для копирования потенциально испорченных дисков использовать GNU ddrescue, а не оригинал, который назвал устаревшим. Но в комментариях nerfur указал мне, что dd_rescue регулярно обновляется и умеет на лету сжимать данные для последующей передачи по ssh. Так как эта задача GNU ddrescue не под силу, слухи об устаревании dd_rescue как видно сильно преувеличены.

Понятное дело — надо немедленно выяснить, чем современный вариант dd_rescue отличается от GNU ddrescue, что умеет и, возможно, убрать рекомендацию избегать использования оригинала из статьи. А также написать новую статью — про отличия этих двух программ, чем я и занялся.

Для тех, кто хочет побыстрее узнать чем кончилось дело и не интересуется душераздирающими подробностями сразу скажу, что после изучения вопроса моё мнение не изменилось — я всё ещё рекомендую пользоваться GNU ddrescue, но теперь уже по другой, гораздо более вменяемой причине — GNU ddrescue сначала сохраняет хорошо читаемые области диска и уже потом приступает к остальным. dd_rescue этого не умеет by design.

Уже несколько лет как появилась возможность любому смертному желающему арендовать не только shared-хостинг, но и «полноценный» сервер с root-доступом и возможностью настроить его так, как хочется самому. Настроить, например, кроме web-сервера еще и кучу других сервисов.
Так же поступил и я несколько лет назад. Сначала арендовал один сервер, потом другой, и переносил настройки ручками, находя нужные файлы в директории /etc.

За пару лет на моём сервере осело несколько блогов друзей, и даже почтовый сервер, так как давно не хочу, чтобы моя почта была у Google. Насчет сохранности данных задумывался после каждой статьи на Хабре, но всё было как-то не до этого. И, как говорится, админы делятся на три категории: на тех, кто не делает бэкапы, на тех, кто уже делает и на тех, кто даже проверяет восстанавливаемость из бэкапов. Так получилось и со мной, хоть хостер и очень хороший, но произошла у них авария с жесткими дисками. Да такая, что неделю они пытались восстановить диски и предварительные оценки были очень неутешительными. А бэкапов у меня не было. Какое настроение у меня было в те дни можете сами представить.

Но через несколько дней техникам хостера удалось-таки восстановить данные и запустить все виртуальные сервера на той ноде. А я задумался о бэкапах. Думал я так — бэкап должен быть не на том же сервере (естественно!), желательно, чтобы он был у меня на компьютере, но не в одном экземпляре. Я обдумал и установку FTP на домашний компьютер и даже отправку архивов письмами, но все эти варианты меня не устраивали. И я понял, что надо попробовать Dropbox, которым я к тому времени пользовался уже пару лет, а бесплатных гигов у меня было около 18-ти.

Преимущества бэкапа в Dropbox:

• Независимость от домашней инфраструктуры и канала в Интернет
• Множественные копии (сразу на все синхронизируемые ПК)
• Кроме собственного хранения бэкапы хранятся и в облаке

Что делает представленный мной скрипт?

• Инкрементальный бэкап файлов в указанных папках (по первым и пятнадцатым числам идет полный бэкап)
• Бэкап всей базы MySQL
• Бэкап архивируется с помощью 7zip, с указанием пароля (вам же не надо хранить пароли в открытом виде в Dropbox'е?)