Jason Dixon wrote:
> On Thu, Mar 19, 2009 at 06:08:23PM -0700, Kevin Keane wrote:
>
>> Jason Dixon wrote:
>>
>>> I've tried that. But since the scheduled OS backup jobs are already
>>> running, the client-initiated transaction log jobs are forced to wait.
>>>
>>>
>> Then you probaby still had a Maximum Concurrent Jobs = 1 setting somewhere.
>>
>
> The only place I have "Maximum Concurrent Jobs = 1" are for the OS
> backups. The database and transaction log jobs all use "Maximum
> Concurrent Jobs = 10".
>
As long as they both go to the same storage, that one single Maximum
Concurrent Jobs will block the other backups.
>> What I am thinking is that if the transaction log only needs to be kept
>> for 24 hours (since the last full backup), you might be able - and
>> better off - storing it on a hard disk rather than a tape in the first
>> place. Preferably of course a separate hard disk.
>>
>
> We run full backups every day of the database. Mind you, these are
> backups of a slave replication PostgreSQL database. There are multiple
> layers of redundancy and recovery.
>
>
>>> I've been unable to get Migration working as intended. I've posted
>>> previously about that but never got a working conclusion.
>>>
>>>
>> I'm not talking about migration. Spooling is a pretty low-level feature;
>> it's in the original job itself. Basically, instead of writing the data
>> from a job straight to the tape, bacula creates a file, stores the data
>> there, and then as soon as the tape becomes available copies it to the tape.
>>
>
> One of the requirements dictated to me is that these logs are saved to
> tape immediately. Spooling or queueing to disk is not a viable option
> for this application (in management's eyes).
>
Oh, the pesky little thing of "requirement". Been there, done that (of
course, we all have).
> Thank you for your feedback thus far. But please understand that my
> role within the scope of this task is that of the implementor of these
> requirements. I'd like to complete this as painlessly and "correctly"
> within the parameters defined.
Been there, done that. But ultimately, that's not the point here. What I
was trying to do was first to *understand* the requirements. Usually, I
found that impossible requirements come down from management for one of
two reasons. Either, there is something going on that I am not aware of,
or a simple misunderstanding in the first place. Or management has not
been giving you requirements at all, but rather come up with what they
thought was a solution. And if it doesn't work, you'll get the blame
even if it was the wrong solution in the first place. In that case, it's
a matter of office politics.
Say you are given the requirement "I want you to build a race car, but
it must be built with a John Deere engine and able to transport two 20'
cargo containers." At first glance, completely nonsensical. It comes
down to figuring out if the requirement came down because the race was a
tractor-trailer race sponsored by John Deere - or because the manager
didn't know anything but John Deere and shipping containers.
That is why I usually like to dig beyond the requirements, and
understand the context; it will address both issues. That's what I was
trying to do here.
Very often, once you understand a requirement, you'll find that it
actually can be implemented with a slight "tweak."
> Under other circumstances, I'd be happy
> to weigh the pros and cons of the architecture. But in this case, it's
> just a matter of:
>
> 1) Backing up the transaction logs immediately (initiated by client).
> 2) Backing up the full Database snapshot.
> 3) Backing up the OS jobs nightly.
> 4) Making doubly sure #1 happens as quickly as possible (i.e. not having
> to queue behind #2 or #3.
>
It seems to me that the only way to accomplish this is to ask for the
budget to buy a separate backup device.
Otherwise, you will have a choice of:
- Interrupting the full backup every ten minutes and then resuming it
(which can't be done - and would probably be too slow even if it could)
- Interleaving the full and log backups through multiple concurrent
jobs. Bacula can do that, but it will slow down the restore and cause
tape-management issues. It will also likely be too slow. On a tape
drive, it might also cause shoeshining issues or the like.
- Spooling. Which doesn't meet your requirements.
Incidentally, I see yet another possible issue. I am assuming that you
are taking the full database snapshot from an LVM snapshot? The backup
of the log files would be based on the database state at the time of the
backup, so the full database and the log file backup might be
inconsistent with each other.
--
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Network You Never Have to Think About
Office: 866-642-7116
http://www.4nettech.com
This e-mail and attachments, if any, may contain confidential and/or
proprietary information. Please be advised that the unauthorized use or
disclosure of the information is strictly prohibited. The information herein is
intended only for use by the intended recipient(s) named above. If you have
received this transmission in error, please notify the sender immediately and
permanently delete the e-mail and any copies, printouts or attachments thereof.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
