6

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.

What problems could I have the cloned copy?

What problems could I have with the original disk?

What alternatives can I use (if available) to clone a working (in use) disk?

2
  • 1
    It is the disk on which system files reside? I mean /, /usr, /var and so on.
    – enzotib
    Jul 14, 2013 at 6:28
  • 1
    Without really knowing the type of disk and the mount points relevant to the system I would say this is not really a proper question. I would clone a storage point or find a way or making a snapshot of it, but would not try the same feature under a system mounted location under the risk of that being completely useless: why would anyone make clones if they are not to work or contain corrupt data? :P Jul 14, 2013 at 6:33

3 Answers 3

6

As it is safe to bitwise clone an unmounted hard drive using dd we should not do so from a mounted drive which is in use. This is especially true for the mounted system drive.

It is not recommended to clone the system drive of a running system because we inevitably will have data inconsistencies from cloning files where the system will currently write to.

Nevertheless it is possibly to almost clone a running system after we had excluded our used system files from being copied.

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:

/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found

We may also want exclude the trash, or other directories from /home/ to speed up the backup process.

Such an exclusion can nicely be done with rsync Install rsync resulting in a command similar to this:

sudo rsync -avxAX /* /backup/directory --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found}

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.

1
  • I feel OP should accept this as the best answer. I'll be using it for my WIP cloning project: askubuntu.com/questions/1028604/… I think I'll be cloning Ubuntu 16.04 many many times and upgrading it to 18.04 to work out bugs. I do not wish to be bothered with Live USB booting and cloning. Apr 28, 2018 at 16:49
3

From what I understand, you are trying to clone a hard drive that is currently in use.

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.

I don't see any problems with the process, but I'm not experienced with 'cloning' and I'm not entirely sure of how safe it is.

0

There would be a difference if you do as user :

dd if=/dev/sdb of=/dev/sda

or if you do :

sudo dd if=/dev/sdb of=/dev/sda

resp log in as su and then do :

dd if=/dev/sdb of=/dev/sda

This would have effect to the permission attributes of some files.

7
  • 3
    dding a mounted disk is not really a good idea, no matter how many syncs you do, corruption might occur... Jul 14, 2013 at 7:16
  • @BrunoPereira thx - good to know. Jul 14, 2013 at 7:23
  • To add why: a mounted filesystem will be changed all over the place, while the dd runs over the filesystem on block level from beginning to end. The result will be an inconsitent copy, i.e. some parts at the beginning will not include changes you have on the end. A filesystem is not meant to mitigate this and will likely result in corruption.
    – gertvdijk
    Jul 14, 2013 at 11:45
  • @gertvdijk rsync is then more safe for to preserve the datas resp. copied datas ? There is difference too, if I do rsync as sudo and as user without sudo ? Jul 14, 2013 at 13:16
  • @dschinn1001 rsync copies on file level, not block level. You will still get inconsistencies across the whole system you copy as rsync does not make a "snapshot" of the whole state before copying. Always make sure no other processes can write to the files you're rsyncing.
    – gertvdijk
    Jul 14, 2013 at 13:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .