similar to: Skip creating files in --backup-dir if content has not changed

On Fri, 17 Apr 2015 23:45:42 -0400, Kevin Korb wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So, I am assuming that without --itemize-changes you couldn't tell the > difference between "I am transferring a file" and "I am fixing the > timestamp on a file". > > Even if I am right, you are probably still mis-using --checksum. When

Hi, I'm having trouble with --compare-dest, to copy only files that differ in content. Here are the commands used thusfar: rsync -av --checksum --delete --progress --stats --compare-dest=../old new/ new_archive rsync -av --checksum --delete --progress --stats --compare-dest=../new old/ old_archive old/ a.txt new/ a.txt Note: both a.txt are the same (except for a different

Hi, we had the same problems last year and we use NTFS. Luckely we switched to Linux this year. Kind regards, Bart Coninckx Network Administrator CNE, ASE ************************************* Sita ICT Services Lilsedijk 19 B-2340 Beerse Belgium e-mail: bart.coninckx@sita.be Tel: + 32 (0) 14 62 28 22 Fax: + 32 (0) 14 62 41 47 *************************************

On Fri, 17 Apr 2015 21:27:56 -0400, Kevin Korb wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Any time rsync wants to do something to a file you don't think it should > be see what --itemize-changes says about it. In fact, -v is almost > entirely useless without --itemize-changes. In fact, if I was in charge > I would make -v include --itemize-changes.

Hi, I am running rsync backup on Centos 6, the following command does not seem work, the /backup/fll_copy was fine, but the /backup/Wednesday in the remote machine was not created even I changed the source contents several times. rsync -e "ssh -q -o StrictHostKeyChecking=no" --backup --backup-dir=username at ipaddress:/backup/$(date +%A) -av $SRC username at

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

Hello, I have a weird issue with rsync randomly marking some files as having a different checksum (see sample outputs below - run one after another). You would think it is some kind of corruption / io problem with the files but it doesn't seem so - I have copied files around, changes source to different machines, counted md5s manually 100s of times - always the same. All files except

Dear all is it possible to rsync in a master-slave scenario saving to slave gzip content? i'm not talking about compression during transfer, i'm talking about -saving- the destination in a compressed format. Example: FROM: -folder_A --file_A --file_B TO: -folder_A --file_A.gz --file_B.gz I know that this won't be a "real" rsync between two folder, but it will be an

Hello I am setting up a central data repository for my team (several thousands of files, totaling about 4TB). There are multiple sources that I need to consolidate: a source may have a fraction of the total number of file, and there can be conflicts between different sources (that should be very occasional though). I want to detect those conflicts and manually merge them. Also, the

Hello. I would like to transfer files which have changed on another box. The rsync man page says: --size-only ..This is useful when starting to use rsync after using another mirroring system which may not preserve timestamps exactly.. Which is my situation. My problem is that the size-only switch (clearly) ignores files with different content, but that have the same size. I'd like to

Hi, I am runing rsync --backup --backup-dir=$BACKUPDIR where the BACKUPDIR=$(date +%d) to recycle the $BACKUPDIR in a month. But rsync does not clean the $BACKUPDIR before writing to it in cycling. I guess you have to clean it manually before the rsync can write to it. As my $BACKUPDIR is in remote machine, do you have to run ssh to delete it first before calling rsync in a script? Or if there

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.

I use --filter='dir-merge .backup-filter" to allow my users to designate portions of their home directories that should be excluded from my rsync-based backup system. I'm looking for a way to periodically generate a report that shows the amount of backup space being used by each user. I've tinkered with writing my own script that processes any filter files into --exclude

Hi Kevin, Thank you very much for the response. Actually, I don't think I need to clean the backup dir defined in --backup-dir=<backup dir>, when the contents has already been deleted in the destination (no exist), it will delete from the backup dir as well in next cycle, correct? Regards, - j On Thu, Feb 4, 2016 at 12:39 PM, Kevin Korb <kmk at sanitarium.net> wrote: >

How do I minimize the amount of disk activity? I'm copying a large number of files: rsync -av -W /from/here/. /to/here/. I'm using rsync because I need the incremental updates and other features. Otherwise, I'd use tar piped to tar or some similar technique. Note: Both the source and destination are "local". Well, not really. The source is a network-mounted partition

Hi all, I've a local repository for Debian, and I'm doing some rsync testings on it. See the following commands for detail: werner at debian:~/software/LocalRepo$ rsync -amvHKLPRSB131072 -n \ ftp.uk.debian.org::debian/./dists/wheezy-updates/main/\ debian-installer/binary-amd64/Packages.gz \ repo.debian.local/debian/ [snip]

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

I am working with rsync on Debian, package version 3.0.9-1. I am trying to use rsync --compare-dest to make a delta-copy of a directory. In my case, the mtimes are all unreliable. The data is the same, but the times are all messed up and always will be. I am trying to use --compare-dest with --checksum or --size-only and it does not work. All files are transferred and the delta copy

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I still don't see an output from rsync --itemize-changes with an A/B difference. On 04/18/2015 12:15 AM, Hongyi Zhao wrote: > On Fri, 17 Apr 2015 23:45:42 -0400, Kevin Korb wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> So, I am assuming that without --itemize-changes you couldn't >> tell the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, I am assuming that without --itemize-changes you couldn't tell the difference between "I am transferring a file" and "I am fixing the timestamp on a file". Even if I am right, you are probably still mis-using --checksum. When you use --checksum you force a checksumming of absolutely everything on both ends before anything