Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] rsync v. cp in data migration



Thanks for the good advice.  I've tweaked my rsync command (below).

A couple questions come up:

Rich: you said change the rsync command if NTFS filesystems were involved,
but I don't see any reference in the rsync man page to NTFS execution
differences or gotchas. [1]  I'm guessing that you took out the -a because
you can't copy block devices from Linux to NTFS or something to that
effect.  It doesn't apply to my case, but I'm curious.

Also, you said use "the file system's preferred backup and restore tools"
so I'll bite:  What are those?  I'm using Ext4 and NFS in my case.  By
backup/restore, do you mean "use tar".  Or do you have a recommendation
like rbackup?

In my case, we're talking about user's home dirs which are full of svn
working copies, so there are TONS of file duplicates across the volume.  Is
there a good tool that would apply in this case?  ie. a backup tool that
de-dupes?

Ned: rsync is definitely more advanced.  for example (from rsync(1))
  If  the  sending  side  detects any I/O errors, then the deletion of any
files at the destination will be automatically disabled. This is to prevent
temporary filesystem failures (such as NFS errors) on the sending side
causing a massive deletion of files on the destination.  You can override
this with the --ignore-errors option.

I was looking at the source of cp (thanks Tom) and there are more than one
FIXME / HACK in there. I view cp as a fairly simple tool whereas rsync has
a great number of options to finely control what you want to do.

At this point I've concluded that a
  cd source; tar cSf - . | ( cd dest; tar xpf - )
for phase 1 followed by a
   rsync -avSHP --del source destination
for the final sync is the way to go.



[1] There is an interesting note about *NFS* - the Network File System
-O, --omit-dir-times
     This tells rsync to omit directories when it is preserving
modification times (see --times).  If NFS is sharing the directories on the
receiving side, it is a good idea to use -O.  This option is  inferred  if
 you  use  --backup without --backup-dir.

Greg Rundlett



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org