On 12.01.25 03:52, Anthony LaTorre via rsync wrote:
$ rsync -aPh --link-dest=/user/snapshots/rsync_test/last
/home/user/rsync_test
rsync://admin@readynas.internal/snapshots/user/Jan_11_2025
Password:
sending incremental file list
--link-dest arg does not exist: /user/snapshots/rsync_test/last
On 24.12.24 09:53, Mario Marietto via rsync wrote:
There are times when a large file is copied up to 99% and then deleted after
having received the error. Other times when the error occurs earlier and only a
part of it is copied. Does it make sense to calculate the checksum if in both
cases
On 23.12.24 22:06, Mario Marietto wrote:
-> Did you re-read the data and compare checksums ?
Don't know how to do this.
Files can be considered binary identical if they do have the same checksums.
e.g.
# md5sum [files]
Using windows:
https://windowsreport.com/checksum-on-windows/
c:certu
On 23.12.24 20:44, Mario Marietto via rsync wrote:
What would you think if I told you that using Windows I no longer had that
problem ?
Would you still think that there are hardware problems ?
And if so, why would they only manifest themselves using Linux and FreeBSD and
not using Windows?
Am 06.09.23 um 08:49 schrieb Paul Slootman via rsync:
The current version is 3.2.7, especially 2.6.8 is quite ancient.
You may want to upgrade before going bug hunting, chances are your
problem has already been fixed.
Oh yes, exactly the step to 3.* did a lot both to option and PERFORMANCE!
Am 29.06.23 um 22:31 schrieb Stephane Ascoet via rsync:
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 tha
Don't know if this is enough for you, but it may help at least a bit to hunt
down your problem. There is a flag -i
From man rsync
--itemize-changes, -ioutput a change-summary for all updates
this gives either a "." for no change, or a letter code for each change in "data,
time, size" etc.,
I second Francis here. You don't need to diagnose incomplete file transfers as
long as you have racing conditions as you described. This leads to strange
result inevitably.
NEVER start several rsync jobs manipulating the same data - especially if there
are modifications to BOTH sides source and
Robin is right.
Read back verification has lost its meaning since old days when we used
extremely unreliable media or transports. Who writes to floppies anymore? In
those old days you could/should use any copy program with a -v verify flag. But
read-back wore down your floppy faster, so in the
If this helps, in old days I used to use cpio for a similar thing.
I do not want to spam you with my whole script, but willing to share if you
want. I think you will get the hang of it by the following snippet. (Get
yourself man-knowledge about the -i -o -p mechanism of cpio and the use of dd.)
as --copy-dest).
On 9/25/22 14:26, Hardy via rsync wrote:
Hi,
SHORT:
rsync shall ignore differences in meta (inode) data, but does not even
with --size-only. -- If in combination with --link-dest.
Is there any flag I missed?
EXPLANATION:
I use
rsync -avbuH --size-only --stats --delete
Hi,
SHORT:
rsync shall ignore differences in meta (inode) data, but does not even
with --size-only. -- If in combination with --link-dest.
Is there any flag I missed?
EXPLANATION:
I use
rsync -avbuH --size-only --stats --delete-excluded
--link-dest=/path/to/last "user@system:Shared/Data" /pat
You only log you would like to to mount /backup, but the actual command
is missing. You should also log errors, so something like
/usr/bin/mount /backup >> /var/log/rsyncd.log 2>&1
would be adequate before your line to check what is mounted.
Hope this helps
Hardy
Am 24.09.22 um 15:15 schrob d
13 matches
Mail list logo
