[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Optimizing disk based backups


On May 23, 2008, at 1:31 PM, Michael Short wrote:

> Hello,
>
> I realize that Bacula was originally developed for tape based backup
> systems, but disk space is becoming more inexpensive everyday. It is
> cheaper and more reliable to maintain a system which uses disk based
> mediums to store backup data. The problem is that disk based restores
> are unnecessarily slow, due to the linear nature of the backup
> volumes.
>
> I am addressing this problem because at some point it would be
> necessary to access old backup archives should anyone implement an
> rsync or xdelta type enhancement for Bacula. Perhaps instead of
> storing individual file locations in the catalog, an index of the
> backup could be stored at the beginning or end of a volume, so that
> unnecessary "forward spacing" would no longer be needed for disk based
> volumes. This extra would also make the process of recovering catalog
> information from volumes much less painful.

Well, if you put the index at the front of the volume, then you break  
tape volumes.

I would suggest that the right way to do this is to, if you're backing  
up to disk volumes, have many more volumes each of which is much  
smaller.

Set your maximum file size to be, say, 1GB (or 100MB or whatever your  
own personal tolerance is), and then have Max Volumes be very large.   
Locating the right volume is therefore a matter of a SQL lookup and  
locating the file within it is a much smaller seek problem.

Adam

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.