(until a better answer comes along)
The killed rsync process should leave a temporary file .file-name.random
If you rename the temporary to the real file name, rsync should continue
from about where it left off.
-Original Message-
From: rsync-boun...@lists.samba.org
Check the TIMESTAMPS on both source and target.
(you probably want -av or such (instead of -vr) to include ...)
-Original Message-
From: rsync-boun...@lists.samba.org [mailto:rsync-boun...@lists.samba.org] On
Behalf Of Grant
Sent: Friday, February 22, 2013 3:24 PM
To:
This may help: (man ln)
A hard link to a file is
indistinguishable from the original directory entry; any changes to a
file are effectively independent of the name used to reference the file.
Hard links may not normally refer to directories and may not span file
systems.
Assuming you do many
From man rsyncd.conf
max connections
This parameter allows you to specify the maximum number of
simultaneous connections you will allow. Any clients connecting
when the maximum has been reached will receive a message telling
them to
--timeout=SECONDS set I/O timeout in seconds
I think this timeout must be set big enough so that data actually gets
transferred during the window.
Having the target verify that nothing has changed yet seems to not qualify as
resetting the timeout.
Figure on enough time so that
If the directories are large enough, /path/* becomes too long.
My own opinion is that that syntax is a very small price to
pay for the flexibility and power.
-Original Message-
From: rsync-boun...@lists.samba.org [mailto:rsync-
boun...@lists.samba.org] On Behalf Of Kevin Korb
Sent:
Until you get responses from people who actually know what they are talking
about.
?1 what is the file system on the usb drive. Fat32 cannot preserve owner/group
or their permissions.
?2 preserving hard links end-to-end
a3 rsync will use whatever targets are currently existing and their
OK, I'll bite.
With all file system designs, there is a tradeoff between speed and safety.
This tradeoff occurs at all levels where there might be something that buffers
information.
Writing into the middle of a structure can be incredibly slow if everything is
done safely.
Enter disk caches
Thanks for the detail.
Try
du -s /tmp/full_20110329_122743 /tmp/20110329_122743
du -s /tmp/20110329_122743 /tmp/full_20110329_122743
du -s /tmp/full_20110329_122743
du -s /tmp/20110329_122743
Technically, the directories have entries which point to the inodes which are
in fact the files.
When
Robert Holtzman wrote:
Running Ubuntu 10.04.1 and rsync 3.0.7-1. Used rsync successfully for
over a year for backups. Recently there was a kernel upgrade to
2.6.32-25. Don't know if that has any bearing. When I tried to run a
backup today rsync failed with the error message:
sending
balearenin...@gmx.net wrote:
Hola,
new to the list and maybe having problems with english I ask for a
friendly and a not too difficult answer.
Using Windows 7 Pro,
D-link DNS-323 NAS-Storage
rSync: actual Version (just downloaded)
Here is the stange behavier:
I use
rsync.exe -a -v
Grarpamp wrote:
Yes, hardlinks save data block duplication... yet on filesystems with
millions
of files / long pathnames, just the directory entries alone can take up
gigs
per image. Multiply that out by frequency and it can quickly add up.
Huh?
--
Please use reply-all for most replies to
Matthias Schniedermeyer wrote:
On 05.01.2010 05:36, grarpamp wrote:
That option can be easily missed it's: --size-only
That seems like at least part of what would be useful :)
Certainly it covers the most common case of modtimes.
However, it doesn't seem to work :(
cp -p
Gary Montalbine wrote:
I am trying to backup my /home directory. A friend helped me with this
script:
#!/bin/sh
#backup friday
#Spinning up backup drive and mounting it ..
cd /
mount /mnt/hd2
#Starting backup procedures
rsync -avx --exclude=/home/gary/.thumbnails/
henri wrote:
I agree with everyone else that it would be incredibly useful for
rsync to
either adopt such behaviour by default (assuming always doing
'mkdir -p' isn't
harmful in any way), or have a tunable to enable it.
I also agree the suggested behavior makes a lot of sense and I
Tom wrote:
to make things more clear
1.)
first transfer is done either a initial setup or with a usb hdd to get
sender and receiver in sync.
2.)
transfer does not stop because rsync had a timeout, it stops because
the dsl
line is broken (which i could see at dyndns)
3)
if dsl line
tom raschel wrote:
Hi,
i have to tranfer large files each 5-100 GB (mo-fri) over dsl line.
unfortunately dsl lines are often not very stable and i got a broken
pipe error.
(dsl lines are getting a new ip if they are broken or at least after a
reconnect every 24 hours)
i had a script
FILE NAME WITH SPACES -- this is 4 different space-separated parameters fed
from the shell to the program
FILE NAME WITH SPACES -- this is one parameter fed from the shell to the
program
FOLDER-NAME/ -- this is one parameter and means all the files in the
directory FOLDER-NAME/
FOLDER-NAME --
Carlos Carvalho wrote:
Ryan Malayter (malay...@gmail.com) wrote on 14 July 2009 17:00:
On Mon, Jul 13, 2009 at 4:54 PM, Jamie
Lokierja...@shareable.org wrote:
Remembering hashes doesn't make any difference to speed, if the
bottleneck is the sending side.
Except that in the
Silly question, but are you doing something like compacting,
removing air, or optimizing the database in any form?
If the blobs keep moving around, that makes finding common stuff
much much harder.
It will still have to read both sides even if almost everything is the same
-Original
I think you need to look at the permissions you will need on Windows
if (ie when) you need to recover. You can do a little better than
distinguish read-only from writable, but not much and not easily.
The simpler you can stand it, the happier you will be.
With -a parameter, rsync will complain
Something like
ls -d NetBackup/* | wc
should be informative.
(assuming something unixy, of course -- cygwin stuff might work)
-Original Message-
From: rsync-bounces+tony=servacorp@lists.samba.org
[mailto:rsync-bounces+tony=servacorp@lists.samba.org] On
Behalf Of Daniel.Li
Each different OS has a different idea of what attributes exist for whatever
they call files.
The exact combination of attributes will not map exactly from any OS to any
other OS,
although it is possible to preserve some crude distinctions in many (most?)
cases.
You look at the error messages to
Dunno for sure, but I'd expect differences if S1 is /dev
Simple case, a copy is just a copy.
Edge cases, there's lot of room for differences in exactly
what happens when things are not exactly perfect.
Many times I use rsync because I know what it does and
I'm not exactly sure what cp will do.
There are three areas of fundamental incompatibility (that I am aware of)
Basic File Permissions: Unix has rwx for owner/group/world, Windows has
Hidden/System/Read-Only/Archive. NTFS has ACLs
(The above is an oversimplification, and things can be done so it works
well enough for what is
listserv.traf...@sloop.net wrote:
I've done quite a bit of looking, but I haven't found an answer that
answers this question.
Environment:
cygwin on Windows
rsync 3.0.4
I know that rsync isn't optimzed for speed on local copies - that's
clear in my testing. I'm attemting to sync a
Thomas Ebert wrote:
Hi,
I have a problem backing up my music collection, that is stored on a
fat32 formated hard drive to my ext3 formated backup drive
(ext3 to ext3
works like a charm :) ).
The problem is, that rsync always transfers all of the files and not
only the one that
Matt McCutchen wrote:
Sent: Sunday, March 02, 2008 3:14 PM
To: [EMAIL PROTECTED]
Cc: rsync@lists.samba.org
Subject: Re: Wrong uptodate
On Sun, 2008-03-02 at 17:43 +0100,
[EMAIL PROTECTED] wrote:
Rsync claims files to be uptudate, but they are not ...
From the log:
Thankee! Thankee! Thankee!
I am definitely switching to 3.0 or the next pre.
(currently anything like that that actually gets to the other side is
gravy)
(not all that bad since anything that actually matters is supposed
to be in english not chinese ;-)
This is on/to/through computers
Paul Slootman wrote:
I think you mean file owner? Of file times?
cannot set file names seems unlikely :-)
File OWNER
File GROUP
and DOS/Windows complains
Me, I let it complain --- much more complaining with cp than with rsync
DOS and Windows have different ideas of what file attributes
Are you preserving the times?
There are many combinations.
Me, I always use -a and then add stuff.
Copying or Rsyncing windows stuff always seems to have stuff
(essential to Linux/Unix) missing from the windows side.
But nothing in that parameter list looks like it would
preserve the
Thanks.
Paul Johnson wrote:
soft link is totally different from hard link. that junction on
directory is not the same meaning of hard link in Unix concept.
Windows can (maybe) come close to doing a soft link,
directories/drives at least somewhat
(but try following the
Flames/Cluestick invited if I've got this wrong.
I would expect:
rsync checks blocks on source to see if they are the same.
blocks which seemed to be the same (past tense) are not sent.
blocks which seemed to be different will be sent with whatever the current
content of the block happens to be.
The short answer is It depends
Egoitz Aurrekoetxea wrote:
Hello,
I'm trying to determine if rsync is a sure method of backing
up servers (Linux and Windows) whose files are constantly
being accesed and are not able to be stoped they're services
for backing up purposes... I would use
Fabian Cenedese wrote:
At 15:15 18.09.2007 -0400, Matt McCutchen wrote:
On 9/18/07, Fabian Cenedese [EMAIL PROTECTED] wrote:
I was wondering what happens if a file that is regularly
synched but
seldom changes gets corrupted in the copy.
Are you referring to rsync writing corrupted data
Stephen Zemlicka wrote:
No idea why it's not. I usually use the -v -rlt -z --delete
options. You
could try the -c switch. I believe that will ignore the mod
time and size
and skip based on the checksum only. Though I would think
you need a switch
that does the opposite of that.
Matt McCutchen wrote:
On 9/15/07, roland [EMAIL PROTECTED] wrote:
what`s the rsync equivalent to this?
how can i see which files changed while rsync was
transferring them ?
Handling of concurrent changes to source files is one of rsync's
weaknesses. The rsync sender naively reads
[EMAIL PROTECTED] wrote:
Note that back-to-back rsyncs make the window of opportunity much
much smaller for things to change during transit.
yes, but it still leaves room for corrupted transfers nobody
would probably know about !?
With UNIX file semantics,
Loop until nothing is
Andre Majorel wrote:
On 2007-08-21 05:55 -0400, Matt McCutchen wrote:
On 8/20/07, Andre Majorel [EMAIL PROTECTED] wrote:
Is there a way to make rsync look inside device files ?
The goal is
to copy the contents of a block device to a regular file
incrementally.
Short of
Darryl Dixon wrote:
Hi All,
I've browsed the history of the list, but can't seem to find
an answer to something that I find quite surprising - why
isn't --numeric-ids the default when rsync is told to
preserve permissions? It seems to me that the current
behaviour runs against the
Wayne Davison wrote:
On Sat, Aug 04, 2007 at 07:26:19PM -0400, Matt McCutchen wrote:
What do you all think so far? Am I going in the right direction?
I'll hopefully have some time to check into it more later on,
but I did give your pages a look and they look pretty good.
One thing I
Matt McCutchen wrote:
On 7/16/07, Wayne Davison [EMAIL PROTECTED] wrote:
On Sun, Jul 15, 2007 at 11:09:57PM -0400, Matt McCutchen wrote:
Furthermore, from April 27 to July 10, about 2.5 months passed
without any hanging bugs being found; then, on July 11,
Warren Oates
reported
From an old old old-timer
The first disks that IBM came out with were effectively the same
speed as card readers and line printers. For unblocked records.
Disks are NOT asynchronous. They spin at a very predictable
Rate and timing are extremely different based on whether the
Head is in the right
have tried
--numeric-ids parameter...and nothing...
So if you know another tool which do that...
2007/5/31, Tony Abernethy [EMAIL PROTECTED]:
The uid and gid are numbers. These numbers **MIGHT** correspond to one or
more names.
As a convenience and courtesy, rsync attempts to preserve names
The uid and gid are numbers. These numbers **MIGHT** correspond to one or
more names.
As a convenience and courtesy, rsync attempts to preserve names across the
transfer
Who ever is running the rsync daemon must have the rights to make the
changes or there is nothing possible for rsync to do.
To
Before you trust this always-up-to-date, try it on some
relatively large files.
I suspect you get some nasty surprises.
The basic problem is that Windows writes the directory
entry and then sometime later writes the file contents.
If you only rsync files that are say at least 10 minutes
Old,
-a gets several options you probably want (in particular -o and -g)
(from man rsync)
-a, --archive archive mode, equivalent to -rlptgoD
-r, --recursive recurse into directories
-l, --links copy symlinks as symlinks
-p,
[EMAIL PROTECTED] wrote:
Hi!
I am running rsync 2.6.4 (on Debian sarge) and I am experiencing a
strange behaviour.
I am trying to create an identical filetree on the same filesystems with
the single files being hardlinks to the source like this:
rsync -vaH --progress --delete --stats
The modify-window switch (actually 1 is supposed to be enough)
is because DOS cannot store odd seconds
and an even number and an odd number are never the same number.
If I am understanding you right, the ssh should NOT be there. (flames
invited if I'm wrong)
You are rsyncing from a local source
Cheap
shot that might be effective. Something like this might
work.
On the
samba share,
after
the rsync has finished,
run a
script that touches any file that was last modified in the last few
minutes.
This
marks files that should be retransmitted because they might have
their
Some things fast off the top of my head
(flames invited where I'm wrong;)
I am assuming:
Files live on the Window server.
smb mounted onto the BSD server
(It does what it can, but it's a few cards shy of a full deck)
There is a buch of whatever in Windows ACLs, but
there is enough UNIX permission
this to work.
Copying the whole folder (folder at a time) to the BSD machine,
and then sync it to the Linux box works, but its very time
consuming, and definitely not the way to do it.
Wayne
-Original Message-
From: Tony Abernethy [mailto:[EMAIL PROTECTED]
Sent: Friday, July 07, 2006
/sys ( also /proc , probably others )
some
things that looks like directories and files, do not make sense to copy to
another computer.
generally, these give some kind of access to running kernel-type
things.
I
think some of these "files" are write-only or would give information about
some
(Flames invited if I've got this wrong or misleading;)
Traditional backup. (call this DOS-style backup)
Base: (full backup) (and turn all the archive bits off)
Incremental: copy files with archive bit on (and turn them off)
Backup Files. Add something (suffix) to indicate backup copies.
To monitor the file system, you have to have something down inside
the file system. Unless you know what you are doing, you don't really
want to mess around with any such. Any slipup
copy each others data
Now if this means an update to one implies an update to the other
that should be
This
is mostly wild guesses (with luck you get some more knowledgeable
answers)
From
what I have observed ...
file
of the form .RICHED~1.cab.IEKJmo is an rsync temporary of file
RICHED~1.CAB
Trying
to rename the temporary file to its permanent name, it ran into trouble on the
name
-
From:
Tony
Abernethy
To: Corey Wirun - Lists ; rsync@lists.samba.org
Sent: Sunday, 25 June, 2006 07:31
Subject: RE: Rsync fails to rename on
Windoze2003
This is mostly wild guesses (with luck you get some more
knowledgeable answers)
From what I have
, and that the
errors might be noise.
Thanks for the reply.
Corey.
- Original Message -
From:
Tony
Abernethy
To: Corey Wirun - personal ; rsync@lists.samba.org
Sent: Sunday, 25 June, 2006 10:17
Subject: RE: Rsync fails to rename on
Windoze2003
compared to 2.6.6 (which works 'better').
In any case, I'm going to checksum the source and
target. It does appear that the sync did do something, and that the
errors might be noise.
Thanks for the reply.
Corey.
- Original Message -
From:
Tony
With
the usual caveats of "Your Mileage May Vary", this may give you an idea of how
far you can push things and get away with it.
In
practice, I back up production MySQL databases when they are running. Not that
big a deal.
Some
notes on improving the odds (of getting away with it):
One
This
is the kind of place where EVERY piece of punctuation
matters.
-delete is very unlikely. You probably mean
--delete (two dashes before a "meaningful" parameter)
(-delete would be something wierd following a
-d)
192.168.1.152 might be some kind of
anonymous
I
would expect to see
Marty Mulligan
wrote:
Thanks for
your suggestions. I'll try to put together an rsync call with a more
explicit set of options, although I was under the impressions that by having the
"dont compress" option set in the conf file on the server, the -z option in the
call from the host was
You
should get some better answers, but a couple of points jump out at
me.
If the
files are already compressed, "small" changes result in very different
files,
so the
business of reading both the target and the source to find common stuff is kinda
counterproductive.
Also
the -z
Assuming the problem is Windows and time zones and daylight savings etc.
man rsync
--modify-window=NUM compare mod times with reduced accuracy.
Windows still uses the old DOS method of storing times, which can't put
the value of the seconds into a 32-bin number, so can only represent
even
Excuse
the "humor", but it sounds like you have a virus.
One of
the virus that is called "anti".
( Case
of the "cure" being worse than the disease? ;)
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of
Julian Pace RossSent: Tuesday, May 23,
Max Kipness wrote:
You could of course (right after an rsync run) do a
cd newdir; find . -type f -links 1 -print and then randomly check a
couple and compare all their attributes such as mtime, permissions to
the previous dir. (I still recommend using the --link-dest thing over
using cp
, 2006 6:56 PM
To: Tony Abernethy; rsync@lists.samba.org
Subject: RE: Issue with hard links, please help!
Number of files: 50285
Number of files transferred: 38
Total file size: 16193254538 bytes
Total transferred file size: 4077908049 bytes
Literal data: 86201342 bytes
Matched
100Mbps is about 10MBps so 4GB would take about 400 seconds or a bit under 7
minutes.
BOTH sides will have to read the 4GB file and compare results.
Comparing results will be almost instantaneous over 100Mbps LAN.
Getting the results to compare will depend on disk speed and CPU speed.
It doesn't
ba.orgSubject: Re: random file corruption on
NTFSHi Tony,the volume was previously a FAT32 before
it was reformatted to NTFS. I've wonderedabout the drive being
dodgy, is it that FAT32 is more leanient in terms of file
errors?thanks.Darrin.
On 5/12/06, Tony
Abernethy [EMAIL PROTECTED
Wild
guess, but that sounds a lot like a disk drive going bad.
An
error message like The file or
directory is corrupted and unreadable.
There
is essentially no way that an application (including rsync)
can
cause that kind of thing.
You
probably can cause that by messing with the
Fundamental difference between unix and windows.
Windows locks against simultaneous whatever.
Unix assumes you know what you're doing.
Unix allows deleting a file while someone is writing to it.
Also, you will likely need to stop BOTH outlooks.
There's usually one running that you do not see.
Flames invitied if I'm wrong, but I think you're looking at
the last file successfully transferred as opposed to the
first file unsuccessfully transferred.
I think I saw a /var in there
You get something ungodly long trying to rsync the file that is logging the
rsync.
something like
rsync -av
72 matches
Mail list logo