shrink-backup v1.2

A smaller release this time.

• Added curl install method for users that prefer to have application and configs files in a static location, please see wiki
• Various QOL updates regarding the interface
• Bug fixes

shrink-backup v1.1

With this release versioning is changed from x.x.x to x.x

The most noticeable change is the UI with coloring. But small efficiency increases to the code has also been made.

Support for dietPi and webmin. Also created a way to convert your systems ext4 filesystem into f2fs on the img file.
Downside is f2fs can not be resized while mounted unlike with ext4 so the user have to manually expand the img to cover the entire storage medium manually before booting.
Increasing size while updating the img is also not yet covered, but should be doable so this feature will be implemented in a future release.

A loop function to retry 3 times after looping the img file within the script has been implemented because bug reports started coming in about the UUID on the loop not being found, therefore failing the backup.
Giving the system some time seems to resolve the issue.
This seems to be related to if img file is located on a network storage. Usually, but not always, wifi network.

Features in the release:

• UI improvements in form of coloring and other formatting
• New funcionality: --f2fs convert ext4 on root into f2fs on img file
• Added support for f2fs
• Added support for DietPi
• Added support for webmin
• --version option added
• Added .gitignore to github repo for users that change exclude.txt and want to use git pull without issues.

shrink-backup.v1.0.0

I have made the decision to not deal with other partitions than boot and root for the 1.0 release.
Instead I introduced the --loop function to let the user expand the img file using the [extra space] option and then manually create partitions by running for example: sudo gparted /dev/loop0 in a terminal to edit partitions in a graphical interface using gparted.
I want to give the user freedom, but I also have to stay true to my initial plan with this script: a very fast utility to create a bootable img file from the system and subsequently keep it updated

I haven't dropped the idea of at least handling /home completely, but the script goes from "kinda basic functionality" to "advanced script" pretty fast when I start working on the feature.
If I do this, I still want the script to be as easy as possible to use, but at the same time give power users the ability to fine tune, ie a lot of work.

Features in the release:

• Introduction of --loop, --fix & -z (zoom speed)
• Now crosschecks fstab with lsblk for certain operations.
• Changed MB to MiB etc. Old habits die hard.
• Will now, if needed, check and/or ask for installing gdisk on debian and arch based systems.
• GPT partition table now supported
• Various bug fixes.

shrink-backup.v0.9.5

• Dynamic loops instead of hardcoded
• Experimental support for GPT partition table
• Experimantal support for btrfs

shrink-backup.v0.9.4

Img files can now be resized by updating them (-U) and using the -a option.
Img files can also be increased in size by using -U and adding manual space.

shrink-backup.v0.9.3

Added support for rpi os bookworm and completely reworked how the autoexpansion on rpi works.

shrink-backup.v0.9.2

shrink-backup version 0.9.2

Fixed bug where PARTUUID changed on rpi after autoexpansion
Updated debugging
Updated "UI"

shrink-backup.v0.9.1

shrink-backup version 0.9.1

Detects root file system and backs that up regardless of what device it resides on.

Autexpansion on ArchLinuxArm implemented.

Please see README.md for further information

shrink-backup.v0.9.0

Shrink-backup version 0.9.0

Tested on Raspberry Pi os, Armbian, Manjaro-arm and ArchLinuxARM for rpi with ext4 root partition.
Autoexpansion will not work on ArchLinuxARM (will not fail, only warn) at the moment but works on the other three tested.

Default device that will be backed up unless changed with -d is SD-cards, ie /dev/mmcblk0
Booting/backing up from usb-stick (/dev/sda) with Raspberry pi os has been tested lightly and works but still considered experimental.

See wiki for a bit more information about using other devices.

Don't forget to make the script executable