Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Reading one of the editions of the Nemeth's book (Nemeth et al), have read about volcopy -- an utility that copies a filesystem from one device to another, making "a literal copy" (here's a man page, though not too helpful).

The Book said the utility exists for Linux, but quick googlin' didn't show many results. So the question is -- is it used on Linux, and if not, what is the default alternative to mirror-copy a filesystem ? dump and restore ?

Edit. I was thinking that such an utility could be useful in the case of e.g. hard disk replacement -- currently I am using dd to replicate the root partition etc, this is fast but obviously preserves the size of the partition. So I thought volcopy could be a quick alternative that allows to copy to a bigger partition. dump | restore allow to to that, if I am not mistaken. Sorry for being too unspecific initially.

share|improve this question
add comment

5 Answers

up vote 3 down vote accepted

What you're looking for is a way to clone a filesystem, a disk or partition. See in particular

Cloning the whole disk or partition with cat or cp is the simplest method. There's no reason to use dd, especially since dd is slower. It requires that the filesystem not be mounted, and it also copies the empty space, so it can be slow for that reason.

On Linux (or more precisely with GNU coreutils), cp -a does a good job of copying files and preserving metadata, but it's not perfect. Also, not that copying files can be slower even if the disk is not full, because it is a lot faster to copy disks large swathes at a time than to shuffle back and forth copying each fragment of a file.

If your disks or partitions are on a RAID-1 (mirroring RAID) volume and you want to copy them to a new disk, you can add the new disk to the array. This is pretty fast, less error-prone than using cat on the block devices, and can be done online with everything mounted. The only reason not to do this is when your source partition is not on a RAID-1 volume; you can turn a plain old partition into a Linux software RAID-1 volume, but it takes a bit of low-level work.

If the filesystem you want to copy is on an LVM volume, you can use LVM's mirroring feature.

share|improve this answer
    
Thanks a lot! "Cloning" was indeed the term (and the tag) I was looking for; from the references above, I especially liked the first one (funny enough, it seems to be the first question on 'unix' as well), the third one (the question itself!) and your answer to the fourth one. As for dd, I have also had some weird experience with its speeds, despite the obvious fact that the direct access to the partition should in general probably be faster. I'll add my 2 cents in a separate post. –  ジョージ Dec 1 '11 at 15:03
add comment

I would resort to using rsync tool to setup a mirror-copy sync of a filesystem. It is best since in making differential copies faster once the initial sync is done, leading to less copy changes over the destination filesystem instead of whole copy irrespective of the quantity of changes.

share|improve this answer
    
A great instrument indeed. I am currently more focused on making the initial copy (e.g. for hd replacement; I used to use dd for that purpose, but this obviously needs a partition of the same size). –  ジョージ Nov 30 '11 at 9:37
    
Check out rdiff_backup. –  Sardathrion Nov 30 '11 at 17:22
add comment

You can use dd to copy the data from one device to another.

dd if=/my/source/device of=/my/dest/device bs=4096

dd will do a byte-per-byte copy of the source, of course you will not be able to do this on a running filesystem, this will most likely cause corrupt data. If you are using a fileystem or some other utility like LVM with snapshot ability you can create a snapshot and copy it instead.

lvcreate -L1G -s -n my-snapshot-of-lvname /dev/vgname/lvname
dd if=/dev/vgname/my-snapshot-of-lvname of=/my/dest/path bs=4096
lvremove /dev/vgname/my-snapshot-of-lvname

LVM also has some built in tools for volume management.

Linux has the filesystem btrfs, it's a new still unstable filesystem (inspired by ZFS from Solaris). Btrfs is NOT ready for production but it will most likely be able to do everything you need.

Of course, you may also use rsync (i recommend the a-flag), but that is not a volume copy, but in most cases it will work just fine.

rsync -a /source /path
share|improve this answer
    
You can use dd, but you don't have to. cat is faster. –  Gilles Nov 30 '11 at 23:53
add comment

dd is one of the oldest unix utilities, and does exactly that: duplicate a disk. Usually you do not want an exact duplicate though, because there is no reason to waste time and space copying the unused portions of the disk.

While dump does operate on the unmounted block device, restore does not, and together they do not reproduce an exact copy of the filesystem. Instead they just backup and restore the files in the filesystem, much like tar, only faster.

If you are looking to create a smart disk image that can be restored exactly as it was, you want something like Clonezilla or Ghost4Linux, which are smart enough to skip copying the unused disk blocks. They still can not restore to a disk that is smaller than the original though, nor can you selectively restore individual files, nor do incremental backups. For these reasons, I prefer traditional backup utilities like dump or tar.

share|improve this answer
    
dd doesn't duplicate a disk. It's the device file that does that. There isn't much use for dd as a system tool. cat is faster. –  Gilles Nov 30 '11 at 23:54
    
I wish I could accept this answer as well. dump should be faster than tar, the question is -- do they have comparable speeds (and accuracy) not to bother with dump -- or not? dump well handles sparse files by default; GNU tar has the --sparse option; both handle the hard links and symlinks properly ... I assume the same for permissions and modification times, as it is easier to implement; but I still may be missing something, so to clone a filesystem I'd go with dump by default. –  ジョージ Dec 1 '11 at 15:27
    
@Gilles, a device file doesn't DO anything; it is just a file that you can read/write to the disk with. Originally cat could not read block devices, so you had to use dd. These days you can use either, but dd has options that make it much more flexible and depending on which options you use, can be faster than cat. –  psusi Dec 2 '11 at 2:32
    
@ジョージ, I'm not sure what you mean. They both will provide an accurate backup, but dump can be significantly faster. –  psusi Dec 2 '11 at 2:37
    
@psusi Yes, the device file itself doesn't do anything, it's the driver in the kernel that does the work, but you're quibbling on wording here. My point is that dd does not do anything special, it calls read(2) like everybody else. See my link for a benchmark of dd against cat; in this benchmark, dd lost. There is only one specific device type where dd is called for: tape drives, because they have a fixed block size. But you don't have to use dd even on tapes if you have some other means of controlling the size argument to read. –  Gilles Dec 2 '11 at 10:45
show 1 more comment

Partimage makes exact copies of a partition having a supported filesystem, to the extent that it will copy the filesystem uuid as well. So you may need to change one of the uuids, if it confuses your OS or bootloader. Notable limitation - currently it does not support ext4 or btrfs.

It is also free software, reliable, simple to use, well documented and works on the console so it is easy to use remotely. Basically, it will save the contents of the partition to a file, and then write it back wherever you want.

PS. The partimage page also mentions FSArchiver, but I have never used that.

share|improve this answer
    
Thank you, especially for the note on uuids. They are really evil ) –  ジョージ Dec 1 '11 at 15:29
    
Last I saw, partimage would only restore to a partition of exactly the same size as the original. So make sure your new partition is the same size and adjust it, if necessary, after the restore. I didn't know about the uuid issue. –  Joe Dec 9 '11 at 16:34
    
@user23861: I don't think that is true. It isn't easy to get a partition of exactly the same size, and if this were the case it would make partimage rather less useful. While not an expert on the subject, I think all partimage does it write a filesystem of a specific size to disk. As long as the partition is big enough to contain it, there is no problem, and usually one would just expand the filesystem afterwards to fill the entire partition. –  Faheem Mitha Dec 9 '11 at 18:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.