Linux deploy для чего

Практическое применение Linux Deploy на десктопах

Несмотря на то, что изначально Linux Deploy задумывался как приложение для Android, со временем появляются и другие варианты его применения. С появлением Linux Deploy CLI стал доступен ряд возможностей, открывающих новые сферы применения этого инструмента.

Linux Deploy CLI — это приложение с интерфейсом для командной строки, предназначенное для автоматизации процесса установки, конфигурирования и запуска GNU/Linux дистрибутивов внутри контейнера chroot. Приложение может работать как в обычных десктопных Linux-дистрибутивах, так и на мобильных платформах, основанных на ядре Linux, при условии соблюдения необходимых зависимостей (все зависимости могут быть собраны статически). Приложения из Linux-дистрибутива запускаются в chroot окружении, работают параллельно с основной системой и сопоставимы с ней по скорости. Поскольку работа Linux Deploy базируется на системном вызове ядра Linux, то в роли «гостевых» систем могут выступать только дистрибутивы Linux.

Приложение может работать в двух режимах: с правами суперпользователя (chroot) и без них (proot). В обычном режиме доступны все поддерживаемые типы установки: установка в файл, на раздел диска (логический диск), в POSIX совместимую директорию и в оперативную память (tmpfs). В режиме proot доступна установка только в директорию, а также появляется ряд ограничений:

• все пользователи внутри контейнера имеют полный доступ ко всей файловой системе контейнера, а владельцем всех файлов и каталогов является текущий пользователь;
• нет доступа к привилегированным операциям с системой, например, не работает ping, ulimit и т.п.;
• приложения могут работать только с номерами сетевых портов выше 1024;
• если приложение в своей работе использует системный вызов chroot, то его необходимо запускать через специальную утилиту fakechroot, например fakechroot /usr/sbin/sshd -p 2222.

Приложение поддерживает автоматическую установку (базовой системы) и начальную настройку дистрибутивов Debian, Ubuntu, Kali Linux, Arch Linux, Fedora, CentOS, Gentoo, openSUSE и Slackware. Установка Linux-дистрибутива осуществляется по сети с официальных зеркал в интернете. Также поддерживается импорт любой другой системы из заранее подготовленного rootfs-ахрива в формате tar.gz, tar.bz2 или tar.xz. Приложение позволяет подключаться к консоли установленной системы (контейнеру), а также запускать и останавливать приложения внутри контейнера (есть поддержка различных систем инициализации и собственных сценариев автозапуска). Каждый вариант установки сохраняется в отдельный конфигурационный файл, который отвечает за настройку каждого контейнера. При необходимости, контейнеры можно запускать параллельно. Можно экспортировать конфигурацию и сам контейнер как rootfs-архив для последующего развертывания этого контейнера без повторной установки и настройки.

Вообще, идея Linux Deploy возникла из желания получить легкий и удобный инструмент для быстрого развертывания Linux-дистрибутива, который можно было бы использовать для целей разработки, тестирования или обучения, а затем быстро удалить его, не внося изменения в основную (хост) Linux-систему и не рискуя ее целостностью. Благодаря программе PRoot стало возможным создавать контейнеры для запуска Linux-приложений без прав суперпользователя (root), а также использовать программную эмуляцию QEMU для запуска приложений с отличающийся от хоста архитектурой без необходимости поддержки модуля binfmt_misc на уровне ядра.

Так вышло, что на моей основной работе с 2011 года используются компьютеры с Debian. Местные разработчики периодически нуждаются в системе для запуска и тестирования своих веб-приложений (в основном Java, PHP, Python). Для этих целей обычно использовались виртуальные системы либо на базе VirtualBox, либо в местном «облаке» Proxmox, либо Docker. Основным недостатком VirtualBox является его требовательность к ресурсам компьютера, большой размер VDI образа диска, относительно невысокая скорость работы и вероятность поломки образа VM при неправильном выключении системы. Недостатком при использовании «облака» можно назвать необходимость самому администратору обслуживать запросы пользователей на создание таких систем, а также расходование ресурсов «облака» на второстепенные задачи. Для работы с Docker требуются права суперпользователя.

В этом месяце был проведен эксперимент, PHP-разработчикам их виртуальный сервер был заменен на LD-контейнер. Были подготовлены два контейнера на базе Debian: Apache + PHP + OCI8 и Apache + PHP + MySQL + PhpMyAdmin. Контейнеры были размещены на общем сетевом диске в локальной сети, размер каждого контейнера составил около 150 МБ.

Что от этого получил администратор:

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

Что получил разработчик:

• развертывание, запуск и управление системой в контейнере осуществляется без участия администратора одной командой;
• развертывание контейнера из заранее подготовленных архивов осуществляется по сети менее чем за минуту;
• запуск и остановка контейнера (Веб-сервер + БД) происходит мгновенно, не нужно ждать запуска операционной системы;
• нет риска повредить контейнер, если забыл его отключить при выключении компьютера, т.к. образ системы представляет собой обычный каталог без собственной файловой системы;
• компьютер работает быстрее, т.к. ресурсы тратятся только на запускаемый софт в контейнере, а не на всю операционную систему (в нашем случае это порядка 50 МБ, вместо 500 МБ в VirtualBox).
• проверка работоспособности ПО прямо из каталога IDE без необходимости заливать его на сервер, для этого достаточно подключить к контейнеру необходимый каталог основной системы.

А теперь более подробно о том, как этого добиться. Далее будет приведена инструкция по подготовке и развертыванию LD-контейнера.

Для запуска контейнеров без прав суперпользователя необходимо установить PRoot:

Загрузка и установка Linux Deploy CLI:

Создание конфигурации с именем «linux» для развертывания базовой системы Debian Wheezy (64 бита):

Посмотреть сохраненную конфигурацию:

Запуск развертывания новой системы:

Подключение к консоли контейнера под пользователем root (для выхода команда exit):

Далее можно установить и настроить необходимый софт в контейнере, однако следует учитывать описанные ранее особенности. Например, для запуска Apache нужно поменять его порт (файл /etc/apache2/ports.conf) на 8000, установить пустой параметр APACHE_ULIMIT_MAX_FILES=» » (файл /etc/apache2/envvars), а сам apachectl запускать из-под обычного пользователя (не root).

Настройка автозапуска на базе системы инициализации SysV:

Параметры: INIT_LEVEL — уровень инициализации SysV, INIT_USER — из-под какого пользователя запускать сервисы (по умолчанию это root), INIT_ASYNC — запускать сервисы параллельно.

Подготовка конфигурации, экспорт ее и экспорт контейнера в rootfs-архив (поддерживаются tar.gz, tar.bz2 и tar.xz архивы):

Экранирование «\$» позволяет сохранять в конфиг имена переменных, а не их значения. Таким образом при импорте конфига эти переменные будут автоматически заменены на соответствующие значения, которые могут отличаться от текущих. Теперь есть два файла (linux.conf и linux.tgz), которые можно использовать при импорте контейнера на другом компьютере:

Подключить к контейнеру каталог основной системы (каталог

/www подключить в /var/www контейнера):

Запуск контейнера (для SysV выполняются сценарии /etc/rcN.d/SXXname start):

Остановка контейнера с освобождением ресурсов (для SysV выполняются сценарии /etc/rc6.d/KXXname stop):

В итоге получилось решение, которое удовлетворяет потребностям как разработчиков, так и администраторов. Исходные коды приложения Linux Deploy доступны под лицензией GPL версии 3.

Источник

Превращаем старый телефон на Android в резервный сервер с помощью UrBackup/Linux Deploy. Часть 1

Сегодня я покажу вам, как запустить полноценный резервный сервер на рутованном телефоне Android с помощью UrBackup и Linux Deploy. Пластиковый мусор уже заполонил все вокруг, а в добавок к нему очередной глобальной эко-проблемой становятся еще и электронные отходы. Так зачем выбрасывать прекрасный, пусть даже потрескавшийся и поношенный, телефон?

К тому же этот старый телефон:

1. Вероятно, даже не настолько стар (покупаете ли вы новый ПК каждые 1-2 года?).
2. Возможно, снабжен 4-8 ядрами и

4Гб ОЗУ, а также определенно имеет встроенный ИБП.

Подключите к нему внешний винчестер, и он станет отличным кандидатом на резервную систему для всей домашней сети!

Предупреждение: это проект из разряда «потому что могу». И поскольку здесь мы все-еще работаем с Android, то, помимо ряда ограничений, нам также потребуется обойти несколько препятствий. Это решение станет не самым простым способом создания бэкапа для домашней сети, как и не лучшим вариантом использования UrBackup. И все же! Как только настройка будет завершена, вы получите очень простой способ управления резервными копиями для нескольких машин, а также добавления хранилища.

Список ограничений этой конфигурации

Надежность и безопасность

Linux Deploy создает для вашего экземпляра Linux контейнер chroot . По сути, это песочница, но когда вы даете Linux Deploy root-доступ, то расширяете размер песочницы, охватывая большинство закоулков системы телефона. Самая серьезная уязвимость будет исходить из рутованной ОС Android в связи с недостатком обновляемых патчей безопасности. Некоторые телефоны можно обновлять после получения root-доступа, но тогда после обновления придется делать рутинг повторно.

При условии, что вы отключаете все возможные разрешения и службы, а также избегаете использования интернета из ОС Android, поверхность атаки остается очень узкой (по сути, ограниченной любой оставшейся фоновой службой, не допускающей отключение). Чтобы сохранить устройство в безопасности, следует поддерживать актуальность экземпляра Debian с помощью apt update && apt upgrade и рассмотреть вариант установки антивируса, как и на любой другой сервер. И все же, эта конфигурация не отличается высокой безопасностью. Если вам нужна глубокая защита на каждом уровне домашней сети, то она вам не подойдет.

Постоянное подключение смартфона к сети может сократить срок службы батареи, но само по себе это не опасно. Вообще перезаряжать литиевые аккумуляторы вредно, но в телефонах используются контроллеры заряда, которые останавливают зарядку, когда батарея заполняется. (Подробнее об управлении питанием можно почитать здесь). Причиной же вздутия зачастую служит заводской дефект или чрезмерный нагрев. Если у вас б/у телефон, и вздутие батареи не наблюдается, то скорее всего брака в нем нет.

Для избежания перегрева устройства следует разместить его в хорошо вентилируемом месте, отслеживать загрузку сервера, а также использовать качественную зарядку. Если телефон вдруг нагреется до горяча, отключите его и подумайте об увеличении интервалов между бэкапами, чтобы снизить нагрузку. Если телефон горячий постоянно, то лучше будет подыскать для сервера другое устройство. Как и с любым обычным сервером, добавьте в список его периодического обслуживания аппаратные проверки.

Если вы все еще здесь, то вот наш план действий:

1. Получить root-права на телефоне. Я не стану вдаваться в подробности по этому пункту, а просто направлю вас к инструкции Magisk (англ.), где все это подробно расписано.
2. Установка Linux Deploy и развертывание Debian Buster.
3. Установка UrBackup Server.
4. Подключение клиентов.

Учтите, что в этом руководстве я буду принимать очень специфичные решения в отношении конфигурации, большинство из которых нацелены на наладку работы с Debian и Android в среде chroot .

Требования

В моем случае используется Pixel 4a (8ЦПУ/6Гб ОЗУ). Конкретная модель телефона большого значения не имеет, но при этом у каждой могут быть свои особенности. Если ваш телефон выпущен в течение последних пяти лет, то он наверняка имеет достаточные характеристики. Если же вы о них не знаете, то лучше уточните. Я рекомендую не менее 4 ЦПУ и 2 Гб ОЗУ. Этого должно быть достаточно для большинства домашних сетей, но вам нужно будет оценить требования в соответствии с планируемым объемом резервного копирования. Также учитывайте, что часть ресурсов будет забирать Android система хоста.

Опять же направлю вас к Magisk для рутинга телефона. Вот некоторые советы:

— Убедитесь, что используете файл boot.img , связанный с текущей версией загрузчика вашего телефона.

— Если устройство работает на Android 11, и процедура Magisk не сработала, понизьте версию ОС до Android 10 и повторите попытку. Я убил целый день, воюя с Android 11 на своем Pixel 4a.

— Если вы не хотите использовать именно Magisk, будьте ОЧЕНЬ осторожны с другими аналогичными инструментами. Как показывает практика, многие приложения на рынке оказываются шпионскими или вирусными. Могу посоветовать еще CF-Auto-Root, но скачивать этот инструмент нужно только с проверенного ресурса.

Дополнительное оборудование (рекомендуется)

Несмотря на то, что, в принципе, бэкапы можно сохранять на SD-карте, делать это НЕ желательно. SD-карты медленнее, менее надежны и не могут обрабатывать процедуру записи в течение длительного времени. Если вы планируете сделать резервную копию на SD-карту, то сразу имейте в виду, что в течение года она даст сбой (а при большом объеме данных даже в течение месяца).

Шаг 1. Установка Linux Deploy и развертывание Debian Buster

A. С рутованного телефона перейдите на GitHub и скачайте .apk пакеты для Linux Deploy и BusyBox. Установите эти приложения.

B. После установки откройте BusyBox. Выберите Install . По завершению обратите внимание, куда установилась BusyBox. В данном случае мы видим, что установка произведена в /system/xbin . Этот путь вам потребуется позже.

C. Откройте Linux Deploy и перейдите в настройки через иконку в нижнем правом углу.

c. Настройте следующее:

Если в дальнейшем вы не собираетесь расширять хранилище, то можете смонтировать внешнее блочное устройство здесь, добавив его путь в точки монтирования. Если же расширение хранилища в ваши планы входит, тогда вы можете подождать публикации Части 2, чтобы разбить его на разделы и отформатировать в логический том.

Все, что вы смонтируете здесь, будет непосредственно доступно при загрузке, но не будет доступно для разбиения по разделам и форматирования. Тем не менее учитывайте, что имя вашего блочного устройства ( /dev/block/sdX ) при перезагрузке телефона может измениться, в случае чего вам понадобится проверить/изменить конфигурацию. Если же вы смонтируете логический том, то его имя уже не изменится, и о проверке вам беспокоиться не придется.

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

D. Вернитесь обратно на экран приветствия и выберите верхнее левое меню. Далее выберите Settings и промотайте вниз до PATH variable . Именно здесь нужно установить путь установки BusyBox из шага 1.B. После установки PATH variable выберите Update ENV .

E. Вернитесь на экран приветствия и выберите верхнее правое меню. Жмите Install . Перед вами отобразится живой лог установки. По завершению в конце лога будет прописано deploy . Выберите START в нижнем левом углу экрана. Теперь у вас на телефоне запущен сервер Debian!

Шаг 2. Установка сервера UrBackup

A. Подключитесь к только что развернутому серверу по SSH.

IP-адрес будет тот же, что и у телефона, порт будет 22, а авторизоваться вы сможете с помощью учетных данных, установленных в шаге 1.с. Оставшаяся часть руководства предполагает, что вы авторизованы как корневой пользователь. Свой IP можете увидеть, открыв Linux Deploy:

B. Обновите систему:

C. Скачайте пакет .deb для UrBackup:

Это последняя стабильная версия на момент написания. Возможные обновления можете посмотреть на странице скачивания.

D. Установите пакет:

В ходе установки система спросит, где должна размещаться резервная директория.
Запомните ее путь для следующего шага. Если вы уже смонтировали хранилище в шаге 1.c, установите в качестве этого пути точку монтирования.

E. Создание директории для бэкапа.

В этом примере я установлю директорию как /mnt/backup . Если вы смонтировали хранилище ранее, то директория уже будет существовать. Если же нет, создайте ее:

(Так UrBackup сможет производить запись в эту директорию.)

F. Установка скрипта запуска.

В среде chroot мы не сможем вызывать systemd , поэтому потребуется запускать эту службу вручную:

Но вместо того, чтобы вводить это постоянно, мы просто создадим скрипт:

Скопируйте его в файл:

Сохраняемся и выходим.

Это приведет к появлению лога запуска сервера. Нажатие CTRL-C остановит службу, поэтому откройте еще одну сессию SSH.

Для остановки службы нужно будет просто ее завершить:

H. Добавление cronjobs .

Поскольку мы не можем «активировать» службу UrBackup стандартным способом, то установим задачу cron для запуска при загрузке. В добавок к этому, если вы в дальнейшем отключите внешнее хранилище или перезагрузите телефон, то разрешения для резервной директории могут отмениться. Чтобы гарантировать их установку при загрузке мы добавляем cronjobs :

Добавьте эту задачу:

Сохраните и выйдите.

I. Перейдите в веб-интерфейс.

В браузере перейдите на порт 55414 сервера: YOUR_SERVER_IP:55414

Шаг 3. Подключение клиентов

A. В нижней правой части окна состояния кликните Add new client :

B. Выберите Add new Internet client/client behind NAT и введите имя клиента:

Им должно быть имя хоста нового клиента.

C. Установка клиента.

• Для клиентов Windows:

Скачайте установщик по ссылке «Download preconfigured client installer for Windows» и следуйте его инструкциям.

• Для клиентов Linux:

Обратите внимание на «Default authentication key» вверху. Он вам понадобится.

Авторизуйтесь на клиенте и запустите скрипт установки (НЕ запускайте скрипт, предоставленный сервером):

(Проверьте наличие последних версий клиентов здесь).

В процессе установки скрипт попросит выбрать механизм сохранения снимков состояния. Введите 2 для «LVM — Logical Volume Manager snapshots»:

На телефоне с Android единственной реальной альтернативой будет Dattobd. BTRFS в данном случае не поддерживается, а пренебрежение механизмом сохранения снимков системы очень нежелательно (вам придется останавливать на время резервного копирования все службы, взаимодействующие с файлами, выбранными для бэкапа).

Я попробовал использовать dattobd, но постоянно сталкивался с разными ошибками. Учитывайте, что вам нужно будет установить dattobd и на сервер, и на клиентов. При этом сервер и клиенты должны быть с ним совместимы. Для установки dattobd на устройство Android (ARM64) вам придется скомпилировать исходный код, в чем я не преуспел. Тем не менее у вас может оказаться другой случай, в зависимости от модели телефона или используемого дистрибутива. Мне также не удалось установить его в Ubuntu 20.10, при том что с Ubuntu 20.04 все получилось отлично.

По завершению установки убедитесь, что клиент запущен:

Если не запущен, запустите:

В завершении подключите клиента к серверу:

Убедитесь, что именем хоста, настроенным на шаге 3.B, является YOUR_CLIENT_NAME , а ранее сгенерированным сервером ключом YOUR_DEFAULT_AUTHENTICATION_KEY .

D. Настройка сервера.

Вернитесь в веб-интерфейс. Здесь вы можете обнаружить, что клиент не подключен. Кликните Settings в верхней панели навигации:

В Settings перейдите на вкладку Internet и убедитесь, что установлено следующее:

Если у вас все клиенты локальные, то можете убрать галочки Do image backups over the internet и Do full file backups over the internet .

Промотайте вниз и кликните Save .

E. Настройка директории резервного копирования:

Здесь же в Settings кликните Client settings . Отметьте Separate settings for this client , а в строке Default directories to backup вкладки File Backups укажите директории для резервного копирования.

Можно добавить несколько директорий через ; .

Здесь также настравиваются интервалы резервного копирования.

Кликните Save внизу.

Для клиентов Linux это также можно настроить из командной строки клиента:

F. Вернитесь в веб-интерфейс.

Теперь клиент должен быть подключен. В блоке File backup status может отобразиться No paths to backup configured , но это нормально. Такое сообщение будет отображаться до завершения первого резервного копирования. Также имейте ввиду, что если вы подключили клиента Linux, то бэкапы образов поддерживаться не будут. Тем не менее вы можете просто сделать резервный образ с клиента Linux и указать директорию этих образов для резервного копирования сервером.

Можно запускать первое резервное копирование!

Продолжение следует.

Если вы уже подключили хранилище и довольны конфигурацией, то на этом все. Если же вы хотите добавить хранилищу гибкость, то жду вас в Части 2. LVM (менеджер логических томов) позволяет добавлять или удалять хранилище без необходимости переноса данных на другое устройство хранения. Вы можете просто добавить нужный объем хранилища или удалить его неиспользуемую часть, которую хотите задействовать где-то еще. В Части 2 мы в основном будем работать с LVM. Это хоть и не сложно, но все равно является определенным процессом.

Советы

1. Отключите разрешения для всех служб, для которых это возможно. Разрешения кроются в различных местах настроек, так что уделите время их поиску. Также отключите или деинсталлируйте все приложения, какие можете. Это позволит снизить общую нагрузку на ОС Android.

2. Будьте осторожны с обновлениями Android. При успешном выполнении они скорее всего отменят root-доступ к устройству, и рутинг придется делать повторно. Если же вы хотите произвести обновление, то сохраните резервную копию файла .img , который Linux Deploy создала для контейнера Linux. Если в итоге вы полностью зачистите телефон, то достаточно будет переустановить Linux Deploy и сопоставить ее с резервным образом.

3. Поскольку вы не сможете обновлять телефон часто, то следует ограничить использование ОС Android. Не заходите в браузеры и не скачивайте лишние приложения, чтобы ограничить связь устройства с интернетом. Вы можете (даже рекомендуется) поддерживать версию Debian обновленной и использовать интернет по необходимости.

1. Когда телефон блокируется, Android переводит его в режим простоя. Это замедляет производительность ЦПУ. Чтобы экран был активен постоянно, перейдите в настройки приложения Linux Deploy и отметьте пункт Wake Lock . Найти его можно, нажав на верхней левой иконке настроек и перейдя в Settings . Обратите внимание, что эта функция действует только, когда приложение открыто.

2. Если вам потребуется перезагрузить образ контейнера, просто убедитесь, что расположение целевого образа ( .img ) установлено в Installation path в Properties . Найти этот пункт можно через нижнюю левую иконку настроек. Убедитесь, что указанный в свойствах дистрибутив совпадает с дистрибутивом файла .img . Если он не совпадает, Linux Deploy перезапишет файл .img с настройками из Properties . Затем вернитесь на основной экран и выберите из верхнего правого меню Install .

Для деинсталляции сервера UrBackup выполните:

Для деинсталляции клиента UrBackup выполните:

Если вы удалите клиента из веб-интерфейса сервера, то увидите уведомление «This client is going to be removed… Clients are removed during the cleanup in the cleanup time window». Это означает, что он еще не удален, и вам придется подождать, пока сервер не запустит плановую очистку, в ходе которой и произведет удаление. Такой вариант может вас не устроить, если вы работаете над устранением неисправности, и требуется неотложное повторное добавление клиента. Для ручной очистки остановите службу UrBackup из CLI:

И снова запустите UrBackup:

1. «Volume group „root“ not found»
Если вы делаете бэкап директорий внутри контейнера, то в логах сервера может возникнуть ошибка «Volume group „root“ not found», и создание резервной копии также закончится с ошибками. Ничего страшного, если ваши бэкапы остаются нетронутыми. Так как клиент UrBackup запускается из контейнера, он не сможет проследить свой путь до корня хоста.

2. Мгновенный сбой; без логирования ошибок
Если резервное копирование дает мгновенный сбой, то скорее всего проблема с подключением. Проверьте машину клиента и убедитесь, что UrBackup на нем работает без сбоев. Логи клиента располагаются в /var/log/urbackup.log . Также можете проверить service urbackupclientbackend status . Если вы не можете определить причину проблемы, деинсталлируйте и повторно установите клиента.

3. «ERROR: No permission to access [Backup Directory]»
Если вы смонтировали внешнее устройство хранения напрямую и столкнулись с ошибками разрешений, то вам может потребоваться запустить службу от лица root-пользователя. Сначала проверьте разрешения директории бэкапа для пользователя и группы. Если вы не можете изменить разрешения для пользователя “urbackup” и группы “urbackup”, как в шаге 2.E, то сможете определить запуск UrBackup от лица root-пользователя. Для этого измените последнюю строку файла конфигурации ( /etc/default/urbackupsrv ) с urbackup на root и перезапустите сервер.

4. Ошибки ввода/вывода
Если вы не отсоединяли внешнее устройство хранения и получили ошибки ввода/вывода в процессе резервного копирования, то возможно это устройство повреждено или работает со сбоями. Если перезапуск телефона не решает проблему, скорее всего время подыскать новое блочное устройство.

5. Прочие ошибки
Если вы отклонились от руководства и не выбрали в качестве механизма резервного копирования “LVM”, убедитесь, что клиент и сервер совместимы с выбранной вами альтернативой. К примеру, если на клиенте установлен dattobd, а на сервере нет, резервное копирование провалится.

Остались вопросы по UrBackup? Нужна помощь? Обратитесь к полноценному руководству Administration Manual. Это щепетильный проект, и для каждого телефона возникнут свои сложности, так что, помимо обсуждения в комментариях, можете почитать форумы сообщества UrBackup.

Источник