Connectivity is fine between the server and client (actually on the same
subnet at this point).

I'm just seeing really strange results related to the policy database.  If
I create a new policy using the ALL_LOCAL_DRIVES, it just backs up the root
partition.  If I manually list the individual partitions in the file selection
it works as expected. If I then go back in and change it to ALL_LOCAL_DRIVES it
will only backup the filesystems I had previously listed in the file selection,
such as if there's six local filesystems and I only had three listed manually,
after switching it back to ALL_LOCAL_DRIVES it will only backup those three
filesystems.

If I use a policy that was migrated from 5.1 MP5 which has the ALL_LOCAL_DRIVES
selection, it works as expected (with the same test client).

I've also noticed that if I submit a manual backup via the java console, such
as go in and select a specific schedule and client, it submits the schedule
for all clients in the schedule.  Actually, in the last case manually submitted
a Differential backup for my test client which it submitted and then submitted
the Full schedule for all the clients in the policy.  This is even with the
current date excluded in the Full and Differential schedules.

John

Weber, Philip wrote:
> I've had this issue where there's a problem with connectivity (e.g.
> firewall) between the master and the client, but the (different) media
> server and the client can talk to each other correctly.  It's like the
> master can't query the client to find out what filesystems need backing
> up, but the actual backup of what it knows can take place between the
> client and media server.  Check port connectivity and check for timeout
> messages in the bpsched (I think) log.  I'm using 5.1 MP5 though.
> 
> Phil
> 
> Phil Weber
> Business Technology (Egg)
> Storage Technical Services - Senior UNIX Technologist
> Phone: 01384 26 4136
> 
> 
> 
>>-----Original Message-----
>>From: veritas-bu-bounces AT mailman.eng.auburn DOT edu 
>>[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf 
>>Of Darren Dunham
>>Sent: 17 July 2007 22:28
>>To: veritas-bu AT mailman.eng.auburn DOT edu
>>Subject: Re: [Veritas-bu] ALL_LOCAL_DRIVES not working?
>>
>>
>>
>>>Is there anyway to see how's responding to or processing the bpmount
>>>information coming in from the client?
>>
>>It's been a while since I did that.  If you turn on verbose 
>>logging, one
>>of the log files shows the retreival of the mounts and then the
>>selection of the filesystems.  I'd probably look at bpcd on 
>>the client,
>>but I've forgotten which one on the server is most relevant here.
>>
>>I assume you've already run bpmount -i on the client to 
>>verify it looks
>>reasonable?
>>
>>-- 
>>Darren Dunham                                           
>>ddunham AT taos DOT com
>>Senior Technical Consultant         TAOS            
>>http://www.taos.com/
>>Got some Dr Pepper?                           San Francisco, 
>>CA bay area
>>         < This line left intentionally blank to confuse you. >
>>_______________________________________________
>>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
> 
> 
> -----------------------------------------
> Egg is a trading name of the Egg group of companies which includes:
> Egg plc (reg no 2448340), Egg Financial Intermediation Ltd (reg no
> 3828289), and Egg Banking plc (reg no 2999842). Egg Banking plc and
> Egg Financial Intermediation Ltd are authorised and regulated by
> the Financial Services Authority (FSA) and are entered in the FSA
> register under numbers 205621 and 309551 respectively. These
> members of the Egg group are registered in England and Wales.
> Registered office: Citigroup Centre, Canada Square, London E14 5LB.
> 
> This e-mail is confidential and for use by the addressee only. If
> you are not the intended recipient of this e-mail and have received
> it in error, please return the message to the sender by replying to
> it and then delete it from your mailbox. Internet e-mails are not
> necessarily secure. The Egg group of companies do not accept
> responsibility for changes made to this message after it was sent.
> 
> 
> Whilst all reasonable care has been taken to avoid the transmission
> of viruses, it is the responsibility of the recipient to ensure
> that the onward transmission, opening or use of this message and
> any attachments will not adversely affect its systems or data. No
> responsibility is accepted by the Egg group of companies in this
> regard and the recipient should carry out such virus and other
> checks as it considers appropriate.
> 
> This communication does not create or modify any contract.
> 
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu