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.
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
while this is dead old answer it is still worth noting that you usually do NOT want to copy all the stuff present in
/, excluding i.e.
/procetc. Therefore before issuing that
cpI suggest searching for better approaches (also using rsync) Jun 13, 2019 at 8:17
11@MarcinOrlowski WolfJM's use of the
-xflag means that the synthetic filesystems you mention will not be copied.– Jim L.Jul 31, 2019 at 21:37
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
--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.
1Genius, thank you. Btw, I ended up using
rsync -avxHAWX --numeric-ids --progress / mnt/but I should have done
rsync -avxHAWX --numeric-ids --progress / mnt/ > ~/rsync.out. I suspect pouring the output to the terminal slowed the process. :D– Krista KJan 15, 2014 at 10:15
--progressis useful for large transfers, as it gives overall progress, instead of (millions of lines for) individual files.– FlorianSep 27, 2015 at 8:43
4I had to replace
E, because extended attributes and ACLs are covered by
Eon my mac. Tested:
rsync version 2.6.9 protocol version 29Aug 4, 2016 at 5:17
-S, --sparse handle sparse files efficientlyMar 11, 2017 at 12:55
8If you're copying from some other folder than
/, note that having a trailing slash (or not) on the source directory makes a difference:
rsync source/ dest/copies everything inside
rsync source dest/copies the folder
sourceand everything inside into
dest/. Mar 20, 2017 at 8:22
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
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
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
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.
ddis a very bad idea for 2 reasons: firstly performing a block-level copy of a filesystem that is mounted (which is the case for
/) will more than likely result in target filesystem errors, and secondly
ddwon't copy data from sources mounted within the filesystem like
/home. Your link is valid for disk cloning, not "file hierarchy" cloning– EricAug 16, 2019 at 10:42
@Eric I may have made a few assumptions here. Firstly I assumed "copy the entire file system hierarchy from one drive to another." to be the equivalence of "how do I clone my disk", since "file hierarchy cloning" only becomes useful when cloning a subset of the disk. Secondly I assumed this was a disk used for storage not for the system you are currently running. However, simply mounting the system does not imply filesystem errors. It depends on how its mounted, read-only mounts are perfectly fine to clone. Dec 16, 2020 at 13:42
whatever float your boat– EricDec 17, 2020 at 14:22
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.
"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."
Man Page Here
Adding two useful bits to the thread re rsync: changing cypher, and using
As per Wolfman's post,
cp -ax is elegant, and cool for local stuff.
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)
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:
- Clone (only the used parts of) the partition
- make sure the file system is o.k. (resize2fs enforces this step)
- 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(target) resize2fs -M /dev/sd(target) 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.
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).
'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...
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.
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.
dd if=/dev/sda1 of=/dev/sdb1 bs=4096
ddfor 2 reasons: firstly it's a bad idea to perform a block-level copy of a filesystem that is mounted (which is the case for
/) and secondly
ddwon't copy data from sources mounted within the filesystem like