Copy entire file system hierarchy from one drive to another

Question

I would like to copy the entire file system hierarchy from one drive to another..i.e contents of each directory as well as regular files in Linux platform. Would be gratefull to know the best way to do that with possibly Linuxes in-built functions. The file system is a ext family.

Answer 1

What you want is rsync.

This command can be used to synchronize a folder, and also resume copying when it's aborted half way. The command to copy one disk is:

rsync -avxHAX --progress / /new-disk/

The options are:

-a  : all files, with permissions, etc..
-v  : verbose, mention files
-x  : stay on one file system
-H  : preserve hard links (not included with -a)
-A  : preserve ACLs/permissions (not included with -a)
-X  : preserve extended attributes (not included with -a)

To improve the copy speed, add -W (--whole-file), to avoid calculating deltas/diffs of the files. This is the default when both the source and destination are specified as local paths, since the real benefit of rsync's delta-transfer algorithm is reducing network usage.

Also consider adding --numeric-ids to avoid mapping uid/gid values by user/group name.

Answer 2

Michael Aaron Safyan's answer doesn't account for sparse files. -S option fixes that.

Also this variant doesn't spam with the each file progressing and doesn't do delta syncing which kills performance in non-network cases.

Perfect for copying filesystem from one local drive to another local drive.

rsync -axHAWXS --numeric-ids --info=progress2

Answer 3

I often use

> cp -ax / /mnt

Presuming /mnt is the new disk mounted on /mnt and there are no other mounts on /.

the -x keeps it on the one filesystem.

This of course needs to be done as root or using sudo.

This link has some alternatives, including the one above

http://linuxdocs.org/HOWTOs/mini/Hard-Disk-Upgrade/copy.html

Answer 4

Like Michael Safyan suggests above, I've used rsync for this purpose. I suggest using some additional options to exclude directories that you probably don't want to copy.

This version is fairly specific to Gnome- and Debian/Ubuntu-based systems, since it includes subdirectories of users' home directories which are specific to Gnome, as well as the APT package cache.

The last line will exclude any directory named cache/Cache/.cache, which may be too aggressive for some uses:

rsync -WavxHAX --delete-excluded --progress \
  /mnt/from/ /mnt/to/
  --exclude='/home/*/.gvfs' \
  --exclude='/home/*/.local/share/Trash' \
  --exclude='/var/run/*' \
  --exclude='/var/lock/*' \
  --exclude='/lib/modules/*/volatile/.mounted' \
  --exclude='/var/cache/apt/archives/*' \
  --exclude='/home/*/.mozilla/firefox/*/Cache' \
  --exclude='/home/*/.cache/chromium'
  --exclude='home/*/.thumbnails' \
  --exclude=.cache --exclude Cache --exclude cache

Answer 5

As mentioned in the comments by juniorRubyist, the preferred approach here should be to use dd. The main reason is performance, it's a block-by-block copy instead of file-by-file.

Cloning a partition

# dd if=/dev/sda1 of=/dev/sdb1 bs=64K conv=noerror,sync status=progress

Cloning an entire disk

# dd if=/dev/sdX of=/dev/sdY bs=64K conv=noerror,sync status=progress

Clone a mounted writable partition

The key for cloning a partition that is mounted read-writable is to remount it as read-only. Then do the cloning and finally remount it again to read-writable.

# mount -o remount,ro /path/to/mount_point
# dd if=/dev/sda1 of=/dev/sdb1 bs=64K conv=noerror,sync status=progress
# mount -o remount,rw /path/to/mount_point

Note. Doing this may have some side-effects on running applications. E.g. if your system have applications that requires writing to this particular partition exactly when you need to clone it, these applications would need to be stopped while partition is cloned. Or if its your own application re-write it to handle this scenario.

Clone a disk with one or more mounted writable partitions

The strategy and side-effects are the same as for Clone a mounted writable partition except this time the remount commands are repeated for each writable mount point.

# mount -o remount,ro /path/to/writeable_mount_point1
# mount -o remount,ro /path/to/writeable_mount_point..
# mount -o remount,ro /path/to/writeable_mount_pointN
# dd if=/dev/sdX of=/dev/sdY bs=64K conv=noerror,sync status=progress
# mount -o remount,rw /path/to/writeable_mount_point1
# mount -o remount,rw /path/to/writeable_mount_point..
# mount -o remount,rw /path/to/writeable_mount_pointN

Final notes

The preferred and recommended way of doing disk/partition cloning is to do so on a non-mounted system since that will not have any non-deterministic side effects. The same goes for systems built on the concept of read-only mounts.

References

1. https://wiki.archlinux.org/index.php/disk_cloning

Answer 6

For a one shot local copy from one drive to another, I guess cp suffices as described by Wolfmann here above.

For bigger works like local or remote backups for instance, the best is rsync.

Of course, rsync is significantly more complex to use.

Why rsync :

• this allows you to copy (synchronized copy) all or part of your drive A to drive B, with many options, like excluding some directories from the copy (for instance excluding /proc).

• Another big advantage is that this native tool monitors the file transfer: eg for massive transfers, if the connection is interrupted, it will continue from the breakpoint.

• And last but not least, rsync uses ssh connection, so this allow you to achive remote synchronized secured "copies". Have a look to the man page as well as here for some examples.

Answer 7

rsync

"This approach is considered to be better than disk cloning with dd since it allows for a different size, partition table and filesystem to be used, and better than copying with cp -a as well, because it allows greater control over file permissions, attributes, Access Control Lists (ACLs) and extended attributes."

From:

https://wiki.archlinux.org/index.php/Full_system_backup_with_rsync

Man Page Here

Answer 8

I tried the rsync commands proposed here but eventually I got much cleaner and faster results with partclone. Unmount source and target partitions and then run the following:

partclone.ext4 -b -s /dev/sd(source) -o /dev/sd(target)
e2fsck -f /dev/sd(target)
resize2fs /dev/sd(target)

This performs the following steps:

1. Clone (only the used parts of) the partition
2. make sure the file system is o.k. (resize2fs enforces this step)
3. resize the partition to the new file system

The above works in case the target partition is the same size or larger than the source. If your target is smaller than the source (but fits all data) then do the following:

e2fsck -f /dev/sd(source)
resize2fs -M /dev/sd(source)
partclone.ext4 -b -s /dev/sd(source) -o /dev/sd(target)
resize2fs /dev/sd(target)

resize2fs -M shrinks the filesystem to the minimum size before cloning the data.

Note that partclone is not installed by default on most systems. Use a live distro like clonezilla or install partclone from your distros packet manager (apt-get install partclone on debian-based sytsems).

Edit: thanks @jbroome for pointing out an error in the second code block

Answer 9

Adding two useful bits to the thread re rsync: changing cypher, and using --update:

As per Wolfman's post, cp -ax is elegant, and cool for local stuff.

However, rsync is awesome also. Further to Michael's answer re -W, changing the cypher can also speed things up (read up on any security implications though).

rsync --progress --rsh="ssh -c blowfish" / /mnt/dest -auvx

There is some discussion (and benchmarks) around the place about a slow CPU being the actual bottleneck, but it does seem to help me when machine is loaded up doing other concurrent things.

One of the other big reasons for using rsync in a large, recursive copy like this is because of the -u switch (or --update). If there is a problem during the copy, you can fix it up, and rsync will pick up where it left off (I don't think scp has this). Doing it locally, cp also has a -u switch.

(I'm not certain what the implications of --update and --whole-file together are, but they always seem to work sensibly for me in this type of task)

I realise this isn't a thread about rsync's features, but some of the most common I use for this are:

• --delete-after etc (as Michael mentioned in follow-up), if you want to sync the new system back to the original place or something like that. And,
• --exclude - for skipping directories/files, for instances like copying/creating a new system to a new place whilst skipping user home directories etc (either you are mounting homes from somewhere else, or creating new users etc).

Incidentally, if I ever have to use windows, I use rsync from cygwin to do large recursive copies, because of explorer's slightly brain-dead wanting to start from the beginning (although I find Finder is OS X even worse)

Answer 10

'dd' is awesome, but ddrescue (apt install gddrescue) is even better. If dd gets interrupted, there is no way to restart (another good reason to use rsync). When you use ddrescue with a logfile, it keeps track of which blocks have been copied.

When backing up a dual boot Windows/Linux system, I use ntfsclone for the Windows partitions and ddrescue for the Linux partition and dd for the MBR. (I haven't tried to back up a dual boot system using GPT/UEFI.)

What I'd love to see is a ddrescue tool that can create files like ntfsclone where unallocated space is marked with control characters. This makes the image not directly mountable, but allows it to be only as big as the contained data.

Someone please come up with the ntfsclone "special image format" for ddrescue...

Answer 11

Before you start copying large amounts of data, you may wish to remount your new drive with some more efficient parameters.

For example, I just remounted my new SSD like this so that the rsync copying my /home to the new drive would go faster:

mount -oremount,defaults,noiversion,auto_da_alloc,noatime,errors=remount-ro,inode_readahead_blks=32,discard /dev/sdc1 /run/media/turgut/ssd1t/

Note that this prevents the update of access times, so if you need to re-run the rsync, it might attempt to copy ALL files again. To prevent that, add --ignore-times and --checksum options to your rsync line, so that it only copies the files that have been changed since your first attempt.

Answer 12

rsync is the perfect solution as explained above.

I'd just add -S to "handle sparse files efficiently" in case there is a docker devicemapper volume or similar to be copied.