Martijn (and others),
This sounds like just what I want. I'll give it a whirl.
I understand the options with regards to user priority and schedules,
but I think having the client completely inactivated during experiments
will be the most effective (and most popular with the end users involved).
Background:
A lot of our backup clients are computers that get used for data
acquisition. Data acquisition can be adversely affected when Retrospect
starts reading a lot of data off the hard drive ;-)
The users generally know when the backups are coming, but they don't
always remember. I'd like
The users generally know when the backups are coming, but they don't
always remember. I'd like to give them a way to automatically script
turning the Retrospect client off at the beginning of an experiment, and
to turn it back on at the end (or, more likely, at the next reboot).
It is possible
The users generally know when the backups are coming, but they don't
always remember. I'd like to give them a way to automatically script
turning the Retrospect client off at the beginning of an experiment, and
to turn it back on at the end (or, more likely, at the next reboot).
It is possible
I'd like to give them a way to automatically script
turning the Retrospect client off at the beginning of an experiment, and
to turn it back on at the end (or, more likely, at the next reboot).
The issue is probably the performance hit when the backup is running,
rather than simultaneous access
