open-android-backup icon indicating copy to clipboard operation
open-android-backup copied to clipboard

7 Zip compression

Open lunatik98 opened this issue 3 years ago • 4 comments

Why did you decide to use maximum compression for 7 Zip? It takes very long and is not really neccessary for a phone backup in my opinion because they usually arent that big. Could you make the compression optional or provides different compression settings?

lunatik98 avatar Oct 21 '22 15:10 lunatik98

I've been thinking about this honestly. Ultra compression is definitely a waste of time and power in scenarios where the data is completely different in each file (songs, pictures and videos primarily).

Could you please take a backup using ultra compression, then rerun it with normal compression (change mx=9 to mx=5 in line 266 of backup.sh), and reply with the difference in file sizes? Asking you because none of my test devices have real data that I could test with.

mrrfv avatar Oct 21 '22 16:10 mrrfv

Sure i can test it but i need to restore my phone first and cant get it to work. I cant input the backup file location because it doesnt accept : or /. Im using WSL and Powershell on Windows 11.

Screenshot 2022-10-21 194356

lunatik98 avatar Oct 21 '22 17:10 lunatik98

Sure i can test it but i need to restore my phone first and cant get it to work. I cant input the backup file location because it doesnt accept : or /. Im using WSL and Powershell on Windows 11.

Screenshot 2022-10-21 194356

I fixed it now by using the WSL mounted path but its very inconvenient to be honest. Dont know ifs there is a better way

lunatik98 avatar Oct 21 '22 18:10 lunatik98

Bug with Windows/WSL unfortunately. The Linux shell doesn't interpret special characters and drive locations in the same way as Windows does, meaning that you have to enter the file name yourself.

mrrfv avatar Oct 21 '22 18:10 mrrfv

I just did some testing with different compression ratios, note that I had just factory reset my phone today and have only installed a bunch of apps, restored SMS messages, etc., and there are no pictures/videos/music on the phone, so it may not be indicative of a usual backup. (also keep in mind that the timings might be off by about a minute or two when it was waiting for me to input password)

Ran time ./backup.sh:

With compression = 9:

Everything is Ok
Backed up successfully.
If this project helped you, please star the GitHub repository. It lets me know that there are people using this script and I should continue working on it.

real    13m18.850s
user    33m52.106s
sys     0m25.089s

With compression = 5:

Everything is Ok
Backed up successfully.
If this project helped you, please star the GitHub repository. It lets me know that there are people using this script and I should continue working on it.

real    13m46.750s
user    33m50.560s
sys     0m24.094s

With compression = 1:

Everything is Ok
Backed up successfully.
If this project helped you, please star the GitHub repository. It lets me know that there are people using this script and I should continue working on it.

real    13m22.147s
user    33m58.012s
sys     0m24.662s

With no compression:

Backed up successfully.
If this project helped you, please star the GitHub repository. It lets me know that there are people using this script and I should continue working on it.

real    3m34.172s
user    0m1.628s
sys     0m12.512s

Disk usage of each:

hp /mnt/1 # ls -l tmp[159]
tmp1:
total 1571520
-rw-r--r-- 1 root root 1609229421 Nov 10 18:22 linux-android-backup-11-10-2022-18-12-24.7z

tmp5:
total 1571736
-rw-r--r-- 1 root root 1609453469 Nov 10 18:07 linux-android-backup-11-10-2022-17-56-56.7z

tmp9:
total 1572132
-rw-r--r-- 1 root root 1609858093 Nov 10 17:51 linux-android-backup-11-10-2022-17-41-20.7z
hp /mnt/1 # du -s tmp0
2516500 tmp0

The directories tmp1 tmp5 and tmp9 are with compression at 1, 5 and 9 respectively, and tmp0 is uncompressed. Oddly, compression at 1 ended up with less disk usage than at 9, although since I did that one last it's possible that the phone had downloaded something in the meantime. Each of them resulted in ~40% space savings over uncompressed. Huge time savings on not compressing though - 3.5 minutes as opposed to ~13.5 min.

I've actually added an option in the script to set (or disable) compression. I'll do a few more tests tomorrow (including restoring) and if it looks good I'll do a PR.

Cheers Paul

pvint avatar Nov 10 '22 23:11 pvint

Issue fixed by #105 (merged to master, not part yet of latest release) Close the issue?

lhoss avatar Apr 01 '24 08:04 lhoss

Thanks for the reminder.

mrrfv avatar Apr 01 '24 13:04 mrrfv