Про релиз и разработку 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, чтобы она нормально загрузилась и поддерживала большие диски. Сейчас этот выбор возникает у пользователей, которые хотят накатить старую ОС на новую машину. Вот чуть больше деталей о низком уровне с разными ветками конвертаций:

Естественно, раз мы так хорошо разобрали нижний уровень, можно сделать аварийное средство и прямо на локальном компьютере. Мы создаём новую ветку загрузки в EFI, куда пишем свой модифицированный компактный Linux и средства восстановления. Если у вас что-то накрывается, можно попробовать загрузиться с того же компьютера по альтернативной ветке и восстановиться из бэкапа. Это защищает от лени пользователей, которые не хотят носить жёсткий диск к компьютеру для бэкапа по расписанию (и при этом не бэкапятся в облако). Тем не менее, конечно же, от сложных отказов железа это не спасёт, поэтому отдельный носитель с вашими данными всё ещё важен.

Ещё одна интересная вещь – автомаппинг. Он у нас уже был, но в этом релизе стал куда умнее. Дело в том, что восстановление сейчас происходит почти с любого носителя, и даже таких носителей может быть несколько. Например, сетевой ресурс, локальная копия и что-то ещё. Если система существенно поменялась со времени последней итерации бэкапа (например, вы накатываете бэкап годовой давности, такое случается, к примеру, при установке нового рабочего места в некоторых компаниях), то нужно правильно понять, куда и как восстанавливать. Типичный пример – другая разметка жёсткого диска. Ещё случай: когда бэкап старый, но от этого компьютера, и не хочется ждать полного восстановления, то можно попробовать исключить то, что явно не повредилось. Чтобы не ждать пару часов. Наш код автомаппинга позволяет быстро получать разницу и правильно восстанавливаться в таких случаях.

Сетевой бэкап

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

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

Мобильный бэкап

Мы довольно сильно перебрали всю технологию мобильного бэкапа в новом релизе. Главный момент – мы прекрасно понимаем, что далеко не все хотят отдавать копию своих данных в чьё-то облако, поэтому предусмотрели функцию локального бэкапа. Старый облачный вариант тоже доступен, но локальный бэкап был очень и очень востребован. У нас был серверный код в корпоративных разработках (как раз сделанных для параноиков и бэкапов корпоративных устройств внутри сети), и мы решили переиспользовать его. Чтобы было понятнее, сначала расскажу, как работает новая схема:

1. Вы приходите с телефоном домой (точнее, в одну и ту же Wi-Fi сеть, где есть ваш десктоп с базовой версией Acronis True Image).
2. Приложение на телефоне активируется (по расписанию iOS или из фона Android) и определяет возможность подключения к компьютеру в текущей сети. Для этого телефон начинает искать основной хост, чтобы установить SSL-соединение.
3. После этого начинается итеративный бэкап – всё, изменённое за прошедший день, разбивается на части и заливается короткими чанками. Предполагается, что пользователь проводит в своей домашней сети довольно много времени, поэтому используются фоновые средства обеих операционных систем: например, в случае iOS мы можем открывать «окна» на 30 секунд, заливать короткий чанк и снова ждать следующего временного окна.

Сложности были почти везде. Во-первых, конечно же, трафик, активация из фона и энергопотребление на новых версиях iOS и Android. В целом, это решается уже относительно просто, и готовые рецепты были. После первого полного бэкапа, как правило, речь о нескольких мегабайтах новых фотографий, паре килобайт контактов и другой пользовательской информации. Мы переписали код, отвечающий за заливку: чанки не рвутся, хорошо докачиваются даже после суточного перерыва в работе сети. Контакты теперь льются первыми по приоритету. Заодно обновили облачную заливку (в случае, если бэкап не локальный), теперь контакты видно сразу после того, как они были получены, даже не дожидаясь конца чанка.

Довольно нетривиально было установить соединение между телефоном и десктопом. Мы попробовали много методов, пока не остановились на QR-кодах – нужно сфотографировать QR-код с экрана десктопа в приложении. Но даже в этой версии было довольно сложно: поначалу мы зашивали в визуальный код сразу полноценный SSL-сертификат, и далеко не все библиотечные читалки его разбирали. Пришлось сильно уменьшить QR и установить новый протокол обмена ключами.

Сам дискаверинг делается сразу разными путями, поэтому даже если вы запускаете операционную систему внутри виртуальной машины (как это любим делать мы), телефон найдёт свою пару. Частый домашний случай, это когда телефон подключён по Wi-Fi, а ноутбук подключён локальным кабелем. Резолв идёт по IP4, бонжур-сервисам и имени хоста. К сожалению, российские пользователи 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-планшеты планируется десктопная версия), для быстрого подмонтирования бэкапов как виртуальных дисков, восстановления и переезда системы, быстрого поиска отдельных данных в архиве.

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

Автор: Acronis

Источник