Migrate data from device to device

Rondarius

I did a new backup on my phone and tried to migrate to another Nexus 5. The wifi nor the mobile network works, notes, the clock app, the calculator an gallery does not work either. But all my contacts and messages has been imported. I have not tried with other apps.

kwah

Found this topic again after a while, since screen of my bq 4.5 is not responding to touches anymore.

Tried to do backup as explained by @Flohack in Migrate data from device to device. Below are my observations and notes.

Sequence adb reboot recovery followed by adb pull /data/system-data have not copied anything, because it errored out:

$ adb pull /data/system-data
adb: error: failed to copy '/data/system-data/lib/ufw/user6.rules' to './system-data/lib/ufw/user6.rules': remote Permission denied

Added adb root to the mix to handle "Permission denied", and after a bit of copying I've got to the next error:

$ adb pull /data/system-data
adb: error: failed to copy '/data/system-data/var/log/installer/media-info' to './system-data/var/log/installer/media-info': remote No such file or directory

Looks like permission errors can be resolved. Why files are missing?

After digging a bit (cross-referencing results of broken symlinks in recovery and normal environments, looking into mounted filesystems and layout) I think it is because of "dangling" links pointing to nowhere for the following reasons:

Parts of the file system are not available in the recovery environment, because not mounted, like many click packages
There are broken links in the systems (links that are broken also in normal boot) accumulated through its lifetime due to bad behaviors of install/uninstall/upgrade tools and SW in general

All the above leads me to the following:

Looks like adb pull should be run at least in rooted recovery (maybe it should also use -a switch to preserve permissions?)
adb pull cannot handle "dangling" links

So in my experience adb pull is not a good tool to make a backup.

I would really appreciate, if someone could comment on the above and tip better and working ways to backup data so that it can be restored on the other device.

Currently I am looking into the option of creating backup on external sdcard using tar + gzip.

kwah

Here is an instruction that worked for me to transfer data from Bq 4.5 to Fairphone 2

Required:

SD-card
Both device should have SD-card slot
adb tools

Preliminary Steps

Check that your SD-card is accessible on both devices
While device is booted and connected to PC, figure out SD-card info needed for accessing it when device is booted into recovery:
- In adb shell issue mount command
- Note the device that is mounted to /media/phablet/<...>, example in my case
```
<... -removed>
/dev/mmcblk1p1 on /media/phablet/ubackup type vfat (rw,nosuid,nodev,relatime,uid=32011,gid=32011,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
```
  Note that device /dev/mmcblk1p1 is mounted to /media/phablet/ubackup, which is SD card in my case, expect that last part of /media/phablet/ubackup will be different in your case. Make note of the device name (/dev/mmcblk1p1).

Backup data to SD card

If not done before: connect phone to PC while adb is running
Reboot phone into recovery: adb reboot recovery
Acquire root: adb root
Activate shell: adb shell
In the root shell (command prompt ends with # sign)
5.1 Mount SD card with the following command (note that /dev/mmcblk1p1 above becomes /dev/block/mmcblk1p1) :
```
mount -t vfat -o flush,utf8 /dev/block/mmcblk1p1 /sdcard
```
5.2 Backup system-data and user-data partitions (commands below will also create log files, that can be examined for possible errors) :
```
tar -czpv -f /sdcard/system-data.tgz /data/system-data/ >/sdcard/system-data.out 2>/sdcard/system-data.err
```
```
tar -czpv -f /sdcard/user-data.tgz /data/user-data/ >/sdcard/user-data.out 2>/sdcard/user-data.err
```
5.3 Check created archives. The commands below should not produce any output:
```
tar -xzv -f /sdcard/system-data.tgz >/dev/null
```
```
tar -xzv -f /sdcard/user-data.tgz >/dev/null
```
Power down your device (example for adb shell) :
```
shutdown -P now
```

Restore data from the backup on SD card

For me it was repeat of the sequence from the previous section but with the target device connected. The only difference was in the final step.

In principle, external card reader device may require different device name in mount command of step 5.1 options. You can check it as indicated in the Preliminary Steps section above.

Repeat steps 1. ... 5.1 to make SD card accessible.

In the root shell (command prompt ends with # sign)
5.1 Mount as in the 5.1 above
5.2 Restore data:
```
tar -xzv -f /sdcard/system-data.tgz
```
```
tar -xzv -f /sdcard/user-data.tgz
```
Reboot your device

flohack

TLDR; In case you get pull errors, leave system data out. You will loose all your settings in system-settings etc but the app data is in user-data and that folder must always be pullable without issues. You might want to delete the contents of .cache before to make it smaller...

kwah

@Flohack said in Migrate data from device to device:

TLDR; In case you get pull errors, leave system data out. You will loose all your settings in system-settings etc but the app data is in user-data and that folder must always be pullable without issues. You might want to delete the contents of .cache before to make it smaller...

Well, loosing all settings in system-settings etc. looks like a big deal. One needs to reconfigure everything then.

As far as I understand, system data is not and will not be pullable unless the tools are fixed with respect to handling "dangling" symlinks.

Unfortunately, I had issues with user-data as well.

By the way, do you agree that in the original instruction adb root should be added? I don't know which phone you used as a reference to create the instruction, but I have noticed that adb shell on Fairphone 2 has root enabled by default.

Looks like we start to get requirements for user data lint tool / backup prepare tool (maybe something for UT Tweak):

Cleanup caches (is it safe to remove qmlcache/qml_cache/api_cache and friends?)
Remove "dangling" sym-links
...

flohack

Hmm I am wondering maybe its your adb version that makes that issue, can you check which one you have? Try adb version...

You cannot remove dangling symlinks, as they are probably used in the live image. I will try again what I did. adb shell should give root on all devices in recovery.

BR Florian

kwah

I used adb from Ubuntu 19.04 repositories:

$ adb version
Android Debug Bridge version 1.0.39
Version 1:8.1.0+r23-5
Installed as /usr/lib/android-sdk/platform-tools/adb

$ apt-cache policy adb
adb:
  Installed: 1:8.1.0+r23-5
  Candidate: 1:8.1.0+r23-5
  Version table:
 *** 1:8.1.0+r23-5 500
        500 http://archive.ubuntu.com/ubuntu disco/universe amd64 Packages
        100 /var/lib/dpkg/status

Concerning root: I had to explicitly request it on Bq 4.5. On FP2 adb shell was with root access enabled by default.

thepeter

Consider this my "log" how I've transferred data from phone to phone (worked between two nexus 5 devices) without SD card
I hope it will be helpful for somebody - but I've basically used combination of two methods described before plus some man pages
NOTE: both devices have ubports image installed and are prepared for adb access ()

Source device

After connecting source device on PC commands in terminal as follows:

Reboot phone into recovery: adb reboot recovery
Acquire root: adb root
Activate shell: adb shell (command prompt will change to # sign)
Backup system-data (this will also create log files, that can be examined for possible errors) :
tar -czpv -f /system-data.tgz /data/system-data/ >/system-data.out 2>/system-data.err
NOTE: I've just put these files into root directory and it went just fine and pulled just one file into connected computer since adb has much better chance to transfer one big file without errors than many small ones
logout from shell to your terminal (Ctrl+D)
NOTE: I am assuming computer is linux with root access etc.
this sub-step can be done before step 3
5.1 go to directory where backup data are to be stored in PC (using cd and mkdir commands)
transfer data from phone to PC adb pull /system-data.tgz
6.1 it is good idea to have logs copied too adb pull /system-data.out and adb pull /system-data.err but it is not necessary
steps 3. to 6. repeat but with user-data instead of system-data excluding .cache folder
(so commands will look like tar -czpv -f /user-data.tgz /data/user-data/ --exclude='*data/user-data/phablet/.cache*' >/user-data.out 2>/user-data.err, adb pull /user-data.tgzetc.)
NOTE: data which can be transferred by MTP should be moved that way since process of packing can take quite long for user data and may even stop/fail (e.g. not stopping process, just waiting and overheating battery, because all outputs are transferred to log files) if there is not enough space for package

Destination device

Reboot phone into recovery: adb reboot recovery
Acquire root: adb root
Push archived data from PC to phone (root folder) adb push ./system-data.tgz / and adb push ./user-data.tgz /
NOTE: in case of failure pushing both files and then unpacking both in adb shell it is possible to work the process "per partes" so following steps 4. and 5. will be done after each push and removing archive from phone (rm ./system-data.tgz in adb shell and then returning by Ctrl+D to PC shell)
Activate shell: adb shell (command prompt will change to # sign)
Extract archives tar -xzv -f /system-data.tgz and tar -xzv -f /user-data.tgz
Restart phone, unplug, recharge (battery will be probably rather low ) check data and switch SIM card

PS:

After finishing and documenting the process, I'we found out that WiFi settings has not been transferred to destination device those must be somewhere in .cache folder then (I don't really mind, messages, apps, contacts and other settings are quite enough for me)

TartanSpartan

This is great information and thank you guys for the guide. It truly helped me migrate from an M10 with a shattered screen (but the touchscreen still works) to a new one with bigger storage. But I'd like to make my own recommendation on top of this. @thepeter recommends to exclude *data/user-data/phablet/.cache*. This makes sense in general (most app cache directories are pretty disposable and will be rebuilt automatically and as necessary on your new device), but I would take an extra (as in, separate from the main archives you compress) .tgz archive of .cache/libertine-container/ (if you have one or even more than one container) as this will copy over all Libertine apps, app icons, dependencies, the container's rootfs etc. It's arguably just as important as user-data.tgz as that one copies the main Ubuntu Touch apps.

Are there any other directories within .cache which people think would be worthy of backing up and migrating, for genuinely useful and essential stuff like the Libertine apps, and so which should be made an exception to the exclusion command criteria?

Moem

I'm probably asking too much, but it can't hurt to ask...

Is there any method to migrate data from device to (identical) device that does not involve the command line? I'm not a friend of the terminal at the best of times, and that's on a laptop. The terminal on UT, I'm sorry to say, makes me cry for my mother.

Luksus

@moem If you have a nextcloud, you can use UBsync to sync all the data you need.
You could even sync your .config folder to keep app-configs.
But apps itself, should be reinstalled I think.

Keneda

A "Save & restore" app would be so usefull in open-store... I'm really not confident with command line.

AppLee

@moem
AFAIK and at this point the answer is no.
BTW I don't think having different Ubuntu Phones would be an issue except if you want to migrate data from a 16GB to a 32GB (or else, but you get the idea)...
I think an app makes sense but it will have to be unconfined in order to do the job.

Keneda

@applee said in Migrate data from device to device:

it will have to be unconfined in order to do the job.

Yes like some others ones very usefull (UTTT not to say for ex) ^^

Moem

@luksus said in Migrate data from device to device:

If you have a nextcloud, you can use UBsync to sync all the data you need.

Why would I need other people's computers for that? Can't I just use one of my own?

Luksus

@moem sure install a nextcloud instance on your pc and sync your data to it.

Moem

@applee said in Migrate data from device to device:

AFAIK and at this point the answer is no.

Okay, thank you. That is most regrettable. But now that I know, I can stop searching.

I think an app makes sense but it will have to be unconfined in order to do the job.

I have no idea what that means but I don't think it would help me if I did.

Keneda

@moem said in Migrate data from device to device:

I have no idea what that means but I don't think it would help me if I did.

He talks about access to all data with r/w rights on the device, like UTTT do.

cliffcoggin

@moem What sort of data do you want to migrate? If it is in File Manager perhaps you could copy it to a computer and from there to your other phone. I know it works moving photos to and from the phone though I have not tried other sorts of data.

Moem

@cliffcoggin said in Migrate data from device to device:

If it is in File Manager perhaps you could copy it to a computer and from there to your other phone.

Thank you Cliff! I have done almost exactly that: I connected both phones to my laptop with USB cables, and copied my photos directly from one phone to the other. I have also moved my exported contacts and my custom ringtone in a similar way. Those things were the most important bits of data, so I'm well on the way.
My app settings and settings of the phone itself, well, I'll just have to redo them. Not a very big deal.

Also: whenever I want to move a small bit of data (such as some words or numbers and it's too much to type over... or one image) from one phone to another or from phone to laptop or vv, then I just send it to myself through Telegram / Teleports.

So there's not one streamlined solution, but there are a number of usable workarounds.