On Tue, 22 Nov 2005, Keith Edmunds wrote:
I see this as down to the system administrator to manage, and much easier
too. For example, suppose I have two backup jobs, one backing up user xxx and
a second backing up user yyy. Those two backup jobs might writing,
respectively, to:
/backups/home/xxx/...
/backups/home/yyy...
That won't cause a problem at all. Now suppose on your system you backup the
whole of /home. A second invocation is started, so at one point there are two
rdiff-backup processes, and they are writing to the directories shown above.
How should rdiff-backup decide that the former pair of processes are safe to
run, but the latter pair are not? Yes, it can be done by parsing command
lines of other processes - but even that may not be possible if each of user
xxx and yyy are running the backup process under their own UIDs.
Actually, one could use some kind of locking mechanism, since the
directory being written to by rdiff-backup is well-defined by the
existence of the rdiff-backup-data directory at the top level.
This is hardly an ideal solution though, since one problem with locking is
guaranteeing that it be released correctly.
What I do:
#!/bin/bash
# Start of script
ACTIVE_FLAG=/var/run/backup_in_progress
[ -e $ACTIVE_FLAG] && exit 1 || touch $ACTIVE_FLAG
.
.
# End of script
rm $ACTIVE_FLAG
Actually it's a little more sophisticated than that, but you get the idea.
Yes, fair enough. I'm doing something similar in concept, but using mounts
of LVM volumes instead. The trouble with what you are doing it that if the
script exits unexpectedly, the ACTIVE_FLAG file might still remain, no?
I was just wondering if this issue had been considered, and what the
concensus thinking about it was.
Thanks for your comments.
Faheem.
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
