search

balena-io / etcher

Flash OS images to SD cards & USB drives, safely and easily.
https://etcher.io/
Apache License 2.0
29.51k stars 2.1k forks source link

Implement a way to perform a backup from a drive #266

Open jviotti opened 8 years ago

jviotti commented 8 years ago

From https://github.com/resin-io/etcher/issues/265

This option would copy whatever there is on the device as a local *.img file, and will compress it as a ZIP archive, in a way that can be easily burnt back with Etcher.

Front logo Front conversations

rin67630 commented 5 years ago

By the way: to get rid of the useless data, you could implement a simple preliminary step: write a growing file with zeroes to the SD card until until it returns "full", then delete that file... The compressed result should be perfect...

mitra42 commented 4 years ago

Judging by the length of this topic, I guess this is never going to happen. RPI's do a good job (mostly) with this with their SD Card copier, but seems to be incompatible with something (maybe usbmount) - would be great to see this is in Balena Etcher

jadonk commented 4 years ago

I'd really like to see this pushed across the finish line.

jellyfish-bot commented 4 years ago

[thundron] This issue has attached support thread https://jel.ly.fish/07f4700b-023b-477c-abf3-6671b374f3cd

kevincastejon commented 4 years ago

You should have listened to @alexandrosm 3 years ago when he was proposing to implement a "dumb" copying of the image as a start and improve it later.. I'm really waiting for this feature to come.

knghtbrd commented 3 years ago

I'm no longer looking for this feature in balenaEtcher.

I'd suggest that garnering a reputation for deleting criticism isn't good PR, but doubt anyone at balena cares what I think.

thundron commented 3 years ago

@iKarith given it wasn't criticism but just banter and veiled insults for a completely different issue (not that would be justified in a different issue), yes, we don't want those to appear anywhere ideally and it's not the first time either. Now on criticism - it can be hard, but we don't and will never disapprove it and we even welcome it as much as we can - when it stays in the boundaries of criticism, that is. Let's keep the discussion on the subject now - this issue is for backing up a drive and I'd like it to stay so :)

shawaj commented 3 years ago

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

lurch commented 3 years ago

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) ? :wink:

shawaj commented 3 years ago

@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 :-)

jellyfish-bot commented 3 years ago

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

daviderickson commented 3 years ago

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.

thundron commented 3 years ago

@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 commented 3 years ago

@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.

jellyfish-bot commented 3 years ago

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

charettepa commented 2 years ago

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

doug62 commented 2 years ago

+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)

LeeBinder commented 2 years ago

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

djgranger commented 2 years ago

6 years and still no movement.

LeeBinder commented 2 years ago

indeed, embarrassing.

mattbland commented 2 years ago

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.

lurch commented 2 years ago

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).

WhoCares1337 commented 1 year ago

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

matthew-l-weber commented 1 year ago

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

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

LeeBinder commented 1 year ago

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
matthew-l-weber commented 1 year ago

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

lurch commented 1 year ago

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 ?

LeeBinder commented 1 year ago

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?

matthew-l-weber commented 1 year ago

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.

KaKi87 commented 1 year ago

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

pschonmann commented 1 year ago

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

meta-vi commented 4 months ago

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

Hello, are you using this tool to cloning Tinkerboard image? Could you give me some guide to use it. Thanks

enessmr commented 1 month ago

just turn on RAID-5 and copy all of the data of ur disk then bam you can flash image now