[Q] Remote nandroid backup by direct `adb pull /dev/block/mmcblk0` - Android Q&A, Help & Troubleshooting

Hi,
The [GUIDE] How to make a nandroid backup directly to your computer without using sdcard guide contains a promising description of performing a bit-for-bit copy of the NAND memory directly to PC. However, when I was reading it, it came to my mind that with the following assumptions (obvious?):
having the phone launched in a recovery mode (to avoid risking inconsistent backup due to partitions being mounted and potentially being written to, so I guess a reasonable assumption),
the ADB working with root privileges (default in recovery, at least in ClockWorkMod),
a simple:
Code:
adb pull /dev/block/mmcblk0
ought to do the same without the need for FIFOs, setting up FTP and such. What is the difference between the two? I'm seeking understanding of the process, as opposed to solving a specific problem now. I haven't found any related question or explanation either in that thread or outside.

Related

[Q] Best way to backup and restore on a number of devices

Hi
I've done a bit of searching but can't find anything too specific to what I'm trying to do. Basically we have 10 Android tablets, and I want to make them all standardised e.g. have the same Apps on, configured in the same way (e.g. enterprise wireless network added).
Now the thing is if anyone messes around with them I want a really easy way to restore them to the original config which I've done.
One way I thought was to configure one fully, install Titanium Backup on it, do a full backup of apps/system data etc, and put the backup onto an SD card. Then I already have the base ROM on an SD card so if theres any problems, I can just flash the ROM over it again, install TB, and restore all the data. Would this be suitable to do to duplicate the data onto 10 tablets, and also restore the data if required?
The other thing I looked into was customising a ROM myself, don't want to do anything too tricky it'll just be a case of removing all the preinstalled crap I don't want, preloading the Apps we do want, and if possible preloading the wireless key and getting rid of the first boot initial set up wizard.
PS I've looked at installing CWM and doing whole image backups, but supposedly the tablet isnt supported (its an Ainol Novo 7 Elf 2)
Any advice would be great, hopefully theres some fairly straight forward way of managing this
Thanks
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
kuisma said:
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
Click to expand...
Click to collapse
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
fro5tie said:
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
Click to expand...
Click to collapse
Ok, I see. Compile the image to you likings (boot image and system partition), and then flash it using fastboot onto you devices.
Hi
Does anyone have any more thoughts on this?
I have experimented with Titanium Backup and this seems to work quite well. I have installed a ROM, and customised it e.g. installed the apps I need and configured the apps, wireless settings and home screens etc. Then I do a full apps + system backup in TB to my SD card.
Then the plan is, I can reflash the ROM onto the other device, install TB and then restore this backup. This saves my user state and wireless settings etc.
Only problems is when I flash the ROM, I have to go through all the initial set up again and also remove some preinstalled apps which I dont want. Any ways around this?
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
kuisma said:
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
Click to expand...
Click to collapse
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
fro5tie said:
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
Click to expand...
Click to collapse
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
kuisma said:
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
Click to expand...
Click to collapse
Hi
Thanks for the quick reply, much appreciated.
Unfortunately you've lost me a bit here!
Yes the device is rooted, I dont have a linux machine though.
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
fro5tie said:
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
Click to expand...
Click to collapse
I can provide you specific answers to specific questions, but I have no experience of the tablet in question, so you'll have to do some digging yourself first. Make sure it supports fastboot, investigate what the proprietary bootloader is capable of, see how/if you can obtain an original image etc.
One maybe easier solution, especially if you plan to restore the tablets on a regular basis, is to only make a new boot image to reflash the devices with. The only modification done is that you change the /init.rc script to mount /data and /system from the SDcard instead of from the internal nand disk device.
Once this is done, you'll power up and run the installation wizard and everything on your master tablet. Then power it down, and clone the SDcard. This SDcard now contains everything, so you'll simply restore a device by replacing its SDcard with a copy of this master card. I guess it's easier to clone a SDcard than reflashing several internal partitions. Easier to make the master as well - you don't need to dd or tar them, they are already in "image" format. If you can get hold of the original firmware, this should be quite easy without the need to preserving data from the device itself.
fro5tie said:
Any chance you'd be able to provide some more specific instructions?
Click to expand...
Click to collapse
Issue the commands "cat /proc/mtd" and "mount" on your device at command prompt (e.g. via "adb shell" or the "ConnectBot" terminal app). This shows you if the device allows you to copy the boot image from it. Paste in the output into this thread. If you believe the "clone the tablet via the SDcard" is a good solution for you, the process is in short terms something as below;
Copy the boot image to the sdcard:
# dd if=/dev/mtd/mtd2ro of=/mnt/sdcard/boot.img bs=2048 (device dependent of contents of /proc/mtd)
Remove the sdcard, insert into a computer, split the boot image info kernel + initramfs. Read http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images for instructions about how to work with the boot.img file. I really recommend a GNU/Linux environment for this.
Then edit /init.rc replacing the "mount yaffs2 [email protected] /system" with "mount ext3 /dev/block/mmcblk0p2 /system" for system and data (use p3 for data partition, the device name may be different on your tablet, see mount output).
Create an SDcard with three partitions: #1 vfat (standard), #2 and #3 ext3. Insert into you device and boot it up again.
# mount -t ext3 /dev/block/mmcblk0p2 /root
# cd /system
# tar cf - . | (cd /root ; tar xf - )
# umount /root
# mount -t ext3 /dev/block/mmcblk0p3 /root
# cd /data
# tar cf - . | (cd /root ; tar xf - )
# umount /root
This copies your partitions to the SDcard. Shutdown the tablet again.
Make a new boot.img using the instructions in the link above, using the edited init.rc script.
Now you can non-destrutive give this a try.
Place you tablet in fastboot mode (often vol-up (or vol-down) during power on).
$ fastboot devices
This vill verify the tablet is in fastboot mode. It should be listed. Then:
$ fastboot boot boot.img
Note here, only BOOT the tablet, do NOT use the "flash" keyword. This in case of the image isn't working, you'll just have to restart you tablet, and no harm's done.
Look around. Do a "mount" command. Everything works? Mount shows /data and /system from sdcard? Perfect. Now you can reflash it. Shutdown and flash:
$ fastboot flash boot boot.img
Now the device will use /data and /system from the SDcard every time. Customize your device, and then clone your SDcard and try it in tablet #2 you'll booting with your new boot.img and the cloned SDcard. Verify that #tablet #2 is a perfect clone of tablet #1. It is? Now you can flash the boot,img into all your tablets.
--------------------
But don't forget, there may be other solutions as well, maybe more suitable. This you'll have to investigate yourself.
And the usual disclaimer - you can probably not follow above by the letter. There sure is some obstacle you'll have to overcome, something non-standard, etc.
Also keep the original boot.img file for safekeeping in the case you want to restore the device's boot image some day.
Wow! Thanks for the info! This is really helpful, I need to set aside a bit of time to work through this and have a look. Thanks again its really appreciated, I'll be back with info once I've had chance to give it a go!
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
tweeny80 said:
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
Click to expand...
Click to collapse
Hi
Yes that was my first thought as well, tablets are rooted yes but there is no CWM for the tablet. Its an obscure Chinese branded tablet.
Unless there is another way to do nandroid backups?
hmm tricky situation. Catch 22 ! From what I know, your best bet is to backup all possible things through Titanium Backup given that you don't have the use of Nandroid backups. You can include wifi settings, messages etc but it's modular & not systemic.
I did a quick google search with no luck - time to upgrade your fleet dude :-0
Best of luck.

[Q] adb backup v. adb pull

I didn't search too thoroughly for the answer to this question, but I can't imagine that I'm the first asking it:
In fiddling around with adb backup and the Android Backup Extractor, I noticed that all it really seems to do is pull the Shared Preferences, Internal Storage, and SQLite Databases from every /data/data/<app>/ directory and unnecessarily box and encrypt them together (if you've encrypted your phone like I do) into a tight little package. Worse, it seems not to catch everything (like com.android.providers.contacts where your address book lives). If I simply run
Code:
adb pull /data/data localBackup
I get all of the SP, IS and SQLDBs - with the caches - from all of the apps, but with the benefit of it not being stuck in an over-wrapt file and knowing that I've gotten every app. My phone is rooted but does one need root access to do this from ADB?
I have two questions:
What advantage does adb backup have over adb pull /data/data? The latter seems much safer (as in it's easier to check if it's been done properly) and restore (simply push the pulled data back into its folder)
What user settings and/or information is not included in /data/data, aside from the obvious data on the /sdcard? Put another way, would a copy of /data/data and /sdcard be a sufficient backup of all of my phone's data? (notwithstanding needing to reinstall the original APKs and ROM)

[Q] Cloning Android Devices

We are a large urban school district located in southern California that will be soon be distributing approximately 11,000 android tablets to our first grade classrooms. The biggest challenge we’ve had with this project so far is coming up with a way to quickly and reliably clone the devices with all the apps and settings. The approach we’ve been attempting to take is the same as how we would handle PC’s by creating a master image that then gets copied to all the other devices.
Our first attempt at doing this was by using adb backup/restore. This process was less than ideal as it didn’t copy all the settings/preferences that we wanted and still required a lot of manual configuration to get the devices in to our ideal state. The bigger problem we had here was that sometimes it would just hang during the restore. Most of the time it did work but we’ve run in to this restore problem enough that we need something more reliable.
So our current cloning method is using Clockworkmod Recovery. Basically we flash CWM on to the device, make our backup, copy that backup to the destination devices and restore it with CWM. Seems to work great. And it copies everything on the devices so there’s virtually no manual configuration that needs to be done.
However there’s a few caveats with this process. At first we found that it was also cloning the MAC address which of course caused havoc on our wireless network. Through a whole lot of trial and error I found that if I delete /data/nvram/RestoreFlag from the data backup tar the MAC address no longer gets cloned. Thought we were good, but…
The next problem we found when attempting to enroll the devices in to our MDM system. They end up replacing each other because they all show the same UDID and GUID. The MDM app is installed in the backup image but we are waiting until after it is restored to complete the enrollment. I’m not sure if the UDID and GUID is something specific to the MDM or if that’s a global Android thing.
So does anyone know if there something else I can delete from the backup to prevent this? This also raises the question, are there any other items in a CWM backup that should not be copied between devices? Or is there a better method we could use to clones the devices?
The device we are currently using is a Lenovo A1000 (MTK MT8317). After creating the backup I’ve been removing the system and cache tars entirely and only the file mentioned above from within the data tar. So the only parts that get restored are data and boot. Any suggestions are welcome.
ttttttttttttttttt said:
We are a large urban school district located in southern California that will be soon be distributing approximately 11,000 android tablets to our first grade classrooms. The biggest challenge we’ve had with this project so far is coming up with a way to quickly and reliably clone the devices with all the apps and settings. The approach we’ve been attempting to take is the same as how we would handle PC’s by creating a master image that then gets copied to all the other devices.
Our first attempt at doing this was by using adb backup/restore. This process was less than ideal as it didn’t copy all the settings/preferences that we wanted and still required a lot of manual configuration to get the devices in to our ideal state. The bigger problem we had here was that sometimes it would just hang during the restore. Most of the time it did work but we’ve run in to this restore problem enough that we need something more reliable.
So our current cloning method is using Clockworkmod Recovery. Basically we flash CWM on to the device, make our backup, copy that backup to the destination devices and restore it with CWM. Seems to work great. And it copies everything on the devices so there’s virtually no manual configuration that needs to be done.
However there’s a few caveats with this process. At first we found that it was also cloning the MAC address which of course caused havoc on our wireless network. Through a whole lot of trial and error I found that if I delete /data/nvram/RestoreFlag from the data backup tar the MAC address no longer gets cloned. Thought we were good, but…
The next problem we found when attempting to enroll the devices in to our MDM system. They end up replacing each other because they all show the same UDID and GUID. The MDM app is installed in the backup image but we are waiting until after it is restored to complete the enrollment. I’m not sure if the UDID and GUID is something specific to the MDM or if that’s a global Android thing.
So does anyone know if there something else I can delete from the backup to prevent this? This also raises the question, are there any other items in a CWM backup that should not be copied between devices? Or is there a better method we could use to clones the devices?
The device we are currently using is a Lenovo A1000 (MTK MT8317). After creating the backup I’ve been removing the system and cache tars entirely and only the file mentioned above from within the data tar. So the only parts that get restored are data and boot. Any suggestions are welcome.
Click to expand...
Click to collapse
You can try use adb from Android SDK but this method needs root
We did initially try adb but it was inconsistent during the restore phase. Sometimes it would just stop in the middle and never complete. Didn’t try it on a rooted device. So maybe that would have helped…
Anyhow I found the solution to my immediate problem. Figured out what our MDM vendor refers to as the UDID is really the Android_ID. So by deleting that row from the settings database in our master backup image it’ll generate a new one the first time the OS starts after restoring with CWM.
I’m still a little concerned we’re going to find other issues cause by this cloning method later on but I guess we’ll just have to roll with the punches as they come.
In case someone else ever needs to clone devices like this and in the interest of sharing here’s the basic steps we’re following.
1.) Setup the master device as you like with all the apps and settings.
2.) Install Clockworkmod Recovery on to the master device
3.) Boot into CWM Recovery
4.) Mount /data and connect to adb
5.) Delete /data/nvram/RestoreFlag (this step prevents duplication of MAC address)
6.) Using sqlite open the database (this prevents duplication of Android_ID): \data\data\com.android.providers.settings\databases\settings.db
execute: delete from secure where name='android_id';
7.) unmount /data
8.) Create a backup
9.) Boot the device back in to normal mode and copy the clockworkmod folder to your computer. This the backup image you’ll restore on the other devices.
10.) [OPTIONAL] I deleted the system and cache backup files from this folder and also removed them from the nandroid file. There didn’t seem to be anything in these we cared about so removing those speeds up the restore process.
Once you have the backup image here’s how to restore it on the other devices:
1.) Install CWM Recovery
2.) Copy the clockworkmod folder from your computer on to the device
3.) Boot in to CWM Recovery
4.) Restore the backup
5.) Reboot the device back in to normal mode
6.) [OPTIONAL] Complete MDM enrollment
Sorry for the thread grave dig, but thanks for posting info on how to do this. I have attempted cloning in the past and ran into similar issues. My question - is this process the same for Android Lollipop 5.0/5.1? I have some Lenovo K3 Notes I'd like to deploy and cloning would save a lot of time.
Haven’t had the need to do any devices running 5.x versions so can’t say for sure. I would imagine a similar process would work.
But I will provide a bit of an update. Our initial deployment of 11,000 Lenovo A1000 devices have been out in the field since February/March of 2014 and no trouble has come to light using this cloning method. These devices run 4.1.2
Sometime around May 2014 we did another round that was about 300 Lenovo A3000 devices. Don’t have one of these handy and I don’t remember the exact Android version but it was 4.x something.
Then starting in October 2014 we put out another 9000 or so Lenovo A3500 devices. These run 4.4.2
All around so far so good.
For the A3000 and A3500 there were two changes to the process. For step 5 in creating the backup I had to clear the entire nvram directory instead of just the one file. I don’t remember what exactly but there was something undesirable getting copied over. The result of clearing this directory is the first boot after the restore takes a little longer as each app runs through the “update” process at startup. The second change was I could not get CWM to backup and restore to/from the internal memory so instead did it from a micro-sd card. This ended up speeding up the restore process since we didn’t have to copy the backup to each device and instead just moved the sd card with the files already there.
this should be pinned in android dev
also sorry for grave digging? except this should be a maintained topic. why isnt this an ongoing thread?

[Q] Cloning partition without root but with CWM ?

Hi,
I need to recover deleted sms messages (from a Samsung Galaxy SIII I9300) and there is no backup of the mmssms.db database.
It's for a customer and I would like avoiding to root and to alter the operating system.
This mean that I would be very happy if the procedure could be as much "read only" as possible.
I'm however aware that I will have to write something to the phone, and I plan using the recovery partition for this.
After reading this much interesting thread http://android.stackexchange.com/questions/28296/full-backup-of-non-rooted-devices
my main hope is based on flashing ClockWorkMod (CWM) or TWRP to the recovery partition with Odin (or maybe Heimdall).
This seems a priori possible without root access. (see http://forum.xda-developers.com/showthread.php?t=2313072)
Afterwards, I would like to clone the whole DATA partition, in order to not only get the current "mmssms.db" file, but to also possibly find older versions of it through file carving.
The adb shell seems being a feature of CWM (source: http://forum.xda-developers.com/wiki/ClockworkMod_Recovery) but I'm not sure whether the adb shell resides on the recovery partition or on another one and if root privilege is required to apply commands like push or pull to exchange files between partitions and the sdcard.
Furthermore, I'm not sure if I could run commands like "dd" from recovery partition.
Something like having Busybox commands available also when starting the phone on the recovery partition.
Else, saving a Nandroid backup to the sdcard seems possible, but this sounds saving a directory structure and appears to me being not equal as cloning a partition (at low level). Hence, it would not be possible to carve dereferenced files from the Nandroid backup. Correct ?
TWRP also sounds interesting, as being able to backup only specific partitions like the "DATA" one.
But the fact that its navigation is based on the touch screen appears me being unsafe if the touch screen had to dysfunction in a later time.
I'm familiar to Linux but a newbie in Android-based smartphones.
Thank you very much for your help.

How to be foolproof when attempting flashing

Hello,
I am new to xda, but with what I would say a good understanding of computers in general, and good knowledge of c programming (if that matters)
I am structuring a guide for myself to be as foolproof as possible when attempting flashing my new phone. Please fill in any voids, comment, or answer questions if you can. This should prove useful to other users as well as it's not so model-specific.
1) It appears that the custom recovery of choice in most situations and for the time being is TWRP (correct?).
2) If I can get a backup of EVERY partition on my stock phone (as it came from the factory) using TWRP, could I conceivably restore ALL of them and be in a factory default setting? Excluding stuff like eFuse and similar mechanisms.
3) If the phone supports fastboot, unlocked bootloader and there is a compatible TWRP for it, would it be possible to boot the TWRP recovery through fastboot (without flashing that particular partition to phone), open a shell and take backups of all partitions on the phone? That should give us a file for each partition.
4) If one accomplishes step 3 successfully, in what scenarios would he/she NOT be able to bring the phone back to life after software bricking?
Minor questions:
a) "To have root" on a phone, is basically the same as having a root account on a BOOTED OS partition (like the admin accoun on a booted windows machine, or a root account on a linux machine)? If that's the case, booting a different partition (for example the recovery partition) could also give you root priviledges without affecting the booted partition, correct?
b) Why do some custom ROMs require a certain version of the stock/OEM rom to be installed PRIOR to flashing, since they are going to replace those partitions anyway?
c) How is Xiaomi's Anti Roll Back (ARB) feature implemented, if one restores all partitions to stock from step (3) ? There must be some other places of storing of information on the phone, besides internal memory, correct?

Categories

Resources