Резервне копіювання Microsoft 365: реальний досвід, обхід лімітів Graph API та архітектурні факапи

Це сталося у вівторок о 4:15 ранку. Звільнений системний адміністратор перед здачею ноутбука запустив деструктивний скрипт, який повністю очистив OneDrive та SharePoint-сайти критично важливого департаменту — загалом близько 14 ТБ даних. Коли ми спробували запустити повне відновлення з нашого локального бекап-сервера, ми моментально влетіли в жорстоку реальність: швидкість відновлення впала до смішних 1.2 МБ/с через перманентний HTTP 429 (Too Many Requests) від Microsoft Graph API. За такого темпу відновлення зайняло б майже 140 днів. Цей інцидент змусив нас повністю переписати архітектуру резервного копіювання Microsoft 365 та навчитися обходити обмеження вендора.

Міф про «вбудовану безпеку» та модель спільної відповідальності

Багато хто досі вважає, що хмара Microsoft — це безсмертна сутність, яка не потребує резервного копіювання. Це перша і найдорожча помилка архітектора. Microsoft чітко прописує це у своїй Shared Responsibility Model: вони відповідають за працездатність інфраструктури (uptime), але за збереження, класифікацію та безпеку ваших даних відповідаєте ви самі.

Вбудовані політики утримання (Retention Policies) в Exchange або SharePoint — це не бекап. Якщо шифрувальник-вимагач (ransomware) отримає доступ до тенуту з правами глобального адміністратора, він зашифрує і робочі файли, і їхні попередні версії в SharePoint. Без ізольованої копії поза межами вашого основного тенуту ви залишаєтеся абсолютно незахищеними.

Чому Graph API вас ненавидить: природа лімітів HTTP 429

Коли ви намагаєтеся викачати або залити назад терабайти даних, ви моментально вдаряєтеся в ліміти тротлінгу. Microsoft захищає свої ресурси у мультитенантній хмарі та безжально обмежує швидкість доступу.

• Ліміти на рівні Application ID: кожен зареєстрований додаток в Entra ID має свій пул лімітів на кількість запитів за хвилину.
• Ліміти на рівні користувача (User-level throttling): якщо ви робите занадто багато запитів від імені одного сервісного облікового запису, Microsoft заблокує його на кілька годин.
• Динамічне обмеження: під час пікових навантажень на конкретний дата-центр Microsoft ліміти закручуються ще сильніше.

Отримавши відповідь HTTP 429, ваш бекап-софт змушений зупиняти роботу і чекати, зчитуючи заголовок Retry-After. Якщо у вас тисячі поштових скриньок, без оптимізації бекап просто не встигатиме виконуватися за добу.

Обхід лімітів: архітектура з багатьма додатками (Multi-App Registration)

Єдиний робочий спосіб обійти ліміти Graph API — це розподілити запити між десятками або сотнями різних додатків Azure AD (Entra ID). Кожен додаток отримує свій власний ліміт тротлінгу, що дозволяє паралелізувати потоки даних.

Замість використання одного сервісного облікового запису ми створюємо пул допоміжних додатків (Auxiliary Applications). Нижче наведено PowerShell-скрипт для автоматичного створення пулу з 10 додатків в Azure AD:

# Скрипт для реєстрації допоміжних додатків в Azure AD для обходу тротлінгу
$TenantId = "your-tenant-id.onmicrosoft.com"
$AppNamePrefix = "M365-Backup-Aux-"
$AppCount = 10

Connect-MgGraph -TenantId $TenantId -Scopes "Application.ReadWrite.All"

for ($i = 1; $i -le $AppCount; $i++) {
    $AppName = "$AppNamePrefix$i"
    Write-Host "Створення додатку: $AppName" -ForegroundColor Green
    
    # Створення додатку в Entra ID
    $App = New-MgApplication -DisplayName $AppName
    $ServicePrincipal = New-MgServicePrincipal -AppId $App.AppId
    
    # Виведення деталей для конфігурації бекап-софту
    [PSCustomObject]@{
        AppName = $AppName
        AppId   = $App.AppId
        Tenant  = $TenantId
    } | Format-Table
}

Увага: не використовуйте один і той самий сертифікат для 100 додатків. Microsoft відстежує такі патерни і може заблокувати весь пул за підозрілу активність. Ротуйте сертифікати та розподіляйте їх рівномірно.

SharePoint та OneDrive: особливе коло пекла

З поштою все відносно просто — протокол Exchange Web Services (EWS) або Graph API працюють передбачувано. А от SharePoint та OneDrive — це суцільний біль для інженера:

1. Величезні файли: відео та архіви забивають канали і часто викликають таймаути на боці Microsoft.
2. Мільйони дрібних файлів: генерують колосальну кількість метаданих. Кожен файл — це окремий API-запит. Тут multi-app архітектура є критично важливою, інакше швидкість впаде до кілобайт.
3. OneNote блокноти: це не просто файли, а складна структура в базі даних. Їх бекап через API часто ламається, якщо блокнот має пошкоджену структуру сторінок.

Практичні поради з налаштування Veeam Backup for M365 (VBO)

Якщо ви використовуєте Veeam (де-факто стандарт для ентерпрайзу), ніколи не залишайте налаштування за замовчуванням. Ось перевірені в продакшені правила:

• Використовуйте тільки Modern Authentication з сертифікатами. Забудьте про Legacy Auth та паролі.
• Додайте щонайменше 10 допоміжних додатків (Auxiliary Applications) для кожних 1000 користувачів. Для великих тенутів на 5000+ користувачів ми тримаємо пул з 50 додатків.
• Виділяйте окремі проксі-сервери для SharePoint/OneDrive і окремі для Exchange. У них абсолютно різні профілі навантаження на CPU та RAM.
• Не пишіть метадані бекапів на повільні диски. Використовуйте тільки NVMe для баз даних репозиторію (Jet DB або PostgreSQL в останніх версіях VBO), інакше операції порівняння стану (incremental sync) задушать дискову підсистему ще до початку копіювання самих даних.