7 Zip compression level too high

[lunatik98]

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?

[mrrfv]

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.

[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.

[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.

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

[mrrfv]

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.

[pvint]

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

[lhoss]

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

[mrrfv]

Thanks for the reminder.