similar to: "-b --suffix '' --delete --backup-dir /path/" combination does not act as expected

Hi, How about adding now option '--backup-only' that means making backups only and don't change any destination files? (I posted similar patch a month ago, but the patch was made for nightly snapshot of 20020808, which was tooo old! Laugh at me...) I want to use rsync with LVM snapshot to make incremental backups like below: 1) Make LVM snapshot of file system and mount it.

I'm having an issue with the --suffix and -b flags - I've tried the following commands: rsync -avbr --backup-dir=/rsyncbackup rsynctest user@server.com::module rsync -avbr --backup-dir=/rsyncbackup --suffix="" rsynctest user@server.com::module and either way, I wind up with a tilde as a suffix on all the files moved into the backup directory at time of synchronization.

Dear All, I have been seeing some strange behavior using rsync 3.1.1 on OSX with the 3 standard patches applied when using the --backup and --backup-Dir options. This works as expected on 3.0.9, moving any files on dest that are not on source to the backup folder. If no changes then the backup folder is not even created. -aHAXN --fileflags --force-change --protect-decmpfs ?delete --backup

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear list members, there are two new rsync-features I made up and would like to discuss with you. If you think these new features might be useful for the whole rsync-community, please give me a note and I'll send you the patches (or post them here). 1.) Setting owner and/or group of backup files. In our servers I'm using rsync to backup

Hopefully the email to the announce list will show up soon. Until then, you can get a jump on the rest by checking out the rsync home page to read the announcement: http://rsync.samba.org/ It includes a security note about a fix that affects read/write daemons that are not using chroot. If that includes you, you should look into upgrading (or maybe enabling chroot on an older rsync).

Included below is a shar archive containing two patches that together: 1) make backup files get their setuid and setgid bits stripped by default 2) add a "-s" option that allows backup files to continue to have these privileges This means that if you update a collection of binaries with rsync, and one or more of them has a local-root security problem, the backup file(s) created when

I have attached a patch that supports a new "--direct-write" option. The result of using this option is to write directly to the destination files, instead of a temporary file first. The reason this patch is needed is for rsyncing to a device where the device is full or nearly full. Say that I am writing to a device that has 1 Meg free, and a 2 meg file on that device is out of date.

Hi folks, we would like your feedback on a new option we have implemented. We would like to know whether it should be merged into the CVS tree. Perhaps one of the rsync developers can have a look at the code, improve it where necessary, and committ it to CVS. The name of the option is "--delete-mdays=DAYS" and it works in conjunction with the option "--delete." It modifies

https://bugzilla.samba.org/show_bug.cgi?id=7565 Summary: --check-point=<TIME> +options.c.patch +generator.c.patch Product: rsync Version: 3.0.7 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org

Hi All, I think I am missing something with the backup-dir-dels.diff patch. How does that differ from the original --backup -backup-dir=DIR option? Using the original one works fine (on patched or non-patched rsync), putting deleted source files into the DIR on destination, but when I run --backup -backup-dir-dels=DIR, nothing happens to the deleted files. Rob D

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

On Tue, 2018-09-11 at 12:56 -0400, Kevin Korb via rsync wrote: > --timeout is about network connection timeouts. You aren't using the > network so it doesn't apply at all. Even if you were networking an > unmounted filesystem is an empty directory as far as rsync is > concerned > and rsync would treat it that way with no idea that you intended to > have > something

Running rsync 3.0.6 on OS X 10.5.7 (on a MacBook Pro) and using the -b flag (and -v --verbose), the "backup_dir" is reported in the output, but sometimes on STDOUT and sometimes somewhere else. Note that the rsync daemon running on the "server" is 2.6.9 (on another MacBook Pro, OS X 10.5.7) For example, in bash, this happens: axe-MBP:bin work$ /usr/local/bin/rsync

Hi, I have question about the behavior of --backup-dir with --delete-after option. In my testing with version 2.6.4, it appears that the backup option only backups altered files. Files that will be deleted on the destination system will NOT be placed in --backup-dir location. I would like to back up deleted files. Is there a way to do this? Thanks

There is a small race condition in rsync 2.5.6. When the transfer is finished, and the file is moved into place, there is a short time period where the new file is in place with the wrong permissions. When using rsync on a busy email server to replace the exim config file with a new file, exim will produce several complaints in that short period. This small patch fixes the problem, by making

I have a script that runs nightly as a cronjob to backup my drive to a USB drive https://pastebin.com/yivqrGUC On the command line I use the --timeout option. Is this sufficient to ensure that if the external drive somehow becomes unmounted that rsync will gracefully fail without trying to write to the hard drive instead of the USB drive? rsync -vaWSHpl --timeout=15 --delete-excluded --filter

Dear collegaues, please evaluate the patch attached, which allow to use both --detect-renamed and --fileflags extra features. This is meta-patch which sould be applied to detect-renamed. fileflags patch should be applied first, following by the modified detect-renamed patch. It is included in current FreeBSD port, but it seems it would be much more useful to be supported by samba

I am having a problem using the backup_dir option of rsync. The command being used is basically rsync --archive --delete --backup --backup_dir=PathToBackup/save user@fromsystem:FilePath/ PathToBackup/ The feature that is unique to this problem is that the "save" directory is under the path where the files are being backed up. Fortunately, rsync is clever enough to not delete

I''ve begun using Hiera in combination with Foreman, primarily storing data that is best left in Array/Hash form. I''d like to be able to have a module, in this case BackupPC, query all the Hiera data for each node where the backup directories/databases are stored. Then use all that information on the BackupPC server to generate proper configuration files for each

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I restored a filesystem by using rsync to copy directories and files from a backup volume to the newly recreated volume. All of the re-created files were given the current date and time rather than the original file's timestamp. I am sure there was a way to prevent that from happening. Is there a way to use rsync to set the timestamps