Hello Frank,
On Thursday 17 November 2005 20:56, Frank wrote: > Dear Kern, > > Based on the discussions on the bacula-users mailing list, I would > like to propose the following two feature requests. I'm sending > them directly to you, hope that is o.k, it was not clear to me if > I should send them to you, bacula-devel or bacula-users. It is best to send the requests to bacula-users and bacula-devel. > > I have no clue how complex it is to embed them into Bacula, but I > hope you will consider them. I consider all Feature Requests, and would like to implement most of them (possibly with some modifications), but, well maybe in another 5 years ... > > Kind regards, > > Frank > > --------------------------------------------------------------------- > > Item 1: "spool-only" backup > Origin: Frank Volf ([EMAIL PROTECTED]) > Date: 17 november 2005 > Status: > > What: In the bacula implementation a backup is finished after > data is succesfully written to storage. When using a tape backup > it is very annoying that a backup can take a day, simply because > the current tape (or whatever) is full and the administrator has > not put a new one in. During that time the system cannot be taken > off-line, because there is still an open session between the > storage daemon and the file daemon on the client. > > Although this is a very good strategey for making "safe backups" > This can be annoying for e.g. laptops, that must remain connected > until the bacukp is completed. > > The proposal is to implement a "spool only" option that considers > the backup finished as soon as all data is spooled to the storage > daemon (and might not be writen to a backup medium). > > It seems reaonable to restrict the backup of a client/file-set to > allow only only one spooled but not committed job, so you never > have the problem to determine what files to include in the next > incremental backup > > > Why: > Makes backup of laptops much easier. > > > Notes: > None. > > I'll be happy to add the above item to the list, but I am not really sure how many people will give it a priority high enough to implement ??? > --------------------------------------------------------------------- > > > > Item 2: Calling home feature > Origin: Frank Volf ([EMAIL PROTECTED]) > Date: 17 november 2005 > Status: > > What: It is often a problem to backup systems with a dynamic IP > address. > > This is especially the case for laptops used by people that > do a lot of travelling or work at different locations. It can also > be useful in environments were DHCP is used to assign an IP address > and fixed IP addresses are impossible to arrange. > > In the "calling home feature", the file daemon on the client connects > to the director to tell its current IP address and requests a > backup/restore session to start to that IP address. > > > Why: There is no good alternative to fix this problem and the > problem is real. > > > Notes: It would be brilliant if one could make the communication > setup from client to server only. With this I mean that the TCP > connection is setup from the client and no connection from the server to > the client is required to perform the backup. The huge advantage > is that you then can backup systems that are behind a firewall that > allows only outbound connections, and you can backup systems that are > behind a NAT device. > > This feature would also highly benefit from the "spool-only" feature > mentioned above. A laptop can then once per day contact "home base" and > quickly run a "spool-only" incremental backup to save its data. Your Item 2 is really two separate requests. The first one is already implemented -- I think. It is call "setip" and is a bconsole command that has a good number of restrictions. As far as I know it works, but no one has specifically said that he/she uses it. Please see the documentation and if it doesn't do what you want or work, please let me know (copy the bacula-devel list). Concerning the second part, namely the ability to initiate a backup using the connection from the Client. This is a project that I would like to see done, and there are probably a few lines of code already written for it, but it was never completed. If you submit a Feature Request for this, I will be happy to include it. One big problem, however, that this request will not solve is that the File daemon must be able to contact the Storage daemon. If the Storage daemon is behind the firewall and NATed, that would double the size of the project. Please include this aspect in your request if you need it ... ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
