List of Clients, whether part of a policy or not

[R_M_H]

Hi again all,

Apologies for all the basic questions. I am coming from other products and very keen to absorb as much info as possible on NetBackup.

When deploying a client I don't see any reference to it in the GUI until I manually add it to a policy and it then appears in the Clients area. I fear this introduces some risks that clients may be missed from being added to policies or taken from policies and missed from being re-added. How do others deal with this? Just rely on internal processes to add new systems to policies?

If a client is set up to talk to the Master Server wouldn't it make sense to have them appear in a new non-configured client area perhaps?

Do decomissioned servers still appear in the clients list even after they are removed from the policy?

Thanks for your patience all.

Richard

[RiaanBadenhorst]

Hello

As you noticed, a client will only appear in the list once its put in a policy. And similarly, once its removed from all policies, it will disappear from the client list.

This is how it works.

[manatee]

FWIW, in my linux master server, i only need to have the client pingable and present in /etc/hosts file. of course, client needs to have NBU agent installed ;)

[Marianne · Accepted solution]

You were asking what others do? Internal processes. System owners need to notify backup team when new server is deployed along with all relevant backup requirements : filesystems and/or database, backup windows, retentions, etc. Some of our customers also have charge out procedures, which means that the backup request need to include the necessary billing information and authorization.

[sdo · Accepted solution]

I prefer the NetBackup way of not hanging on to details/lists of defunct clients.  Your businesses robust ITIL change control procedures should be the instigator of actual change.  I find applications that retain defunct lists to be a distraction... which only ever generates additional levels of confusion...  Should it be in backups?  Should it not?  Why?  Who installed it?  Why has it popped up in the list?  What am I supposed to do now?   etc.

[R_M_H]

I do agree that there should be strict processes in place, but all too often I don't see this and software should be there to assist where it can.

I still like the idea of at least having a way to see clients that aren't part of policies and hopefully this will be a feature that can be investigated one day by the product team. Even if, when adding clients, you get a section where it will list all known clients and unconfigured clients instead of having to manually type in the host name would be great functionality IMO.

Saying all that, thanks for the helpful responses all and thanks for making this a great community. I have been spending many hours going through your solutions and responses and have learnt a great deal from them. Sometimes reading through the Admin Guides doesn't actually give you a good feel for what people actually do with the product and this place is filling in a lot of the gaps I have.

[revarooo]

" software should be there to assist where it can."

Netbackup is designed to backup systems NOT to alert you to new systems in an environment.

How could you tell with NetBackup is a client is not in a policy - especially if that client does not have NetBackup installed yet!?

Nothing to stop you writing your own software to gather a list of ALL clients and check if NetBackup is installed, perhaps by checking if PBX or bpcd port is connectable I guess? Not ideal but easily doable.

[R_M_H]

Thanks for the input revarooo, I was assuming they would already have the client installed, just not in a policy. Good thoughts on the connectable ports script too.

[Marianne]

I have seen a customer using OpsCentre Analytics report where a full server list is used as input to compare with NBU client list in policy. This list was obtained from the Server and/or network team. Bottom line: there is no way that new servers in the environment can be automatically added to NBU. The only difference is for VMware backups where new VMs can be automatically detected with VIP config.

[Genericus]

Create a policy called ADD.A.SERVER - no schedules, it never runs. Add every new systems as part of your build doc.

Create a policy called DELETED.SYSTEMS - no schedules, it never runs. Add every system as you remove it as part of your decommission doc.

If a system is not in a policy, there are several places where it will not show up.

If a system is not in a policy, you cannot see it in host properties.

If you remove a system from every policy, it will not be in the drop down to do a restore - NB does not read the files in the images directory to find systems to restore.

What did you name that system you decommissioned last year you need to restore data from? You can go to the OS, or have it in a policy...

There are several things that a little bit of planning / documenting, will save you time later.

[cruisen]

Hello,

we do it differently, we do not delete the policies of the client we just deactivate, therefore no backup is ran, but all clients are still visible on the client host properties.

So you can create a policy and call it deployment (deactivate it, for no backup) you add all you servers to it of the network, also double check with your clients that are being backup up on a daliy basis. The delta are the clients that need to be added to backup.

The advantage of doing so is, that you can check quickly the connnectivity and the response of the agent from the master server just by doubleclicking on it. By selection all of you clients, and doubleclicking on it, you can run a connectivity test for all clients from you master.

best regards,

Cruisen