I just had some ideas for this: The problem at the moment is that blindly copying the device contents back means copying a lot of unnecessary data and having a backup image that equals the drive size. If you want to flash that back to a drive that is smaller, but in which the image logically fits, you'll have a hard time figuring out how to reduce appropriately.

As a solution, we can scan the partition table and only copy what is really necessary.

As a solution, we can scan the partition table and only copy what is really necessary.

I thought I'd already suggested that, but maybe I'd imagined it and it was something I was going to suggest, but forgot to 😕
Sounds good 👍

Haha, maybe it was on another related issue and it somehow got lost?

@jviotti, reading this again, I think you're making your life difficult. We can start with a "dumb" imaging process, and improve on that later

Reading the partition table to determine how much of the disk to actually read, and simply outputting a smaller diskimage at the end of the process, isn't that complicated IMHO :-) It's only a small part of the process, so I'd see no reason to leave it out.

@alexandrosm The thing is that copying back the whole thing could bring a lot of issues in the case of Etcher. Most users get away with it using something like dd, since dd will only copy what it can and discard the rest (so doing a backup of the whole thing causes no issues most of the time), however Etcher will complain in that case, which means users can only backup drives that they will re-flash to the same drive or a larger one.

Maybe I'm indeed overthinking it and that's not an usual scenario (maybe people only re-write the backups to the exact same drive most of the time), but if it is, Etcher would feel really awkward.

Any updates/progress on this issue @jviotti?

This would be pretty important for me too - I'd just be doing backups and restores (if needed = I screw up) on the same card anyway.

Hey there,

We are sadly not making progress on this one now given that we're preparing some other major features for a new release. This is something we really want to support, so we'll definitely allocate some time for this soon.

That being said, if anyone is motivated enough to make this work, we welcome contributions to https://github.com/resin-io-modules/etcher-image-write, and then to integrate it with the UI (ping me on Gitter if you're interested and I can provide guidance to implement this)

For anyone just finding this you can now clone devices in balenaEtcher since v1.5.107

You can find the latest versions on the balenaEtcher website or from the GitHub latest release page

For anyone just finding this you can now clone devices in balenaEtcher since v1.5.107

But I guess there's still a slight difference between "clone" (i.e. copy the contents of one SD card to another SD card) and "backup" (i.e. create an image of your SD card on your hard drive) ? 😉

@lurch yep for sure! Have left it open as it is not really a fix - but does allow you to "backup" an image - at least in one sense of the word :-)

[pipex] This issue has attached support thread https://jel.ly.fish/3dd29c3e-5059-4fda-8571-dcb493ae4095

Etcher is so good at writing images, it would be great if the other half of the pipeline of creating images could be covered. And in particular, as the size of cards continues to grow, having an ability to go straight to a compressed image with no intermediate uncompressed file would be tremendously useful.

@daviderickson that would mean having the image information outside of the compressed image, which I'm not sure is possible, or decompressing directly to the media drive which can be significantly slower than just decompressing and then flashing

@daviderickson that would mean having the image information outside of the compressed image, which I'm not sure is possible, or decompressing directly to the media drive which can be significantly slower than just decompressing and then flashing

What image information are you referring to? .img files are raw byte by byte transfers, there wouldn't be any need to decompress part of it to determine how to write it. No question that writing a compressed image would likely be slower than an uncompressed one, but if it saved many GB of temporary disk usage and writes in the meantime, I'd gladly make the trade.

[dtischler] This issue has attached support thread https://jel.ly.fish/d8b51be1-2f34-4a0b-ba36-8c25a552f532

any update on this, it seems to have been in the works since 2016

+1 This - The ability to copy a snapshot/image to a host iso so that they can be cloned later is critical (and so easy given the app's current features)

How many hours of coding do you think this would take?

6 years and still no movement.

indeed, embarrassing.

Just to add another voice that I'd like this feature. Also, compressing to .7z file rather than zip as much better compression. An option to suggest how big an image to make. When inserting a 64GB card with a 8Gb image on it, an possibly a previous image on the card, it might be an idea to have an option for 'erase card before proceeding?' when imaging new media. When creating backup then have an 'Advanced Option' to allow 'select image size' - in MB or GB from the start of the card/disk and discard the rest.

When creating backup then have an 'Advanced Option' to allow 'select image size' - in MB or GB from the start of the card/disk and discard the rest.

AFAIK you can't just "discard the rest" because that would lead to filesystem corruption. I.e. you'd actually need to resize (shrink) the filesystem on the card before you're able to make a "smaller backup" of it. Have a look at e.g. https://github.com/Drewsif/PiShrink (which I think only runs on Linux, because Windows and Mac don't support Linux filesystems).

May 2023 be the year that you finally implement this...

I ended up putting a script together to fill this gap....

(updated link) https://github.com/matthew-l-weber/create-etcher-image/tree/main

Thank you @matthew-l-weber

Two questions:

1. Can the resulting image be restored with Balena Etcher?
2. When you write error "Image file exists, skilling capture...", do you rather mean error "Image file exists, killing capture..."?

.. and one suggestion - instead:

#  -z         Compress image after shrinking with gzip
#  -Z         Compress image after shrinking with xz

->

#  -g         Compress image after shrinking with gzip
#  -x         Compress image after shrinking with xz

Thank you @matthew-l-weber

Two questions:

1. Can the resulting image be restored with Balena Etcher?

2. When you write `error "Image file exists, skilling capture..."`, do you rather mean `error "Image file exists, killing capture..."`?

.. and one suggestion - instead:

#  -z         Compress image after shrinking with gzip
#  -Z         Compress image after shrinking with xz

->

#  -g         Compress image after shrinking with gzip
#  -x         Compress image after shrinking with xz

1. Yes the resulting compressed image can be restored with Balena Etcher
2. I meant to have that error state that I'm skipping the capture as the image file already exists. I'll move the code into the follow git repo so it's easier if others want to comment/pull request - https://github.com/matthew-l-weber/create-etcher-image/tree/main
3. For the suggestion, I dropped the usage that I had copied as it was from the pshrink tool the script uses. Instead I updated the comment to point at the original repository readme

I'll move the code into the follow git repo so it's easier if others want to comment/pull request - https://github.com/matthew-l-weber/create-etcher-image/tree/main

IMHO as your script makes use of PiShrink, it would seem "polite" to credit https://github.com/Drewsif/PiShrink in https://github.com/matthew-l-weber/create-etcher-image/blob/main/README.md ?

Mighty fine. xz is more efficient than gzip anyway.

However, I get

git@github.com: Permission denied (publickey). fatal: could not read from remote repository

I can git from other repositories no problem, though. Do you need to make it available for the public?

Mighty fine. xz is more efficient than gzip anyway.

However, I get

git@github.com: Permission denied (publickey). fatal: could not read from remote repository

I can git from other repositories no problem, though. Do you need to make it available for the public?

It was public but I noticed I had used ssh cloning. I've switched it to http so things should be good.

Hello,

Any news on this ?

If Etcher can image a drive and clone it to another, it certainly could just export said image to a file.

Thanks

I give up and going to backup with https://github.com/stevenshiau/clonezilla