1 |
On Wed, 2010-05-05 at 18:35 +0100, Stroller wrote: |
2 |
> On 5 May 2010, at 18:24, Florian Philipp wrote: |
3 |
> >> ... |
4 |
> >> man inotify(7): |
5 |
> >> ... When a directory is monitored, inotify will return events for the |
6 |
> >> directory itself, and for files inside the directory. |
7 |
> >> ... |
8 |
> > |
9 |
> > To repeat my comment on Iain's original "backup to a cold-swap drive" |
10 |
> > thread ... |
11 |
> |
12 |
> Sorry, I started ignoring that almost immediately it was posted. |
13 |
|
14 |
ooohh, ouch! :) |
15 |
|
16 |
> He |
17 |
> rejected too quickly too many workable solutions to basically |
18 |
> functional backup. Perhaps Iain is a perfectionist, but I did not wish |
19 |
> to follow the thread. |
20 |
|
21 |
Perhaps I am a bit of a perfectionist, but I think you misunderstood my |
22 |
aim. I rejected 3 options straight away (dd, gparted, and Ghost4Linux) |
23 |
because they're not designed for backing up a live filesystem in a |
24 |
"change only" fashion ("intelligent" is the word I used). |
25 |
|
26 |
Beyond that I didn't reject anything else that anyone mentioned. |
27 |
|
28 |
> > ... Inotify has two drawbacks which make it hard or even impossible |
29 |
> > to use for Iain's use case: |
30 |
> > |
31 |
> > a) It does not work recursively which means that you have to create a |
32 |
> > new handle for each subdirectory. Of course, this only means more work |
33 |
> > for the programmer but there is also the problem that |
34 |
> |
35 |
> Pardon me. I assumed that "files inside the directory" meant that foo |
36 |
> would be be changed when foo/bar changed, thus monitoring grunt would |
37 |
> reflect changes in grunt/foo/bar. I overlooked that a directory is not |
38 |
> a file. |
39 |
|
40 |
isn't it? I thought a directory was just a file containing names (or |
41 |
inodes) of other files? Which would explain why monitoring grunt |
42 |
wouldn't show changes in grunt/foo/bar, since the directory/file called |
43 |
grunt remains the same (ie. contains the same list of inodes) even if |
44 |
grunt/foo/bar changes. |
45 |
|
46 |
Let me tell you what I actually want to do, which I may not have made |
47 |
clear originally: |
48 |
|
49 |
I want to backup root to an external drive (or that could be rephrased |
50 |
as "I want to backup any mount to any other mount), such that: |
51 |
1. My backup is an hour or so out of date (at most) |
52 |
2. I don't need to copy the entire filesystem every time |
53 |
|
54 |
To do that, I could either: |
55 |
* Run rsync every hour over the entire filesystem (I'm doing this |
56 |
now with ionice, takes about 10 minutes when there are no |
57 |
changes) |
58 |
* Use some file notification monitor to tell me which file was |
59 |
just changed, and only rsync that file |
60 |
|
61 |
The problems with rsync is that during the rsync process, the filesystem |
62 |
is changing, so I will end up with a slightly inconsistent backup. If I |
63 |
use some notification method that tells me a file has changed, I can |
64 |
greatly reduce any inconsistency, and I reduce my hour down to seconds |
65 |
or minutes, depending on how much changes at any one time. |
66 |
|
67 |
I'm considering LVM for it's snapshot capability, but I'd still have to |
68 |
rsync root. I would prefer a file notification method as well, so I can |
69 |
just rsync the file that just changed. |
70 |
|
71 |
So far all the file monitoring tools are based on individual files (even |
72 |
the recursive ones), and you eventually reach a system limit. |
73 |
|
74 |
Thanks, and willing to listen to any ideas from anyone (except |
75 |
Stroller :p ) |
76 |
|
77 |
-- |
78 |
Iain Buchanan <iaindb at netspace dot net dot au> |
79 |
|
80 |
Usually, when a lot of men get together, it's called a war. |
81 |
-- Mel Brooks, "The Listener" |