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

In message <560CE706.303 at sanitarium.net>, Kevin Korb <kmk at sanitarium.net> wrote: >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. I just now remembered the (forehead slap) bloody obvious reason I decided to use

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

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.

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

Hello All, I have lately heard from a couple of people that delete option was not deleting extraneous files on destination. This only happens when there are several source directories and at destination some show delete working and others not. I can not reproduce the issue so it is hard to pinpoint. one example: This is on OSX Mavericks running rsync 3.0.9 with the usual osx patches and

Hi, I've configured 'backuppc' to transfer files via rsyncd, with enabled checksums. Whith one of the shares I get the error (in syslog): --------------------------------------------------------------------- robbe rsyncd[2183]: ERROR: out of memory in receive_sums [sender] robbe rsyncd[2183]: rsync error: error allocating core memory buffers (code 22) at util2.c(106)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remove the -n and look at the results. You would be copying the one dir into the two dir instead of copying the contents of the one dir into the two dir. On 09/30/2015 08:28 PM, Ronald F. Guilmette wrote: > > In message <560C79FF.5010302 at sanitarium.net>, Kevin Korb > <kmk at sanitarium.net> wrote: > >> Because you

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. ;-)

Dear rsync users, I'm trying to copy my Time Machine Backup from my old USB hard drive to a new one. I got error messages, because rsync don't create group and other permissions. I use rsync 3.1.3. Did I use the correct parameters? Who has an idea, what mistake? Thanks! Best, André -- The bash script: #!/bin/bash source=/Volumes/LaCie\ d2\ Quadra\ v3/Backups.backupdb

-----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