similar to: Verifying backups

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First off, --fileflags --force-change are not in my man rsync so I don't know what those are. Second, you should look into using either ZFS subvolume snapshots or rsync --link-dest to maintain multiple backups. Now, for your actual question... Add --itemize-changes to your standard command line. -v is almost entirely useless without it anyway.

In message <560C4A51.4040702 at sanitarium.net>, Kevin Korb <kmk at sanitarium.net> wrote: >First off, --fileflags --force-change are not in my man rsync so I >don't know what those are. These are probably (Free)BSD specific. Here's what the man page says: --fileflags preserve file-flags (aka chflags) --force-change affect user/system immutable

Kevin Korb <kmk at sanitarium.net>, I thank you greatly for your attempts to educate me, however as we get deeper into discussing more and more different rsync options, I feel that I am actually just getting more confused and frustrated. I've been sitting here, trying all sorts of different combinations and permutations of the various options we've discussed, and that you've

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, when it comes to local copies cp is significantly faster than rsync. Without --link-dest there isn't much advantage to using rsync for backups. The only thing you get beyond cp -au is --delete. Also, when it comes to static data like media files I like to keep an md5 file around with checksums for all the files. That way I can easily

Just chiming in slightly off topic. As a first step if you are going to be backing up files to some media with a computer it would be a really good idea to ensure, that the hardware being used is not faulty. I am not saying that your hardware is faulty. However, it would be worth checking this somehow. Check the drive media for bad blocks, check that all the cables are working well. Ensure the

In message <560C660F.5000202 at sanitarium.net>, Kevin Korb <kmk at sanitarium.net> wrote: >Just add --itemize-changes and --checksum to what you were doing >before and know that it will take a long time. I'm still not getting to where I need to be. Maybe you can explain what has gone wrong in this very simple example: % mkdir one two % echo hello > one/hello % ln

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 reply inline... On 09/30/2015 05:18 PM, Ronald F. Guilmette wrote: > > In message <560C4A51.4040702 at sanitarium.net>, Kevin Korb > <kmk at sanitarium.net> wrote: > >> First off, --fileflags --force-change are not in my man rsync so >> I don't know what those are. > > These are probably (Free)BSD

In message <560C79FF.5010302 at sanitarium.net>, Kevin Korb <kmk at sanitarium.net> wrote: >Because you are making two/one. Change to: >rsync -n -v --itemize-changes -checksum -a one/ two/ OK, I tried it with your suggested command line, and yes, that produces rather more substantially useful results. However... Perhaps I am just a bit thick, but I really don't have any

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just add --itemize-changes and --checksum to what you were doing before and know that it will take a long time. On 09/30/2015 06:42 PM, Ronald F. Guilmette wrote: > > Kevin Korb <kmk at sanitarium.net>, > > I thank you greatly for your attempts to educate me, however as we > get deeper into discussing more and more different

Hi *, it seems rsync with --fileflags isn't able to work on (already) hardlinked and immutable ("schg") files on FreeBSD. The following scripts will create a simple example for this behaviour: -------------------------------------------------------------- #! /bin/sh # # set -x DIR="/var/tmp/rsync_$(date +%s)/" mkdir "${DIR}/" # Preparing dir_A mkdir

Ok, thank you for this extra info. I have experienced exactly what you described. The rsync dry run is _still_ running after being started at 1:30am PST :) But it is finding the right files to update. Most of the entries are: >fc........ Which is what I want. So, just because I see: >f at the beginning... That doesn't necessarily mean that the file is going to get updated at the

Hello. Does rsync verify its writes? Re, 'info rsync'. Maybe I just being stupid, but there's no mention of verification in the 'DESCRIPTION' section, so despite the words in the 'OPTIONS' section, '-c, --checksum' topic (which I may be misinterpreting), I assume rsync does not verify except for the checksum directive. I admit that I'm paranoid. ;-)

What about -c? It seems I'm getting a lot of spurious file transfer candidates when using: -avvznIi --no-o --no-g --no-p It's showing transfers (receive) for many files I know haven't been tampered with. Thanks, -Clint On Tue, Oct 27, 2015 at 7:53 PM, Kevin Korb <kmk at sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > That is correct.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Normally, I would say that --checksum is actually slower than just letting rsync re-copy everything and therefore is almost always the wrong thing to do. However, in this case, you really don't want to overwrite the running OS even with files that are essentially the same. So, if the system is running from that storage then --checksum might

https://bugzilla.samba.org/show_bug.cgi?id=13423 Bug ID: 13423 Summary: Checksum option does not work as expected when append-verify is used Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

Before anyone yells at me, yes, you can use rsync's --checksum to detect (and fix) files that are incorrect despite having correct timestamps and sizes. This would mean that a previous rsync had been corrupted not the current one. But it is important to note that this would only be reported to you if you also use --itemize-changes and what to look for (a file with a c but not an s or a t).

> You are missing the point of the checksum. It is a verification that > the file was assembled on the target system correctly. The only > post-transfer checksum that would make any sense locally would be to > make sure that the disk stored the file correctly which would require > a flushing of the cache and a re-reading of the file. Rsync has no > capability to do this

Hi I am using "rsync" to send files from a source machine to a remote machine as one typically does. I would like to clarify that the "-c" option will cause the checksum on the receiving end to be created by reading the already written file and NOT the data stream on the receiving end. This would help in catching disk I/O errors if the checksum is done on the file on disk.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, even if bandwidth is your concern I would say that --checksum is wrong. Maybe if bandwidth is so scarse that a few KB vs a few MB equates to dollars then sure, use --checksum. Otherwise, letting rsync re-delta-xfer everything is certainly faster and not much more bandwidth intensive than --checksum. Plus that is only if you screwed up and ran

I chose rsync over diff -r because diff -r is a binary comparison and it takes longer than creating a checksum. Isn't that correct? I did not understand this: > Rsync isn't even smart enough to not bother checksumming things that don't even have a comparison file. --checksum seems to work as you say even in --dry-run mode. At least it takes a lot of time, which should be a good