Disk Clone
Vilma Steiert
I have read through the support forum and also read Headless backup. The Headless backup seems dated as it was done in 2015 and consists of 22 steps and ends up with the image on a data drive. You then have a number of additional steps to burn that image to an external SSD.
I run OMV5 from a 32GB SSD and have recently purchased 2 identical SSDs. I would like to clone the system SSD to each of the backup SSDs. Having read the Clonezilla Live Doc for this disk-to-disk process (consists of 11 steps) I am unable to see how to do it in OMV using the built in version of Clonezilla?
macom Thanks for the list. However your 8 steps only gets to the first step of Clonezilla - then need to complete the next 8 to actually get a backup.
I had already done your steps, at least up to 7, and after getting Clonezilla Live started I ran into the problem of not finding my backup drive listed in the available options.
So now that I have at least one good backup of the OS drive I will follow your steps to see if I can also do the same from Clonezilla Live. More to follow...
So....I connected the computer to a monitor and a keyboard and everything is still the same, it goes directly to clonezilla and doesn't show me the grub menu. Do I have to press any specific key for the menu to appear? Sorry but this is the first time something like this has happened to me.
PS: sorted out. I created a bootable USB with Super Grub2 Disk and selected the grub corresponding to the OMV. Then I entered the OMV page and set the OMV kernel to default, which strangely was already selected but didn't work. I've done this so many times and it's never happened to me, but there's always a first time.
Yep
Take care about the UUID (fstab and Grub part) if you are using partition and done a simple dd.
Have a look there :
[How-To] Restore OMV system backup made with openmediavault-backup plugin
Hello, we already use clonezillas option to clone a local disk and save the image in a remote repository using SSH but if we need to clone a remote disk and save the image in a remote repository? Is it possible? I was imagining if we could boot Clonezilla live in a ComputerA and ask it to clone some disk/partition of ComputerB and save the image in ComputerC. Is not mandatory this scenario of 3 computers because in the end, what we really want is to clone a remote disk. Could also be something like boot Cloneziila live in ComputerA and ask it to clone some disk/partition of ComputerB and also save the imagem in another area of ComputerB or even ComputerA. Thanks to all who made and help keep alive Clonezilla!
I'm trying the exact same thing. Is it possible to have Clonezilla on computer A then PXE boot computer B grab its image and save that image in a network share on computer C. I've gone through the link and I don't see the disk to remote option. "In this step:
-live/doc/03_Disk_to_disk_clone/images/ocs-06-disk-to-local-disk-clone.png
Choose "disk_to_remote_disk" then follow the wizard." The option does not show up. I'm running clonezilla live 2.7.2-39-amd64
Update. I have been able to capture a remote image from computer B. I used DRBL Live and within it used Clonezilla server on Computer A. I used the save-disk option then booted computer B and saved the image to an external USB hard-drive. Now I just need to figure out how to mount computer C drive to allow Computer B's image to be saved on it. If anyone else needs to remote save an image here is a link of the video I found that helped. =jURy0_x026M
Not to pile on but If I figure how to mount to a network share/computer C how would it work if I turned on let say 10 computer. would all the images be the same name or is there a way to save it by MAC address/IP Address?
Thanks Steven I checked out the links some I understand others I don't. When I use the Clonezilla Live USB 2.7.2 I have no problem mounting the share. What I would like to have happen is to be able to run the same mount command in DRBL live terminal and connect to the share but it does not seem to work. Here is what I get in Clonezilla Live
LC_ALL=C mount -t cifs "//192.168.2.37/Users/Skipper/images" /home/partimag -o user="Skipper"
That wouldn't work for me in terminal on DRBL Live even when I put sudo in front of mount.
It works fine in Clonezilla Live but only in DRBL Live was I able to actually connect to another computer and then save the image to a drive. If I can do that in Clonezilla great but I never saw the "disk_to_remote_disk" option. All of the Clonezilla seem to need to boot to clonezilla then run. With DRBL Live I was able to PXE boot right into a session and have it send the image.
The option "disk_to_remote_disk" is for you to "clone" disk to the disk on the different machine via network. What you want to do now is "save" an image on another machine, not "clone".
I suggest you just boot Clonezilla live on the machine you want to take the image then mount the CIFS server as image repository, i.e., follow this:
-live-doc-content.php?topic=clonezilla-live/doc/01_Save_disk_image
Ok understood. Yes I cannot boot from the machine we have special requirements on the time in which we have to back up racks of computers at each site. The plan was that a remote back up to a NAS would be the quickest. That's why I tried DRBL Live because I could potentially save a batch of computers to a NAS per session.
Thanks Steven, I tried using lite server which seemed to work but I guess I'm stuck. I can mount to the server share and log in. Then I boot the source computer from PXE but it just comes up into the Clonezilla menu. I thought it would boot then capture the image and send it to the previously mounted home/partimag
I've done some research, from what I read I thought it was a file which needed editing now that I see a video I realize it something that needs to be completely created with the parameters that I need. I'm still going to need help from co-workers who are more familiar but I think I know have an idea of what this entails.
There's been a number of questions regarding disk cloning tools and dd has been suggested at least once. I've already considered using dd myself, mainly because ease of use, and that it's readily available on pretty much all bootable Linux distributions.
What is the best way to use dd for cloning a disk? I did a quick Google search, and the first result was an apparent failed attempt. Is there anything I need to do after using dd, i.e. is there anything that CAN'T be read using dd?
Be aware that while cloning every byte, you should not use this on a drive or partition that is being used. Especially applications like databases can't cope with this very well and you might end up with corrupted data.
CAUTION: dd'ing a live filesystem can corrupt files. The reason is simple, it has no understanding of the filesystem activity that may be going on, and makes no attempt to mitigate it. If a write is partially underway, you will get a partial write. This is usually not good for things, and generally fatal for databases. Moreover, if you screw up the typo-prone if and of parameters, woe unto you. In most cases, rsync is an equally effective tool written after the advent of multitasking, and will provide consistent views of individual files.
However, DD should accurately capture the bit state of an unmounted drive. Bootloaders, llvm volumes, partition UUIDs and labels, etc. Just make sure that you have a drive capable of mirroring the target drive bit for bit.
When using dd to clone a disk which may contain bad sectors, use conv=noerror,sync to ensure that it doesn't stop when it encounters an error, and fills in the missing sector(s) with null bytes. This is usually the first step I take if trying to recover from a failed or failing disk - get a copy before doing any recovery attempts, and then do recovery on the good (cloned) disk. I leave it to the recovery tool to cope with any blank sectors that couldn't be copied.
Also, you may find dd's speed can be affected by the bs (block size) setting. I usually try bs=32768, but you might like to test it on your own systems to see what works the fastest for you. (This assumes that you don't need to use a specific block size for another reason, e.g. if you're writing to a tape.)
Of course, make sure that you have proper permissions to read directly from /dev/hdb (I'd recommend running as root), and that /dev/hdb isn't mounted (you don't want to copy while the disk is being changed - mounting as read-only is also acceptable). Once complete, image.img will be a byte-for-byte clone of the entire disk.
There are a few drawbacks to using dd to clone disks. First, dd will copy your entire disk, even empty space, and if done on a large disk can result in an extremely large image file. Second, dd provides absolutely no progress indications, which can be frustrating because the copy takes a long time. Third, if you copy this image to other drives (again, using dd), they must be as large or larger than the original disk, yet you won't be able to use any additional space you may have on the target disk until you resize your partitions.
As far as issues or gotchas go, dd, for the most part, does an excellent job. However, a while ago I had a hard drive that was about to die, so I used dd to try and copy what information I could off it before it died completely. It was then learned that dd doesn't handle read errors very well - there were several sectors on the disk that dd couldn't read, causing dd to give up and stop the copy. At the time I couldn't find a way to tell dd to continue despite encountering a read error (though it appears as though it does have that setting), so I spent quite a bit of time manually specifying skip and seek to hop over the unreadable sections.
d3342ee215