Про реліз і розробку True Image 2017 — все хардкорні фічі на місці

У нас нещодавно був свято — вийшов реліз True Image 2017, над яким ми працювали цілий рік. Змін дуже багато, але перше, що кидається в очі, – це «казуальний» мінімалістичний дизайн. Якщо наші перші релізи були інструментами просунутих користувачів і сисадмінів, то останні кілька років світова популярність продукту така, що бэкапят їм дуже і дуже різні люди. В тому числі ті, хто не особливо відрізняє монітор від системного блоку.

Тому наш підхід – зберегти весь старий добрий хардкор, гнучкість налаштувань і безліч нетривіальних інструментів, але зробити упор на спрощення інтерфейсу.


На першому місці – основні дії з завідомо хорошими умолчаниями


Але всі налаштування на місці

Ще в цьому релізі ми навчилися робити локальний бекап iOS і Android на ваш десктоп, бэкапить профіль Facebook (спасибі користувачеві Маша Відро), попрацювали з архітектурою архіву і так далі. Розповім про основні фічі і складності в їх розробці.

Традиційний десктопний бекап

Перший режим, з якого ми історично починали, – посекторный бекап – природним чином зберігся і в 2017-му релізі. Нагадаю, як це працює: ви робите повну фізичну копію жорсткого диска і можете працювати з нею далі, як вам хочеться. Це дуже зручно при відновленні даних (щоб нічого не покорраптить на ледве дихаючому диску). Ще такі диски (точніше, файли з образами) можна подмонтировать прямо в Acronis True Image і бачити в провіднику як окремі диски R/O.

Традиційний бекап робиться трохи інакше, за ітеративної схемою. Спочатку знімається повний образ (всі файли жорсткого диска за урахуванням винятків), потім в бекап додається різниця. Розклад і всі деталі дуже гнучко налаштовуються, а для «казуальних» користувачів стоять оптимальні настройки.

Звичайно ж, ми всі так само пропонуємо зробити аварійний диск або аварійну флешку для завантаження з неї. Ми пишемо на флешку фактично Linux з інструментами відновлення (у випадку Mac туди пишуться їх «рідні» стандартні засоби аварійного відновлення і наша утиліта). Можна користуватися цим, власне, інструментом Next-Next-Finish, без спеціальних знань, а можна перемкнути екран і зробити щось своє.


Вибір гілки завантаження


Утиліта відновлення

У російській версії збереглася повноцінна історія з відновленням драйверів і їх накаткою на нову систему (в США з цим юридичні складності). Історія в тому, що якщо взяти бекап з XP, Vista або Win7, а потім занести на новий комп'ютер з іншим залізом), нічого просто так не запуститься. Знадобиться заново ставити всі драйвера, фактично ще раз конфігурувати всю ОС. В результаті приблизно 8 років тому ми дуже глибоко попорпалися з реверсом віндового коду і написали свій власний інсталятор драйверів. Тепер треба просто переїхати на нову конфігурацію, зробити відновлення і показати, де лежать драйвера для змінився заліза. У нас є для цього окрема утиліта, вона йде в комплекті (тобто безкоштовна для користувачів 2017-го релізу), але качати її потрібно окремо.

Ще одна складність – перенесення даних MBR/EFI. У нас є сценарій, коли ми можемо взяти MBR-операційку і створити для неї гілку в EFI, щоб вона нормально завантажилася і підтримувала великі диски. Зараз цей вибір виникає у користувачів, які хочуть охопити стару ОС на нову машину. Ось трохи більше деталей про низькому рівні з різними гілками конвертацій:








Source(Archive)\Target
BIOS booted system/ target HDD < 2^32 logical sectors
BIOS booted system/ target HDD > 2^32 logical sectors
EFI booted system/ target HDD < 2^32 logical sectors
EFI booted system/ target HDD > 2^32 logical sectors
MBR
not UEFI capable OS
(32 bit windows or 64bit Windows prior to Windows Vista SP1)

no changes in bootability or disk layout (1)
1. Use as non-system disk GPT — not available for Windows XP x32 host(7)
2. Migrate as is that user Warning is unable to use the entire disk space, if OS installed on source is Windows XP warning that the system may not be bootable(8)
Migrate as is. warning that the system will not be bootable in UEFI(14)
1. Use as non-system disk GPT(20).
2. Migrate as is that user Warning is unable to use the entire disk space + warning that the system will not be bootable in UEFI(21);
MBR UEFI capable OS
(Windows x64: Windows Vista SP1 or later)

no changes in bootability or disk layout(2)
leave MBR, warning that user is unable to use the entire disk space. warning prompt to change the system to EFI, reboot from media and re-start the operation in order to be able to use the entire disk space with GPT(9)
Convert to disk GPT layout, fix Windows bootability(15)
Convert to disk GPT layout, fix Windows bootability(22)
MBR no OS or non-Windows OS
1. leave MBR.(3)
2. convert to GPT, warning that the disk will be converted to GPT and the disk must be non-system — not available for Windows XP x32 host(4)
1. leave MBR, warning that user is unable to use the entire disk space.(10)
2. convert to GPT, warning that the disk will be converted to GPT and the disk must be non-system — not available for Windows XP x32 host(11)
1. leave MBR.(16)
2. convert to GPT, warning that the disk will be converted to GPT and the disk must be non-system(17)
1. leave MBR, warning that user is unable to use the entire disk space.(23)
2. convert to GPT, warning that the disk will be converted to GPT.(24)
GPT UEFI capable OS (Windows x64: Windows Vista SP1 or later )
no changes in bootability or disk layout, warning that the system will not be bootable in BIOS(5)
no changes in bootability or disk layout, warning that the system will not be bootable in BIOS(12)
no changes in bootability or disk layout(18)
no changes in bootability or disk layout(25)
GPT no OS or non-Windows OS
no changes in bootability or disk layout(6)
no changes in bootability or disk layout(13)
no changes in bootability or disk layout(19)
no changes in bootability or disk layout(26)


Природно, раз ми так добре розібрали нижній рівень, можна зробити аварійний засіб і прямо на локальному комп'ютері. Ми створюємо нову гілку завантаження в EFI, куди пишемо свій модифікований компактний Linux і засоби відновлення. Якщо у вас щось накривається, можна спробувати завантажитися з того ж комп'ютера з альтернативної гілці і відновити з бекапа. Це захищає від ліні користувачів, які не хочуть носити жорсткий диск до комп'ютера для бекапа за розкладом (і при цьому не бэкапятся в хмару). Тим не менш, звичайно ж, від складних відмов заліза це не врятує, тому окремий носій з вашими даними все ще важливий.

Ще одна цікава річ – автомаппинг. Він у нас уже був, але в цьому релізі став набагато розумнішими. Справа в тому, що відновлення зараз відбувається майже з будь-якого носія, і навіть таких носіїв може бути кілька. Наприклад, мережевий ресурс, локальна копія і щось ще. Якщо система істотно змінилася з часу останньої ітерації бекапа (наприклад, ви накатываете бекап річної давності, таке трапляється, наприклад, при установці нового робочого місця у деяких компаніях), то потрібно правильно зрозуміти, куди і як відновлювати. Типовий приклад – інша розмітка жорсткого диска. Ще випадок: коли бекап старий, але від цього комп'ютера, і не хочеться чекати повного відновлення, то можна спробувати виключити те, що явно не пошкодилося. Щоб не чекати пару годин. Наш код автомаппинга дозволяє швидко отримувати різницю і правильно відновлюватися в таких випадках.


Мережевий бекап

І так, на всяк випадок додам, що всі старі речі, на кшталт «на комп'ютері моєї бабусі все бэкапится прямо на флешку, яка встромлена позаду» або «на моїй виртуалке можна відновити бекап домашнього комп'ютера дівчини, поки вона на вихідних у мене», вони все так само залишилися.


Синхронізація папок

Мобільний бекап

Ми досить сильно перебрали всю технологію мобільного бекапа в новому релізі. Головний момент – ми прекрасно розуміємо, що далеко не всі хочуть віддавати копію своїх даних в чиє-то хмара, тому передбачили функцію локального бекапа. Старий хмарний варіант теж доступний, але локальний бекап був дуже і дуже затребуваний. У нас був серверний код в корпоративних розробках (як раз зроблених для параноїків і бекапів корпоративних пристроїв всередині мережі), і ми вирішили переиспользовать його. Щоб було зрозуміліше, спочатку розповім, як працює нова схема:
  1. Ви приходите з телефоном додому (точніше, в одну і ту ж Wi-Fi мережу, де є ваш десктоп з базовою версією Acronis True Image).
  2. Додаток на телефоні активується (за розкладом iOS або з фону Android) і визначає можливість підключення до комп'ютера у вашій мережі. Для цього телефон починає шукати основний хост, щоб встановити з'єднання SSL.
  3. Після цього починається ітеративний бекап – все, змінене за минулий день, розбивається на частини і заливається короткими чанками. Передбачається, що користувач проводить в своїй домашній мережі досить багато часу, тому використовуються фонові кошти обох операційних систем: наприклад, у разі iOS ми можемо відкривати «вікна» на 30 секунд, заливати короткий чанк і знову чекати наступного часового вікна.
Складності були майже скрізь. По-перше, звичайно ж, трафік, активація з фону і енергоспоживання на нових версіях iOS і Android. В цілому, це вирішується вже відносно просто, і готові рецепти були. Після першого повного бекапа, як правило, мова про декількох мегабайтах нових фотографій, парі кілобайт контактів та іншої інформації. Ми переписали код, що відповідає за заливку: чанкі не рвуться, добре докачиваются навіть після добового перерви в роботі мережі. Контакти тепер ллються першими за важливістю. Заодно оновили хмарну заливку (у разі, якщо бекап не локальний), тепер контакти видно відразу після того, як вони були отримані, навіть не чекаючи кінця чанка.

Досить нетривіально було встановити з'єднання між телефоном і десктопом. Ми спробували багато методів, поки не зупинилися на QR-кодах – потрібно сфотографувати QR-код з екрану десктопа в додатку. Але навіть у цій версії було досить складно: спочатку ми зашивали в візуальний код відразу повноцінний SSL-сертифікат, і далеко не всі бібліотечні читалки його розбирали. Довелося сильно зменшити QR і встановити новий протокол обміну ключами.

Сам дискаверинг робиться відразу різними шляхами, тому навіть якщо ви запускаєте операційну систему всередині віртуальної машини (як це любимо робити ми), телефон знайде свою пару. Частий домашній випадок, це коли телефон підключений по Wi-Fi, а ноутбук підключений локальним кабелем. Резолв йде по I4, бонжур-сервісів та імені хоста. На жаль, російські користувачі Yota поки залишаються без цієї фічі: їх «провайдерські» модеми, роздають Wi-Fi, створюють NAT, за яким щось намацати досить складно.

Про переиспользование серверного коду теж окрема історія. Спочатку це був Linux-сервер, який теоретично можна було перенести, наприклад, під Win. При цьому вся логіка компонента побудована так, що у нього є керуючий сервер, який віддає команди. В результаті при корпоративному бекапі ми створюємо микросервер, який виступає в ролі командного центру для цієї підмережі. У домашньому випадку такий «наносервер», можна сказати, імітуються на десктопі. Точніше, просто компонент надсилає запити, а десктоп, у разі локального бекапа, сам віддає відповіді (у разі хмарного – відповіді дає віддалений сервер). Сам цей компонент був потрібен для того, зокрема, щоб консоль дізнавалася, що вже забэкаплено, а що — ні.

Відновлення теж йде через мобільний додаток, але вже при активному запуску через GUI. Ну, і, звичайно, більшу частину даних можна мігрувати між різними пристроями: наприклад, якщо ви переїжджаєте з iOS на Android, перетягнути фотографії – найпростіше справа.

Бекап профілю Facebook

Якщо у вас просто викрали сторінку – це, загалом, не дуже велика проблема, найчастіше, її можна відновити штатними засобами. Якщо Facebook вас несподівано забанив – навряд чи ви щось витягнете. Якщо ваша сторінка загине з-за технічного збою на їх стороні – теж. Іноді користувач сам щось випадково видаляє (наприклад, одиничну фотографію) і дуже хоче відновити. Загалом, багато запитували, чи можна бэкапить профіль Facebook. Так, можна. Тепер ми це робимо.

Коли ви запускаєте з десктопа засіб копіювання профілю, відкривається сторінка Fb, де вам потрібно дозволити спеціальним додатком доступ до ваших даних. Це гейт для Facebook API, по суті, сховище токен для роботи бекапа. Далі ви можете обмежити на стороні Facebook «видимість» вашого профілю через API, і ми зможемо почати копіювати.

Копіювання піддається не всі. Наприклад, не можна взяти і зберегти граф друзів, Facebook дуже ретельно (на відміну від багатьох інших персональних даних) захищає свою головну власність. Зате вийде забрати всі фотографії, всю стіну, всі повідомлення і так далі. Фотографії і відео в разі чого можна швидко відновити API дає можливість заливати їх заднім числом і не показувати у стрічці оновлень, але, природно, на них не буде «лайків» та коментарів. Ці дані назад не заливаються ніяким чином, що, в цілому, досить зрозуміло. Ваш Timeline теж не відновлюється: на відміну від фото, всі записи будуть датовані часом зворотного заливки. Ваші лайки збережуться у бекапі, але теж відновлені не будуть.

API Facebook виявилося достатньо забагованным, точніше, багатим на вкрай нелогічні фічі. Цей інструмент спочатку не призначений для великих завдань: як правило, додатки смикають один-два запиту на щось дуже конкретне, але не все відразу. Це вилилося в те, що той же інкрементальний бекап робити дуже складно. Наприклад, швидко отримати різницю між поточним і попереднім станом на певну дату майже неможливо. Немає штатних методів і не буде – це, схоже, частина політики безпеки Facebook. Довелося добре подумати над організацією алгоритмів в наявних обмеженнях. У підсумку проковырялись сильно, але знайшли баланс. Другий момент — є обмеження з токеном. Найдовший токен не вічний, живе 60 днів. І, за логікою Facebook, треба через 60 днів знову зайти на дашборд і натиснути кнопку. Звичайні веб-токени переносяться при активності користувача: коли ви заходите у свій профіль, і у вас є куки з згадкою такого сертифіката, він оновлюється. Ми ж працюємо без живого заходу, в окремій сесії. З іншого боку, на щастя, ми не виробники SmartTV. У них користувачі обов'язково отримують код на телефоні або десктопі і забивають його з пульта на телевізор раз на два місяці. На щастя, у нас просто одна кнопка.

Дуже весело йшло тестування. Facebook дозволяє створювати тестових користувачів-віртуалів, яких не видно в основній мережі. На жаль, ці «манекени» не вміють лайкати один одного, не можуть коментувати і мають безліч інших обмежень. У результаті ми створили своїх «живих» користувачів, головною з яких згодом стала Маша Відро (її ще можна знайти в мережі, але ми почистили профіль). У фіналі ми працювали з профілями наших топ-менеджерів – нам потрібні були дуже «роздуті» профілі людей, які вели активне мережеве життя багато років і сьогодні ведуть. У результаті обсяг бекапа стали міряти одним із співробітників, могли бути пояснення до тикетам кшталт: «З Facebook забрали даних на 50 Іванових, а прийшло лише 48».

Цікаві речі в changelog

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

Перша цікава історія – це виключення. Наприклад, звичайний сценарій бекапа не бере тіньову копію системи – це просто не має сенсу. Щоб полегшити бекап (що особливо актуально для тих, хто заливає його по мережі), ми дуже добре попрацювали з винятками. Крім тимчасових папок (за винятком кешу браузера – він виявився несподівано важливим), системних журналів, аварійних дампів пам'яті і інших системних речей, виключається те, що має власні засоби відновлення. Наприклад, якщо явно не вказати зворотну, ми не бэкапим Dropbox, Яндекс.Диск, Google Drive, OneDrive, бібліотеки кшталт iTunes і карантини антивірусів. Відповідно, довелося отреверсить всі ці інструменти, щоб знайти їх параметри, визначити їх конфігураційним записів, що вони є в системі, і зрозуміти, що треба брати, а що – ні. Довше за всіх від нас тікав Яндекс.Диск – вони в різних версіях зберігають свої налаштування абсолютно по-різному. Перший раз він нам попався ще в минулому релізі — з конфіг в XML-файлі, потім він почав зберігати налаштування в SQLite-базі, потім поміняли формат зберігання… Ми ганяли ці налаштування і намагалися зрозуміти логіку для кожного винятку.

У зворотний бік теж потрібні були винятки. Наприклад, щоб підняти на новій системі старий архів, ні в якому разі не можна відновлювати драйвери від старої ОС, своп-файл і так далі. Відповідно, від релізу до релізу ми підтримуємо такі набори правил.



Ще ми виключаємо з бекапа файли цього ж бекапа, якщо вони зберігаються на тому ж диску. Інакше виникала б рекурсія. При цьому у нас є новий вид зберігання – архів непотрібних файлів (стисла версія папок «Разобрать1», «Разобрать2» і так далі, які користувач сам показує і зберігає з ностальгічних почуттів) – їх бекап ми включаємо.

Дуже сильно змінився архів, в якому зберігаються дані бекапа. У нас за цей і минулий рік з'явилося багато ідей, як оптимізувати його і зробити більш доступним (зрештою, ми ж «прозоро» підмонтуємо диски з архівних файлів і даємо веб-доступ до хмарної копії). Зараз локальний бекап зберігається у другій версії архіву з істотними доделками по архітектурі, а мобільний – вже в третій, з зовсім іншою архітектурою. Думаю, в наступному році ми перейдемо на третю версію вже скрізь. За великим рахунком, наш архів являє собою окрему файлову систему «в собі». Так, наприклад, всередині нього може лежати до 20 версій одного файлу (з дедупликацией або без), є власне засіб видалення старих версій. Є свій аналог збирача сміття: можна «почистити» архів, і всередині нього утворюється місце для зберігання (при цьому сам розмір файлу не зміниться). Як і в класичних файлових системах, видалені файли всередині архіву для оптимізації не видаляються, а розмічаються як підлягають перезапису. З-за словникової структури архіву потрібно звільнення словникових ділянок для повного видалення. Також у нас є власне засіб внутрішньої дефрагментації архіву, але ми не використовуємо його без прямої команди користувача (так само як ніколи не рухаємо дані в момент видалення). Справа в тому, що будь-яке переміщення інформації створює загрозу втрат. Наприклад, характерна проблема – «USB-гірлянди», коли користувач вводить пристрою через кілька перехідників (особливо часто ми це бачимо у користувачів маленьких ноутбуків). Спроба видалити файл всередині архіву із зміною розміру архіву призведе до того, що всі дані посекторно переїдуть. На довгій «гірлянді» це викликає втрати, і у нас було кілька десятків таких випадків у підтримці.

Ми попрацювали і над відновленням окремих файлів. Зокрема, тепер вони дуже швидко шукаються в локальному архіві.

Де взяти реліз

Ось сторінка російського релізу. Як і в минулій версії, можна придбати підписку (що актуально для тих, хто бэкапит в наше хмара) або ж версію «раз і назавжди», але з лімітом 5 безкоштовних гігабайт в хмарному (це варіант для тих, хто бэкапит в локальній мережі або на диски у шафу). Ліцензії бувають на 1, 3 або 5 пристроїв (Mac або Win) і плюс на необмежене число мобільних пристроїв.

Ну, і підсумую. Зараз наш реліз можна використовувати для повноцінного бекапа на будь-який локальний або мережевий носій, у хмару, для синхронізації даних на різних комп'ютерах, для ряду сисадминских завдань (зокрема, улюблений багатьма Try&Decide на місці), для Facebook, для бекапа мобільних пристроїв iOS і Android (на Win-планшети планується десктопна версія), для швидкого подмонтирования бекапів як віртуальних дисків, відновлення і переїзду системи, швидкого пошуку окремих даних в архіві.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.