Optimize boot backup by disabling compression (or adding a toggle)

Over the years, the boot directory has grown. The native boot backup utility (traditionally referred to as the flash backup) compresses the entire directory, which takes a few minutes and generates unnecessary CPU load.

The largest core system files (like bzmodules, bzfirmware) and many plugin packages, which already use compressed formats like .txz, are already compressed files. Re-compressing them achieves almost nothing, as the rest of the boot directory consists mostly of text-based configuration files, scripts, and XML templates. In my case, testing a backup using compression method 0 (passing the -r0q flags to the zip command) dropped the execution time from nearly two and a half minutes down to just 10 seconds, while the final zip file size only increased by about 14 megabytes out of the 1.3 GB total.

Another benefit of using a store-only archive involves secondary backup systems that use deduplication, such as restic or rsync. Standard zip compression alters the entire byte stream when even a single line changes in a config file. This completely breaks deduplication, forcing backup tools to upload and store over a gigabyte of redundant data daily. Using method 0 allows these tools to recognize that the large system files are identical, saving immense amounts of storage and bandwidth over time.

My suggestion is to either switch the default boot backup behavior to use no compression via the -r0q flags by default, or add a simple checkbox toggle in the interface called something like "Fast backup (no compression)" so users can choose this behavior themselves. It makes the backup experience instantly responsive for a negligible storage cost.