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.
---------------------------------------------------------------------
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.
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 ;-)
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
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
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
