У вихорі свят і різноманітних подій, що відбулися після канікул, можна було й випустити з уваги, що довгоочікуваний реліз Veeam Availability Suite версії 10.0 побачить світ вже зовсім скоро — у лютому.
Про нову функціональність вийшло чимало матеріалів, включаючи доповіді на онлайн та офлайн-конференціях, пости в блогах та різних спільнотах різними мовами. Для тих, кому не довелося ще з ними ознайомитися, та й просто для всіх, кого цікавлять галузеві новинки, сьогодні я коротко перерахую нові можливості Veeam Backup & Replication і зупинюся на одній із ключових докладніше.
Отже, ласкаво просимо під кат.
"Всі роботи хороші - вибирай на смак"
Справді, всі команди розробників зробили свій внесок у ювілейний реліз. Для кожного потенційного клієнта знайдеться набір фіч, необхідних для його інфраструктури. Ось лише неповний перелік новинок:
- Бекап NAS та файлова куля
- Data Integration API
- Linux VIX та бекап-проксі для Linux
- Підтримка клонування блоків XFS
- Оновлений Cloud Tier та репозиторій SОBR
- Репозиторій резервних копій NFS
- Робота з NetApp ONTAP SVM
- Плагін RMAN Plugin for Solaris
- Архівування бекапів журналів транзакцій (transaction logs backup copy job)
- Завдання з політикою зберігання GFS Retention M Primary Backup Jobs
- Покращений WAN-акселератор
- Покращене резервне копіювання для віртуальних інфраструктур на платформі Nutanix AHV
І це тільки нововведення у Veeam Backup & Replication! Адже майбутня версія Veeam Availability Suite має на увазі і новий Veeam ONE, і нові Veeam Agents. Нас чекає, без сумніву, багато цікавого — але все ж таки почнемо по порядку.
Резервне копіювання для NAS та файлових куль
Ця функціональність дуже давно очікувалася, і наші інженери не дарма працювали над нею не один місяць. Користувачі отримають інструментарій з дуже гнучкими можливостями для бекапу та відновлення файлів та папок, все це реалізовано на базі зрозумілої та масштабованої архітектури та у звичному інтерфейсі.
З люб'язного дозволу нашого Vanguard-а Євгена Єлізарова (), який відвідав наприкінці 2019 року форум Veeam Vanguards, ділюся посиланням на його з цієї фічі.
Зі свого боку, розповім трохи про схему роботи та процедуру налаштування цього виду бекапу.
Як це влаштовано
Загальну схему роботи показано нижче:
Як бачимо, у процесі резервного копіювання задіяні такі компоненти:
- Початкове файлове сховище (NAS, SMB share)
- Сервер Veeam Backup & Replication, відповідальний за керування
- Допоміжний проксі-сервер File Backup Proxy, що виконує передачу даних при бекапі, а саме: енумерацію, читання, запис, компресію, декомпресію, шифрування, дешфрування. (Цей компонент ідентичний загальновідомому backup proxy.)
- Репозиторій бекапів, де зберігаються резервні копії та файли метаданих, що описують вихідну структуру кулі та місцезнаходження відповідних файлів та папок у резервних копіях.
- Кеш-репозиторій: тут зберігається знімок файлового дерева, зроблений під час останнього запуску бекапа. Завдяки йому инкрементальные проходи робляться набагато швидше, т.к. немає необхідності порівнювати кожну вихідну папку з бекапі, що міститься. Це також прискорює процес відновлення файлів. Цей репозиторій може бути розміщений безпосередньо на підключеному фізичному чи віртуальному сервері Windows чи Linux, а можна використовувати і NAS (або SMB share). Рекомендується розташовувати такий репозиторій на SSD, ближче до кулі.
Примітка: У цій ролі можна використовувати вже наявний в інфраструктурі репозиторій Veeam, де зберігаються бекапи віртуальних машин. Однак майте на увазі, що SOBR/Deduplication storage/Cloud repository як такий репозиторій використовувати не можна.
- Архівний репозиторій, якщо є необхідність, а вона найчастіше є, у довгостроковому зберіганні. Тут можна задіяти недорогу СГД та налаштувати регулярне архівування бекапів з основного репозиторію, як буде показано нижче.
Примітка: Як репозиторії не підтримуються rotated drives.
Основні етапи процесу коротко виглядають так:
- Veeam Backup & Replication ініціює енумерацію та побудову дерева папок та файлів у вихідній кулі.
- Ці дії виконує файл proxy, який передає побудовану структуру в кеш-репозиторій на зберігання.
- Коли файл proxy отримує нову структуру, то порівнює її з попередньою, що зберігається в репозиторії. Якщо виявлено зміни, то кеш-репозиторій надсилає на бекап-репозиторій запит на його ресурси
- File proxy починає читання нових даних з вихідної кулі та передачу в бекап-репозиторій. Вони передаються, будучи “упакованими” у BLOBs: кожен BLOB містить дані резервної копії як файлів розміром по 64 Mb. Також зберігаються файли метаданих.
Подивимося, як це можна налаштувати в інтерфейсі.
Налаштовуємо файловий бекап у консолі Veeam
Для початку треба налаштувати потрібні компоненти: проксі, файлову кулю та репозиторій.
Налаштування file proxy
Як проксі для бекапу файлів можна задіяти сервер Windows - головне, щоб x64, і дуже бажано, щоб старше Windows 2012R2, якщо треба бекапити CIFS кулі з використанням VSS.
Ця машина має бути вже включена до інфраструктури резервного копіювання, або можна додати новий сервер — для цього в поданні Backup Infrastructure потрібно клікнути правою кнопкою по вузлу Backup Proxies та вибрати команду Add file backup proxy. Потім проходимо кроками майстра, вказуючи:
- Ім'я нового проксі
- Максимум завдань, що виконуються одночасно (1 завдання — 1 вихідна куля). Значення за промовчанням — автоматично розраховується з наявних ресурсів.
На кроці Правила дорожнього руху налаштовуємо правила обробки мережевого трафіку, як завжди робимо для проксі.
Додавання вихідної кулі
У поданні Інвентаризація з'явився новий вузол - File Shares, а також відповідні йому команди:
- Add file share — додати нову кулю
- Створити роботу - Створити завдання резервного копіювання
- відновлення - Виконати відновлення з бекапу
Додаємо файлову кулю в інфраструктуру таким чином:
- Після кліку по вузлу File Shares треба вибрати команду Add file share.
- Вибираємо тип об'єкта, який додаватимемо.
Можна вибрати як вихідне файлове сховище:- Файловий сервер Windows чи Linux.
- Шару NFS - підтримуються версії 3.0 та 4.1.
- Кулю SMB (CIFS), причому для SMB3 підтримується бекап зі снапшотів Microsoft VSS.
Наприклад виберемо опцію c SMB share.
Примітка: Під час встановлення облікового запису для доступу до вихідної кулі переконайтеся, що цей обліковий запис має як мінімум права на читання (а якщо хочете і відновлювати, то і на запис). І не забувайте, що у проксі серверів, що використовуються, теж повинні бути права на читання.
- Якщо ви хочете використовувати для резервного копіювання снапшоти, слід натиснути Advanced і вказати, якого типу снапшоти потрібно задіяти VSS або storage.
Примітка: Підтримка VSS вимагає правильного налаштування File Backup Proxy. А якщо ви хочете використати сторадж-снапшоти, то вам потрібно буде налаштувати їх створення на стороні вашого сховища.
- На наступному кроці потрібно встановити параметри процесингу:
- Вказати, який file proxy ми плануємо використовувати - за замовчуванням будуть задіяні всі проксі (All proxies).
- Вказати шлях до кеш-репозиторію Cache repository. Пам'ятаємо, що SOBR/Deduplication/Cloud як такий репозиторій використовувати не можна.
- Користуючись налаштуванням Backup I/O control, вибираємо кращу характеристику виконання операцій при бекапі
- Lower impact (Найменший вплив на ваш NAS) - обробка запитів на читання буде йти в один потік;
- Faster backup (висока швидкість) - відповідно, багатопоточність; застосовується до високопродуктивних сховищ.
Який варіант краще використовувати у вашій інфраструктурі, з'ясовується, звісно, за допомогою тестування. Але загальний принцип такий: якщо у вас СГД, призначена для Enterprise-інфраструктур, можна сміливо виставити Faster backupа якщо скромний NAS домашнього рівня, то, звичайно, орієнтуємося на Lower impact.
- Потім говоримо Застосовувати, завершуємо кроки майстра - і в дереві інфраструктури Veeam Backup бачимо нашу файлову кулю.
Завдання резервного копіювання
Тепер потрібно створити завдання резервного копіювання. З меню Backup Job вибираємо Спільний доступ до файлів.
Запускається майстер налаштування завдання. У ньому ми спочатку вказуємо ім'я нового завдання, а потім на кроці Файли та папки — те, що хочемо бекапити.
Якщо хочемо задати фільтри, що включають виключні, натискаємо кнопку Advanced. За умовчанням бекапитися буде весь вміст.
Потім переходимо до кроку зберігання, де задаємо налаштування зберігання:
- Backup repository – шлях до репозиторію
- Keep all versions of each file for N days — період короткострокового зберігання, тобто. наскільки довго потрібно зберігати всі версії забекаплених файлів у репозиторії на випадок необхідності відновлення (за замовчуванням 28 днів - так-так, для файлів ми вважаємо не "точки відновлення", а просто дні).
- Якщо потрібно і довгострокове зберігання, зачекуємо галочку Keep file versions history і вказуємо, скільки часу зберігати старі версії файлів, яких саме і де (тут можна вказати не основне, а допоміжне сховище, його можна буде налаштувати на наступному кроці).
Щоб вибрати, для яких файлів організувати довгострокове зберігання, натискаємо Вибирати:
Тут крім включаючого виключаючого фільтра по масці можна окремо налаштувати, скільки версій треба зберігати в активних файлів і у віддалених файлів (поля Active file versions to keep и Deleted file versions to keepвідповідно). Зрозуміло, всі ці налаштування потрібно виконувати відповідно до вашої політики забезпечення доступності даних.
тиснемо ОК і повертаємось до кроку майстра.
Звичні налаштування повідомлень, кастомних скриптів тощо. доступні на кліку на Advanced.
Якщо вам потрібне довгострокове зберігання на допоміжному архівному репозиторії, то переходимо до кроку Secondary Target. Архівування даних стартуватиме після закінчення бекапу.
Це також невелике нововведення. Власне, це всім відомі Backup Copy завдання, але одночасно вбудовані в головне, тобто. немає потреби створювати окреме.
Якщо хочеться додатково налаштувати для конкретного репозиторію політику зберігання, шифрування та тривалість вікна архівування, потрібно вибрати репозиторій у списку та натиснути Редагувати.
Далі налаштовуємо розклад - тут все як завжди.
Ну і на останньому кроці перевіряємо налаштування та при необхідності вибираємо негайний запуск (Run the job when I click Finish), після чого спостерігаємо за перебігом бекапу:
Можливості відновлення
Відновлення можливо в трьох режимах: можна відновити всю кулю на певний момент часу, можна вибрати конкретні файли для відновлення або відновити всі файли, які змінилися в момент бекапа.
- Файлова куля відновлюється повністю на стан, в якому вона була забекаплена і потрапила до обраної точки відновлення. Буде відновлено всі файли та папки; можна відновити їх у вихідне або інше розташування:
- Відкат до вибраного моменту часу шляхом відновлення тільки змінених файлів: тут теж все зрозуміло - спочатку вибираємо потрібний момент часу, потім файли папки, які хочемо відновити.
Дещо змінилася логіка вибору точки відновлення. Запустивши майстер відновлення, можна вибрати:
- Latest Restore Point — відновлення з останнього бекапу у вибраному режимі.
- Selected restore point - Якщо промахнулися з точкою відновлення, тепер її можна вибрати заново прямо в майстрі (раніше для цього доводилося виходити в основний інтерфейс).
- Весь час - У цьому режимі можна побачити всю історію бекапів кулі, плюс можна відновитися з архівного сховища.
Крім того, для об'єкта, що відновлюється, можна також вказати його версію:
На сьогодні, мабуть, все. Але продовження слідує!
Додаткові матеріали
Джерело: habr.com