On Sun, 12 Feb 2006 16:18:01 -0500, Brian A. Seklecki [EMAIL
PROTECTED] said:
On Thu, 2006-02-09 at 22:10 +0100, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
=20
In many cases (i.e. when, during the mv operation, to time stamp of the=
=20
testfile inode was
Martin Simmons wrote:
On Sun, 12 Feb 2006 16:18:01 -0500, Brian A. Seklecki [EMAIL
PROTECTED] said:
How often does the Director poll the system date time? How often does
the Storage director? I don't see any options in the config to control
this. Specifically, for periodic maintenance like
{Increm/Diferer}ential to Full...
How often does the Director poll the system date time? How often does
the Storage director? I don't see any options in the config to control
this. Specifically, for periodic maintenance like
recycling/pruning/volume status flagging.
AFAIK, these
On Wed, 2006-02-08 at 09:02 +0100, Arno Lehmann wrote:
Hello,
On 2/8/2006 6:54 AM, Brian A. Seklecki wrote:
Is there any built-in mechanism to test Schedule {} planning? I need to
verify the behavior will work as expected.
If you trust Bacula itself, use the show job=xxx command. Part
On Thu, 2006-02-09 at 22:10 +0100, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
In many cases (i.e. when, during the mv operation, to time stamp of the
testfile inode was modified) /dir1/testfile will not be stored because
it's not recognized as new - it's time stamps
On Wed, 2006-02-08 at 20:30 +0100, Arno Lehmann wrote:
Hi,
On a related note, if you're consistently bumping the clock around on
your test platform (where DIR and SD are) using date(8) to simulate
catching scheduled jobs, and your FD is not localhost but somewhere
else where the clock is
Hello,
On 2/9/2006 10:10 AM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
uses the unix time stamps to determine which files to store - together
with mv'in files to different directories this can become a problem!
You scare me. What sort of problem? Moving or renaming
In message [EMAIL PROTECTED] you wrote:
In many cases (i.e. when, during the mv operation, to time stamp of the
testfile inode was modified) /dir1/testfile will not be stored because
it's not recognized as new - it's time stamps are older than the last
full backup.
RGHHH It was
Hi,
On 2/9/2006 10:10 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
In many cases (i.e. when, during the mv operation, to time stamp of the
testfile inode was modified) /dir1/testfile will not be stored because
it's not recognized as new - it's time stamps are older than
On Feb 9, 2006, at 1:10 PM, Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
In many cases (i.e. when, during the mv operation, to time stamp
of the
testfile inode was modified) /dir1/testfile will not be stored
because
it's not recognized as new - it's time stamps are older
Bumping the clock around on the machine seems reasonable, but ugly.
File system activity can also be scripted outside of the system.
Somehow I don't understand what file system activity has to do with the
schedules...
I guess I need to test more than just the schedule. I need to
Is there any built-in mechanism to test Schedule {} planning? I need to
verify the behavior will work as expected.
Bumping the clock around on the machine seems reasonable, but ugly.
File system activity can also be scripted outside of the system.
TIA,
~lava
12 matches
Mail list logo
