On Thu, Mar 12, 2009 at 06:44:54PM +0100, Kern Sibbald wrote: > 1. As a general principle, it is not a good idea to be cycling through > storage daemons seeing if they work or not, which is what I think you are > proposing unless I misunderstood it. ...[snip]... > we need a very detailed careful design that looks at the current capabilities > (including the undocumented features) and shows how we are going to evolve > those gracefully into implementation of multiple storage daemons. ...[snip]... > Another thing that would be helpful is to specify on a much higher level what > feature you are trying to implement. You've proposed a somewhat low level > solution to a problem of using Bacula in a way that is either not possible or > hasn't been fully implemented, and by starting from the high end, we might be > able to make it work by simplely completing some of the features that have > been planned and partially implemented but not completed for many years now.
Hello, Thank you for the comments. I think you have possibly misunderstood me when you read this paragraph: > > Why: It is useful to be able to backup to any number of different storage > > daemons. For example, your first storage daemon may run out of space, so > > you switch to your second and carry on. Bacula will currently let you do > > this. However, once you come to restore, bacula cannot cope when volumes on > > different storage daemons are required. I do not mean that bacula would automatically switch between multiple storage daemons when backing up. I mean that the user of the software might tell a particular job to backup to a storage daemon, and then after some period of time, change the job to backup to a different storage daemon. This would mean that he might now have some incrementals at one location based on fulls/differentials at another location. Currently, bacula cannot correctly restore from them. I also have another scenario that demonstrates the same problem. The user wants to be able to recover from his office burning down. He also wants to be able to quickly recover the secretary's accidentally deleted Microsoft Word file that was backed up yesterday. The user sets up one job with two pools. One pool is for full backups. The other pool is for incremental backups The full pool uses a remote storage daemon. The incr pool uses a local storage daemon. (Using the 'Storage =' directive of the Pool resource, as documented at http://www.bacula.org/en/rel-manual/Configuring_Director.html#PoolResource) This would mean that he will definitely have some incrementals at one location based on fulls at another location. Currently, bacula cannot correctly restore from them. I will reply to the rest of your points separately. Thanks, Graham. ------------------------------------------------------------------------------ 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
