Disk-to-disk backups and the scratch pool

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Disk-to-disk backups and the scratch pool

James Chamberlain
Hi Bacula Users,

I'm having trouble with scratch pools.  I have a three main backup  
pools configured in Bacula (Desktops, Infrastructure, Servers).  Each  
corresponds to a separate RAID device (disk0, disk1, disk2), for disk-
to-disk backups.  I have added a fourth RAID device (disk3) which I  
want to act as a scratch pool to catch overflow if any of the three  
main pools fill up, but it doesn't seem to be working.  The volumes  
appear to be there, but Bacula won't use them.

The only theories I've been able to come up with as to why is that the  
volumes in the Scratch pool have a different media type (Disk3) than  
that of the other pools (Disk0, Disk1, and Disk2, respectively), and  
that Bacula can't literally move the volume Disk3-0001 to the disk0  
device (it being full and all).  Assuming either of these theories is  
correct, is there any easy way to fake Bacula out and get it to Do  
What I Want(tm)?  If the theories aren't correct, does anyone have a  
better idea what's going on, or is there more information I can  
provide that would help?  I'm using bacula-mysql-2.4.3-1.

Thanks,

James

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

John Drescher
> I'm having trouble with scratch pools.  I have a three main backup
> pools configured in Bacula (Desktops, Infrastructure, Servers).  Each
> corresponds to a separate RAID device (disk0, disk1, disk2), for disk-
> to-disk backups.  I have added a fourth RAID device (disk3) which I
> want to act as a scratch pool to catch overflow if any of the three
> main pools fill up, but it doesn't seem to be working.  The volumes
> appear to be there, but Bacula won't use them.
>
> The only theories I've been able to come up with as to why is that the
> volumes in the Scratch pool have a different media type (Disk3) than
> that of the other pools (Disk0, Disk1, and Disk2, respectively), and
> that Bacula can't literally move the volume Disk3-0001 to the disk0
> device (it being full and all)

Bacula will make different media types incompatible. Also it will
never move a job from one storage device to a different one. So if a
job starts on drive0 it must end on drive0.

>  Assuming either of these theories is
> correct, is there any easy way to fake Bacula out and get it to Do
> What I Want(tm)?  If the theories aren't correct, does anyone have a
> better idea what's going on, or is there more information I can
> provide that would help?  I'm using bacula-mysql-2.4.3-1.
>

You probably want to experiment with the virtual disk changer script
and use smaller volumes.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

nysander (Bugzilla)
In reply to this post by James Chamberlain
You do not understand idea of scratch pool. this pool is literally speaking
some kind of trash for volumes that were recycled. you cannot use volumes in
scratch pool. they are grabbed from it and placed to the pool which needs new
media so adding new storage for scratch pool is senseless for me.

but I may be wrong, because I use bacula quite shortly.

Greets
PawelMadej



------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

John Drescher
> You do not understand idea of scratch pool. this pool is literally speaking
> some kind of trash for volumes that were recycled. you cannot use volumes in
> scratch pool. they are grabbed from it and placed to the pool which needs new
> media so adding new storage for scratch pool is senseless for me.
>
> but I may be wrong, because I use bacula quite shortly.
>

Sounds correct to me.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

John Drescher
In reply to this post by nysander (Bugzilla)
> You do not understand idea of scratch pool. this pool is literally speaking
> some kind of trash for volumes that were recycled. you cannot use volumes in
> scratch pool. they are grabbed from it and placed to the pool which needs new
> media so adding new storage for scratch pool is senseless for me.
>
> but I may be wrong, because I use bacula quite shortly.
>

Sounds correct to me.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

James Chamberlain
>> You do not understand idea of scratch pool. this pool is literally  
>> speaking
>> some kind of trash for volumes that were recycled. you cannot use  
>> volumes in
>> scratch pool. they are grabbed from it and placed to the pool which  
>> needs new
>> media so adding new storage for scratch pool is senseless for me.
>>
>> but I may be wrong, because I use bacula quite shortly.
>>
>
> Sounds correct to me.
>
> John

Why would you ever want such a pool?  The only reason I can think of  
is if you have more pools than backup devices; but that's the opposite  
of the problem I'm trying to solve.  I have more backup devices than  
pools.  In some sense, I want to have multiple devices within the same  
pool.  Ideally, I'd like to have one of those devices in multiple  
pools.  I want the volumes and not the devices bound to the pool.  
Each pool could then tag any volumes it uses with the correct pool  
label and return them to scratch when they expire.  That's that I was  
hoping for when I read the documentation for the scratch pool, though  
that interpretation is apparently incorrect.

The basic problem for me is that I've hit the 8 TB file system size  
limit with ext3, and I don't have ext4 available to me yet.  With tape  
libraries, you can keep adding more tapes to increase the size of your  
pool.  With disk-based backups, once you've hit that 8 TB limit with  
ext3, you can't.  So if that's the problem I'm trying to solve, what  
are my options with Bacula?

Thanks,

James

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

John Drescher
> Why would you ever want such a pool?  The only reason I can think of is if
> you have more pools than backup devices;

Exactly what you said. I have 20 pools and 2 backup devices with my 2
drive 24 slot autochanger.

> but that's the opposite of the
> problem I'm trying to solve.  I have more backup devices than pools.  In
> some sense, I want to have multiple devices within the same pool.  Ideally,
> I'd like to have one of those devices in multiple pools.  I want the volumes
> and not the devices bound to the pool.  Each pool could then tag any volumes
> it uses with the correct pool label and return them to scratch when they
> expire.  That's that I was hoping for when I read the documentation for the
> scratch pool, though that interpretation is apparently incorrect.
>
> The basic problem for me is that I've hit the 8 TB file system size limit
> with ext3, and I don't have ext4 available to me yet.
>
I would use XFS over ext3. ext3 is horribly inefficient with large files.

> With tape libraries,
> you can keep adding more tapes to increase the size of your pool.  With
> disk-based backups, once you've hit that 8 TB limit with ext3, you can't.
>  So if that's the problem I'm trying to solve, what are my options with
> Bacula?
>

Can you split your jobs up in some logical way so you can divide the
storage in more than 1 part?

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

James Chamberlain
>> Why would you ever want such a pool?  The only reason I can think  
>> of is if
>> you have more pools than backup devices;
>
> Exactly what you said. I have 20 pools and 2 backup devices with my 2
> drive 24 slot autochanger.

Why so many pools?  Are you doing one per client?

>> but that's the opposite of the
>> problem I'm trying to solve.  I have more backup devices than  
>> pools.  In
>> some sense, I want to have multiple devices within the same pool.  
>> Ideally,
>> I'd like to have one of those devices in multiple pools.  I want  
>> the volumes
>> and not the devices bound to the pool.  Each pool could then tag  
>> any volumes
>> it uses with the correct pool label and return them to scratch when  
>> they
>> expire.  That's that I was hoping for when I read the documentation  
>> for the
>> scratch pool, though that interpretation is apparently incorrect.
>>
>> The basic problem for me is that I've hit the 8 TB file system size  
>> limit
>> with ext3, and I don't have ext4 available to me yet.
>>
> I would use XFS over ext3. ext3 is horribly inefficient with large  
> files.

That's not something I can change at this point.

>> With tape libraries,
>> you can keep adding more tapes to increase the size of your pool.  
>> With
>> disk-based backups, once you've hit that 8 TB limit with ext3, you  
>> can't.
>>  So if that's the problem I'm trying to solve, what are my options  
>> with
>> Bacula?
>>
>
> Can you split your jobs up in some logical way so you can divide the
> storage in more than 1 part?

I think I have.  I have two 8 TB file systems and one 1.1 TB file  
system.  My individual volumes on each of those file systems are only  
50 GB.  I just have 160 of them per 8 TB file system and 20 on the 1.1  
TB.  I have another 1.1 TB left over that I want to use if any of the  
others fill up before old jobs expire.  As for splitting up the jobs,  
I've broken them into desktop, server, and infrastructure pools.  Is  
that what you were getting at?

Thanks,

James

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

John Drescher
On Mon, Apr 13, 2009 at 6:02 PM, James Chamberlain <[hidden email]> wrote:
>>> Why would you ever want such a pool?  The only reason I can think of is
>>> if
>>> you have more pools than backup devices;
>>
>> Exactly what you said. I have 20 pools and 2 backup devices with my 2
>> drive 24 slot autochanger.
>
> Why so many pools?  Are you doing one per client?
>
Not exactly. More closely to 1 pool per type of data. Additional pools
were added for independent duplicates of the data.

>>> but that's the opposite of the
>>> problem I'm trying to solve.  I have more backup devices than pools.  In
>>> some sense, I want to have multiple devices within the same pool.
>>>  Ideally,
>>> I'd like to have one of those devices in multiple pools.  I want the
>>> volumes
>>> and not the devices bound to the pool.  Each pool could then tag any
>>> volumes
>>> it uses with the correct pool label and return them to scratch when they
>>> expire.  That's that I was hoping for when I read the documentation for
>>> the
>>> scratch pool, though that interpretation is apparently incorrect.
>>>
>>> The basic problem for me is that I've hit the 8 TB file system size limit
>>> with ext3, and I don't have ext4 available to me yet.
>>>
>> I would use XFS over ext3. ext3 is horribly inefficient with large files.
>
> That's not something I can change at this point.
>
I understand.

>
>>> With tape libraries,
>>> you can keep adding more tapes to increase the size of your pool.  With
>>> disk-based backups, once you've hit that 8 TB limit with ext3, you can't.
>>>  So if that's the problem I'm trying to solve, what are my options with
>>> Bacula?
>>>
>>
>> Can you split your jobs up in some logical way so you can divide the
>> storage in more than 1 part?
>
> I think I have.  I have two 8 TB file systems and one 1.1 TB file system.
>  My individual volumes on each of those file systems are only 50 GB.  I just
> have 160 of them per 8 TB file system and 20 on the 1.1 TB.  I have another
> 1.1 TB left over that I want to use if any of the others fill up before old
> jobs expire.  As for splitting up the jobs, I've broken them into desktop,
> server, and infrastructure pools.  Is that what you were getting at?
>

Yes.


The other option will take work/research from you. The virtual disk
autochanger concept. There has been discussion about this on the list.
The theory is to create a diskchanger script similar to the mtxchanger
script that make the individual arrays look like just 1 storage device
or 1 auto changer (with 1 or more storage devices) then with dozens or
even hundreds of volumes and the ability to switch mount points to the
different physical arrays to access volumes in the virtual slots. I
hear mention of a virtual disk changer in bacula 3.0.0, however I have
not investigated that.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

Martin Simmons
In reply to this post by James Chamberlain
>>>>> On Mon, 13 Apr 2009 17:41:00 -0400, James Chamberlain said:
>
> The basic problem for me is that I've hit the 8 TB file system size  
> limit with ext3, and I don't have ext4 available to me yet.  With tape  
> libraries, you can keep adding more tapes to increase the size of your  
> pool.  With disk-based backups, once you've hit that 8 TB limit with  
> ext3, you can't.  So if that's the problem I'm trying to solve, what  
> are my options with Bacula?

I'm not sure if it will work, but you could try using symbolic links from one
file system to the volumes on the other file system(s)?

__Martin

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

James Chamberlain
On Tue, 14 Apr 2009, Martin Simmons wrote:

>>>>>> On Mon, 13 Apr 2009 17:41:00 -0400, James Chamberlain said:
>>
>> The basic problem for me is that I've hit the 8 TB file system size
>> limit with ext3, and I don't have ext4 available to me yet.  With tape
>> libraries, you can keep adding more tapes to increase the size of your
>> pool.  With disk-based backups, once you've hit that 8 TB limit with
>> ext3, you can't.  So if that's the problem I'm trying to solve, what
>> are my options with Bacula?
>
> I'm not sure if it will work, but you could try using symbolic links from one
> file system to the volumes on the other file system(s)?
>
> __Martin

Thanks for the suggestion, and I considered it, but I don't think it'll
work.  The Disk3 volumes are still going to be of a different media type
than the Disk0 volumes.

James

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

Josh Fisher

James Chamberlain wrote:

> On Tue, 14 Apr 2009, Martin Simmons wrote:
>
>  
>>>>>>> On Mon, 13 Apr 2009 17:41:00 -0400, James Chamberlain said:
>>>>>>>              
>>> The basic problem for me is that I've hit the 8 TB file system size
>>> limit with ext3, and I don't have ext4 available to me yet.  With tape
>>> libraries, you can keep adding more tapes to increase the size of your
>>> pool.  With disk-based backups, once you've hit that 8 TB limit with
>>> ext3, you can't.  So if that's the problem I'm trying to solve, what
>>> are my options with Bacula?
>>>      
>> I'm not sure if it will work, but you could try using symbolic links from one
>> file system to the volumes on the other file system(s)?
>>
>> __Martin
>>    
>
> Thanks for the suggestion, and I considered it, but I don't think it'll
> work.  The Disk3 volumes are still going to be of a different media type
> than the Disk0 volumes.
>
>  

The disk autochanger approach should still work. You would have to have
multiple autochangers, since volumes associated with any one autochanger
will all have the same media type, but there is nothing preventing that.

As for the file system limitations, I'm not sure I understand the
problem. Why do the backup volumes have to be on ext3? They should be
independent of your data file systems. LVM could be used to partition
storage for the backup volumes if needed. Putting the backup volumes on
a XFS file system would increase the limit from 8 TB to 8 EB and would
certainly be more efficient with large 50 GB files.

> James
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Bacula-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>  

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

James Chamberlain
On Apr 14, 2009, at 10:04 AM, Josh Fisher wrote:

> James Chamberlain wrote:
>> On Tue, 14 Apr 2009, Martin Simmons wrote:
>>>>>>>> On Mon, 13 Apr 2009 17:41:00 -0400, James Chamberlain said:
>>>>>>>>
>>>> The basic problem for me is that I've hit the 8 TB file system size
>>>> limit with ext3, and I don't have ext4 available to me yet.  With  
>>>> tape
>>>> libraries, you can keep adding more tapes to increase the size of  
>>>> your
>>>> pool.  With disk-based backups, once you've hit that 8 TB limit  
>>>> with
>>>> ext3, you can't.  So if that's the problem I'm trying to solve,  
>>>> what
>>>> are my options with Bacula?
>>>>
>>> I'm not sure if it will work, but you could try using symbolic  
>>> links from one
>>> file system to the volumes on the other file system(s)?
>>>
>>> __Martin
>>>
>>
>> Thanks for the suggestion, and I considered it, but I don't think  
>> it'll work.  The Disk3 volumes are still going to be of a different  
>> media type than the Disk0 volumes.
>
> The disk autochanger approach should still work. You would have to  
> have multiple autochangers, since volumes associated with any one  
> autochanger will all have the same media type, but there is nothing  
> preventing that.

Is it possible to switch to this approach without dumping my existing  
backups and starting over from scratch?

> As for the file system limitations, I'm not sure I understand the  
> problem. Why do the backup volumes have to be on ext3? They should  
> be independent of your data file systems. LVM could be used to  
> partition storage for the backup volumes if needed. Putting the  
> backup volumes on a XFS file system would increase the limit from 8  
> TB to 8 EB and would certainly be more efficient with large 50 GB  
> files.

The problem is not that they have to be on ext3, but that they already  
are.  I can't afford to take my backup system down and be without a  
safety net for a couple of weeks.  If I ditched my existing backups  
and started from scratch, it would take that long to do the fulls.  If  
I used convertfs to do the job for me, based on the time estimates  
I've seen (20 mins for 240 MB, "days" for hundreds of GB), I'd be  
looking at the same sort of time frame.

Also, it's a minor point, but on 32-bit systems, xfs is limited to 16  
TB, not 8 EB.

Thanks,

James

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

Martin Simmons
In reply to this post by James Chamberlain
>>>>> On Tue, 14 Apr 2009 07:54:51 -0400 (EDT), James Chamberlain said:
>
> On Tue, 14 Apr 2009, Martin Simmons wrote:
>
> >>>>>> On Mon, 13 Apr 2009 17:41:00 -0400, James Chamberlain said:
> >>
> >> The basic problem for me is that I've hit the 8 TB file system size
> >> limit with ext3, and I don't have ext4 available to me yet.  With tape
> >> libraries, you can keep adding more tapes to increase the size of your
> >> pool.  With disk-based backups, once you've hit that 8 TB limit with
> >> ext3, you can't.  So if that's the problem I'm trying to solve, what
> >> are my options with Bacula?
> >
> > I'm not sure if it will work, but you could try using symbolic links from one
> > file system to the volumes on the other file system(s)?
> >
> > __Martin
>
> Thanks for the suggestion, and I considered it, but I don't think it'll
> work.  The Disk3 volumes are still going to be of a different media type
> than the Disk0 volumes.

Yes, that's true :-(

You would have to decide in advance how many volumes of each pool should be
stored on disk3 (using the existing media types).

__Martin

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

John Drescher
In reply to this post by James Chamberlain
> Is it possible to switch to this approach without dumping my existing
> backups and starting over from scratch?
>
I believe you can do this. But agian this approach would be work and
experimentation on your part because this customization is not in
bacula. This may be something that you can get from a contract support
from the enterprise bacula foundation.

>
>> As for the file system limitations, I'm not sure I understand the
>> problem. Why do the backup volumes have to be on ext3? They should
>> be independent of your data file systems. LVM could be used to
>> partition storage for the backup volumes if needed. Putting the
>> backup volumes on a XFS file system would increase the limit from 8
>> TB to 8 EB and would certainly be more efficient with large 50 GB
>> files.
>
> The problem is not that they have to be on ext3, but that they already
> are.  I can't afford to take my backup system down and be without a
> safety net for a couple of weeks.  If I ditched my existing backups
> and started from scratch, it would take that long to do the fulls.  If
> I used convertfs to do the job for me, based on the time estimates
> I've seen (20 mins for 240 MB, "days" for hundreds of GB), I'd be
> looking at the same sort of time frame.
>
> Also, it's a minor point, but on 32-bit systems, xfs is limited to 16
> TB, not 8 EB.
>
A second option would be to make one single file system on top of the
3 raid arrays using autofs or unionfs. And then move all volumes to
the same media type. I believe this is possible with either bconsole
or database manipulation.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users
Reply | Threaded
Open this post in threaded view
|

Re: Disk-to-disk backups and the scratch pool

Kjetil Torgrim Homme
In reply to this post by James Chamberlain
James Chamberlain <[hidden email]> writes:
> On Tue, 14 Apr 2009, Martin Simmons wrote:
>> I'm not sure if it will work, but you could try using symbolic
>> links from one file system to the volumes on the other file
>> system(s)?
>
> Thanks for the suggestion, and I considered it, but I don't think
> it'll work.  The Disk3 volumes are still going to be of a different
> media type than the Disk0 volumes.

sure, but that's fixed with a single UPDATE statement in your database
(and some sed on your config, of course.)

--
Kjetil T. Homme
Redpill Linpro AS - Changing the game


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Bacula-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bacula-users