On Mon, 13 Jul 2015 02:19:23 +, 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
Andrew Gideon wrote:
> These both bring me to the idea of using some file system auditing
> mechanism to drive - perhaps with an --include-from or --files-from -
> what rsync moves.
>
> Where I get stuck is that I cannot envision how I can provide rsync with
> a limited list of files to move
inotifywatch or equiv, there's FSM stuff (filesystem monitor) as well.
constantData had a product we used years ago - a kernel module that dumped
out a list of any changed files out some /proc or /dev/* device and they
had a whole toolset that ate the list (into some db) and played it out
as it co
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 rsy
Andrew Gideon wrote:
> However, you've made be a little
> apprehensive about storebackup. I like the lack of a need for a "restore
> tool". This permits all the standard UNIX tools to be applied to
> whatever I might want to do over the backup, which is often *very*
> convenient.
Well if y
On Mon, Jul 13, 2015 at 5:19 PM, Simon Hobson
wrote:
> > What's needed is a file system that can do what hard links do, but at the
> > file page level. I imagine that this would work using the same Copy On
> > Write logic used in managing memory pages after a fork().
>
> Well some (all ?) enterp
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 large file. Rsync is smart about
> moving minimal data, but it still stores an entire new copy of the file.
>
> What's needed is a file sy
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 sometime
Ken Chase wrote:
> And what's performance like? I've heard lots of COW systems performance
> drops through the floor when there's many snapshots.
For BTRFS I'd suspect the performance penalty to be fairly small. Snapshots can
be done in different ways, and the way BTRFS and (I think) ZFS do it
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 th
Andrew Gideon 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 ta
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
yeah, i read somewhere that zfs DOES have separate tuning for metadata
and data cache, but i need to read up on that more.
as for heavy block duplication: daily backups of the whole system = alot of
dupe.
/kc
On Thu, Jul 16, 2015 at 05:42:32PM +, Andrew Gideon said:
>On Mon, 13 Jul 201
13 matches
Mail list logo
