similar to: LVM snapshots vs. --link-dest

On Tue, 14 Jul 2015 08:59:25 +0200, Paul Slootman wrote: > btrfs has support for this: you make a backup, then create a btrfs > snapshot of the filesystem (or directory), then the next time you make a > new backup with rsync, use --inplace so that just changed parts of the > file are written to the same blocks and btrfs will take care of the > copy-on-write part. That's

On Mon, 13 Jul 2015 15:40:51 +0100, Simon Hobson wrote: > The think here is that you are into "backup" tools rather than the > general purpose tool that rsync is intended to be. Yes, that is true. Rsync serves so well as a core component to backup, I can be blind about "something other than rsync". I'll look at the tools you suggest. However, you've made be

Hi. This is bug report and simultaneously urgent asking for help. I am trying to write my rsync wrapper script, which will create minutely snapshots of my data using --link-dest. I want this script to be robust, it should work even if I do suspend/hibernate/reboot without notifying the script about this actions, it should work if I make hard-reset of the computer and if I disconnect network. Also

On Mon, 13 Jul 2015 02:19:23 +0000, Andrew Gideon wrote: > Look at tools like inotifywait, auditd, or kfsmd to see what's easily > available to you and what best fits your needs. > > [Though I'd also be surprised if nobody has fed audit information into > rsync before; your need doesn't seem all that unusual given ever-growing > disk storage.] I wanted to take this

>- --inplace and --append-verify are essentially irrelevant when >- --link-dest is in play. With --link-dest in play the target system >must write an entirely new file even for a change in permissions or >timestamps so any potential benefit by these options are out the >window from the start. The only thing they can do is add the >possibility of incomplete or corrupt copies on

And what's performance like? I've heard lots of COW systems performance drops through the floor when there's many snapshots. /kc On Tue, Jul 14, 2015 at 08:59:25AM +0200, Paul Slootman said: >On Mon 13 Jul 2015, Andrew Gideon wrote: >> >> On the other hand, I do confess that I am sometimes miffed at the waste >> involved in a small change to a very

I don't specify --partial-dir. As you can see from the script, rsync at first copies to "in-progress", and then renames this to (for example) 2014-12-01-000000. So, if rsync interrupts, then at the next run the script will end "in-progress" (all partial files will be done) and then will rename this dir to 2014-12-01-000000. So, there never will be partial files in finished

https://bugzilla.samba.org/show_bug.cgi?id=4079 Summary: rsync fails with --inplace, --link-dest and --no-whole- file Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: major Priority: P3 Component: core AssignedTo: wayned@samba.org

Ok, thanks. I removed --inplace and --append-verify and kept --link-dest and --partial. And now the script works exactly as I want: hard-links are not updated, the script is still robust and can copy large files over unstable links etc, etc. == Askar Safin http://vk.com/safinaskar Kazan, Russia

I've identified a situation where the combination of --fuzzy --fuzzy (yes: two of them) and --link-dest is not behaving as I'd expect. I'm first wondering if my expectation is wrong. Assuming that it is not, then I'm wondering how best to figure out the problem. The double use of --fuzzy is based upon https://bugzilla.samba.org/ show_bug.cgi?id=4056 which should be present on

Hello, This is my first post to the list. Is it possible to specify the --link-dest option server-side in the rsyncd.conf file? What I'd like to do is implement incremental snapshot backups without having to change the clients which all just do regular dumps to the rsync server. I'd like to specifiy this option on the server rather than on the client because I don't want to

>BTW, if you want it to always have that behavior (it can save a lot of >backup space) you can use the old cp -al method instead of --link-dest >so that the target dir starts out completely populated. You mean making "cp -al" on the remote and then start rsync to newly created dir with --partial and without --link-dest, --inplace, --append-verify? What is benefits? Even metadata

I'm using the -A patch on v2.6.2, and I'm doing the usual "incremental backup using links" thing.??The?destination?is?a?machine?running?Fedora? (both 2 and 3), and the sources are machines running various Linuxes and Solaris. During my initial testing, I found a lot of diskspace being wasted.??I? traced this back to files being copied when a link would suffice.??I?found? that

On Mon, 13 Jul 2015 17:38:35 -0400, Selva Nair wrote: > As with any dedup solution, performance does take a hit and its often > not worth it unless you have a lot of duplication in the data. This is so only in some volumes in our case, but it appears that zfs permits this to be enabled/disabled on a per-volume basis. That would work for us. Is there a way to save cycles by offering zfs

Hello, I am trying to use ACL and link-dest without success. Here is what I do. First step, without ACL : rsync -ai --link-dest=<date_folder_1> --link-dest=<date_folder_2> /sourcedir myserver::backup/$(date)/ All works fine there, my files are hard linked together, "ls -li" on myserver confirms. Second step, adding ACL : rsync -aiA --link-dest=<date_folder_1>

This is OK for me. I care about file contents, not metadata. == Askar Safin http://vk.com/safinaskar Kazan, Russia

No. Now there is no --inplace. So, rsync will never write new file directly into old one (without unlinking). If there already is old file and it needs updating, then rsync will write into something like .file-He4gw, and then it will rename this file to its right name. This new file will not have any hardlinks to old files == Askar Safin http://vk.com/safinaskar Kazan, Russia

https://bugzilla.samba.org/show_bug.cgi?id=5201 Summary: Rsync lets user corrupt dest by applying non-inplace batch in inplace mode Product: rsync Version: 3.0.0 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=3693 Summary: rsync can use same --link-dest file several times, leading to incorrect hard links Product: rsync Version: 2.6.8 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

https://bugzilla.samba.org/show_bug.cgi?id=7368 Summary: Support --link-dest when receiving from a old version Product: rsync Version: 3.0.7 Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: