NetBackup 7.0.1 Backing up skipped files

[gumbo]

Hi,

I'm currently running NetBackup 7.0.1. I have a master/media server set up using SUSE Linux 10, and a client also on SUSE 10.

My backup policy is set up to 'Standard', with 'Active' and 'Allow multiple data streams' checked. I'm doing a full system backup on 'ALL_LOCAL_DRIVES'. When I initiate the backup, I get 5 different backup jobs in the 'Activity Monitor', 3 of which contain the following status: "Info nbrb(pid=5636) Limit has been reached for the logical resource lnx.NBU_CLIENT.MAXJOBS.svr7.' I think I received that warning because I didn't have enough resources to run the job. After the other two active jobs completed, the pending jobs with that status message were able to complete without problems according to the detailed status.

However, in some of the detailed status I would see messages like:

"info bpbrm (pid=23524) from client: TRV - /var/run/acpid.socket is a socket special file. Skipping."

or

"info bpbrm (pid=23311) from client: TRV - /var is in a different file system from /. Skipping."

Is it possible to also backup these files?

Thanks.

[Marianne · Accepted solution]

5 different jobs means 5 different file systems. /var is a filesystem on its own and is therefore skipped while the root filesystem (/) is backed up. One of those 5 jobs is probably for /var.

About 'socket special' files, see this TN for a list of files that are not backed up by NBU:

http://www.symantec.com/business/support/index?page=content&id=TECH52350

What files will NetBackup automatically exclude during backup?

[gumbo]

I'm trying to understand cross mount points and NFS. I was reading the admin guide for NBU 7.0.1 on Linux and I was wondering why if the policy has ALL_LOCAL_DRIVES checked to be backed up, the cross mount points option shouldn't be used?

Thanks.

[J_H_Is_gone]

Because a NFS mounted drive is NOT a LOCAL DRIVE.

A local drive is something that belongs to that server..

A NFS mounted drive does not belong to that server but to another server.

And if you are following a good back practices that NFS mounted drive is getting backed on the server it belongs to.

So you have to do that extra step saying you want to back it up via this server rather then at the source server (usually because they are not backing up the source server)

(this was a new question on a different topic, it should have been opened as a new thread)

[J_H_Is_gone]

You said:

My backup policy is set up to 'Standard', with 'Active' and 'Allow multiple data streams' checked. I'm doing a full system backup on 'ALL_LOCAL_DRIVES'. When I initiate the backup, I get 5 different backup jobs in the 'Activity Monitor', 3 of which contain the following status: "Info nbrb(pid=5636) Limit has been reached for the logical resource lnx.NBU_CLIENT.MAXJOBS.svr7.' I think I received that warning because I didn't't have enough resources to run the job. 

logical resource lnx.NBU_CLIENT.MAXJOBS.svr7  - is the key point on this.

There are a number of places where you can limit the number of jobs that can run at once.

1) in the storage unit - where you say multiplex 8, meaning only 8 jobs can run to a tape drive at once

2) in the policy, you can limit the number of active jobs for a policy to run at once

3) the client (global) - go to properties of the master server, Global Attributes , Max jobs per client.  In this one you are saying for all client server only run this many jobs concurrently.

4) client (per each client) - go to properties of the master server Client Attributes. Maximum data streams.   Again this says the number of jobs that can run concurrently for this client (note the client names here have to be added by hand, so if your client is NOT here it would be #3 that was limiting it)

One of the reasons for doing this is to not overtax you little clients.  I had one server that was so old and and an old network connection that I could not run more then 1 job at a time or it would crash the server.

So this limit is not a bad thing, and is configurable. (this is not an error, just informing you that it has hit its limit and will run the jobs when one of the others finish.)

[Marianne]

If your backup selection specifies 'ALL_LOCAL_DRIVES' then all local file systems will be backed up.

If you select 'cross mount pounts' as well, then all file systems will still be backed up, BUT backup of root filesystem (/) will also backup all other mount points under / as well.

You end up with everything backed up twice.

[gumbo]

Ah that makes sense.

When you say:

NFS mounted drive is getting backed on the server it belongs to. So you have to do that extra step saying you want to back it up via this server rather then at the source server (usually because they are not backing up the source server)

How do I perform that extra step?

Are there any other good practices in terms of performing a full backing up a linux system that has multiple filesystems? Would the best approach be to create one policy that backs up root filesystem (/) not ALL_LOCAL_DRIVES with cross mount points and nfs enabled?

The /sys file also appears to cause a lot of ERRs in the backup process. I excluded it from my backup. Is it safe to exclude this file completely?

(Sorry i will create a new thread next time. I thought the topic was remotely related because the document Marianne linked me to specified that in order to backup other file systems, cross mount points should be checked.)

Thanks!

[Andy_Welburn]

(by original source I mean filer or some other server that hosts that data) then you would need to select "Follow NFS" in your policy, or you could set up a separate policy for these - depends what best suits your requirements really.

It should be perfectly fine to exclude /sys (we have on a fair few of our Linux platforms) not sure why it's not on the list of items that are excluded automatically (similar to /proc which is automatically excluded):

What files will NetBackup automatically exclude during backup?
http://www.symantec.com/business/support/index?page=content&id=TECH52350

[Marianne]

I prefer to backup ALL_LOCAL_DRIVES and select 'allow multiple datastreams' in the Attributes tab.

This method creates a form of checkpoint - if backup of one filesystem fails, backups of other filesystems will not be affected. A retry of the job will only retry the failed job.

Depending on MPX values in the schedule and STU config as well as Max Jobs Per Clients, you can multistream and multiplex the streams, resulting in faster backups.

If you backup / with 'Cross Mount Points' one single job will be created. No multiplexing/multistreaming will be possible. If job fails at 99% and you did not enable checkpoints on the policy, the entire job has to be restarted from scratch.

Please also read the Policy chapter of Admin Guide I. (Chapter 15)

[Andy_Welburn]

be careful - too many streams running on a client at any one time could have an adverse affect on available resources (disk I/O etc). You may need to monitor & tweak the settings to get the 'ideal' number of consecutive streams.

[gumbo]

Thanks for all your responses, very useful.

[Duke_Dorn]

We have a similar situation:

/dev/vx/dsk/TSTDG2/tst2                        10G    20M   9.4G     1%    /tst1/tst2
 

If ALL_LOCAL_DRIVES is selected and “cross mount points” is selected  all drives are backed up, but when it backs up “/” it picks up all the filesystems again. So we have 2 copies of the same backup

If ALL_LOCAL_DRIVES is selected and “cross mount points” is unchecked, then we do not get 2 copies, but submounts like /tst1/tst2 do not get backed up at all. Only /tst1 gets backed up

If ALL_LOCAL_DRIVES is selected and “cross mount points” in unchecked and “Allow multiple data streams” in unchecked, only one backup stream backs up all the local filesystem only once. This seems to get it right, but with only one stream

Is there a way we can get multiple data streams, picking up file-systems that are not local drives, without getting "/" twice and without having to specify the paths in the policy? (may be too much to ask for)