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

Подробное описание всех проверок, включая ключи реестра, можно прочитать в статье Security & Compliance Analyzer.

Для игнорирования проверки жмёте “Suppress”, а вот если хотите исправить, то идёте в статью базы знаний “Script to Automate Implementation of Security & Compliance Analyzer Recommendations” где размещен powershell-скрипт исправляющий часть настроек. Сначала заново валидируете конфигурацию, а потом выбираете исправления, которые вас устраивают:

1) В этом году компания Veeam обещает выпустить девятую версию своего флагманского продукта – Backup and Replication. Больше всего из заявленного функционала мне нравится запись на ленты в несколько приводов и консоль администрирования сервера. Я тестировал запись на свои ленты в v7 и v8 – скорость записи на один привод удручает.

А если бы Вим научился работать с лентами напрямую, минуя жесткий диск, то и мечтать о большем было бы не нужно. Я, конечно, понимаю, что у всех разные ситуации, но у меня ситуация такая, что есть много терабайт в VTL или MSL и немного терабайт на СХД. И мне как раз актуальнее система резервного копирования, которая умеет работать с лентами напрямую. Прямо сейчас это освободило бы мне десяток терабайт…

2) А еще я протестировал работу механизма Backup Copy в Veeam Backup and Replication v8, призванного реализовать схему GFS (дед, отец, сын) для резервного копирования.

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

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

Мне интересно было проверить работу этой схемы, после постановки задачи по наличию месячных резервных копий за последние полгода. Чтобы не заниматься долгим процессом восстановления (бэкапа с ленты -> почтовых баз Exchange из бэкапа -> Clean Shutdown -> восстановления информации из базы в пользовательский ящик) я решил посмотреть – получится ли у меня отложить месячную резервную копию и использовать ее в Veeam Explorer for Exchange.

В качестве репозитория была подключена сетевая папка с системы HP StoreOnce 4500 с функционалом дедупликации.

Для повышения эффективности “аппаратной” дедупликации Veeam складывает на папку бэкап в несжатом состоянии. Такой функционал есть при архивации на HP StoreOnce и EMC Data Domain. Это можно заметить, сравнив размер полной резервной копии на StoreOnce и на обычном хранилище. Я же хочу поделиться цифрами по двум месячным резервным копиям для почты и виртуальных машин.

– два бэкапа Exchange. На StoreOnce лежат два файла: 5,7Тб и 4,5Тб. Полная резервная копия и инкремент до следующей месячной копии. Согласно данным в консоли StoreOnce: User Data – 11,3Тб; Data on Disk = 5,2Tb. Одна полная копия Exchange на обычном хранилище (то есть с сжатием и дедупликацией от Veeam) – 5Тб.

– два бэкапа виртуальной инфраструктуры. На StoreOnce лежат два файла: 3,9Тб и 1,5Тб. Аналогично – Full+Incr. Согласно данным в консоли StoreOnce: User Data – 5,9Тб; Data on Disk = 1,7Tb. Одна полная копия инфраструктуры на обычном хранилище – 2,2Тб.

Я считаю, цифры просто фантастичны. HP StoreOnce круче дедуплицирует, чем Veeam

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

E-mail оповещение с каждого сервера не подходит. Слишком много ненужной информации и будет приходить столько e-mail, сколько задач по всем нашим серверам, то есть как минимум 40 штук. Поднимать ради простого отчета Enterprise сервер тоже не хотелось, к тому же его отчет не совсем то, что мы хотели видеть.

Было принято решение написать центральный скрипт мониторинга, который бы опрашивал все серверы бэкапов и выдавать консолидированную красивую картинку. С задачей успешно справился мой коллега, A.Shabalin. Результат его плодотворной работы ниже.

Собственно сам скрипт:

Script.ps1

param(
$xml_param_file= "VeeamBackupMonitoring.xml",
$smtpServer= "mail"
)

$script= {
function Fun_4{
get-vbrjob | select name, lateststatus, @{Name=”LatestRun”; Expression={(get-vbrjobschedule (get-vbrjob $_.name)).latestrun}}
}

function Fun_5{
get-vbrjob | select name, @{Name=”LatestStatus”; Expression={$_.info.lateststatus}}, @{Name=”LatestRun”; Expression={(get-vbrjobscheduleoptions $_).latestrun}}
}

function Def{
Get-process -name “Veeam.Backup.Service” | select @{Name=”Name”; Expression={“Information”}}, @{Name=”LatestStatus”; Expression={$_.ProductVersion}}, @{Name=”LatestRun”; Expression={“You need add this version to script”}}
}

get-pssnapin -registered | add-pssnapin
Get-process -name “Veeam.Backup.Service” | select ProductVersion | foreach-object {
switch ($_.productversion){
“5.0.1.198” {Fun_5}
“5.0.2.224” {Fun_5}
“5.0.2.230” {Fun_5}
“4.1.1.105” {Fun_4}
“4.1.0.96” {Fun_4}
“4.0.0.80” {Fun_4}
default {Def}
}
}
}

$xml_param= [xml](Get-Content $xml_param_file)

$xml_param.root.item | foreach-object{

$body= “”
$stat_war= 0
$stat_err= 0
$stat_all= 0
$stat_ic_error= 0
$_.host | foreach-object{
$body += “n$_n”
$IC_error = “”
$jobs = Invoke-Command -ComputerName $_.ToString() -scriptblock $script -errorvariable IC_error

if ($IC_error -ne “”) {
$body += “$IC_errorn"
$stat_ic_error ++
}
elseif ($jobs -eq $null) {$body +="Нет заданийn”}
else {
$jobs | foreach-object {
$body +=”$($_.lateststatus.tostring()): $($_.name), прошлый запуск $(get-date $_.LatestRun -f ‘dd-MM-yy HH:mm:ss’)n"
$stat_all++
if($_.lateststatus.tostring() -eq "Failed") {$stat_err ++}
if($_.lateststatus.tostring() -eq "Warning") {$stat_war ++}
}
}
}

if (($stat_err + $stat_war + $stat_ic_error) -eq 0) {
$subject = "Всё OK,ошибок нет"
$mail ="Любимый город может спать спокойно ...nn"
}
else
{$subject = "VeeamBackup: ошибок - $stat_err, предупреждений - $stat_war из $stat_all"
if ($stat_ic_error -ne 0) {$subject +=", ошибок соединения - $stat_ic_error"}
$mail = "Ошибки резервного копирования VeeamBackup.nn"
}

$mail += $body
$footer = "n`n” + $(hostname) + ”                         From RUSSIA with love”
$mail += $footer

$_.email | foreach-object {
send-mailmessage -to (‘Administrator <‘ + $_ + ‘>’) -from ‘VeeamBackup monitoring<script@domain.ru>’ -body $mail -subject $subject -smtpServer $smtpServer -Encoding ([System.Text.Encoding]::UTF8)
}
}

И файл параметров к нему:

VeeamBackupMonitoring.xml
<root>
<item>
<email>mail@domain.ru</email>
<host>perm-bckp-01</host>
<host>backup.oren</host>
<host>ulsk-bckp-01</host>
</item>
</root>

Как вы заметили, используется функционал Powershell Remoting (WinRM), который, соответственно, необходимо включить и настроить на серверах бэкапов:
Winrm qc –q

Особо пытливые умы заметили наличие оператора switch с перечислением возможных версий Veeam. Все потому, что разработчики Veeam переписали интерфейс оснастки powershell для версии 5. На 6-ой версии работа скрипта еще не проверялась.

P.S. Кстати, классная идея использовать в качестве файла параметров для скриптов powershell файл xml, который прекрасно разбирается в коде левой задней пяткой:
$xml_param = [xml](Get-Content $xml_param_file)

И на выходе получается объект, свойствами которого являются указанные параметры.

В нашей организации мы движемся к 100% виртуализации всех сервисов. Один из приятных моментов виртуализации – нам практически не надо думать как выполнять резервное копирование сервиса. Есть универсальное средство – Veeam Backup.

Не так давно у нас появился и стал расти DAG кластер Microsoft Exchange Server 2010. На данный
момент его емкость составляет примерно 3000 ящиков, 27 почтовых баз, 27 VMDK по 110 Гб под базы. MS Exchange DAG кластер состоит из 2-х нод, на каждой из которых лежат все 27 баз.

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

А вот результат получился не совсем ожидаемым…

Первое с чем столкнулся при выполнении бэкапа – успешно проходит задание только для полностью пассивной ноды (нет активных БД). Наличие же хотя бы одной активной копии БД на ноде приводило с 80% вероятностью к ошибке:

Cannot create a shadow copy of the volumes containing writer's data. A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer]. Class ID: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{cd169187-75d1-4c72-96f2-d41f9673f22e}]. Writer's state: [VSS_WS_FAILED_AT_FREEZE]. Error code: [0x800423f2].]

Понял, что где-то я был не прав, и обратился к первоисточнику, из которого http://technet.microsoft.com/ru-ru/library/dd876851.aspx выяснил, что необходимо отключить модуль записи VSS службы репликации Microsoft Exchange:

HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters.

Добавить новое значение DWORD с именем EnableVSSWriter и установить для него значение 0.

Отлично! Теперь бэкап выполняется….. в 60-70% случаев успешно;)

Техсаппорт Veeam отправил меня сюда http://www.veeam.com/kb_articles.html/KB1337/All:1:1/vss
что вообщем-то логично. Ну что ж, следовало ожидать. Будем трясти нашего железячника на предмет ускорения дисковой подсистемы.

Однако это еще не все проблемы, с которыми пришлось столкнуться:

Как многие знают, MS Exchange DAG кластер работает на базе стандартного MS Cluster Service. Суть кластера – обмен хертбитами. Если хертбиты пропадают, значит нода упала – надо поинтересоваться у свидетеля на предмет, не меня ли отрубили от сети и поднимать сервис.

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

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

По совету интернетов, поправил настройку MS Cluster Service http://technet.microsoft.com/en-us/library/dd197562(WS.10).aspx,
увеличив до максимума задержку между хертбитами (2 секунды) и порог срабатывания (количество пропущенных хертбитов до 10):

cluster /cluster:<ClusterName> /prop SameSubnetDelay=2

cluster /cluster:<ClusterName> /prop SameSubnetThreshold=10

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

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

Резюмируя данные результаты, приходим к выводу: если вы хотите бэкапить виртуальный кластер DAG, то у вас есть три варианта:

1. Бэкапить на уровне приложения (например при помощи
   DPM)
2. Бэкапить полностью пассивную ноду
3. Тюнинговать производительность ваших
   систем.

Снапшоты

Описывать что такое снапшоты не буду – дам набор ссылок:

• Снапшоты в vSphere.
• Снапшоты не являются бэкапами и следуют следовать рекомендациям при работе с ними.
• Механизм для исправления проблем с неотработавшими операциями со снапшотам отличается в версиях 3.x-4.x и в версии 5.0 (по-русски).
• Статьи про снапшоты на нашем сайте – первая, вторая.

Как определить у каких машин есть снапшоты?

Предложу следующие варианты (гуёвые):

1. Пробежать  по каждой VM, по правой кнопке мыши Snapshot-Snapshot Manager
2. Поставить утилиту VMware Guest Console и переключиться  на режим Snapshot Manager
3. Воспользоваться утилитой Trilead VMX, которая нам поможет в дальнейшем
4. Использовать утилиту RVtools, закладка vSnapshots.
5. Storage View в vClient (подсказывают в комментариях).

Проблемы со снапшотами

Первая проблема – это ошибки удаления/создания снапшотов, решилась запуском описанной выше процедуры консолидации снапшотов.

Вторая проблема, потрепавшая нервы – это проблема “зависания” на 99%, как при консолидации, так и при удалении. Выглядит она, как часами наблюдаемый прогресс-бар в состояни 99%.

Для понимая, что процесс идёт, VMware рекомендует мониторить наличие delta-файлов через команды консоли в этой статье.

Я же воспользовался Trilead VMX.

В разделе DataCenter добавляем хосты и находим нужную виртуалку со снапшотами, по правой мышке кликаем на Locate Files…

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

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

Проблема четвертая, скорее частная, чем общая, при удалении снапшотов резко растёт лог БД vim_vcdb – гигабайты в минуту, что приводит к его переполнению и остановке vCenter. К сожалению, советы эти мне не помогли. Проблема существенная, так как может происходит во время операции по резервному копированию виртуальных машин. Дальнейшее решение по этой проблеме в комментариях к статье.

Выводы

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

Для тех, кто привык в графическому интерфейсу, на основе этих же команд Shogan.tech выпустил GUI утилиту. Брать тут.

Новые функции:

• Built-In Scheduler Service: VM Explorer 3.5 теперь запускается, как сервис, не надо делать назначенного задания в ОС, либо оставлять вошедшего в ОС пользователя.
• Advanced Email reporting: Почтовые отчеты улучшены и содержат больше информации, также отчет можно просмотреть в VM Explorer. Есть возможность выбрать между ежедневным отчетом и отчетом о запланированном задании.
• Advanced scheduled task reporting: отчеты о запланированных задания можно просмотреть в VM Explorer либо выгрузить в html
• Добавлена функция “On error execute next task”, позволяющая делать следующие  после ошибочного задания
• Добавлена функция “delete backup”
• Более гибкие настройки инкрементального бэкапа
• Добавлена возможность включения ВМ после восстановления из резервной копии
• Backup Explorer: новый Backup Explorer позволяет искать бэкапа среди созданных и инициировать восстановление

Качать здесь.

Выбирая СРК, мы долго не метались – в 2007 году был куплен Symantec BackupExec 11d, по функционалу он нас почти устраивает. Вот если бы он еще мог резервировать пару новых приложений, появившихся за это время. Так как контракт на поддержку куплен не был, то у нас сейчас выбор один – покупать его заново (правда, с 35% скидкой, как старые клиенты). Текущая версия – Symantec BackupExec 2010. Появилось море функционала, о котором раньше я не слышал:

– синтетические бэкапы (есть даже в версии 11d), требуют дополнительной лицензии;

– бэкап данных через SAN (аналогично, просто раньше не покупались нужные лицензии);

– дедупликация данных (вроде новый функционал, раньше доступный только в NetBackup);

– бэкап виртуальных машин VMware vSphere (новый функционал).

Оговорюсь сразу, это далеко не полный перечень как нового, так и стандартного функционала Symantec BackupExec 2010 (по сравнению с более старой 11d). Желающие могут ознакомиться с документом – “Backup Exec %Version% administrator guide” – для версии 11d там 1600 страниц.

Сравнить его я решил, как видно из заголовка, с Veeam Backup and Replication 4.1. Благо этот продукт вроде как собрал приз “админских” симпатий. Естественно, сравнение касается только бэкапов виртуальных машин, а весь перечисленный функционал у него есть.

Под катом опишу свои ощущения от работы с ознакомительными версиями обоих продуктов…

Veeam

Установился без проблем, подключил удаленную SQL-базу, простой и быстрый интерфейс. При создании бэкапа был приятно удивлен наличием архивации – полный бэкап всех виртуальных машин стал влазить в 120 гигабайт. Так как SAN у меня нет, проверить этот функционал и скорость по нему не получилось.

В сумме, бэкапы за две недели с учетом двух фулл-бэкапов (один последний – синтетический) и инкременталов, создающихся ежедневно, занимает 400 гигабайт. Учитывая общий объем ВМ ~ 400GB, вполне удобно.

В целом, ощущения позитивные.

А теперь поговорим о Symantec Backup Exec 2010.

Несмотря на мое приятственное к нему отношение, за месяц я не смог добиться от него стабильной работы по бэкапу виртуальных машин. Кроме того, за этот же месяц вышло 4 апдейта к нему, которые теоретически должны были пофиксить проблемы. Видимо, пофиксили не все – продукт сыроват! А жаль, по функционалу он мне очень даже нравится (как и наличие единой СРК).

Теперь о фичах, перечисленных мною выше:

• синтетические бэкапы – работают только для файл-серверов;
• дедупликация данных – на один сервер доступен один дедублицированный каталог. Требуется 64-битная ОС;
• бэкап виртуальных машин VMware vSphere. Есть весчь под названием GRT – внутрь ВМ устанавливается агент SBE, после этого помимо бэкапа/восстановления самой ВМ доступно восстановление объектов AD/SQL/Exchange. Правда, я так и не смог разобраться, действует ли в этом случае лицензия на хост, или же надо дополнительно лицензировать таких агентов.

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

В принципе, слышал один положительный отзыв про Acronis. Еще есть Vizionscore, но про них ничего не слышал.

UPD: Кстати, Veeam пока не поддерживает бэкап на стримеры! Вроде в пятой версии обещают поправить!

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

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

Ввиду того, что средний системный администратор (СА) – существо либо ленивое, либо занятое, бэкапы он не тестирует. Это справедливо для большинства компаний из сектора SMB (малый/средний бизнес).

Кроме того, СА может не делать бэкапы, придумывая следующие оправдания:

1. Нет достаточного места под резервные копии / нет выделенного сервера под резервные копии;
2. Нет системы автоматизированного создания резервных копий (СРК – система резервного копирования);
3. Нет времени на проверку резервных копий (либо некуда восстанавливать), а раз так – зачем их нерегулярно делать;
4. Отсутствует лицо, заинтересованное в создании резервных копий или целостности данных;
5. Просто влом.

Как правило, все пять причин/проблем находятся лишь в голове у СА. Люди, принимающие решения, ничего о них не знают. Ведь находятся же деньги на оплату труда специалистов по восстановлению информации с мертвых дисков (или приложений). Это следствие косноязычия ИТ – оно не умеет говорить с людьми.

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

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

Лично я считаю, что:

• СА обязан иметь бэкапы инфраструктурных данных (например, AD);
• При возможности, иметь последний бэкап пользовательских данных. При невозможности создания такого бэкапа по объективным причинам – уведомить об этом свое руководство и предложить решение!

Общее направление к обоснованию резервных копий.

• Определить, кому нужны резервные копии. Если никому – не делаем их и точка (это касается пользовательских данных. Сохранность инфраструктуры нужна СА – он же побежит компы в новый домен перевгонять);
• Если нашлись такие люди, смотрим на их влияние в компании. Помочь в принятии решения о закупке СРК (или даже простого жесткого диска) рядовой менеджер не сможет;
• Если резервные копии все же нужны менеджменту или руководству компании, выясняем их потребности. Дальше смотрим ниже

1) Нет места под резервные копии / нет выделенного сервера.

Как так – воскликнете вы! Ведь новый терабайтный жесткий диск стоит 100$. Да и в серверах есть еще незанятые жесткие диски. Вон, на контроллере домена свободно 20 гигабайт, на почтовом – еще 200. Бэкапь туда, место кончится – тогда и поговорим. Зачем тебе нужен выделенный сервер?

Обоснование первого пункта (и инфраструктуры резервного копирования вообще) стоит начинать не с жестких дисков и с серверов, а с определения списка информационных ресурсов и их объема. После этого мы находим лиц в менеджменте компании, которые заинтересованы в целостности этих ресурсов и согласовываем с ними планы по резервному копированию. Например, базы бухгалтерии надо архивировать раз в день, хранить последние 7 ежедневных бэкапов, 4 еженедельных и 12 ежемесячных. В результате, у нас есть 23 резервных копии, которые теоретически позволят нам восстановить определенные данные на состояние до года назад. Если нужна 100% восстанавливаемость всех данных, храним последние 365 копий. В результате, от сервисов мы придем к необходимому объему, требуемому под бэкапы. Кроме того, в выборе ресурсов для резервирования должен участвовать человек от ИТ. Это позволит гарантировать, что мы не забудем про резервные копии для контроллеров домена, например.

Так что там с жесткими дисками? Все просто – если мы не хотим, чтобы внезапно кончилось место на почтовом сервере / контроллере домена и службы встали, то нужны отдельные жесткие диски! Если не хотим, чтобы бэкапы бухгалтерии за последний год канули в лету вместе с жестким дисков, то настраиваем дополнительно архивацию на другие носители или внедряем рейд-массив. Под “если не хотим” я подразумеваю, “если не хочет заинтересованное лицо”.

Если:

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

то нам нужен выделенный сервер под хранение резервных копий.

Если нам нужно создание отчуждаемых архивов данных, смотрим в сторону DVD-дисков или ленточных накопителей. Если раньше стоимость хранения на них была низкой по сравнению с HDD, то сейчас жесткие диски по стоимости мегабайта находятся рядом! Выбор между DVD и лентами сделать просто – если нужна:

• автоматизация процесса архивации;
• высокая частота сброса данных на съемный носитель;
• объем данных для архивации велик (>10GB)

то берем ленточную библиотеку (может быть, даже с автозагрузчиком).

2) Нет программного обеспечения для автоматического создания резервных копий.

3) Нет времени на проверку резервных копий.

На самом деле, такое бесплатное программное обеспечение есть

Это NTBackup для Windows 2003 Server и Windows Server Backup для Windows 2008 Server. Другие приложения (Exchange, SQL, Oracle), как правило, имеют свои средства автоматизации резервного копирования. Тут есть несколько своих проблем:

• Разнообразные интерфейсы систем резервного копирования (СРК) с различным функционалом. Для настройки и мониторинга работы СРК тратится много времени, особенно, если счет серверов идет на десятки;
• Не всегда есть контроль целостности созданных бэкапов;
• Нет автоматизированной системы по восстановлению бэкапов!

К примеру, сравним MS DPM 2010 и Symantec Backup Exec 2010. Первый – автоматизированная система по созданию резервных копий. Второй – АС по созданию и восстановлению резервных копий. То есть вы можете не только автоматизировать процесс создания резервной копии, но и ее восстановления для тестирования резервных копий. Я не говорю, что DPM не умеет восстанавливать данные. Я говорю о том, что он не умеет делать этого автоматически.

Возьмем другой популярный продукт – Veeam Backup and Replication. Летом обещают запустить новую версию, а также весчь под названием SureBackup. Обещанный функционал – возможность автоматизированного тестирования – восстанавливается ли это письмо, база SQL из бэкапа. А также – восстанавливается ли набор виртуальных машин или нет…

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

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

4) Отсутствует лицо, заинтересованное в  создании резервных копий или целостности данных.

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

5) влом.

Это единственная проблема, которую решать должен либо сам СА, либо его руководство с помощью системы мотивации / замены персонала.

Выводы

Как я уже упомянул, единственное предназначение СРК и бэкапов – гарантия восстановления данных. Основная причина, по которой не делаются или не восстанавливаются для тестов резервные копии – бездействие системнного администратора.

Как правильно внедрить у себя инфраструктуру резервного копирования:

• тщательно проанализировать потребности бизнеса. Ради бэкапа 2 гигабайтов данных никто в здравом уме миллионы не тратит. Делать бэкап только базы AD можно на жесткий диск своего ПК. Для этого – провести диалог либо с начальником службы ИТ, либо с директором предприятия, подготовив табличку с сервисами. Постараться донести мысль, что хотя бы одна резервная копия любых данных всегда должна быть. Исключение – каталоги с фильмами и музыкой;
• проработать несколько вариантов инфраструктур, различающихся по стоимости. Для каждого варианта составить краткую выкладку по возможностям и тому, как это подходит под ваши потребности. Вариант типа “подключить в свою рабочую станцию два жестких диска, сетевую карточку на гигабит” всерьез рассматривать не стоит;
• Предложить эти варианты на выбор.
• Если желания бизнеса никак не совпадают с его возможностями, то…

любое действие на ваш выбор.

Good luck!

Для бэкапов можно использовать не только ЖД, но и ленточные приводы, библиотеку с роботом.

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

В первый раз я погрешил на “грязный” привод библиотеки и запустил очистку.

Сейчас – понял, что дело не в “грязи”.

Анализ кассет, помещенных в сет “File Backup”, показал, что из 20 кассет:

• 10 полные и защищены от перезаписи в ближайшее время;
• 9 имеют ошибку End marker unreadable и не позволяют дозапись;
• и только на одну можно что-то писать.

Я сказал “Ахтунг” и начал чистить “больные” кассеты.

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