Clone Disk Free
Lola Maroun
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
The share is there, I can see it on any system through SMB. There are other drives present as well but none are showing up when clicking on the pulldown for the destination. They are all present when I click on the Source.
As far as I know, this plugin is used to clone the system disk from the GUI. So I think you need to connect an empty disk/SD card/USB pendrive to be able to clone, that's why the GUI is not showing you possible destinations of the cloned disk. Try it by connecting an empty disk.
I have a hard drive I am using and I need to clone it, but I can not turn the computer off to take the HDD out. I want to know how safe it is to clone a disk that is being used at the moment it is being cloned.
It is at least the content of system directories below we should exclude from our backup copy. The content of these directories will be created on boot time but note that the directories will not be created, therefore we have to copy these, but exclude their content Source:Arch Wiki:
This command should further be adapted to meet our personal needs (see [manpage for the rsync command]. Note that we may want to omit the option -x in case we also want to copy a source on multiple filesystems. We then should also exclude .gvfs to avoid copying GFVS mounted contents there.
Of course the master boot sector, partition boot sectors, partition tables, and format of the source drive will not be copied by this. We will have to partition the backup drive before we are able to "clone" the source with rsync. We may also have to install Grub to this drive in case we want to also be able to boot from this drive.
Still many files from the source system may not be really needed in the cloned system (think of old packages, kernels, etc.). Therefore rather than cloning a system we may be better off performing a backup of our source to restore it somewhere else.
I wouldn't recommend cloning whilst it's still in use. The software might refuse to perform the task (e.g. GParted won't move/resize with mounted/in use partions/hard drives). It might be possible since all you are doing is copying the what's on the hard drive (as opposed to moving the data to another hard drive). How are you going to clone it?
Is the software you are using to clone it on the same hard drive or a separate one. If it's separate, then try to unmount the hard drive before cloning. I'd normally suggest booting into a live CD or live USB of a linux OS or partitioning program (e.g. Ubuntu, GParted), but you say that you can't turn off the computer.
The way I see it, cloning is similar to copying files, and (since copying files with the disk in use is safe) it would appear to be safe to clone it. I'm not entirely sure, but that's all I can offer at the moment.
IMO although there are many possible ways to do this,
The easiest is to use Clonezilla.
You can clone the entire disk or individual partitions. There is never a problem cloning to a partition the same size or larger.
You cannot clone a partition you are booted from. One of the live media made at least in part for the purpose of cloning is required, depending on your cloning prowess. The only way to clone a disk booted from is on a multiboot disk, partition by partition, always excluding the partition booted from from the clone process. Thus, you cannot clone your entire boot disk if you are booted from any filesystem on it. If you can boot from anything else that provides dd, you can dd an entire HD to an SSD, if you plan to not ever boot while both are simultaneously connected before restoring the uniqueness of every UUID and filesystem label.
Today, to clone a disk, I fail the array, then rebuild onto another disk. This results in a new disk being inserted into the array, and I have a clone in my hands, but it is the old disk from the array that I take away. To leave the original disk in the array is a messy process of new config, and meticulously adding all the disks back correctly, and putting the old disk back in the old slot. Very messy and prone to user error.
If I were to make a clone, for example to experiment with potentially invasive file recovery, I'd simply use dd. Pro: No need for breaking the array. Con: Not for the faint of hearth, easy to cause a monumental mess.
DD is intended to be used on drives in the same system. You can use it over the wire, but doing dd across the wire is slow... you have to use netcat or ssh (netcat is unencrypted and faster, and you can pipe it through bzip. ssh is secure, but slow.)
I have 2 servers where the backup server is a disk for disk match to my main server. My main server is XFS now, but the backup server is still RFS. It is time to convert the backup server to XFS by cloning the disks in the main server and installing them in the backup server.
And then pulled them from the main server and installed them in the backup server with the array stopped. Again I used the same code to write to the existing 3 disks in the array. The intent was to end up with 3 newly XFS disks in the backup server. The problem was that once the RFS disks were overwritten with XFS, and I tried to start the array, it wouldn't start. Claimed that the disks were unmountable. (unRaid 6.1.9)
I then did a reboot and they were still unmountable. I finally did a new config and this allowed me to add them back in and they showed up as expected, converted to XFS. I will now create a fresh parity.
I didn't mean the default filesystem for new disks, if you click any disk with the array stopped you can select the filesystem fir that disk, default is auto, if they were set to Reiser the XFS disks wouldn't mount.
After converting a number of disks, from RFS to XFS via dd, I have this situation. After dd was finished, the disk was pulled and moved to another server and hot plugged and mounted via unassigned devices. The other times I have rebooted after doing an RFS->XFS conversion via DD, but since this is a different server, and was running processes that I didn't want to interrupt, I did it this way.
I suppose a reboot is in order, but I have never had to do that before. Moving the disk back to the original server where it was converted via dd and it hot-plugs and mounts via unassigned devices as a new XFS disk without issue. However on the original server it seems to conflict with disk4 (disk4 was the source copy of the dd command so this makes sense), and disk4 shows unmountable if this disk is mounted via unassigned devices. Unmounting this disk allows the array to start and disk4 is good, but now this disk won't mount.
The fact that a clone disk has the same UUID and can't be mounted together with the source is expected, same happens with a unRAID rebuild, can't see how you would get the same UUID on a different server, coincidence or you cloned the same disk twice?
From the OP's earlier posts it appears that he's got two servers, the contents of the disks being the same but the main one having XFS-formatted disks and the backup one having ReiserFS-formatted disks. He's cloning the disks from the main server one at a time and inserting the clones into the backup server in place of the equivalent ReiserFS disk. It isn't the way I'd go about converting from ReiserFS to XFS or how I'd maintain a backup server, but as an experiment it's interesting to watch. I wouldn't attempt the hot-plugging either.
c80f0f1006