On 5/6/20 11:49 AM, Peng Yu wrote:
> On 5/5/20, Kevin Korb via rsync wrote:
>> Rsync != diff.
>
> What do you mean? I only need to know what files are not the same, but
> I don't need to know what the differences are with the files.
See diff -q
>
>> However, i
On 9/29/20 7:07 AM, joe--- via rsync wrote:
> unknown module Linux1
This would imply that "Linux1" is not defined in the rsyncd.conf file on
the backup server. Of course since it is a NAS appliance I don't know
if you have any access to the config file.
1 check you could run is 'rsync
Interesting idea. It isn't something I have ever wanted to do. BTW, if
your find is recent use + instead of \;. + replaces {} with however
many entries fit in the command line length limit instead of running
individual rsync processes for each entry.
On 9/29/20 7:46 PM, Rob Campbell via rsync
Mostly it means that the file rsync ended up with on the target end
didn't match the file on the source it started with. This is mostly
caused by the file being modified on the source while rsync is copying
it but it can also be a memory corruption problem.
On 8/11/20 1:13 PM, Peng Yu via rsync
Unfortunately the hard links are the problem. In order to keep them
straight rsync has to remember the details of every file it finds with a
link count >1 making it grow and grow. Of course without -H rsync will
end up duplicating them.
On 6/25/20 10:30 AM, Andy Smith via rsync wrote:
> Hi,
>
user@x.x.x.x:port/ModuleName is not correct syntax. You may have
something in your shell config translating that for you. Correct syntax
is --port and user@host::module
On 6/25/20 6:01 PM, Chandrasekar Natarajan via rsync wrote:
> Hi,
>
> I am trying to pull folders from a windows remote
The only time I have seen something like that was when I was using rsync
to backup a snapshot and something went wrong in the snapshot creation
resulting in me rsyncing an empty dir instead of a mounted filesystem.
Does the --stats output imply that rsync saw an empty dir?
On 6/9/20 2:46 AM,
volumes but I would have to manually recreate the symlinks on the
> destination NTFS volume once.
>
> Have I understood correctly?
>
>
> On Tue, 29 Dec 2020 at 13:53, Kevin Korb via rsync
> mailto:rsync@lists.samba.org>> wrote:
>
> If you delete the li
If you delete the link then restore it does it start working again when
in the correct place?
Also, don't use --checksum unless you are really certain you understand
how terribly slow it is and how it doesn't actually accomplish much of
anything (certainly not any kind of data verification).
On
and with the --archive flag (preserve symlinks).
>>>
>>> The result was the symlinks on the destination volume were preserved or
>>> at least not destroyed by the subsequent sync. If this test is what you
>>> intended then it shows rsync can preserve the symlink between N
Either that or you have a hardware problem causing the checksum routine
to return the wrong result.
On 12/15/20 11:47 PM, Dan Stromberg via rsync wrote:
>
> On Tue, Dec 15, 2020 at 3:25 AM Laurent B via rsync
> mailto:rsync@lists.samba.org>> wrote:
>
> Dear all,
>
> I'm encountering a
A few things here...
What filesystem is on /mnt/sony?
Add a --itemize-changes to see what it says is going on.
There really isn't a good reason to exclude lost+found. It should always
be empty and take up no space. If there is something in it that is a
sign that there is a problem with your
You need to include the dirs leading to there...
--include=httpd/, --include=httpd/conf.d/
Otherwise it will never look inside to see the cluster.d
(I am assuming you are right about lsyncd using the same patterns as rsync).
On 10/21/20 9:01 AM, lejeczek via rsync wrote:
> hi guys,
>
> I'm
Rsync by default displays nothing. There are more than one options that
tell it to display the files it is touching. There are other (and
duplicate) options that tell it to show everything. You didn't say what
options you are using so we have no idea. Except that you aren't using
Short answer: Don't use --append[-verify]
If you aren't syncing files that aren't tagged with 'chattr +a' you
don't want --append. --append-verify is essentially "I think --append
is a good idea to use on general files but rsync keeps corrupting
stuff!" but it still allows files to be out of
I am not sure if I have missed information here but... Rsync only sets
the mtime on files that it completely transferred. The back-dating of a
file is rsync's guarantee that that file was completely transferred and
verified.
On 2/2/21 9:03 PM, Leon Vanderploeg via rsync wrote:
> Windows Cygwin
Those aren't really rsync errors they are just rsync telling you what
the kernel told it. The only thing I see wrong in your paste is that
you didn't use a trailing / on the source+target. Those do mean
something to rsync. The only thing I see wrong in the instructions is
the use of dd to make
You should both look into rrsync. It comes with rsync and is designed
to do exactly this. Unfortunately some Linux distros are maintained by
insane people who install rrsync as if it was documentation (compressed
and not executable) instead of a helper script which is what it is.
On 2/18/21
In my experience backing up multiple hosts to a single host can speed
things up. Especially if using rsync over ssh with multiple CPUs on the
single host. You would need to do some experimentation to determine the
best number for your hardware and network. Also, if you exceed that
number you
wrote:
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, August 24, 2021 8:25 PM, Kevin Korb via rsync
> wrote:
>
>> In my experience backing up multiple hosts to a single host can speed
>> things up. Especially if using rsync over ssh with multiple CPUs on the
>> sin
:
>>
>>> ‐‐‐ Original Message ‐‐‐
>>> On Saturday, September 18, 2021 12:06 AM, Kevin Korb via rsync
>>> rsync@lists.samba.org wrote:
>>>
>>>> Not really sure what you are trying to accomplish here. Seems like it
>>>> should work the way you h
Not really sure what you are trying to accomplish here. Seems like it
should work the way you have it. Note that many wonky rsync kludges are
due to people not realizing that rsync can have multiple source
arguments. Instead of the source simply being . it can be a list of
stuff. Also, note
Well, what you have should function. But rsync is going to sort the list.
On 9/17/21 8:26 PM, hancooper wrote:
> ‐‐‐ Original Message ‐‐‐
> On Saturday, September 18, 2021 12:06 AM, Kevin Korb via rsync
> wrote:
>
>> Not really sure what you are trying to accomplis
:20 PM, Kevin Korb via rsync
> wrote:
>
>> --archive is all you really need. I actually wish --archive was the
>> default because it is all most people need and with the exception of
>> writing to a FAT filesystem it is almost always needed.
>>
>> --append
--archive is all you really need. I actually wish --archive was the
default because it is all most people need and with the exception of
writing to a FAT filesystem it is almost always needed.
--append is for very special cases and should only be used if you really
know you need it and why.
-av
> --inplace ?
>
> What can I do for the files which have been sent but got rsync aborted during
> transfer?
>
>
>>> On 9/11/21 9:29 PM, hancooper wrote:
>>>
>>>> ‐‐‐ Original Message ‐‐‐
>>>> On Saturday, September 11, 2021 11:20 P
Rsync does almost everything cp does but since it is designed to network
it never got that feature. I was thinking maybe --link-dest could be
tortured into doing it but if it can I can't figure out how. BTW, you
have some pointless dots in there.
On 9/4/21 6:41 PM, L A Walsh via rsync wrote:
>
4, 2021 at 4:57 PM Kevin Korb via rsync
> mailto:rsync@lists.samba.org>> wrote:
>
> Rsync does almost everything cp does but since it is designed to network
> it never got that feature. I was thinking maybe --link-dest could be
> tortured into doing it but if i
See --link-dest. That is what makes rsync shine for backups.
On 10/6/21 10:09 AM, Helmut Jarausch via rsync wrote:
> Hi,
>
> I'd like to mirror my root file system (e.g.) to a different disk. The
> mirror should always be most recent.
> In addition, I'd like to be able to restore my file system
wrapper that works very well over networks but
is similarly very slow over local disks. I thought it was a bug in my
code but didn't get around to tracking it down since my use cases were
all network/ parallel file systems.
Harry
On Sun, Nov 28, 2021, 11:43 AM Kevin Korb via rsync
mailto:rsync
rsync is terribly slow at local copies. Also, it doesn't do its normal
optimizing (see --whole-file). Just use cp.
On 11/28/21 13:38, Mario Marietto via rsync wrote:
Hello to everyone.
I'm copying a large file from a NTFS formatted disk to another
one,UFS/FreeBSD disk,both are removable
There maybe a proper solution but an obvious workaround would be to run
rsync twice. The first time without the --fileflags option.
--no-perms wouldn't help. That is only the standard unix permissions.
On 10/30/21 8:04 PM, Fred Fugate via rsync wrote:
> Hi,
>
> I have some subdirectories
rsync have anything similar?
>
> Kevin Korb via rsync wrote:
>
>> There maybe a proper solution but an obvious workaround would be to run
>> rsync twice. The first time without the --fileflags option.
>>
>> --no-perms wouldn't help. That is only the standard unix
Rsync includes a script named rrsync that handles this perfectly.
On 3/12/22 01:08, Richard Hector via rsync wrote:
On 12/03/22 18:38, Richard Hector via rsync wrote:
And I do my backups (using dirvish) as root, using a key with a forced
command.
FWIW, that forced command is here:
Are you using the same source and target each time? I ask because the
only discrepancy I see is the link count which shows that there are 11
more instances of that inode on the source than the target. Maybe
instances in other snapshots are being updated/re-linked?
The only other thing to
You have --itemize-changes but either it didn't or you filtered it out.
--
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
Kevin Korb Phone:(407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc.
Is this being accessed via a fuse mount? If so it seems like that is
where this kind of feature should be implemented (like a mount option to
decide how to handle such files). Rsync shouldn't need special features
to deal with every kind of file storage.
On 9/12/23 05:22, Brian "bex"
-0400, Kevin Korb via rsync wrote:
I have heard in the past that rsyncing an empty dir over a tree to
delete the tree is faster than an rm -rf but I can't say I have ever
benchmarked it to get any actual numbers.
This **may** indeed be a myth (for a long time now) re-cited again and again
I had intended to come back to this but because I didn't really think I
had anything to add to the discussion I put it at a low enough priority
that I forgot about it. But I saw your bug report and was surprised to
see that I was already unhelpful on this topic but because that original
I think you are thinking too much of rsync here. Rsync groups are the
same as users they just have an @ in front of the name. If you want
UNIX style users and groups then use rsync over ssh and get the bonus of
ssh's authentication as well as not needing an rsyncd.conf file at all.
On
for the reply.
пт, 24 июн. 2022 г. в 19:00, Kevin Korb via rsync <mailto:rsync@lists.samba.org>>:
I think you are thinking too much of rsync here. Rsync groups are the
same as users they just have an @ in front of the name. If you want
UNIX style users and groups then use rsync
It actually does that by default. Though you might need to add to the
list of file types with --skip-compress.
On 6/24/22 19:35, Joseph Garvin via rsync wrote:
I have an rsync cron job to backup folders that contain many different
types of files. Most of these are uncompressed files, so the
Rsync does not verify writes. --checksum doesn't verify anything.
Sounds like you want a file verification tool. The simplest would be
md5sum.
On 7/12/22 02:31, Mark Filipak via rsync wrote:
Hello. Does rsync verify its writes?
Re, 'info rsync'.
Maybe I just being stupid, but there's no
there are legitimate causes for that.
On 7/12/22 17:26, Paul Slootman via rsync wrote:
On Tue 12 Jul 2022, Kevin Korb via rsync wrote:
Rsync does not verify writes. --checksum doesn't verify anything. Sounds
like you want a file verification tool. The simplest would be md5sum.
Running rsync --checksum
.
Or, alternately, be in a situation where a bit flip would be
catastrophic. Such situations are not common.
On Thu, Jul 14, 2022 at 04:26:48AM -0400, Kevin Korb via rsync wrote:
You should almost never use --checksum. It is slower than just re-copying
everything. You should almost always use
You should almost never use --checksum. It is slower than just
re-copying everything. You should almost always use --times (or
--archive which includes --times). Without this rsync is almost as dumb
as cp. Also, ssh has been the default --ssh for a long time.
On 7/14/22 04:22, Fourhundred
Includes override excludes that follow. So, your include of * meant
that nothing was being excluded. An exclude before any includes isn't
affected by the includes.
On 4/30/22 20:04, H via rsync wrote:
On 04/30/2022 07:56 PM, H via rsync wrote:
Ah, I was under the impression that all
includes
and excludes into the same file.
On 4/30/22 20:48, H via rsync wrote:
On 04/30/2022 08:22 PM, Kevin Korb via rsync wrote:
Includes override excludes that follow. So, your include of * meant that
nothing was being excluded. An exclude before any includes isn't affected by
the includes
You are using rsync over ssh. The connection timeout (and port) options
don't matter if rsync isn't doing the networking.
On 9/1/22 08:49, Roland via rsync wrote:
hello,
i do some backup via rsync/ssh and pull data from remote machine to
local machine.
whenever on remote machine there is
I think I must be missing something. If source and dest are the same
place rsync shouldn't do anything unless it it responding to changes
happening at the same time. For example, when I do 'rsync -vain
--remove-source-files /tmp/ /tmp/' rsync does nothing.
On 10/17/22 23:12, Sridhar
Rsync does not have a --no-clobber. -n is --dry-run. It shows what
rsync would do without actually doing it. But I didn't know you were
using --backup. Anyway, I tried it again with --backup and
--remove-source-files and it did in fact delete all the files (but not
the dirs). It didn't
solve my
problem? Will give it a try.
Am 25.09.22 um 20:30 schrob Kevin Korb via rsync:
-a is telling rsync to copy the metadata. --size-only is telling
rsync to skip the contents of files that are the same time. Without
--link-dest rsync would just update the metadata on the target.
However
-a is telling rsync to copy the metadata. --size-only is telling rsync
to skip the contents of files that are the same time. Without
--link-dest rsync would just update the metadata on the target.
However, with --link-dest rsync is being told to make the same file with
2 different metadatas.
You aren't logging any stderr. That is where any error messages would
go. Add some 2>&1.
Also, mount has a -v
On 9/24/22 09:15, dotdeb--- via rsync wrote:
I've been using rsync for years to backup my machines both at work and
at home.
These days I faced a new "challenge": at work I connect
You can put it all in quotes. Also, if you are scripting you might find
setting $RSYNC_RSH easier.
On 10/7/22 04:46, c.buhtz--- via rsync wrote:
Hello,
rsync does offer the --rsh argument. I would like to use it that way
rsync --rsh=ssh -o ServerAliveInterval=240 -o LogLevel=Error -o
The first "Bug Fix" listed in
https://rsync.samba.org/ftp/rsync/NEWS#3.2.4 is almost certainly
related. Apparently it was fixed via remote option but since your test
doesn't include networking that fix wouldn't help.
On 12/8/22 15:03, Mark Raymond via rsync wrote:
I believe I have found a
The included github test case failed for me on vanilla rsync-3.2.7...
% ./test.sh
new.bin test.bin differ: byte 28345, line 1
% md5sum -b *.bin
7e11df4130968b5e4859f58b9bd6b453 *initial.bin
ff14ab080514d5681c99e4e1de01e29f *new.bin
151dd8b1c7bd628afcf38ac6c44155be *test.bin
% rsync --version
I am not 100% sure I am interpreting this correctly but I think you are
complaining that the file was being deleted in the first command? If
so, instead of -F try --include='*/' --exclude='*'. Otherwise, maybe
you want a second -F?
On 3/6/23 16:04, Heiko Schlittermann via rsync wrote:
on.
*From:* rsync on behalf of Kevin Korb
via rsync
*Sent:* Wednesday, June 7, 2023 3:26 PM
*To:* rsync@lists.samba.org
*Subject:* [External] Re: ctrl -c while executing --progress --size-only
--partial results in unhidden but incomplete file
[You don't often get email from rsync
That is what --partial does. It keeps the partial file. If it kept the
temporary file with the random file name that would just be a useless
orphaned file.
On 6/7/23 15:02, Lacey, Nathan via rsync wrote:
This is a clone from https://github.com/WayneD/rsync/issues/484
find /mnt/foo/* -maxdepth 0 -print -exec rsync -an `realpath {}`
/mnt/bar/ \;
(realpath eliminates the trailing slashes)
On 8/3/23 22:27, Fourhundred Thecat via rsync wrote:
Hello,
I am copying /mnt/foo to /mnt/bar/
rsync --info=name1,del2 -rl /mnt/foo /mnt/bar/
/mnt/foo contains deep
NFS is slowing things down even more than your bandwidth measurements as
it is also forcing --whole-file.
On 8/2/23 05:03, Perry Hutchison via rsync wrote:
Sebastian G??decke via rsync wrote:
We're facing some flapping traffic when rsyncing atm 70T from
one server to an DELL Isilon.
Both
--itemize-changes will cause rsync to tell you what it thinks is
different. Also, -z is counter-productive when rsync isn't networking.
On 6/28/23 22:28, Stephane Ascoet via rsync wrote:
Hi, /media/clec1enextsanstampon/gigamopourcdas4/ contains an old copy of
files of /media/mo. I'm
On 6/29/23 16:31, Stephane Ascoet via rsync wrote:
Kevin Korb le 29/06/2023 04:52:
--itemize-changes will cause rsync to tell you what it thinks is
Hi, thank you so much! Today I used a little different way of doing it,
and another computer, and the behaviour is the same. It seems that the
You should also read about --inplace. Without it --no-whole-file you
are telling it to do all the extra data diffing only to write out an
entire new file anyway (just using data from source and target to create
it).
On 6/30/23 21:29, Selva Nair via rsync wrote:
So this disable a lot
The only way I know of to determine this behavior is to use the
--link-dest option in rsync OR use the much older cp -al then rsync over
top of it method. With --link-dest a change in the file's metadata
causes rsync to duplicate the file in order to store both versions of
the metadata. With
now it sounds like you have too many hard links for rsync to handle.
On 2/7/24 08:05, Franke via rsync wrote:
Am 06.02.24 um 23:20 schrieb Roland:
and then, it stops totally quiet.
you mean it simply exits without any message?
Yes rsync ends totally quit.
what's the return code ( echo
I'm not really blaming the user. If it were up to me, -v would include -i.
On 2/9/24 05:36, Andreas Gruenbacher wrote:
On Sun, Feb 4, 2024 at 7:20 PM Kevin Korb via rsync
wrote:
rsync's -v is fairly useless. Learn to use -i instead or in addition to.
Well, note that I didn't say anything
Normally, when rsync isn't deleting things the problem is that there is
some kind of error (possibly scrolled off screen unnoticed) but it
sounds like you are getting no output at all which would eliminate that
possibility.
The other likely cause is your $SOURCE being something that contains a *
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Unfortunately, exit 23 litterally just means something else went wrong
and might have scrolled off of the screen if you have rsync listing
files (--verbose or --itemize_changes). Essentially, it is anything
that doesn't have its own exit code. I
What is the error? I assume you know that with that syntax the
filelist.txt is local rather than remote.
On 12/20/23 09:50, Alex via rsync wrote:
Hi, I've been using rsync on fedora over ssh to sync directories for
decades, but suddenly having a problem with transferring multiple files
at a
l.com>> wrote:
Hi,
On Wed, Dec 20, 2023 at 11:03 AM Kevin Korb via rsync
mailto:rsync@lists.samba.org>> wrote:
What is the error? I assume you know that with that syntax the
filelist.txt is local rather than remote.
Yes, I do know i
rsync's -v is fairly useless. Learn to use -i instead or in addition to.
On 2/4/24 12:58, Andreas Gruenbacher via rsync wrote:
Hello,
when trying to rsync files between hosts, I ran into a surprising case
in which rsync replaces a symlink with a directory, with no indication
of any kind.
In
Also, instead of -a use -rt. Those are the only parts of -a that FAT
even pretends to support.
On 1/21/24 16:42, Roland via rsync wrote:
it's most likely because of vfat timestamp limitation
try
--modify-window
When comparing two timestamps, rsync treats the
timestamps as
I don't believe that what you are asking for can be done with rsync. At
first thought you can't mix --ignore-existing with --ignore-non-existing
as that would ignore everything. Something would have to at least exist
and not be ignored for rsync to link to it.
Anyway, for a laugh, I asked
It appears that xattr changes (that is what the x mens) never made it
into the verbose output. I would call that a bug but I would rather it
be fixed by making -v include -i.
On 6/3/24 05:22, - via rsync wrote:
Hi,
Version: sync version 3.3.0 protocol version 31
If I do a
I get:
101 - 176 of 176 matches
Mail list logo