Phil Stracchino wrote:
> Laptops frequently have both a wireless network adapter and a wired
> network adapter.  Sometimes both are built in; sometimes the wired
> connection is in a docking station.  Rarely do both have the same
> address or hostname, as doing so is something of an unwise way to go
> about things.  Nevertheless, it is desirable to have a laptop able to be
> backed up via either interface, with the wired interface preferred due
> to much greater throughput.  (In fact, throughput limitations may very
> well rule out doing Full backups over wireless.)
> 
> Similarly, it may be desirable to back up a laptop whether it is onsite
> or at a remote location, though it will very probably have a different
> address while at the remote location.  Also, system administrators in
> secured environments may have a policy of performing restores only to
> machines physically present on-site, so as to be able to physically
> verify they are restoring to a machine which is authorized to hold the
> data to be restored.
> 
> 
> I propose, first of all, the following addition:
> 
> 
> 1.  Add an optional "Secondary Address" or "Alternate Address" field to
> the Client record.  (I'm not certain which is better; I'm leaning
> towards "Secondary".)
> 
> example:
>       Address = myhost.wired.mynetwork
>       Secondary Address = myhost.wireless.mynetwork

I like it.  Sounds pretty simple too.

> When attempting to contact a client, Bacula will attempt to contact it
> using the address or FQDN given in the Address record first.  If the
> client is not reachable at this address, AND a "Secondary Address" field
> is defined in the Client record, Bacula will then attempt to contact the
> client at the secondary address.

How does this interact with other options, such as retrying on error etc?

I suspect we'd want to retry Secondary immediately, then allow the other 
options to take effect.

> Secondly, to address the possibility of limited bandwidth while at an
> alternate location or connected only via a wireless interface, or
> security policies restricting remote restore jobs:
> 
> 2.  Add a "Secondary Address Allowed Levels" field, ignored unless an
> "Secondary Address" field is found.
> 
> example:
>       Secondary Address Allowed Levels = INCR, DIFF, VERIFY
> 
> Before starting a job to a client with a defined secondary address,
> Bacula will compare the level of the job to be run against the list of
> allowed job types (INCR, DIFF, FULL, VERIFY, RESTORE) in the Secondary
> Address Allowed Levels field, if one is present.  If the level of the
> job is not found in the list, then that job type is not permitted to run
> via that interface and the job is cancelled.  If the field does not
> exist in the client record, then all job types are presumed to be permitted.

Sounds nice as well.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to