bedna Posted July 28, 2023 Posted July 28, 2023 (edited) shrink-backup is a bash script for backing up your SBC:s into an img file Version 1.2 Info updated: 20 Oct, 2024. shrink-backup I made this script because I wanted a universal method of backing up my SBC:s into img files as fast as possible (with rsync), no matter what os is in use. Supports backing up root & boot (if existing) partitions. Data from other partitions will be written to root if not excluded (exception for btrfs, all existing subvolumes in /etc/fstab will be created). Please see Info section. Autoexpansion tested on Raspberry Pi os (bookworm and older), Armbian, Manjaro-arm, DietPi and ArchLinuxARM for rpi with ext4 or f2fs root partition. (Now also experimental btrfs functionality, please read further down) Full support for usage inside webmin (including "custom command" button). Latest release: shrink-backup.v1.2 Testing branch if you want to have the absolute latest version. There might be bugs. Very fast restore thanks to minimal size of img file. Can back up any device as long as root is ext4 or f2fs (experimental btrfs) Default device that will be backed up is determined by scanning what disk-device root resides on. This means that if boot is a partition, that partition must be on the same device and before the root partition. Backing up/restoring, to/from: usb-stick /dev/sdX with Raspberry pi os has been tested and works. Ie, writing an sd-card img to a usb-stick and vice versa works. Ultra-fast incremental backups to existing img files. See wiki for information about installation methods, usage and examples. Ideas and feedback is always appreciated, whether it's positive or negative. Please just keep it civil. If you find a bug or think something is missing in the script, please file a Bug report or Feature request Don't forget to ensure the script is executable. To restore a backup, simply "burn" the img file to a device using your favorite method. When booting up a restored image with autoresize active, wait until the the reboot sequence has occured. The login prompt may very well become visible before the autoresize function has rebooted. Usage: shrink-backup -h Script for creating an .img file and subsequently keeing it updated (-U), autoexpansion is enabled by default Directory where .img file is created is automatically excluded in backup ######################################################################## Usage: sudo shrink-backup [-Uatyelhz] [--fix] [--loop] [--f2fs] imagefile.img [extra space (MiB)] -U Update existing img file (rsync to existing img) Optional [extra space] extends img size of root partition -a Autoresize root partition (extra space is ignored) When used in combination with -U: Expand if partition is >=256MiB smaller than resize2fs recommended minimum Shrink if partition is >=512MiB bigger than resize2fs recommended minimum -t Use exclude.txt in same folder as script to set excluded directories One directory per line: "/dir" or "/dir/*" to only exclude contents -y Disable prompts in script (please use this option with care!) -e DO NOT expand filesystem when image is booted -l Write debug messages to logfile shrink-backup.log located in same directory as script -z Make script zoom at light-speed, only question prompts might slow it down Can be combined with -y for UNSAFE ultra mega superduper speed --fix Try to fix the img file if -a fails with a "broken pipe" error --loop [img] Loop img file and exit, works in combination with -l & -z If optional [extra space] is defined, the img file will be extended with the amount before looping NOTE that only the file gets truncated, no partitions Useful if you for example want to manually manage the partitions --f2fs Convert root filesystem on img from ext4 to f2fs Only works on new img file, not in combination with -U Will make backups of fstab & cmdline.txt to: fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak Then change ext4 to f2fs in both files and add discard to options on root partition in fstab --version Print version and exit -h --help Show this help snippet ######################################################################## Examples: sudo shrink-backup -a /path/to/backup.img (create img, resize2fs calcualtes size) sudo shrink-backup -e -y /path/to/backup.img 1024 (create img, ignore prompts, do not autoexpand, add 1024MiB extra space) sudo shrink-backup -Utl /path/to/backup.img (update img backup, use exclude.txt and write log to shrink-backup.log) sudo shrink-backup -U /path/to/backup.img 1024 (update img backup, expand img size/root partition with 1024MiB) sudo shrink-backup -Ua /path/to/backup.img (update img backup, resize2fs calculates and resizes img file if needed) sudo shrink-backup -Ua --fix /path/to/backup.img 1024 (update img backup, automatically resizes img file if needed, fix img free space) sudo shrink-backup -l --loop /path/to/backup.img 1024 (write to log file, expand IMG FILE (not partition) by 1024MiB and loop) -t (exclude.txt) The folder where the img file is created will ALWAYS be excluded in the backup. If -t option is selected, exclude.txt MUST exist (but can be empty) within the directory where the script is located or the script will exit with an error. Use one directory per line in exclude.txt. /directory/* = create directory but exclude content. /directory = exclude the directory completely. If -t is NOT selected the following folders will be excluded: /lost+found /proc/* /sys/* /dev/* /tmp/* /run/* /mnt/* /media/* /var/swap Please see info section further down. -l (Log file) Use -l to write debug info into shrink-backup.log file in the same directory as the script. -z (Zoom speed) The -z "zoom" option simply removes the one second sleep at each prompt to give the user time to read. By using the option, you save 15-25s when running the script. When used in combination with -y warnings will also be bypassed! PLEASE use with care! --fix (Broken pipe) Add --fix to your options if a backup fails during rsync with a "broken pipe" error. You can also manually add [extra space] instead of using -a to solve this. Example: sudo shrink-backup -Ua --fix /path/to/backup.img The reason it happens is because rsync normally deletes files during the backup, not creating a file-list > removing files from img before starting to copy. So if you have removed and added new data on the system you backup from, there is a risk rsync tries to copy the new data before deleting data from the img, hence completely filling the img. Using --fix makes rsync create a file-list and delete data before starting to transfer new data. This also means the backup takes a little longer. Having a "broken pipe" error during backup has in my experience never broken an img backup after either using --fix (can be used in combination with -a) or adding [extra space] while updating the backup with -U. --loop (Loop img file) Use --loop to loop an img file to your /dev. Example: sudo shrink-backup --loop /path/to/backup.img If used in combination with [extra space] the amount in MiB will be added to the IMG FILE NOT any partition. With this you can run for example run: sudo gparted /dev/loop0 (if you have a graphical interface) to manually manage the img partitions in a graphical interface with gparted. If you added [extra space] this will then show up as unpartitioned space at the end of the device where you can create partition(s) and manually copy data to by mounting the new loop partition that will become visible in lsblk. If you do this, don't forget to create or update the img with -e (disable autoexpansion) first. Autoexpansion will not work since the space will be occupied by your manually managed partition. Example: sudo shrink-backup --loop /path/to/backup.img 1024 This functionality works on any linux system, just use the script on any img file anywhere available to the computer. To remove the loop: sudo losetup -d /dev/loop0, change loop0 to the correct dev it got looped to. To remind yourself: lsblk /dev/loop* (if you forgot the location after using --mount) --f2fs (Convert ext4 into f2fs on img file) ONLY use this for CONVERTING filesystem into img file, if you already have f2fs on your root, do not use this option. The script will detect what filesystem is used on root and act accordingly. Only supported with new backups, not when using -U. Autoexpansion at boot is not supported for f2fs (there is no way of resizing a mounted f2fs filesystem, unlike with ext4) so resizing root partition have to be made manually after writing img to sd-card. Resize operations (when updating backup with -U) is not available for f2fs as of now. The script will make backups of fstab & cmdline.txt into fstab.shrink-backup.bak & cmdline.txt.shrink-backup.bak on the img. It will then change from ext4 to f2fs in fstab & cmdline.txt and add discard to the options on the root partition in fstab. Please read information about f2fs further down. Info Rsync WILL cross filesystem boundries, so make sure you exclude external drives unless you want them included in the backup. (separate /home for example) The script will ONLY create boot (if exits) and root partitions on the img file. The script will ONLY look at your root partition when calculating sizes. Not excluding other partitions will copy the data to the img root partition, not create more partitions so make sure to manually add [extra space] if you do this. Experimental btrfs is an exception to this, all subvolumes will be created. Applications used in the script: fdisk sfdisk dd parted e2fsck truncate mkfs.ext4 rsync gdisk (sgdisk is needed if the partition table is GPT, the script will inform you) ######################################################################## Image creation To create a backup img using recomended size, use the -a option and the path to the img file. Example: sudo shrink-backup -a /path/to/backup.img Theoretically the script should work on any device as long as root filesystem is ext4, f2fs or experimental btrfs. Since the script uses lsblk to crosscheck with /etc/fstab to figure out where the root resides it does not matter what device it is on. Even if you forget to disable autoexpansion on a non supported system, the backup will not fail. Order of operations - image creation Reads the block sizes of the partitions Uses dd to create the boot part of the system + a few megabytes to include the filesystem on root (this can be a partition) Removes and recreates the root partition, size depends on options used when starting the script Creates a new ext4 filesystem with the same UUID and LABEL as the system you are backing up from Uses rsync to sync both partitions (if more than one) Uses lsblk & /etc/fstab to figure out the correct disk device to back up. Reads the block sizes of the system's root (and boot if it exists) partition. Uses dd to create the boot part of the system + a few megabytes to include the filesystem on root. (this can be a partition) Uses df & resize2fs to calculate sizes by analyzing the system's root partition. (For btrfs: btrfs filesystem du + 192MiB is used instead of resize2fs) Uses truncate to resize img file. Loops the img file. Removes and recreates the root partition on the loop of the img file. Creates the root filesystem on loop of the img file with the same UUID and LABEL as the system you are backing up from. Creates a temp directory and mounts img file root partition from loop. Checks if boot partition exists, if true, checks fstab and creates directory on root and mounts accordingly from loop. Uses rsync to sync filesystems. Tries to create autoresize scripts if not disabled with -e. Unmounts and removes temp directory and file (file created for rsync log output). Added space is added on top of df reported “used space”, not the size of the partition. Added space is in MiB, so if you want to add 1GB, add 1024. The script can be instructed to set the img size by requesting recommended minimum size from e2fsck by using the -a option. This is not the absolute smallest size you can achieve bit is the “safest” way to create a “smallest possible” img file. If you do not increase the size of the filesystem you are backing up too much, you can most likely keep it updated with the update function (-U) of the script. By using -a in combination with -U the script will resize the img file if needed (not supported on f2fs). Using combination -Ua on an img that has become overfilled works, if not add --fix and retry. Please see --fix and image update sections for more information. Smallest possible image To get the absolute smallest img file possible, do NOT set -a option and set “extra space” to 0 Example: sudo shrink-backup /path/to/backup.img 0 This will instruct the script to get the used space from df and adding 128MB “wiggle room”. If you are like me, doing a lot of testing, rewriting the sd-card multiple times. The extra time it takes each time will add up pretty fast. Example: -rw-r--r-- 1 root root 3.7G Jul 22 21:27 test.img # file created with -a -rw-r--r-- 1 root root 3.3G Jul 22 22:37 test0.img # file created with 0 Disclaimer: Because of how filesystems work, df is never a true representation of what will actually fit on a created img file. Each file, no matter the size, will take up one block of the filesystem, so if you have a LOT of very small files (running docker f.ex) the “0 added space method” might fail during rsync. Increase the 0 a little bit and retry. This also means you have VERY little free space on the img file after creation. If the filesystem you back up from increases in size, an update (-U) of the img file might fail. By using -a in combination with -U the script will resize the img file if needed (not supported on f2fs). Using combination -Ua on an img that has become overfilled works, if not add --fix and retry. Please see --fix and Image update sections for more information. ######################################################################## Image update To update an existing img file simply use the -U option and the path to the img file. Example: sudo shrink-backup -U /path/to/backup.img Order or operations - image update Loops the img file. Probes the loop of the img file for information about partitions. If -a is selected, calculates sizes by comparing root sizes on system and img file by using fdisk & resize2fs. Expands filesystem on img file if needed or if manually added [extra space] is used. Creates temp directory and mounts root partition from loop. Checks if boot partition exists, if true, checks fstab and creates directory on root and mounts accordingly from loop. Uses rsync to sync filesystems. Shrinks filesystem on img file if -a was used and conditions were met in point 3. Tries to create autoresize scripts if not disabled with -e. Unmounts and removes temp directory and file (file created for rsync log output). Resizing img file when updating If -a is used in combination with -U, the script will compare the root partition on the img file to the size resize2fs recommends as minimum (or du calculations depending on filesystem). The img file root partition needs to be >=256MB smaller than resize2fs recommended minimum to be expanded. The img file root partition needs to be >=512MB bigger than resize2fs recommended minimum to be shrunk. This is to protect from unessesary resizing operations most likely not needed. If manually added [extra space] is used in combination with -U, the img file's root partition will be expanded by that amount. No checks are being performed to make sure the data you want to back up will actually fit. Only expansion is possible with this method. ######################################################################## f2fs The script will detect f2fs on root automatically and act accordingly. Do NOT USE --f2fs unless you are converting from a ext4 filesystem (on your system) into f2fs on the img file. Autoexpansion at boot is not possible with f2fs. User will have to manually expand img to cover entire storage media (f.ex sd-card) when restoring. Resizing of img root partition while updating img (-U) is not possible with f2fs as of now. User will have to create a new backup if img runs out of space. This is something I am planning to implement further down the line. btrfs ALL testing has been done on Manjaro-arm THIS IS NOT A CLONE, IT IS A BACKUP OF REQUIRED FILES FOR A BOOTABLE BTRFS SYSTEM! All options in the script should work just as on ext4. The script will detect btrfs and act accordingly. The script will treat snapshots as nested volumes, so make sure to exclude snapshots if you have any, or directories and nested volumes will be created on the img file. This can be done in exclude.txt, wildcards should work. When starting the script, the initial report window will tell you what volumes will be created. Make sure these are correct before pressing Y. As of now, top level subvolumes are checked for in /etc/fstab and mounted accordingly, mount options should be preseved (if you for example changed compression). Autoresize function works on Manjaro-arm. ---------------------------------------------------------------------------------------------------------------------------------------------------------- Thank you for using my software ❤️ A backup is not really a backup until you have restored from it. Edited October 20 by bedna Updated information because I now could. :) 0 Quote
bedna Posted July 28, 2023 Author Posted July 28, 2023 (edited) A few changes introduced a bug that made armbian detect 2 partitions instead of one so If you have cloned it since op was made, you have to re clone it, the bug is now fixed. Sorry about that. Edited July 28, 2023 by bedna 0 Quote
bedna Posted August 1, 2023 Author Posted August 1, 2023 Good news everyone! Yesterday a new kernel update (5.15.93-sunxi64 > Linux 6.1.42-sunxi64) was pushed to my armbian on an opiPC2 and u-boot was triggered. Made tests by updating my old image instead of creating a new, then trying to boot from that image with GREAT success! I did not look deeper into what the u-boot actually did, but this time it worked at least. 0 Quote
bedna Posted August 14, 2023 Author Posted August 14, 2023 (edited) Attention, attention, version 0.9.1 released!! come get your free copy! xD A lot has happened: Device being backed up is what root resides on, ie works on any device now, not just mmcblk. No need to specify, script is smart enough to figure it out. ArchLinuxArm autoexpansion now supported without the need for any AUR downloads, only parted is needed. Tested to update with same image through kernel and boot changes on Armbian on orangePi-PC2 and no issues detected. Tested to update with same image through kernel and boot changes on ManjaroArm and no issues detected. Generally a more user friendly interface and the debug function is beyond explanatory. hint hint Hope you find it useful! Edit: Sadly I can no longer edit the original post to update with current information, but the link to github is still valid and all new info is available there. 😄 Edited August 14, 2023 by bedna 0 Quote
bedna Posted January 29 Author Posted January 29 Version 0.9.5 released. Support added for OrangePi 5. (gpt partition table) Experimental support for btrfs. For more information, please see https://github.com/UnconnectedBedna/shrink-backup 0 Quote
bedna Posted April 19 Author Posted April 19 ==> shrink-backup v1.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. I hope you find it useful! 0 Quote
bedna Posted June 26 Author Posted June 26 ==> shrink-backup 1.1 release <== 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. Thank you for reading. 0 Quote
basshunger Posted September 25 Posted September 25 wow nice read! thanks for your work! gonna test that out now on my x86 laptop running Armbian 24.8.3 0 Quote
robertoj Posted October 7 Posted October 7 Thank you for your work The concept sounds super useful to me... I will try it 0 Quote
robertoj Posted October 18 Posted October 18 I tried it... and I wished that the -d option was still there... I had to download an old version... however, it didn't work with -d /dev/mmcblk0 ... it started scanning my nvme root But I like the mechanics and the interface Now I am going to try it the normal way, with latest version. Update: I tried it from my orange pi zero 3, Armbian Linux 6.6 Spoiler roberto@myopiz3:/media/thumbdrive/shrink-backup$ sudo ./shrink-backup -a my_armbian_backup.img ## Zoom speed NOT requested... ## Scanning filesystem and calculating... ##################################################################################### # A backup will be created at /media/thumbdrive/shrink-backup/my_armbian_backup.img # # ext4 filesystem detected on root # # --------------------------------------------------------------------------------- # # Write to logfile: false # # Zoom speed requested: false # # Autocalculate img root partition size: true # # Autoexpand filesystem at boot: true # # Use exclude.txt: false # # Bootsector size: 3MiB # # Estemated root usage: 2176MiB # # Auto calculated size (root partition): 2578MiB # # Total img size: 2582MiB # ##################################################################################### ## Do you want to continue? [y/n] y ## Creating bootsector... 18431+0 records in 18431+0 records out 9436672 bytes (9.4 MB, 9.0 MiB) copied, 0.395813 s, 23.8 MB/s ## Resizing img file... ## Looping img file... ## Removing root partition... ## Recreating root partition... ## Formatting filesystem... mke2fs 1.47.0 (5-Feb-2023) Discarding device blocks: done Creating filesystem with 660106 4k blocks and 165312 inodes Filesystem UUID: 90b38738-deb4-4021-8044-9eddfda48c58 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done ## Checking img filesystem... armbi_root: 11/165312 files (0.0% non-contiguous), 28708/660106 blocks ## Creating temp directory... ## Mounting img root partition... ## Backing up files... sending incremental file list deleting lost+found/ ./ bin -> usr/bin initrd.img -> boot/initrd.img-6.6.16-current-sunxi64 initrd.img.old -> boot/initrd.img-6.6.16-current-sunxi64 lib -> usr/lib sbin -> usr/sbin vmlinuz -> boot/vmlinuz-6.6.16-current-sunxi64 vmlinuz.old -> boot/vmlinuz-6.6.16-current-sunxi64 boot/ boot/.next 0 0% 0.00kB/s 0:00:00 (xfr#1, ir-chk=1066/1105) boot/Image -> vmlinuz-6.6.16-current-sunxi64 boot/System.map-6.6.16-current-sunxi64 3.56M 6% 23.51MB/s 0:00:00 (xfr#2, ir-chk=1078/1105) boot/armbianEnv.txt 3.56M 6% 23.51MB/s 0:00:00 (xfr#3, ir-chk=1077/1105) boot/armbian_first_run.txt.template 3.56M 6% 23.36MB/s 0:00:00 (xfr#4, ir-chk=1076/1105) boot/boot.bmp 3.79M 7% 22.82MB/s 0:00:00 (xfr#5, ir-chk=1075/1105) ... thousands of lines later ... var/log/sysstat/sar09 1.99G 99% 4.53MB/s 0:06:58 (xfr#88868, to-chk=14/102914) var/log/sysstat/sar10 1.99G 99% 4.53MB/s 0:06:58 (xfr#88869, to-chk=13/102914) var/log/sysstat/sar19 1.99G 99% 4.53MB/s 0:06:58 (xfr#88870, to-chk=12/102914) var/mail/ var/opt/ var/spool/ var/spool/mail -> ../mail var/spool/cron/ var/spool/cron/crontabs/ var/spool/rsyslog/ var/tmp/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-bluetooth.service-x9tTvV/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-bluetooth.service-x9tTvV/tmp/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-chrony.service-jC1xd8/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-chrony.service-jC1xd8/tmp/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-systemd-logind.service-CHH53d/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-systemd-logind.service-CHH53d/tmp/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-systemd-resolved.service-lnPMrV/ var/tmp/systemd-private-3643107540ea46368972fb8ab0e9a9ff-systemd-resolved.service-lnPMrV/tmp/ 1.99G 99% 4.53MB/s 0:06:59 (xfr#88870, to-chk=0/102914) Number of files: 102,914 (reg: 88,876, dir: 10,303, link: 3,735) Number of created files: 102,913 (reg: 88,876, dir: 10,302, link: 3,735) Number of deleted files: 1 (dir: 1) Number of regular files transferred: 88,870 Total file size: 2.00G bytes Total transferred file size: 1.99G bytes Literal data: 1.99G bytes Matched data: 0 bytes File list size: 2.36M File list generation time: 0.003 seconds File list transfer time: 0.000 seconds Total bytes sent: 2.00G Total bytes received: 1.76M sent 2.00G bytes received 1.76M bytes 4.76M bytes/sec total size is 2.00G speedup is 1.00 ## Rsync done... ## Please stand by... ## Finalizing filesystem... armbi_root: Inode 100609 extent tree (at level 1) could be shorter. IGNORED. armbi_root: /lost+found not found. CREATED. 102918 inodes used (62.26%, out of 165312) 88 non-contiguous files (0.1%) 30 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 99269/4 585744 blocks used (88.73%, out of 660106) 0 bad blocks 1 large file 88870 regular files 10303 directories 0 character device files 0 block device files 0 fifos 6 links 3735 symbolic links (3636 fast symbolic links) 0 sockets ------------ 102914 files ## Remounting for autoexpansion... ## Mounting img root partition... ## Enabling fs-autoexpand... ## Armbian OS detected... ## Armbian filesystem autoresizing at boot... ## Backup done. ##################################################################################### ## Write to logfile: false # ## Autoexpand filesystem at boot: true # ## Use exclude.txt: false # ## /media/thumbdrive/shrink-backup/my_amrbian_backup.img is 2582MiB with a root partition of 2578MiB # ## Please wait for the system to reboot after restoring an image with autoexpansion # ##################################################################################### ## Exiting and cleaning up... ## Please stand by... ## Done. ## Elapsed time: 08.04 roberto@my-opiz3:/media/thumbdrive/shrink-backup$ ls -l total 2325160 -rw-r--r-- 1 roberto roberto 83 Aug 1 2023 exclude.txt -rw-r--r-- 1 roberto roberto 1539 Jun 25 15:20 LICENSE -rw-r--r-- 1 root root 2707992064 Oct 18 18:52 my_armbian_backup.img -rw-r--r-- 1 roberto roberto 18192 Jun 25 15:00 README.md -rwxr-xr-x 1 roberto roberto 99071 Jun 25 14:58 shrink-backup roberto@my-opiz3:/media/thumbdrive/shrink-backup$ Now I have a 2.7GB IMG file in a USB drive which I bring to my Linux Mint laptop Balena etcher has just finished flashing, and is estimating 30 minutes to validate 2.7 GB completed validating quickly too (I was using the laptop sd writer and that is not as reliable as my very cheap USB microSD writer). The Armbian Image booted just fine in a newer Orange Pi Zero 3. THANK YOU FOR MAKING THIS TOOL. I WILL USE IT MANY TIMES 0 Quote
bedna Posted October 20 Author Posted October 20 I am not sure why I do not get email notifications when posts are made here, I thought I fixed that... (lmao, I just realized I had for some reason unclicked "follow topic") Thank you so much, both of you for your feedback! ------------------------------------------------------------------------------------------------------- shrink-backup v1.2 released As per usual, I can not change OP so for full and updated information please visit https://github.com/UnconnectedBedna/shrink-backup 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 Thank you for using shrink-backup! 0 Quote
Werner Posted October 20 Posted October 20 1 hour ago, bedna said: As per usual, I can not change OP Try again 0 Quote
bedna Posted October 20 Author Posted October 20 2 hours ago, Werner said: 3 hours ago, bedna said: Try again Thank you! Op now updated to reflect current version. 0 Quote
Igor Posted October 21 Posted October 21 22 hours ago, bedna said: Op now updated to reflect current version. Welcome to try with integration to https://github.com/armbian/configng We didn't set rules how to include tools from external repo yet, so this is a bit wild ... - there are unit tests in place for each command - automatic documentation generation is WIP 0 Quote
bedna Posted October 22 Author Posted October 22 (edited) Yes, I am working on that. Whiptail is what I am educating me in closer right now. But it will most likely be it's own script. Trying to implement the script straight up I think would become messy pretty fast, and I don't think anybody is interested in that. But yes, it is happening, sometime.. xD I was honestly hoping it would already be a reality, but my health keeps putting up roadblocks for me. Edited October 22 by bedna 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.