On 07/01/2011 17:00, Blake Dunlap wrote:
On Fri, Jan 7, 2011 at 06:30, Mister IT Guru <misteritg...@gmx.com
<mailto:misteritg...@gmx.com>> wrote:
On 07/01/2011 12:23, James Harper wrote:
>>> Suggestion:
>>>
>>> Schedule the day's Incremental, then schedule the VirtualFull,
say,
> 30
>>> minutes later.
>>>
>>> Put a RunBeforeJob script on the incremental that creates a
lockfile
> (in
>>> a properly race-safe manner, of course) for the client.
>>>
>>> Put a RunAfterJob script on the incremental that removes the
> lockfile.
>>> Put a RunBeforeJob script on the VirtualFull job that checks for
>>> presence of the client's lockfile, and, if it finds it still
> present,
>>> sleeps for five minutes before checking again, and does not return
> until
>>> the lockfile has been gone for two consecutive checks (thus making
>>> certain there is a minimum of five minutes for attribute metadata
> from
>>> the job to be flushed).
>>>
>>>
>> Brilliant - sounds workable, I just don't know if my bacula
skills are
>> up to it, I'm still very fresh to it, but the theory of your
> suggestion
>> is the closest I guess we can come. I will look into in - Thank you
>> bacula list :)
> I'm not completely sure, but I think that Bacula figures out
what media
> it is going to use before it calls RunBeforeJob. This would mean
that if
> you schedule your VirtualFull while your Incremental is running, the
> VirtualFull will not include the Incremental backup, no matter
how much
> you wait inside the VirtualFull's RunBeforeJob script.
>
> Does anyone know for sure?
>
> James
I'm thinking that a workaround for this would be a script that
checks if
the previous incremental has finished, and if it hasn't exit the job,
and then schedule a new job for $timenow+30mins. And then in 30 mins,
it'll check again. That way, no overlap"
What I just said works on paper, but may not be able to actually
run in
bacula, I say that because google will index this msg and people
may not
read the whole thread when they find this:)
I have a specific perl script that runs, and fires off the top x (in
our case 3) vfulls each morning queued to run, based on what
incrementals are seen running successfully the night before, and has
had no fulls within x (in my case 90) days.
We did this because of the poor scheduling capability of bacula, and
the desire to have constant aniversary based backups, instead of any
kind of set "weekend full" backup schedule, which would be impossible
to complete in a window.
I am happy to post if anyone wants.
-Blake
I wouldn't mind taking a look at that script Blake, and I;m pretty sure
some of the guys adn girls that have contributed to this thread would
also like to take a peek :)
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
