-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The answer to the original question What is it doing? is usually
best answered by rsync it self with -vvv
Perry Smith skrev 2014-01-14 00:19:
Yea. Shouldn't be hard to split up. The hard part is some type of
dependable rotation.
You mention
denote a metafile that is copied, one
line at a time, to the client, as the traversal of each of the trees
completes.
Perry
On Jan 14, 2014, at 5:25 AM, Christian Huldt christ...@solvare.se wrote:
Signed PGP part
The answer to the original question What is it doing? is usually
best answered
This is my first time to really use rsync. I did small tests to get the
arguments like I wanted and then kicked off the big rsync about 2 and a half
hours ago. So far, it has not copied over any files.
The command I used is:
rsync \
--relative \
--recursive \
--copy-links \
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
First, don't run rsync without either --times or --archive. Without
that rsync won't copy timestamps and it won't be able to tell what is
changed when you run it again.
Second, if rsync isn't copying anything then there are 2 reasons...
1. You
A friend and I noticed the --times or --archive flag. I have not
stopped it yet but I'll add that flag (probably --times).
This is the first time so it must be #2.
The side issuing the command is a Mac using rsync version 2.6.9
protocol version 29. The other side is AIX using rsync version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/13/2014 05:05 PM, Perry Smith wrote:
A friend and I noticed the --times or --archive flag. I have not
stopped it yet but I'll add that flag (probably --times).
This is the first time so it must be #2.
The side issuing the command is a
Ok. I can get the Mac up to version 3 but I'm wondering if
I need to rethink my whole strategy. Since the source is on NFS,
doing a stat on all the files each run may cost me too much
time.
I might need to split it into smaller pieces and then rotate
through the pieces via a script. Do you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is still the same number of stat calls. Doesn't really matter if
you split them up.
Can you rsync to the NFS server directly?
On 01/13/2014 05:34 PM, Perry Smith wrote:
Ok. I can get the Mac up to version 3 but I'm wondering if I need
to
The NFS server is off somewhere else, locked down. secure, blah blah.
Doing it via a script that rotates is the same number of stat calls but it
would start at a different place each day.
If I start it day 1 and it gets 25% through the stat calls, on day 2, will rsync
start where it left off or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you have to abort it then I suppose that makes sense. Otherwise
you could throttle or pause it.
If you do have to split it up then it shouldn't be difficult. Your
original command was specifying multiple sources using a glob of some
kind so you
Yea. Shouldn't be hard to split up. The hard part is some type
of dependable rotation.
You mention pause... I have to disconnect so I assume that would
abort the transfer. But that triggered another question: would
daemon mode help in this situation? (I assume not. The daemon
probably folks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
By pause I essentially meant ^Z. If you have to actually disconnect
then you wouldn't be able to simply resume.
The only way rsyncd would help here would be that you could define
your globs in the rsyncd.conf file instead of on the command line.
On 1/13/2014 5:34 PM, Perry Smith wrote:
Ok. I can get the Mac up to version 3 but I'm wondering if
I need to rethink my whole strategy. Since the source is on NFS,
doing a stat on all the files each run may cost me too much
time.
I might need to split it into smaller pieces and then rotate
On 1/13/2014 6:19 PM, Perry Smith wrote:
Yea. Shouldn't be hard to split up. The hard part is some type
of dependable rotation.
You mention pause... I have to disconnect so I assume that would
abort the transfer. But that triggered another question: would
daemon mode help in this situation?
Perry Smith wrote:
This is my first time to really use rsync. I did small tests to get the
arguments like I wanted and then kicked off the big rsync about 2 and a half
hours ago. So far, it has not copied over any files.
-
Is it really making progress? Or will it take this long to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I agree completely about getting rsync onto the NFS server. Rsync
(especially over ssh) is far more secure than NFS. Even if the NFS
server is actually a NAS appliance many of them can do rsync as well.
On 01/13/2014 11:14 PM, Linda A. Walsh wrote:
Hey.
Can anybody spot my mistake?
mkdir a b c
echo foo a/test
echo foo b/test
rsync -av --compare-dest=b a/ c/
Expected results:
no copy of a/test to c/test, since it is already present in b.
Actual results:
a/test gets copied to c/test
What is wrong here? My expectation? my syntax? I'm
On Thu, 2007-11-15 at 15:41 +0100, Lucas Meijer wrote:
Can anybody spot my mistake?
mkdir a b c
echo foo a/test
echo foo b/test
rsync -av --compare-dest=b a/ c/
Relative --*-dest paths are interpreted relative to the destination
directory (as stated in the man page), so you should use:
Hey Matt,
Relative --*-dest paths are interpreted relative to the destination
directory (as stated in the man page), so you should use:
rsync -av --compare-dest=../b a/ c/
tried that too, same result for me:
mkdir a b c
echo foo a/test
echo foo b/test
rsync -av --compare-dest=../b a/ c/
On Thu, Nov 15, 2007 at 10:29:58PM +0100, Lucas Meijer wrote:
mkdir a b c
echo foo a/test
echo foo b/test
rsync -av --compare-dest=../b a/ c/
The two test files don't match in their preserved attributes. They must
either have the same mtime, or you must not ask rsync to preserve times.
the destination fedor://test/Kibbutz with a copy of the 29G file in the
destination directory, it takes about 30m of real time and 9m of user time.
It seems to be specific to source and destination being on the same system.
Would either Wayne or Tim give me some insight into what I am doing to screw
]
Subject: Re: what am I doing wrong
On Fri, Jun 11, 2004 at 02:53:53PM -0400, Wallace Matthews wrote:
I am seeing some rather strange behavior with synch of 2 directories on the same
system using 2.6.2.
The older file is the image of a full backup and is 29Gig in size. The new image is
a slice
Thanks Wayne!
Both options worked well -- upgrading clients to 2.6.0 or using /.
instead of / to specify the root directory.
Perhaps a recap for the regulars here, but maybe useful to some -- I found
that I only needed to upgrade to 2.6.0 on the remote/source side.
Upgrading to 2.6.0 on my
Sorry if this is a boneheaded question. I'm stairing at it and can't see
what I'm doing wrong:
On machine B, I'm trying to mirror all of machine A and want to delete
files that have been deleted off A since the last sync. I run:
rsync -av -e ssh --one-file-system --numeric-ids --relative
On Wed, Apr 21, 2004 at 04:59:19PM -0400, Brian McEntire wrote:
rsync -av -e ssh --one-file-system --numeric-ids --relative --delete
--exclude-from=/backups/control/all.exclude '[EMAIL PROTECTED]:/ /boot /dev/shm
/sandbox ' /backups/A
You have a couple choices on how to make this work:
-
25 matches
Mail list logo
