[PLUG] Moving /home directory

Dwight Hubbard dwight at dwightandamy.com
Sat May 14 06:56:58 UTC 2005


On May 13, 2005, at 9:56 PM, Elliott Mitchell wrote:
>
> I'm aware of the capabilites of cp, I still stand by my point *DO*NOT*
> use cp for moving significant slices of filesystems around! Most Unix
> flavors -pR is sufficient, GNU is the only one that needs an  
> additional
> option for maximal preservation.
>
> Of note I said "links", not "symbolic links". cp *will*not* handle  
> hard
> links correctly. GNU tar will only _probably_ handle them  
> correctly. For
> illustrative purposes, a portion of my home directory on PSU's CS
> systems:
>
> $ ls -lin
> total 1972
>     307209 -rw-r--r--   4 1831     300      1099511627775 Aug  4   
> 2004 -f
>     307209 -rw-r--r--   4 1831     300      1099511627775 Aug  4   
> 2004 -fr
>     307209 -rw-r--r--   4 1831     300      1099511627775 Aug  4   
> 2004 -r
>     307209 -rw-r--r--   4 1831     300      1099511627775 Aug  4   
> 2004 -rf
> <...>
>
> $ du -sk *
> 32      -f
> 32      -fr
> 32      -r
> 32      -rf
> <...>
>

Under GNU cp, hard links are copied too:
dhubbard at linux:/tmp/testdir> dd if=/dev/random of=testfile bs=1k count=2
0+2 records in
0+2 records out
dhubbard at linux:/tmp/testdir> ln testfile testfile2
dhubbard at linux:/tmp/testdir> ls -i
91573 testfile  91573 testfile2
dhubbard at linux:/tmp/testdir> mkdir testdir2
dhubbard at linux:/tmp/testdir> cp -a testfile* testdir2
dhubbard at linux:/tmp/testdir> cd testdir2
dhubbard at linux:/tmp/testdir/testdir2> ls -i
91579 testfile  91579 testfile2

And on modern distributions it also copies ACLs

dhubbard at linux:/tmp/testdir> setfacl -m u:dhubbard:r testfile
dhubbard at linux:/tmp/testdir> getfacl testfile
# file: testfile
# owner: dhubbard
# group: users
user::rw-
user:dhubbard:r--
group::r--
mask::r--
other::r--

dhubbard at linux:/tmp/testdir> cp -a testfile* testdir2
dhubbard at linux:/tmp/testdir> cd testdir2
dhubbard at linux:/tmp/testdir/testdir2> ls -la
total 8
drwxr-xr-x  2 dhubbard users 104 2005-05-14 01:01 .
drwxr-xr-x  3 dhubbard users 128 2005-05-14 00:46 ..
-rw-r--r--+ 2 dhubbard users 170 2005-05-14 00:46 testfile
-rw-r--r--+ 2 dhubbard users 170 2005-05-14 00:46 testfile2
dhubbard at linux:/tmp/testdir/testdir2> getfacl testfile
# file: testfile
# owner: dhubbard
# group: users
user::rw-
user:dhubbard:r--
group::r--
mask::r--
other::r--

It also works between filesystems types, like say between reiserfs  
and ext3, dump/restore don't.

> There are plenty of other strange things people can and *will* do  
> on home
> directories. cp won't correctly replicate this. GNU tar will likely
> successfully replicate something roughly equivalent this, after  
> burning
> processor time for *hours*, and the result may not fit on a single  
> modern
> disk. By contrast, dump/restore *will* replicate this perfectly in  
> less
> than a second, and the result will be less than a megabyte.

Yes tar is one of the least efficient ways of moving data I have used.

> Disk moves are best accomplished by tools designed for that. dump/ 
> restore
> beat everything else, because they'll replicate everything (in  
> addition
> to the above, they'll also handle ACLs, flags and other interesting FS
> features, such as lsattr/chattr on ext2). tar will get the most  
> crucial
> bits of structure, but it is a very poor second compared to dump/ 
> restore.
> cp isn't even close to vaguely adequate for this purpose.

That is a good point, cp certainly doesn't copy the filesystem  
attributes and probably never will.   I'll have to play with these a  
bit :-)

> Just in case anyone is curious, I'm pretty sure home directories at  
> PSU's
> CS department are backed up with dump.  :-)
>
>
>> I personally think rsync is the best option, since it preserves
>> links, modes, permissions and time stamps and it makes it possible to
>> stop and resume later.
>>
>> mkdir /newhome
>> rsync -av /home/ /newhome
>>
>
> rsync can handle hard links and sparse files, but it won't do so with
> anywhere near the efficiency of dump though. Not to mention you still
> lose filesystem features as with tar.

The only thing rsync doesn't handle are the file attributes, current  
versions of rsync support softlinks, hardlinks, sparse files, and  
acls just like gnu cp.

Rsync is really useful when the user home directory is very large and  
you want to keep the downtime to a minimum, because you can rsync it  
once to get the bulk of the data over to the new location.  Then when  
you are ready to do the switch, run the rsync again.  That second  
rsync is a hell of a lot faster than a dump unless there are a huge  
amount of changes.

Of course the main reason I don't use dump/restore is because they  
don't exist for reiserfs which I'm running on my Linux boxes.
>
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>




More information about the PLUG mailing list