On Fri, 2010-04-30 at 16:24 +0200, Florian Philipp wrote: > Am 29.04.2010 02:38, schrieb Iain Buchanan: > > Hi & thanks, > > > > On Wed, 2010-04-28 at 17:31 +0200, Florian Philipp wrote: > [...] > > > >> If you can live with just one big partition as a backup (probably with > >> separate /boot), you should replace fstab and grub.conf on the backup > >> medium and blacklist them from the files which you want to back up. > > > > why wouldn't I backup fstab and grub.conf as well? If my internal disk > > dies, I assume I'll swap them over, meaning grub and fstab will have to > > be the same. > > I think you misunderstood me or I didn't explain it correctly. I try it > again:
[snip] ah, NOW I get it :) [snip] > Ah, I see what you mean. I've never worked with the file alteration > monitor (FAM) but once evaluated inotify for some administrative > purposes. AFAIK they are not scalable good enough to work on a system > wide basis. For example, I think the default limit of observable files > with inotify is 8192. hm, there goes that idea! Is there any kernel based "watch" on all file based I/O that I could queue up somehow? Just thinking aloud here. I know "everything is a file", but no doubt I could watch all write operations; filter out /dev and put the rest into a file; and then use it like an rsync file-list... > > thanks for the tips :) rsync will at least get me going quickly. > > Yesterday I tried iotop to with dd - some slowness but otherwise quite > > nice. > > > > To reduce the performance impact, you can also use the ionice command. whoops, that's what I meant. Even with ionice, there was some noticeable delay when switching screens, opening programs, etc. More so when my RAM had been swapped from the large amount of I/O (I assume). I didn't try ionice with nice. thanks, -- Iain Buchanan <iaindb at netspace dot net dot au> One family builds a wall, two families enjoy it.
