Related
Is it safe to backup the /misc partition via adb shell or terminal on phone by issuing?
Code:
dd if=/dev/mtd/mtd0 of=/sdcard/misc.img bs=4096
If so what would be the best/safest way of reflashing it in the event of coruption of /misc?
Should the phone be in fastboot?
Why do you want to run this operation?
To have a backup of the original /misc and to examine the contents out of curiosity.
Looking at the solution to usb bricking, the mtd0.img provided to hex edit assumes a software version fitting the pattern x.x.xxx.xx where as mine is currently x.x.xx.xx and was curious what to do about replacing the additional digit, I'd assume the last one should be replaced with hex 00. The files at first glance appear to be blank in contents filled with 0x00 or 0xFF though I may be wrong, I've only glanced at the contents.
Though from what I read, it doesnt really matter what the software version is in the file as long as it has the correct CID
As with newer Samsung Android phones it is practically essential that if you go to the modding scene and start uploading custom roms you should have a backup of your efs
For simple backup of efs partition
by sishgupta
Code:
adb shell
su
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/efs of=/sdcard/efs.img
and for a full image of your brand new phone
as various users have stated there are other more correct ways of backing up your new efs partition,
the one i liked the most is this one by because it backs up all your partitions
by c0ns0le
Code:
IF YOU HAVE BUSY BOX INSTALLED
adb shell
su -
for i in $(ls /dev/block/platform/omap/omap_hsmmc.0/by-name/ | grep -v user)
do
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/${i} of=/sdcard/${i}.img &
done
NO BUSYBOX:
adb shell
su -
for i in boot cache dgs efs metadata misc param radio recovery sbl system xloader
do
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/${i} of=/sdcard/${i}.img &
done
deprecated just staying here because this started all the correct backup commands for your efs
In order to do this for your galaxy nexus you should have adb working on your machine and also debugging enabled in your phone
this is practically easy, your phone must be rooted, or at least booted with the boot.img of this thread How to Root GALAXY NEXUS
Code:
adb root
adb remount
adb pull /factory
and now backup that file to at least 2 places lol
I always get paranoid with this
have fun installing custom roms
i don't think that works for GN
Samsung changed their EFS recently on the new released phones
it's no longer how it was with the Galaxy S line of phones
No one know if we really can backup and restore /factory (EFS)?
this should put an .img file in /sdcard. It's the same method as the one in the sgs2 section but with different paths.
Code:
adb shell
su
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/efs > /sdcard/efs.img
edit: you'll need to be root, obviously
edit again:
this is technically better but does the same thing:
Code:
adb shell
su
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/efs of=/sdcard/efs.img
Out of curiosity, what is efs?
I am pretty familiar with flashing my HTC Desire, but there is not an efs partition (AFAIK)?
Cheers!
It backs up your imei information in case it gets corrupted by flashing custom roms and mods
Sent from my GT-I9000 using xda premium
420SYN said:
It backs up your imei information in case it gets corrupted by flashing custom roms and mods
Sent from my GT-I9000 using xda premium
Click to expand...
Click to collapse
Cool thanks!
Stew
Is this something specific to Samsung phones? I have been rooting and flashing since the nexus one and have never needed this.
Doesn't clockwork mod back this up? If not, why not?
Sent from my LG-P999
dave_t321 said:
Code:
adb shell
su
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/efs of=/sdcard/efs.img
Click to expand...
Click to collapse
Would it be if=/dev/block/platform/omap/omap_hsmmc.0/by-name/factory since this partition is named "factory" now?
If the efs is really in the /factory folder and its not hardlinked files sitting somewhere else is there a better way to save the files and keeping the permissions?
Using tar or gzip on them before?
So which method to follow in order to backup my efs folder?All information is under /factory
use
Code:
adb shell
su
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/efs of=/sdcard/efs.img
this is the right command as if you run ls on the by-name folder you can see that it is still efs not factory
factory must be a link to this
omg, i have a 0049... IMEI after flashing ICL53F via fastboot!
how could i restore my old IMEI?
edit: jippie, i got my IMEI back after flashing the ITL41F odin version from this post!
i suggest everyone to backup the efs before flashing other firmwares!
Could someone provide the correct commands to restore the efs folder please Ive backed it up just need to know how to restore it if something bad happens
There is a guide for it on these forums. Google 'efs restore android' and you should find it.
There is also an efs restore application that will use img files (like how we made in this guide) instead of just the nv_data.bin
Sent from my Galaxy Nexus using XDA App
does it actually work with this phone?
fun w/ shellfoo
Code:
IF YOU HAVE BUSY BOX INSTALLED
adb shell
su -
for i in $(ls /dev/block/platform/omap/omap_hsmmc.0/by-name/ | grep -v user)
do
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/${i} of=/sdcard/${i}.img &
done
NO BUSYBOX:
adb shell
su -
for i in boot cache dgs efs metadata misc param radio recovery sbl system xloader
do
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/${i} of=/sdcard/${i}.img &
done
---------- Post added at 03:43 PM ---------- Previous post was at 03:15 PM ----------
[/COLOR]
dave_t321 said:
this should put an .img file in /sdcard. It's the same method as the one in the sgs2 section but with different paths.
Code:
adb shell
su
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/efs > /sdcard/efs.img
edit: you'll need to be root, obviously
edit again:
this is technically better but does the same thing:
Code:
adb shell
su
dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/efs of=/sdcard/efs.img
Click to expand...
Click to collapse
i've foud this one..wich is better?
adb shell
su
busybox dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/efs of=/data/media/my_efs_backup.img
They are the same with different output locations. The one that leads with busy box is for a configuration where the commands are not aliased for a busy box setup.
Sent from my Galaxy Nexus using XDA App
Similar thing happened to me. I got a 2nd nexus, decided to restore a nandroid from my 1st nexus onto the 2nd one. Restore went fine, it was like a clone of the 1st phone except the IMEI was corrupt with a generic 0049... one. I flashed the phone back to a google factory ITL41D and the IMEI was restored. Needless to say I won't be doing that again!
paratox said:
omg, i have a 0049... IMEI after flashing ICL53F via fastboot!
how could i restore my old IMEI?
edit: jippie, i got my IMEI back after flashing the ITL41F odin version from this post!
i suggest everyone to backup the efs before flashing other firmwares!
Click to expand...
Click to collapse
I've been having lots of trouble with my SD and local filesystems getting corrupted, which in turn has been causing the flush-179 process to go ballistic (100% CPU loop, reboot hangs, etc.). If only there was a way to run a quick FSCK(8) on my Android's unmounted filesystems to check for problems. Well, there is!
This may be old, old news to some of the more seasoned OS hackers, so please be kind with any negative feedback about it being intuitively obvious. It wasn't to me, but after some research and testing, I've come up with these simple steps:
Boot into Recovery
Connect via USB to ADB shell
Code:
C:\Scratch\Android> [B]adb devices[/B]
C:\Scratch\Android> [B]adb shell[/B]
Mount /system and /data to determine the /dev/block names, then umount each
Code:
~ # [B]mount /system[/B]
~ # [B]mount /data[/B]
~ # [B]df[/B]
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 308620 64 308556 0% /dev
/dev/block/mmcblk0p27
295509 121021 159231 43% /cache
/dev/block/mmcblk0p26
1184268 848052 276060 75% /data
/dev/block/mmcblk0p25
562384 461416 72400 86% /system
~ # [B]umount /system[/B]
~ # [B]umount /data[/B]
Run e2fsck against each /dev/block filesystem
Code:
~ # [B]e2fsck -n /dev/block/mmcblk0p25[/B]
e2fsck 1.41.6 (30-May-2009)
/dev/block/mmcblk0p25: clean, 4168/35760 files, 117605/142847 blocks
~ # [B]e2fsck -n /dev/block/mmcblk0p26[/B]
e2fsck 1.41.6 (30-May-2009)
/dev/block/mmcblk0p26: clean, 7173/75200 files, 216745/300799 blocks
~ #
The 'e2fsck' command takes the same command-line switches as UNIX FSCK(8), so you can be as creative and daring as you need.
- Dave
some help
ViperGeek said:
I've been having lots of trouble with my SD and local filesystems getting corrupted, which in turn has been causing the flush-179 process to go ballistic (100% CPU loop, reboot hangs, etc.). If only there was a way to run a quick on my Android's unmounted filesystems to check for problems. Well, there is!
This may be old, old news to some of the more seasoned OS hackers, so please be kind with any negative feedback about it being intuitively obvious. It wasn't to me, but after some research and testing, I've come up with these simple steps:
Boot into Recovery
Connect via USB to ADB shell
Code:
C:\Scratch\Android> [B]adb devices[/B]
C:\Scratch\Android> [B]adb shell[/B]
Mount /system and /data to determine the /dev/block names, then umount each
Code:
~ # [B]mount /system[/B]
~ # [B]mount /data[/B]
~ # [B]df[/B]
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 308620 64 308556 0% /dev
/dev/block/mmcblk0p27
295509 121021 159231 43% /cache
/dev/block/mmcblk0p26
1184268 848052 276060 75% /data
/dev/block/mmcblk0p25
562384 461416 72400 86% /system
~ # [B]umount /system[/B]
~ # [B]umount /data[/B]
Run e2fsck against each /dev/block filesystem
Code:
~ # [B]e2fsck -n /dev/block/mmcblk0p25[/B]
e2fsck 1.41.6 (30-May-2009)
/dev/block/mmcblk0p25: clean, 4168/35760 files, 117605/142847 blocks
~ # [B]e2fsck -n /dev/block/mmcblk0p26[/B]
e2fsck 1.41.6 (30-May-2009)
/dev/block/mmcblk0p26: clean, 7173/75200 files, 216745/300799 blocks
~ #
The 'e2fsck' command takes the same command-line switches as UNIX FSCK(8), so you can be as creative and daring as you need.
- Dave
Click to expand...
Click to collapse
on my phone i have a fiel called fsck.exfat and fsck_msod i think and im trying to run one (though not sure what the difference is) to fix some corrupted files in data internally. im trying to see if the file can be run through recovery without putting it through adb to unmount the data. im not too sure how to figure out what the data block is called because when i rum the mount i get a ton of different blocks (about 32 of them).
im trying to clean up the lost+found files i have and i have 3 of from a corrupted nandroid
robcop19 said:
on my phone i have a fiel called fsck.exfat and fsck_msod i think and im trying to run one (though not sure what the difference is) to fix some corrupted files in data internally. im trying to see if the file can be run through recovery without putting it through adb to unmount the data. im not too sure how to figure out what the data block is called because when i rum the mount i get a ton of different blocks (about 32 of them).
im trying to clean up the lost+found files i have and i have 3 of from a corrupted nandroid
Click to expand...
Click to collapse
Hi Rob.
I'm not sure if I can be of any specific assistance. exFAT is a type of filesystem format, like UNIX/Android ext3 and ext4, but beyond that, I couldn't tell you what those programs do. I do know that on some operating systems, the only way to fix the file chains and blocks is to make sure it's unmounted in single user mode. ADB is the closest we Android guys can get to UNIX single user mode without some clever Recovery Mode ZIP file programming.
– Dave
alrighty
ViperGeek said:
Hi Rob.
I'm not sure if I can be of any specific assistance. , but beyond that, I couldn't tell you what those programs do. I do know that on some operating systems, the only way to fix the file chains and blocks is to make sure it's unmounted in single user mode. ADB is the closest we Android guys can get to UNIX single user mode without some clever Recovery Mode ZIP file programming.
– Dave
Click to expand...
Click to collapse
well thank you for at least writing back on it. im not sure how to run adb let alone run the progrma to try and fix this but i will be learning up on it
robcop19 said:
well thank you for at least writing back on it. im not sure how to run adb let alone run the progrma to try and fix this but i will be learning up on it
Click to expand...
Click to collapse
ADB isn't all that difficult to use. Here's a good primer on it:
http://droidlessons.com/how-to-install-adb-on-a-windows-7-pc/
Once installed, just boot your phone into Recovery (power off completely, then power on with the Vol Down key held, then select RECOVERY). Once it's sitting there, connect your phone to the PC via USB, wait for Windows to find the right drivers, and you're connected. 'adb devices' should list your phone in the "List of devices attached", after which you're good to go.
– Dave
ps. I've not tried it personally, but there's supposedly a "universal USB driver" available here:
https://plus.google.com/103583939320326217147/posts/BQ5iYJEaaEH
wow
ViperGeek said:
ADB isn't all that difficult to use. Here's a good primer on it:
Once installed, just boot your phone into Recovery (power off completely, then power on with the Vol Down key held, then select RECOVERY). Once it's sitting there, connect your phone to the PC via USB, wait for Windows to find the right drivers, and you're connected. 'adb devices' should list your phone in the "List of devices attached", after which you're good to go.
– Dave
ps. I've not tried it personally, but there's supposedly a "universal USB driver" available here:
Wow thank you very much for the help youre giving me I will see if i can go and start finding a solution
Click to expand...
Click to collapse
ViperGeek said:
The 'e2fsck' command takes the same command-line switches as UNIX FSCK(8), so you can be as creative and daring as you need.
- Dave
Click to expand...
Click to collapse
I figured this out about a week ago now I guess and did indeed find that there were corrupted partitions. My phone had been acting up for several weeks before and it pretty much unusable now. I do manage to clean system and data up, and was even able to flash a new ROM which I hadn't been able to, they'd always abort.
I have a question though, is this only good for ext2 partitions? I have the same version as shown in the tutorial and if you run 'e2fsck -V' the output makes me think that maybe it's not happy checking ext3 and ext4 partitions and that's why i was popping up errors, or at least that's why even when i fixed errors it maybe wasn't really fixing the issue.
Thanks.
I've got a different phone, but a search brought me here to this thread. I think my issues though are more corrupted memory rather than device specific so hope you don't mind my post here.
I think this will answer your question
http://linux.die.net/man/8/fsck.ext3
(It should be good for all ext partitions)
Sent from my Galaxy Nexus using Xparent Cyan Tapatalk 2
ahh the good old fsck
glad i found this thread
thanks a lot mannnn
One more helpful tidbit.
Even if you run 'e2fsck -n' and find a "clean" file system, it may be useful to force a scan via 'e2fsck -f'. This just happened to me. I had something funny going on, and so rebooted into recovery and checked my file systems. Everything was cool like Fonzie, which I didn't believe, and so I used 'e2fsck -f' and found lots of fuglies that got fixed.
Be careful running -f on a cross-linked file system like the /data partition on a Galaxy S3/S4. It can have the tendency to unlink the elfin magic Samsung used and make a mess.
- Dave
(Double-tap post deleted)
This will not work with stock Android - default boot to recovery doesn't enable adb - you have to have CWM for that.
So, the questions remains - how can I run e2fsck without rooting my phone (and possibly voiding its warranty)?
How do I get the Moto X in Recovery mode to accept the adb command?
Because when I put in Recovery (Android Robot lying down) mode, the command adb and fastboot are not recognized.
Can this be done in terminal? And would I need su?
PRose61 said:
Can this be done in terminal? And would I need su?
Click to expand...
Click to collapse
Yes, this can be done in terminal on the phone itself. You do need root/su.
ApTeM said:
This will not work with stock Android - default boot to recovery doesn't enable adb - you have to have CWM for that.
So, the questions remains - how can I run e2fsck without rooting my phone (and possibly voiding its warranty)?
Click to expand...
Click to collapse
Is this why I get can't read '/etc/fstab': No such file or directory?
I'm using a stock Samsung S2, but it is rooted and has superuser and busybox.
Code:
ViperGeek said:
I've been having lots of trouble with my SD and local filesystems getting corrupted, which in turn has been causing the flush-179 process to go ballistic (100% CPU loop, reboot hangs, etc.). If only there was a way to run a quick on my Android's unmounted filesystems to check for problems. Well, there is!
This may be old, old news to some of the more seasoned OS hackers, so please be kind with any negative feedback about it being intuitively obvious. It wasn't to me, but after some research and testing, I've come up with these simple steps:
Boot into Recovery
Connect via USB to ADB shell
Code:
C:\Scratch\Android> [B]adb devices[/B]
C:\Scratch\Android> [B]adb shell[/B]
Mount /system and /data to determine the /dev/block names, then umount each
Code:
~ # [B]mount /system[/B]
~ # [B]mount /data[/B]
~ # [B]df[/B]
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 308620 64 308556 0% /dev
/dev/block/mmcblk0p27
295509 121021 159231 43% /cache
/dev/block/mmcblk0p26
1184268 848052 276060 75% /data
/dev/block/mmcblk0p25
562384 461416 72400 86% /system
~ # [B]umount /system[/B]
~ # [B]umount /data[/B]
Run e2fsck against each /dev/block filesystem
Code:
~ # [B]e2fsck -n /dev/block/mmcblk0p25[/B]
e2fsck 1.41.6 (30-May-2009)
/dev/block/mmcblk0p25: clean, 4168/35760 files, 117605/142847 blocks
~ # [B]e2fsck -n /dev/block/mmcblk0p26[/B]
e2fsck 1.41.6 (30-May-2009)
/dev/block/mmcblk0p26: clean, 7173/75200 files, 216745/300799 blocks
~ #
The 'e2fsck' command takes the same command-line switches as UNIX FSCK(8), so you can be as creative and daring as you need.
- Dave
Click to expand...
Click to collapse
Thank you for your very well done post. I also realize that this thread is very old. Still it is the best I have found after days of looking. And finally, I have a different phone. Having said that perhaps someone might help.
My phone is a Galaxy S5 Verizon SM-G900V running KitKat 4.4.4. I have root on the phone, but am running stock Verizon Kitkat with stock recovery.
So I have used ADB by plugging in my phone via USB to my Windows computer. I can get root in ADB and find the /data filesystem and its /dev/block/... device. But when I try to
Code:
umount /data
I get a response that the filesystem is busy. This makes sense.
I have booted into recovery via VOL UP + HOME + POWER and it takes me to the RECOVERY menu. But the only option that connects with my ADB shell is "apply update from ADB". When you use the command
Code:
ADB devices
, my phone shows up, but as "phoneid" sideload, and
Code:
ADB shell
exits immediately.
I have also tried to use a terminal shell and then su to root. Again I cannot umount /data since it is busy. (Of course it is, I am using it...)
And finally I have tried
Code:
touch /forcefsck
to create that file in the root directory. This is supposed to force a fsck during boot up. But the root directory (/) is read only. So you can't write the file to it.
I am at my wits end. What I really need to do is mark the /data filesystem as dirty and have the system check it on reboot. But I can't find anyway to do it.
So if anyone can help, I would be very grateful
Joe
I am making a separate thread specifically for Sprint because I have seen so many posts from Sprint users that took the OTA update, and I don't want this to be buried in the other thread.
If you have a Sprint G2, then you have to wipe the fota partition AND the misc partition.
Thanks so much to autoprime from #lg-g2 for pointing me in the right direction.
Code:
adb shell
cd /dev/block/platform/msm_sdcc.1/by-name
dd if=/dev/zero of=./fota
dd if=/dev/zero of=./misc
If you can't get adb to talk to your phone and only have the terminal from TWRP, then you will have to type the paths out -- make sure you get them right
-- Brian
I keep getting an error saying -
Code:
[email protected]:/dev/block/platform/msm_sdcc.1/by-name # dd if=/dev/zero of=./misc
zero of=./misc
./misc: write error: No space left on device
32769+0 records in
32768+0 records out
16777216 bytes transferred in 1.332 secs (12595507 bytes/sec)1
That is normal since we didn't specify a block size and a count. When dd fills the partition with zeros it errors out that it is out of space. The goal here is to do just that, fill the entire partition with zeros
-- Brian
runningnak3d said:
That is normal since we didn't specify a block size and a count. When dd fills the partition with zeros it errors out that it is out of space. The goal here is to do just that, fill the entire partition with zeros
-- Brian
Click to expand...
Click to collapse
That makes sense. Still learning about this side of android. Appreciate the help bro.
Silicon Knight said:
That makes sense. Still learning about this side of android. Appreciate the help bro.
Click to expand...
Click to collapse
does this work on D802 with CWM?
Also, i actually formatted all partitions shown on CWM advance menu.. does it mean my EFS is corrupt? I did not make EFS backup..
How to backup partition images with dd on the command line (root required)
We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.
Special partitions:
The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.
Using a helper script:There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.
On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.
So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')
And here's one that also skips super:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')
How to dump partitions manually:If you can't/won't use the helper script you can do it by hand. All the following commands need root:
Find the names of all the partitions:
Code:
ls /dev/block/bootdevice/by-name/
Dump one specific partition identified by NAME:
Code:
dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img
Dump all partitions except userdata:
Code:
ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done
Find the active slot:
Code:
getprop ro.boot.slot_suffix
Get checksums for all the images after the dump:
Code:
md5sum *.img
Confused about _a and _b partitions?You should read about A/B Seamless Updates.
Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.
This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.
I used a 128 GB card to take a backup of userdata. The backup script had some trouble with the backup location being on the storage card for some reason and I didn't have time to figure it out, but the dd command I gave above worked fine.
Code:
# time dd if=/dev/block/bootdevice/by-name/userdata of=userdata.img
112111374336 bytes (104 G) copied, 2342.274225 s, 46 M/s
39m02.31s real 1m11.78s user 14m44.72s system
Code:
# adb pull /storage/1234-ABCD/backup/userdata.img ./
/storage/1234-ABCD/backup/userdata.img: 1 file pulled, 0 skipped.
87.2 MB/s (112111374336 bytes in 1225.663s)
So that's 104 GB that took 39 minutes to be written to a new Samsung Evo U3/V30 microSDXC (46 MB/sec real write speed) and 20 minutes to be read to the PC (Samsung Evo M.2) with adb pull over USB (87 MB/sec read speed). Just so you know what you're in for.
I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.
If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
Code:
# adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img
If you want to use the Python script:
Code:
# adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img
Using the same fast SSD on the PC side as above, I now get:
Code:
218967528+0 records in
218967528+0 records out
112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
real 17m57.910s
So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.
Are you able to switch to a different backup location? Say a USB OTG if possible.
mikeshutte said:
Are you able to switch to a different backup location? Say a USB OTG if possible.
Click to expand...
Click to collapse
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
wirespot said:
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
Click to expand...
Click to collapse
Ok I'll give it a try and see what happens. Thanks for your help.
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
jakito said:
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
Click to expand...
Click to collapse
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I see. Thank you nonetheless!
wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I don't know how I ended up but making a backup you can't restore is completely pointless.
Techguy777 said:
I don't know how I ended up but making a backup you can't restore is completely pointless.
Click to expand...
Click to collapse
No, it's not. All your data is in there. You can mount your backup on a linux computer and pull out apks as well as app data. You can then restore these folder by folder with adb and a root shell on your phone.
That beeing said, does anyone know a proper backup software like Titanium Backup for Android 11 and above? Sometimes I read recommendations, but looking at the ratings it seems that no software manages to achieve the same level of comfort and control. Also they all seem to suffer from the same limitations.
Let's be honest: Google wants to make your life hard, so they can lock you in.
@xperinaut
I'm using Titanium on Android 11. Is it not working for you?