Nakivo Backup and Replication

Розробка кросплатформних модулів

Enterprise-платформа резервного копіювання та реплікації для фізичних, віртуальних і хмарних навантажень — роль власника функціоналу кількох кросплатформних модулів відновлення в розподіленій продуктовій команді Nakivo.

Огляд

Галузь: Enterprise IT / Захист даних
Тип продукту: Програмне забезпечення резервного копіювання та реплікації
Архітектура: Java 8 моноліт із Spring backend, ExtJS frontend, кросплатформний рівень виконання скриптів для агентських операцій на Windows і Linux цілях

Платформа забезпечувала резервне копіювання, реплікацію та гранулярне відновлення файлів, директорій і об’єктів служб каталогів у гетерогенних enterprise-середовищах. Розгорнута в украй різнорідній клієнтській інфраструктурі — фізичні хости, кластери гіпервізорів і хмарні навантаження — система вимагала індивідуального діагностичного аналізу для кожного середовища під час збоїв замість припущення про уніфіковану поведінку. Кожен модуль належав одному інженеру від реалізації до командної здачі.

Архітектурний контекст

Середовище

Розгортання на стороні клієнта та в хмарі в умовах украй різнорідних конфігурацій інфраструктури
Цільові системи: фізичні Windows/Linux хости, VMware vCenter, Microsoft Hyper-V, Amazon Web Services (EC2/S3), Microsoft Active Directory, Microsoft 365 (SharePoint Online, OneDrive for Business)
AWS-розгортання вносили значну складність IAM: права ролей інстансів, політики міжакаунтного доступу та контроль доступу S3/EBS потребували індивідуальної діагностики для кожного середовища
Виконання скриптів на цільових машинах через PowerShell (Windows) та POSIX shell (Linux)
Сховище резервних копій: монтується як зовнішній диск на цільовому хості з підтримкою тіньових копій для VSS-сумісних навантажень
Період: жовтень 2017 — серпень 2021

Стек

Backend: Java 8, Spring Framework
Frontend: JavaScript, ExtJS
Скриптинг: PowerShell, POSIX shell
Хмарна інтеграція: Microsoft 365 REST API (SharePoint Online, OneDrive for Business)
Служби каталогів: Microsoft Active Directory (LDAP, тіньові копії, модель об’єктів AD DS)

Функціональність

Резервне копіювання та відновлення на фізичних хостах, VMware vCenter, Microsoft Hyper-V та AWS EC2
Відновлення об’єктів Active Directory з примонтованих резервних образів через тіньові копії
Резервне копіювання та відновлення Microsoft 365: SharePoint Online, OneDrive for Business
Уніфікована кросплатформна модель виконання скриптів із детермінованим логуванням та обробкою кодів виходу
Повне власництво модуля: проєктування, реалізація, доставка та презентація команді

Мій внесок

Прийняття та завершення модуля FileRecovery: логіка монтування/демонтування, отримання дерева директорій, відновлення файлів і директорій через кросплатформні скрипти; стабілізація та виправлення помилок у наявній кодовій базі
Проєктування та впровадження уніфікованої моделі виконання для основного та logging-потоків у всіх PowerShell і POSIX скриптах — стандартизована процедура запуску, детерміновані коди виходу, структурований пайплайн логування; скорочення накладних витрат на налагодження та часу ескалації підтримки при наступних збоях скриптів
Виявлення та усунення невідповідності інтерпретаторів Linux на рівні скриптової інфраструктури: міграція всієї Linux-скриптової поверхні з bash на строгий POSIX sh, що усунуло цілий клас середовищезалежних збоїв у клієнтських інсталяціях
Проєктування та розробка відновлення об’єктів Active Directory з нуля: монтування резервного образу як зовнішнього диска, вилучення тіньової копії AD, реконструкція LDAP-об’єктів із повним маппінгом атрибутів
Відповідальність за крос-середовищну діагностику на AWS-розгортаннях клієнтів: трасування збоїв оцінки IAM-політик, що охоплювали ролі EC2-інстансів, S3 bucket-політики та контроль доступу EBS
Реалізація резервного копіювання та відновлення Microsoft 365 для SharePoint Online і OneDrive for Business через REST API: вилучення даних, локальне зберігання та флоу відновлення
Доставка виправлень помилок у модулях FileRecovery, Active Directory, SharePoint та OneDrive

Інженерні кейси

Невідповідність інтерпретаторів Linux — архітектурне виправлення, не обхідне рішення. Скрипти, що коректно виконувалися в інтерактивних сесіях, мовчки відмовляли в контексті daemon-користувача. Аналіз першопричин виявив, що ОС призначала інтерпретатор dash сервісному акаунту, тоді як інтерактивні сесії за замовчуванням використовували bash — поведінкова розбіжність, що впливала на область видимості змінних, доступність вбудованих команд та поширення помилок. Латання окремих скриптів або усунення системного призначення інтерпретатора усувало б симптоми без вирішення першопричини. Міграція всієї Linux-скриптової поверхні на строгий POSIX sh усунула залежність від інтерпретатора на рівні інфраструктури, зробивши поведінку рантайму узгодженою незалежно від контексту виконання. Це ліквідувало цілий клас середовищезалежних збоїв у клієнтських інсталяціях.

Уніфікована модель виконання скриптів. Наявний скриптовий рівень не мав узгодженої схеми незалежного управління основним потоком виконання та logging-потоком, що призводило до непослідовних поверхонь збоїв і непередбачуваних кодів виходу на різних платформах. Я спроєктував і реалізував стандартизовану процедуру запуску, застосовану однаково до всіх PowerShell і POSIX скриптів: детермінований порядок ініціалізації потоків, структурований пайплайн логування з явними точками скидання та нормалізована семантика кодів виходу. Результат — узгоджені поверхні збоїв на Windows і Linux цілях, скорочені накладні витрати на налагодження при ескалаціях підтримки та перевикористовувана схема для всієї наступної розробки скриптів.

Відновлення об’єктів Active Directory — інваріанти domain controller. Класичне відновлення AD відновлює об’єкти з оригінальними objectGUID та objectSid — незмінними ідентифікаторами, що контролюються domain controller і не можуть бути відтворені в живий каталог із зовнішнього джерела. Аналіз першопричин підтвердив відсутність підтримуваного шляху для справжнього in-place відновлення без інструментів рівня domain controller. Реалізоване рішення: монтування резервного образу як зовнішнього диска, вилучення тіньової копії AD бази, зчитування атрибутів об’єктів через LDAP-інструментарій та реконструкція об’єктів у живому каталозі з ідентичними атрибутами, але новими системними ідентифікаторами. Рішення дотримується інваріантів domain controller, забезпечуючи практичну бізнес-цінність відновлення. Членства у групах та прив’язки ACL, залежні від objectSid, потребували post-recovery виправлення — відоме і задокументоване обмеження, явно зафіксоване в скоупі функціоналу.

AWS-середовище — оцінка IAM-політик як реальний рівень збоїв. Хмарні навантаження AWS вносили клас збоїв, відсутній у локальних розгортаннях. На відміну від фізичних або гіпервізорних цілей, де відмова доступу видима на мережевому рівні або рівні облікових даних, AWS-збої часто були мовчазними або повертали оманливі поверхні помилок — реальна першопричина захована в оцінці IAM-політик: область ролей EC2-інстансів, межі міжакаунтної довіри, S3 bucket-політики або права підключення EBS. Ефективна діагностика вимагала розгляду IAM policy resolution як окремого рівня — відокремленого від логіки застосунку — та трасування збоїв через AWS SDK виклики, CloudTrail та симуляцію політик, а не лише через логи backup-агента.

Інтеграція Microsoft 365 REST API. Резервне копіювання SharePoint Online і OneDrive for Business вимагало орієнтування в REST API-поверхні Microsoft: правильний вибір ендпоінтів для колекцій сайтів, елементів дисків та історії версій; обробка пагінації та throttling; управління операціями відновлення зі збереженням метаданих. Суттєвої архітектурної складності не було — основний виклик полягав у коректності API-поверхні та точності циклу резервного копіювання/відновлення.

Технології

Java 8, Spring Framework, JavaScript, ExtJS, PowerShell, POSIX shell, VMware vCenter, Microsoft Hyper-V, Amazon Web Services (EC2, S3, IAM), Microsoft Active Directory, Microsoft 365 REST API, SharePoint Online, OneDrive for Business