 |
I wonder if this is a smart and scalable option. Inotify (and others on other platforms Solaris also has something which is more or less the same as inotify on Linux) have some severe limitations which are: Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be created. This can take a significant amount time for large directory trees. The inotify API provides no information about the user or process that triggered the inotify event. In particular, there is no easy way for a process that is monitoring events via inotify to distinguish events that it triggers itself from those that are triggered by other processes. Note that the event queue can overflow. In this case, events are lost. Robust applications should handle the possibility of lost events gracefully. The inotify API identifies affected files by filename. However, by the time an application processes an inotify event, the filename may already have been deleted or renamed. If monitoring an entire directory subtree, and a new subdirectory is created in that tree, be aware that by the time you create a watch for the new subdirectory, new files may already have been created in the subdirectory. Therefore, you may want to scan the contents of the subdirectory immediately after adding the watch. So this means that to be suitable you need to put inotify watches on the whole backup tree (at least for all directories) which means a serious amount of memory. |
|
|
Philipp: make some tests, use recursive scripting to scan directory trees. Marco: implement as plugin. |
|
|
At least on Windows the information we are looking for should be already available in the NTFS change journal: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363798%28v=vs.85%29.aspx Limitations: - Only on NTFS - If to many changes the journal will roll-over - All changes will be recorded |
|
|
For Solaris there is ZFS diff which also allows you to see what changed since a certain snapshot. Given the wide differences between this interfaces this seems to be a good candidate for a FD plugin as there are already hooks for saying what to backup (e.g. this is used by the Bacula Systems NetAPP accelerator) |
|
|
Mass closing oldies which doesn't get any attention. |
- Anonymous
