Well, I wrote the instructions above for a reason. When you don't provide the 'bs=' parameter then dd will use its defaults (1 block == 512 bytes) which slows down the cloning process like hell:
bs=n Set both input and output block size to n bytes, superseding the
ibs and obs operands. If no conversion values other than
noerror, notrunc or sync are specified, then each input block is
copied to the output as a single block without any aggregation
of short blocks.
Also it's somewhat weird to not compress the image on the fly. So now just as a reference and as preparation for a hopefully improved Armbian documentation soon.
One way to do an offline clone from an Armbian installation with minimum size requirements would be to fill out all the unused space with zeros before (this really helps with compression afterwards if a lot of filesystem activity happened on the SD card before!) and then use a more efficient packer. So given the SD card is /dev/sdd you would do
mkdir /mnt/clone
mount /dev/sdd1 /mnt/clone
dd if=/dev/zero of=/mnt/clone/empty.file bs=10M || rm /mnt/clone/empty.file
umount /mnt/clone && rmdir /mnt/clone
dd if=/dev/sdd bs=10M | gzip -c >/path/to/gzipped.img.gz
dd if=/dev/sdd bs=10M | 7zr a -bd -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on -si /path/to/7zipped.img.7z
I did this with a quite normal Armbian desktop image on an 8 GB SD card that looks like this
/dev/sdd1 7,3G 2,1G 5,2G 29% /mnt/clone
Instead of an uncompressed image that is 7.3GB in size the zeroed out 7z is 1.2GB in size and the gzip variant 1.7GB (please note that you could add '-9' then gzip would compress a little bit better).
But here comes a more intelligent approach: Only outlined as a stub since others should do the job and try to earn a REWARD for this:
When there's already a PC running Linux with a somewhat recent kernel where we can insert the SD card to create an offline clone then to combine the best of two worlds would be:
Create a btrfs filesystem using maximum compression (compress=zlib)
Configure keyless SSH authentication between your Linux host and the Armbian installation on the SBC to be able to run rsync later to copy filesystem's contents from the SBC to your Linux host
Shut down your SBC, insert the SD card with the Armbian image into the PC, zero the unused space out and create an uncompressed dd image (the image will not be compressed internally since the filesystem does this job. So based on the aforementioned example the image we will create will show as being 7.3GB large but will only need approx. 1.3GB on disk since btrfs provides transparent file compression)
Eject the SD card and start your SBC again
Now setup a script on the Linux host that uses the btrfs command, losetup and rsync to
create a snapshot of the btrfs filesystem where the uncompressed image is hosted
mount the 1st partition of this image
use rsync to incrementally update the OS image on your Linux host with the contents of / on the SBC (/dev/mmcblk0p1) through the network
set up a cron job that does this automagically
This way a whole bootable OS image only using the minimum amount of needed space will be stored on the Linux host and incrementally be updated. Since btrfs allows for transparent file compression and supports snapshots in case 100 MB have changed between two rsync runs (and given this data is compressable by 1:2) the whole storage requirements to store the new OS image variant will only be 50MB more. Yes, you have two independant OS images using this snapshot and compression technique that require not 8GB + 8 GB but just 1.3GB + 50MB.
If such a script has been set up then we're starting to talk about backup and not stupid cloning any more. Since then we're talking about
periodically saving the filesystem's contents
to a different location
implementing versioning (old/deleted/changed stuff remains on the Linux host in the form of older snapshots)
allowing also for desaster recovery (since we created a bootable OS image in the first place)
And the best news: The first step does also work through the network so in case we want to backup an internal eMMC then we boot the SBC with an SD card and transfer the dd image through the network to the Linux host. Also if you want to save a fleet of Armbian installations then simply also activate deduplication in btrfs and you'll end up with disk storage of below 2 GB to store eg. 8 Armbian desktop installation all being +2 GB in size
Now it's time for someone to write this up as a nice tutorial and start to code this armbian-clone script. And please remember: If you do start contributing to community efforts there's something you'll get in return: http://forum.armbian.com/index.php/topic/1325-claim-a-task-and-do-it/
Sorry, we can't support in-place upgrade from any other releases (and even dist-upgrades from much older Armbian releases is not recommended). Just install a clean Armbian image and try to transfer your configuration to the new system.
You can save the file system contents for offline access, but it's not possible to fully emulate this hardware.
Armbian -> Armbian dist-upgrade should work fine for new images, but it's always recommended to start from scratch to include new tweaks and configuration templates.
You should do yourself a favour and get a new SD card showing high random IO performance (I would still recommend Samsung EVO or EVO+): https://forum.armbian.com/index.php/topic/954-sd-card-performance/
Then you start with a fresh Armbian install from scratch and can then migrate settings/stuff from your old installation (maybe an USB card reader needed too) while also being able to boot your old installation to check certain things.
