> 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
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users