I have an external drive I was planning on using to store complete disc images for several different PCs, each image in its own folder, and I just wanted to be clear on what the image feature (not clone) of CZ LiveCD does and does not do before I start.
If I use device-image, and select local device sda for the source and local device sdb1 for the destination, I expect what I will end up with is that several files will be created on sdb1 (from other posts, at least 6 files) which represent the image data for the entire source disc, including all the partition info necessary to completely and exactly re-create the original image.
I expect that it does not matter what format or partition type sdb1 has originally as long as it is one of the standard supported types, and is big enough. The partition and formatting will not be changed in any way by the device-image program, other than to have the new files written to it.
Is everything I have described above accurate?
Is there any reason to chose clone vs image if my purpose is only to backup?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The partition and formatting will not be changed in any way by the device-image program, other than to have the new files written to it. "
Yes. in your case, clonezilla will just mount /dev/sdb1 and write files/dirs on that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for clarifying. I know these are basic questions, but I don't see them answered on your site.
Also I expect that as long as I keep the related image files together, I can copy or move them to any other mountable media and restore the image directly from there (as long as I use the same or newer version of CZ.
A nice feature to have would be a way to run device-image or device-device without any actual writing taking place, so maybe you could see the disc space needed for the image or clone. Even better, using a virtual drive as a destination so you could see the entire detailed report of the process.
Not trying to create more work for you, but you have created a very useful thing that deserves to get even better ;).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
tns1,
Thanks for your ideas. Actually I have no idea how to do "without any actual writing taking place", if you have any more info, please let me know.
As for virtual drive, well, if you can prepare a virtual machine, say virtualbox or vmware, then for Clonezilla, it's not a problem to save an image on virtual machine.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had the 'opportunity' to use images I have created with CZ live to restore my messed up HD twice now, and it did exactly what it was supposed to do. Its fast (~20min for a typical factory image) and the images are smaller than expected. Thanks for a great program.
My biggest problem with CZ was that the dialogs & terminology used in the program did not give me 100% certainty that I was making the correct selections and I was not going to destroy the data I was trying to archive. A little more explanation in the selection dialogs or a GUI (or even a simple ascii graphics picture) would go a long way to eliminate that fear:
For newbies, go out and buy a $100 external usb HD to experiment with and you will soon get past the learning phase with little risk to your data. Thanks to CZ I can have easy to access backup images of 10 or more PCs all on the same portable media.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The whole idea is to provide some kind of practice or 'dry run' option, so a user knows exactly what will happen before actually writing to a disk. Gparted provides something like this by providing a picture of the partitioning before it is applied. If the picture looks good, I have some confidence I'll get what I want.
The simplest idea for CZ is just to provide an estimate of disk space needed for the resulting image. Since there are usually multiple partitions, & compression, it isn't obvious how much space is needed. You would probably only need to extract the numbers obtained in the source disk analysis steps, add them up, and show the number. Even better is to show each file name that will be created with the size & total.
A better version of this might perform just the source disk operations used in creating an image: reading, analysis, compression, but skip the writes, or write to a null device instead. This way you can show most or all of the dialogs that would appear during the actual process.
The idea of using a virtual drive (ramdisk) for the destination is probably not good since available ram is much smaller than a typical disk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the ideas.
I think some of them are related to some GUI, we might have a GUI in the future.
As for estimating the image size, well, it's not an easy thing, since it is done runtime, almost impossible to estimate. Please correct me if I am wrong.
As for write to an null device, if you know how a null device can simulate a real disk, please let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have an external drive I was planning on using to store complete disc images for several different PCs, each image in its own folder, and I just wanted to be clear on what the image feature (not clone) of CZ LiveCD does and does not do before I start.
If I use device-image, and select local device sda for the source and local device sdb1 for the destination, I expect what I will end up with is that several files will be created on sdb1 (from other posts, at least 6 files) which represent the image data for the entire source disc, including all the partition info necessary to completely and exactly re-create the original image.
I expect that it does not matter what format or partition type sdb1 has originally as long as it is one of the standard supported types, and is big enough. The partition and formatting will not be changed in any way by the device-image program, other than to have the new files written to it.
Is everything I have described above accurate?
Is there any reason to chose clone vs image if my purpose is only to backup?
"The partition and formatting will not be changed in any way by the device-image program, other than to have the new files written to it. "
Yes. in your case, clonezilla will just mount /dev/sdb1 and write files/dirs on that.
Thanks for clarifying. I know these are basic questions, but I don't see them answered on your site.
Also I expect that as long as I keep the related image files together, I can copy or move them to any other mountable media and restore the image directly from there (as long as I use the same or newer version of CZ.
A nice feature to have would be a way to run device-image or device-device without any actual writing taking place, so maybe you could see the disc space needed for the image or clone. Even better, using a virtual drive as a destination so you could see the entire detailed report of the process.
Not trying to create more work for you, but you have created a very useful thing that deserves to get even better ;).
tns1,
Thanks for your ideas. Actually I have no idea how to do "without any actual writing taking place", if you have any more info, please let me know.
As for virtual drive, well, if you can prepare a virtual machine, say virtualbox or vmware, then for Clonezilla, it's not a problem to save an image on virtual machine.
Thanks.
I have had the 'opportunity' to use images I have created with CZ live to restore my messed up HD twice now, and it did exactly what it was supposed to do. Its fast (~20min for a typical factory image) and the images are smaller than expected. Thanks for a great program.
My biggest problem with CZ was that the dialogs & terminology used in the program did not give me 100% certainty that I was making the correct selections and I was not going to destroy the data I was trying to archive. A little more explanation in the selection dialogs or a GUI (or even a simple ascii graphics picture) would go a long way to eliminate that fear:
|-----------------------------| |-----------------------------------------------|
| sda (all partitions) | ----image-----> | sdb/2009-01-01-00-dellfactory-img |
|-----------------------------| |-----------------------------------------------|
Continue [Y]es,[N]o ?
For newbies, go out and buy a $100 external usb HD to experiment with and you will soon get past the learning phase with little risk to your data. Thanks to CZ I can have easy to access backup images of 10 or more PCs all on the same portable media.
tns1,
So you mean we'd better to add something like this:
|-----------------------------| |-----------------------------------------------|
| sda (all partitions) | ----image-----> | sdb/2009-01-01-00-dellfactory-img |
|-----------------------------| |-----------------------------------------------|
Continue [Y]es,[N]o ?
right ?
Thanks.
Steven.
The whole idea is to provide some kind of practice or 'dry run' option, so a user knows exactly what will happen before actually writing to a disk. Gparted provides something like this by providing a picture of the partitioning before it is applied. If the picture looks good, I have some confidence I'll get what I want.
The simplest idea for CZ is just to provide an estimate of disk space needed for the resulting image. Since there are usually multiple partitions, & compression, it isn't obvious how much space is needed. You would probably only need to extract the numbers obtained in the source disk analysis steps, add them up, and show the number. Even better is to show each file name that will be created with the size & total.
A better version of this might perform just the source disk operations used in creating an image: reading, analysis, compression, but skip the writes, or write to a null device instead. This way you can show most or all of the dialogs that would appear during the actual process.
The idea of using a virtual drive (ramdisk) for the destination is probably not good since available ram is much smaller than a typical disk.
Thank you for the ideas.
I think some of them are related to some GUI, we might have a GUI in the future.
As for estimating the image size, well, it's not an easy thing, since it is done runtime, almost impossible to estimate. Please correct me if I am wrong.
As for write to an null device, if you know how a null device can simulate a real disk, please let me know.