On Thursday 17 November 2005 22:02, Arno Lehmann wrote: > Hello, > > On 17.11.2005 22:29, Kern Sibbald wrote: > > On Thursday 17 November 2005 20:56, Frank wrote: > > ... > > >>--------------------------------------------------------------------- > >> > >>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 ??? > > This item should no longer be interesting once migration is implemented. > Remember Davids suggestion to implement spooling as a migration scheme? > First backup to a disk pool, and migrate to tape when possible.
There is still the problem of getting the attributes committed. If it takes a very long time to do, with the current code, the job has not terminated, and the File daemon is not freed up. Perhaps this item should be re-writtent to say that the Storage daemon should release the File daemon as soon as all the file data and all the attributes have been sent to it (the SD). Currently the SD waits until everything is on tape and all the attributes are transmitted to the Director before signalling completion to the FD. I don't think I would have any problem changing this. The reason is that even if the FD reports back to the Dir that all is OK, the job will not terminate until the SD has done the same thing -- so in a way keeping the SD-FD link open to the very end is not really very productive ... Frank, do you think you could re-write it in the way I indicate above? Hopefully what I wrote is clear. This wouldn't even be an option, but rather the normal way of running and also would not depend on spooling or not spooling. Obviously if you spool, things will go much faster, and also as was pointed out with Migration, the job can more quickly be written to disk then later transferred to tape. However, the key for you is that the SD release the FD once the SD has all the data ... > > >>--------------------------------------------------------------------- > >> > >> > >> > >>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. > > I id use it sometimes. I have a notebook I mainly use with WLAN access, > but sometimes the WLAN connection drops all few seconds or I need a > higher throughput, so I plug in a network cable. In the cable LAN, the > notebook got another, dynamic, IP and hostname. Using setip and a > properly defined console setup in bacula-dir.conf, I could run jobs > accessing the notebook. Thanks for the confirmation -- so Frank, I think this part of your request is already resolved ... > > > 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 ... > > Hmm. A good manual section about VPN setup could solve these problems :-) > > Seriously, using a VPN to backup data would be one good option as long > as transport encryption is not fully implemented. Once transport > encryption is stable, things look different... One possible solution > might be a bacula proxy to run on the firewall... or simply port > forwarding through the firewall (or NAT device)... but, of course, that > doesn't do everything the client initiated backup does: the schedules > would remain a DIR thingie (just right in my opinion ;-) Is there anyone out there who has used VPN in this way? (I'm not pointing at you Arno). I would appreciate it if someone could explain it to me as clearly as possible, because as Arno says, this could be a nice addition to the manual. > > Arno > > > ------------------------------------------------------- > > 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-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------- 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
