Используем veeam backup free edition 9.5 для резервного копирования виртуальных машин с хоста hyper-v на выделенный файловый сервер на базе debian linux 8.6 c дедупликацией от quadstor

Method B: New Job, New Backup location

To map the existing backup files to a new or different job, follow these steps:

1. Under Backups > Disk, right click the job you are changing repository for, and do either Remove From Backups (v8) or Remove from Configuration (v9).

2. If you are mapping the backup set from one job to another, but the backup location will stay the same, skip this step. If you are moving the backup files to a new location create a new repository for the new location where backup files are located.
3. Rescan the repository where the backup files are located.

4. If the backup files are not encrypted, skip this step. If the backup files are encrypted, the encrypted backup will appear under the Backups > Disk (encrypted) node in the inventory pane. In the working area, select the imported backup and click Specify Password on the ribbon or right-click the backup and select Specify password. More Information This is also relevant for encrypted Veeam Agent backups.
5. Edit the Backup\Backup Copy Job. Go to the Storage\Target tab, and from the drop-down menu, select the repository where the backup files you wish to map are located.
6. Click Map Backup and select the existing backup chain

If you are attempting to seed failover cluster Veeam Agent for Microsoft Windows job’s restore points please follow the actions below (it has a bit different workflow due to the product design):

Грамотно подбираем и тестируем хранилище своих бекапов

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

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

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

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

Разработчик-экстремал: как отдыхают программисты Veeam

Существует много способов отвлечься от работы. Разнообразие предлагаемых услуг в сфере развлечений, порой, сбивает с толку. Одним по душе простые и доступные виды досуга вроде кино и выставок, другим нравится что-то более активное и захватывающее.
Существует мнение, что программисты — люди по своей природе спокойные и малоактивные, — увлекаются, в основном, походами в бары и редко – шашлыками на природе. В опровержение мы представляем вам подборку самых активных и экстремальных хобби среди разработчиков Veeam Software.
Как и многие, наши программисты «болеют» своей работой. Если пройтись по офису в будний день в 8 вечера, мало кто из них окажется не на рабочем месте. Ребята создают продукт мирового уровня, их работа требует максимум внимательности и ответственности. Мы выбрали четырех коллег, которых попросили рассказать о том, как они организовали свое нерабочее время.

Как предотвратить аварийное переключение между узлами DAG при использовании снапшота VSS?

Если узлы вашей DAG находятся на разных площадках и соединены друг с другом через WAN, вы можете столкнуться с таймаутом VSS (по умолчанию время таймаута «замораживания» для модуля записи Exchange составляет 20 секунд). Таймаут может привести к аварийному переключению с активного узла на пассивный во время создания или слияния снапшота. Почему? В службе отказоустойчивого кластера Microsoft (Failover Cluster Service, FCS), которая объединяет независимые сервера для повышения их доступности, заданы достаточно низкие значения таймаутов для быстрого аварийного переключения в среде LAN. Соединения WAN отличаются более продолжительной задержкой, что может приводить к непредвиденным аварийным переключениям узлов DAG в вашей среде во время бэкапа.

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

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

Другие полезные ресурсы:

• Экспертная статья: Как правильно виртуализовать Exchange 2016
• Популярная дискуссия на форуме Veeam на тему бэкапа Exchange 2010 DAG
• Видео: Защита Exchange с помощью Veeam

Используете ли вы Exchange DAG? Я всегда жду отзывов от читателей. Вы можете оставить свой комментарий ниже или присоединиться к обсуждению в .

GD Star Rating
Как сделать резервную копию групп доступности базы данных Exchange с помощью Veeam Backup & Replication, 5.0 из 5 на основании 2 отзывов

VeeamON Forum Mosсow

2 июня 2015

В октябре 2015 мы проводим второй глобальный слет любителей виртуализации VeeamON. Интерес к мероприятию в прошлый раз был колоссальный, в том числе и среди российской аудитории. Но мы понимаем, что просто так сорваться и полететь в Лас-Вегас- нелегко. Поэтому Вегас приходит в Россию — встречайте первый VeeamON Forum Russia в Москве уже этим летом. Вы сможете многое узнать о последних технологиях Veeam и опробовать их самостоятельно. Будет возможность ознакомиться с опытом построения современных высокодоступных ЦОД крупными российскими компаниями, а также пообщаться с инженерами Veeam, NetApp и HP. Традиционно, для наших хаброчитателей приготовлен отдельный сюрприз.

Рекомендации по выбору режима резервного копирования

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

Обратно инкрементальный режим резервного копирования — наш старейший, и самый медленный, метод. Резервное копирование в этом режиме может быть в три или более раз медленнее, чем в других режимах, в зависимости от используемого типа ресурса хранения. При обратно инкрементальном резервном копировании последней точкой восстановления в цепочке является полная резервная копия. Это позволяет быстрее выполнять восстановление из самой последней точки, но ненамного, если сравнивать с прямым инкрементальным резервным копированием (при условии, что длина цепочки резервных копий — около 30 дней).

Инкрементальный бэкап «на лету» с помощью Quick Backup — новая возможность Veeam Backup & Replication v8

• Tutorial

Что чаще всего делают пользователи, которым нужно срочно получить резервную копию виртуальной машины, например, для тестирования и отладки хотфикса? Судя по нашим наблюдениям, чаще всего они делают снапшот. В самом деле, у снапошота достаточно плюсов: его создание не отнимает много времени, а если что-то пойдет не так, можно быстро откатить виртуальную машину на предыдущее состояние. Однако есть и минусы: пока вы экспериментируете с машиной, снапшот разрастается; у виртуальной машины падает производительность чтения/записи; сокращается свободное место на СХД. Вдобавок, «забытые» (бесхозные) снапшоты тоже могут доставить неприятности – недаром VMware рекомендует следить за актуальностью и длиной цепочки снапшотов виртуальной машины. В итоге есть риск, что из-за разросшихся снапшотов возникнут проблемы с доступностью ресурсов продакшена (в частности, из-за чрезмерной интенсивности чтения/записи на СХД), и во время коммита виртуальная машина просто подвиснет.
Чтобы избежать этих неприятностей, для всякого рода тестирования разумно использовать виртуальную лабораторию, или «песочницу» (например, как рекомендуется здесь). Но ее запуск и настройка требуют времени, а как быть, если его в обрез?
Можно запустить процесс резервного копирования – но он тоже отстает по быстроте от создания снапшота, даже если вы используете бесплатную утилиту VeeamZIP (создание полного бэкапа для выбранной виртуальной машины «на лету», т.е. по требованию и без остановки машины). Проход инкрементального бэкапа тоже не всегда является спасением – например, если виртуальная машина бэкапится в одном задании еще с несколькими, то при запуске этого задания придется ждать, пока обработаются они все.
Для таких случаев очень пригодится новая функциональная возможность Veeam Backup & Replication 8.0 – Quick Backup, создающая инкрементальную точку восстановления для выбранной виртуальной машины «на лету».
Что это за разновидность бэкапа, и почему она носит имя Quick — разбираемся под катом.

Virtual Volumes от компании VMware – внедрять нельзя ждать?

Перевод

Компания VMware завершила длительную и кропотливую работу над новой концепцией СХД выпуском в свет vSphere 6.0 с поддержкой программных хранилищ и структуры Virtual Volumes (VVols), о которых и будет мой сегодняшний пост. Начну с официального определения от производителя: «Virtual Volumes — это новая структура интеграции и управления, обеспечивающая виртуализацию массивов SAN и NAS благодаря созданию эффективной эксплуатационной модели, которая оптимизирована для виртуализированных сред и ориентирована на особенности приложения, а не инфраструктуры».
Представляется, что в будущем Virtual Volumes заменят VMFS, поскольку VMware никогда не распыляется на поддержку двух различных вариантов для ключевых компонентов инфраструктуры, то есть на двойную работу. Сперва они упразднили ESX спустя несколько лет после выхода ESXi, затем – VSA, выпустив на замену VSAN, а теперь пытаются перевести пользователей с vSphere Client на Web Client; допускаю, что в какой-то момент они могут решить перейти от vCenter Server на Windows к VCSA. Поэтому можно предположить, что аналогичная судьба ждет VMFS, от которой откажутся в пользу VVols – разумеется, после того, как они достигнут определенной стадии «зрелости» и будут приняты к использованию большинством пользовательской аудитории. Подтверждением этой мысли является и тот факт, что поддержка VVols включена во все редакции vSphere.
Выясним, однако, для начала, почему эксперты советуют не торопиться с внедрением Virtual Volumes.

Проблемы обеспечения 100% доступности проекта

Рассуждать о том, что сайт должен быть доступен всегда — моветон и банальность, но 100% доступность, хотя и является обязательным требованием, чаще всего по-прежнему недоступный идеал. Сейчас на рынке существует масса решений, которые обещают максимальный uptime или предлагают решения для его увеличения, но их применение мало того, что не всегда помогает, в некоторых случаях даже может привести к увеличению рисков и снижению доступности проекта. В этой статье мы пройдемся по классическим ошибкам, которые с которыми мы постоянно сталкиваемся. Большинство проблем — элементарные, однако люди допускают их вновь и вновь.

NAS recovery capabilities

Restore entire share

This option is most useful when there is a complete loss of your file share or major outage, allowing for a complete restore of the latest version of all files either back to the original location or to an alternate location with security and permissions intact.

Rollback to a point time

Quick rollback gives you the ability to roll back to the “last known good configuration” or backup, meaning that any modified files since the last backup can be reverted. The example here would be a ransomware attack and the encryption of a file share. This option would allow you roll back to the last good backup before the ransomware attack occurred.

Check out a live demo of rollback to
a point in time after a ransomware attack in action!

Restore individual files and folders

Designed to be simple with similarities to the File Level Recovery from image-level backups, this restore type provides you with the ability to restore individual files and folders either by overwriting the live system or keeping both copies. Easily choose specific restore points with additional visibility to see all available file versions, making the selection of versions you wish to recover a simple, yet flexible task.

Before you go… even more free software!

Another FREE product we recently released for production use is Veeam Backup for Microsoft Office 365 Community Edition.

If you are utilizing Office 365 and looking for a solution to protect your data, this is a must have. This FREE offering allows you to back up Exchange Online and OneDrive for Business data for 10 users, as well as 1 TB of SharePoint Online data. This is enough to protect the data for yourself and your entire executive management team — which will levitate you to hero status when they experience data loss (which is not a question of IF it will happen, but WHEN). It’s a great opportunity to protect your most important data in Office 365 from accidental deletion, security threats and retention policy gaps. Learn more here.

See More:

On-Demand Sessions from VeeamON Virtual

GD Star Rating
Veeam Backup & Replication Community Edition:Our latest gift to the community, 4.9 out of 5 based on 28 ratings

Почему SMS ограничены именно 160 символами, а сообщения в Twitter — 140 символами?

Документ из архива Твиттер, около 2000 г., рабочее название Твиттер — «Stat.us». Credit: Jack Dorsey

Шел 1985 год. Фридхельм Хиллебранд напряженно работал, сидя за столом в пустой комнате своего дома в Бонне (Германия), и непрерывно печатал на пишущей машинке случайные фразы: новости, просьбы, вопросы… все вперемешку. Закончив печать очередную страницу, Хиллебранд подсчитывал количество букв, цифр, знаков пунктуации и пробелов в каждом напечатанном на странице предложении, и тут же принимался за следующую страницу.
В то время перед коммуникационными компаниями остро стоял вопрос выработки технологического стандарта, который позволил бы мобильным телефонам передавать и показывать на экране текстовые сообщения.
Поскольку в те времена возможности беспроводных сетей были довольно ограничены, а большинство потребителей приходилось на автомобильные телефоны, а вовсе не на носимую электронику, — в рамках разрабатываемого стандарта необходимо было предложить разумное, но жесткое ограничение для максимальной длины сообщения.
«Полторы сотни символов»… Перед тем экспериментом с пишущей машинкой у Хиллебранда был спор с друзьями относительно достаточности такого ограничения для большинства пользователей мобильных телефонов.

Настраиваем файловый бэкап в консоли Veeam

Настройка file proxy

Backup InfrastructureBackup ProxiesAdd file backup proxy

• Имя нового прокси
• Максимум одновременно выполняемых задач (1 задача — 1 исходная шара). Значение по умолчанию — рассчитывается автоматически, исходя из имеющихся ресурсов.

Traffic Rules

Добавление исходной шары

InventoryFile Shares

• Add file share — добавить новую шару
• Create job — создать задание резервного копирования
• Restore — выполнить восстановление из бэкапа

1. После клика по узлу File Shares надо выбрать команду Add file share.
2. Выбираем тип объекта, который будем добавлять.
   Можно выбрать в качестве исходного файлового хранилища:
   • Файловый сервер Windows или Linux.
   • Шару NFS — поддерживаются версии 3.0 и 4.1.
   • Шару SMB (CIFS), причем для SMB3 поддерживается бэкап со снапшотов Microsoft VSS.

   Для примера выберем опцию c SMB share.Примечание: При задании учетной записи для доступа к исходной шаре убедитесь, что у этой учетки есть как минимум права на чтение (а если хотите и восстанавливать, то и на запись). И не забывайте, что у используемых прокси серверов тоже должны быть права на чтение.

3. Если вы хотите использовать для резервного копирования снапшоты, то следует нажать Advanced и указать, какого типа снапшоты нужно задействовать — VSS или storage.Примечание: Поддержка VSS требует правильной настройки File Backup Proxy. А если вы хотите использовать сторадж-снапшоты, то вам нужно будет настроить их создание на стороне вашего хранилища.
4. На следующем шаге нужно задать настройки процессинга:
   • Указать, какой file proxy мы планируем использовать — по умолчанию будут задействованы все имеющиеся прокси (All proxies).
   • Указать путь к кэш-репозиторию — Cache repository. Помним, что SOBR/Deduplication/Cloud в качестве такого репозитория использовать нельзя.
   • Пользуясь настройкой Backup I/O control, выбираем предпочтительную характеристику выполнения операций при бэкапе.
     • Lower impact (наименьшее влияние на ваш NAS) — обработка запросов на чтение будет идти в один поток;
     • Faster backup (высокая скорость) — соответственно, многопоточность; применимо к высокопроизводительным хранилищам.

     Какой вариант лучше использовать в вашей инфраструктуре, выясняется, естественно, с помощью тестирования. Но общий принцип таков: если у вас СХД, предназначенная для Enterprise-инфраструктур, то можно смело выставить Faster backup, а если скромный NAS домашнего уровня, то, конечно, ориентируемся на Lower impact.

5. Затем говорим Apply, завершаем шаги мастера — и в дереве инфраструктуры Veeam Backup видим нашу файловую шару.

Задание резервного копирования

Backup JobFile shareFiles and FoldersAdvancedStorage

• Backup repository — путь к репозиторию
• Keep all versions of each file for N days — период краткосрочного хранения, т.е. сколь долго нужно хранить все версии забэкапленных файлов в репозитории на случай необходимости восстановления (по умолчанию 28 дней — да-да, для файлов мы считаем не “точки восстановления”, а просто дни).
• Если нужно и долгосрочное хранение, зачекиваем галочку Keep file versions history и указываем, сколько времени хранить старые версии файлов, каких именно и где (тут можно указать не основное, а а вспомогательное хранилище, его можно будет настроить на следующем шаге).

ChooseActive file versions to keepDeleted file versions to keepОКAdvancedSecondary TargetEditRun the job when I click Finish

Что под капотом

Давайте теперь пройдёмся по всем компонентам, участвующим в успешном создании бекапа.

Первым будет сам NAS. Забрать с него файлы мы можем тремя путями, реализованными в Veeam:

Метод лобовой атаки: просто взять и скачать. Читаем список файлов, начинаем их копировать, если находим залоченный файл — запоминаем его, ждём, пробуем ещё раз через какое-то время, пишем результат в репорт. Очень простой и быстрый метод

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

И это действительно многим подходит. Сами в шоке.
Следом идёт более сложный, но уже обеспеичвающий консистентнсть бекап через VSS снапшот. Само собой, доступен он только там, где поддерживается эта функция. И не надо думать, что VSS — это удел Windows серверов. Вот вам заклинание, которое в одну строчку включит VSS на Netapp: vssserver cifs options modify -vserver SVM_CIFS -shadowscopy-enable true
Останется только добавить реверс DNS, если шара добавлена по IP — и вы восхитительны.
Кстати, бытует мнение, что VSS снапшот снижает нагрузку на хранилище. В общем случае это не так, поскольку располагается он на том же железе, что и основной LUN. Вот в случае Windows снижения нагрузки можно достичь, если читать снапшот offhost. У многих стораджей тоже есть подобная функция, но её реализация зачастую стоит серьёзных денег.
И самый продвинутый, позволяющий делать всё максимально быстро и быть уверенным в консистентности данных, способ — бекап через storage snapshot. Здесь уже не обойтись без специализированных решений, но на выходе мы получаем минимальную нагрузку на продакшн и гарантию в сохранности данных. Но надо учитывать, что мы чисто физически не смогли бы реализовать поддержку всех на свете NAS решений, поэтому реализация механизма создания снапшотов пока оставлена на стороне пользователя.

Теперь рассмотрим две новые для Veeam сущности: Cache Repository и File Proxy.

Кэш репозиторий — это не хранилище всей налички вашей компании (обидно, да), а специальное хранилище для временного хранения метаданных. Его задача — обеспечивать быстрое создание инкремента и снижать нагрузку на файловую шару во время бекапа. В качестве кэш репозитория может выступать как выделенный Windows/Linux сервер, так и любая CIFS(SMB)/NFS шара. Этот кэш используется исключительно для ускорения создания инкрементов и восстановления отдельных файлов, поэтому может быть потерян без всяких критических последствий. При следующем запуске бекапа он просто будет создан заново. Да, это займёт какое-то время, но без него всё было бы намного дольше.

Естественно, для максимальной производительности кэш надо располагать максимально близко к бекапируемому NAS, и лучше всего на SSD. А его роль назначается любому репозиторию в инфраструктуре Veeam, за исключением облачных, дедуплицированных и SOBR. Про устройство метаданных и зачем они нужны, мы поговорим немного ниже.

Теперь рассмотрим File Proxy. Этот компонент, по сути, полный аналог старого доброго Backup Proxy, только для работы с NAS. Суть не изменилась — прокси выполняет связующую роль между остальными компонентами, задействованными в бекапе, и отвечает за пересылку данных из прода в хранилища бекапов. По умолчанию эту роль выполняет сам сервер Veeam, но такой вариант использования подходит только для небольших инсталяций, где все компоненты находятся в одном сетевом сегменте. Для более интересных вариантов под прокси надо выделять отдельные Windows машины. А лучше даже, когда их несколько, так как они умеют балансировать нагрузку. Но детали, опять же, будут ниже. Кстати, технически ничего вам не мешает использовать существующие прокси для новой роли. Даже новых компонентов устанавливать не придётся. Просто следите за нагрузкой и окном бекапа.

Резервное копирование NAS в Veeam Availability Suite v10

Мы рады
сообщить, что функция резервного копирования NAS появилась в Veeam Backup & Replication v10.  Это огромное достижение.
Мы очень хотели правильно реализовать эту функцию. 

Veeam четко
представлял себе задачу в отношении резервного копирования NAS:

• сделать
  резервное копирование NAS простым и одновременно надежным в соответствии со
  стандартами Veeam Backup & Replication;
• создать гибкое
  решение, которое позволит защитить данные и приложения где угодно, даже на
  типовом оборудовании;
• обеспечить
  надежное масштабирование для защиты больших объемов данных даже в самых крупных
  компаниях.

Такой подход соответствует принципам Veeam: программно-определяемые решения, независимые от оборудования. В результате заказчики могут выбрать оборудование, которое подходит для их задач, не привязываясь без необходимости к конкретным устройствам. Кроме того, решение имеет три отличительных черты.

Гибкость

В мире
существует много типов NAS-систем, использующих разные протоколы и их версии
для хранения неструктурированных данных. Функция резервного копирования NAS в
v10 позволяет защитить не только общие ресурсы SMB и NFS, но и файловые серверы
Windows и Linux.

Отслеживание измененных файлов

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

Поддержка аппаратных снимков

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

Как это работает?

1. Если вы используете Azure-прокси, то Veeam Backup & Replication включит его. Подробнее про этот прокси можно почитать здесь.
2. Veeam Backup & Replication преобразует диски забэкапленной машины в формат VHD и загружает в хранилище (blob storage) в облаке Microsoft Azure.
3. Затем эти диски монтируются к серверу Veeam backup server.
4. Идет подготовка дисков к восстановлению ВМ: активируются правила для работы Remote Desktop, настраиваются правила работы через firewall, готовится почва для установки агента Microsoft Azure, и т.д.
5. Veeam Backup & Replication размонтирует диски.
6. Если был использован Azure-прокси, то он автоматически выключается.
7. Veeam Backup & Replication регистрирует ВМ Microsoft Azure с подготовленными дисками. После этого машина включается, и на нее ставится агент Microsoft Azure.

здесь

• Поддерживаются следующие гостевые ОС:
  • Microsoft Windows Server 2008/Windows Vista и выше
  • Linux — согласно https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-linux-endorsed-distros).
• Размер одного диска восстанавливаемой ВМ не должен превышать 4095 GB.
• Если системный диск исходной машины имеет структуру разделов GPT, то число разделов может быть не более 4. В ходе восстановления такой диск будет преобразован в диск со структурой разделов MBR.
• Не поддерживается программа Azure Hybrid Use Benefit.

Важно!

Как это восстанавливает

Совершенно очевидно, что нет никакой проблемы восстановить несколько файлов/папок обратно на NAS или куда-то в другое место. Или даже восстановить всё хранилище целиком в новом месте.

Гораздо интересней случай, когда часть файлов была зашифрована, случайно удалена или ещё как-то испорчена, из-за чего надо восстановить множество файлов в самых разнообразных папках, и делать это вручную крайне сложно и неэффективно. Тут вам на помощь приходит возможность откатиться на определённый момент времени Rolling back to a point in time. Мы можем выяснить, какие файлы были изменены, и перезаписать их нужной версией из бекапа. Система сама найдёт все изменившиеся файлы и спасёт ваши данные.
Подобный функционал есть в базах данных, когда вместо восстановления всей базы они просто отменяют все транзакции до определённого момента.

Настраиваем расписание запуска сценария

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

Самый простой способ создать расписание для выполнения регулярного резервного копирования — использовать планировщик заданий Windows (Windows Task Scheduler). Просто откройте планировщик и создайте новую простую задачу:

Введите для нее имя и описание, чтобы в будущем было сразу понятно назначение задачи.

Следующая страница — «Task Trigger» (Триггер задачи). Здесь все очень просто и интуитивно понятно. Доступные параметры обеспечивают достаточную гибкость настроек: в зависимости от требуемого показателя RPO, резервное копирование можно выполнять от одного раза в месяц до нескольких раз в день. Большинство пользователей выполняют резервное копирование один раз в день:

Задайте время выполнения задачи в нерабочие часы. В приведенном примере задача выполняется каждый вечер в 22:00, начиная с 22 апреля 2015.

На следующей странице «Action» (Действие) укажите необходимость запуска программы и нажмите «Next» (Далее).

На панели «Start a Program» (Запуск программы) необходимо ввести в соответствующее поле команду:

Powershell –file “Путь к файлу Veeamzip.ps1”

И все! Если после создания задачи нужно внести в нее изменения, откройте окно ее свойств. Для этого поставьте флажок «Open the Properties» (Открыть свойства), перед тем как нажать «Finish» (Готово):

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

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

PowerShell дает пользователям Veeam Backup Free Edition то, о чем они давно мечтали!

Теперь у вас есть отличная возможность сделать то, чего давно хотели — создать расписание резервного копирования для Veeam Backup Free Edition. Решение открывает гораздо больше возможностей для бэкапа и восстановления данных, чем альтернативные решения на базе сценариев.

GD Star Rating
Veeam Backup Free Edition: Теперь с PowerShell!, 5.0 из 5 на основании 13 отзывов

Что внутри?

controller serverController server

• Управление инфраструктурой резервного копирования
• Контроль за созданием снапшотов, резервным копированием и восстановлением ВМ Microsoft Azure.
• Поддержка применения политик бэкапа согласно расписанию
• Управление конфигурационной базой, где хранится информация о политиках, защищенных ВМ, учетных записях и т.д.

политикиworkers

1. Получает данные о конфигурации и дисках VHDs каждой ВМ из Microsoft Azure.
2. Создает и сохраняет снапшоты и резервные копии этих дисков, при этом:
   • Снапшоты managed-дисков сохраняются в ту же ресурсную группу, где находится исходная ВМ — через Azure Compute API.
   • Снапшоты unmanaged-дисков сохраняются в сторадж Microsoft Azure, где находится исходный VHD. Для складывания данных в blob задействуется Blob Service REST API.
   • Бэкапы всех VHD сохраняются в репозиторий как blob также через Blob Service REST API. При бэкапе в репозиторий выполняется шифрование и сжатие данных.
   • Данные о конфигурации ВМ сохраняются в конфигурационную базу Veeam Backup for Microsoft Azure.

Параметры сценария

Сценарий позволяет создавать резервные копии работающих ВМ, которые запущены как на автономных хостах, так и в кластерах или на сервере vCenter

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

По желанию вы можете изменить степень сжатия и срок хранения копии, отключить заморозку VMware и настроить уведомления:

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

Итоговый отчет будет выглядеть следующим образом:

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