teri.e36

10 Posts

1121

January 6th, 2011 09:00

Recover from backup pool by default?

In previous versions of networker, when I used `recover` in interactive mode it would always try to recover data from the backup pool, and it would only use the clone pool if for some reason the original saveset was not browsable. Since version 7.5 that behavior seems to be reversed. Now when I run recover, if the backup pool volumes are not online, it often (always?) requests the clone pool volumes instead. This is a problem because all of our clone volumes are offsite.

The only workaround I have found thus far is to manually figure out which backup volumes the data is on (sometimes a difficult task if the last full backup was several weeks ago and the data has changed many times since then), and make sure all the backup volumes are online before running recover. There are times this just isn't realistic, or even possible. Is there a way to change this so that recover always prefers the original backup volume? I know we could mark all savesets on the clone volumes as suspect, but that's a big hassle and shouldn't be necessary.

Responses(4)

David_Hampson_90e289

243 Posts

0

January 7th, 2011 02:00

Teresa

The priority given to which tape which will be used is on p225 of the current administrator's guide:

No special operation is required to recover cloned data. The volume, either a clone or

original volume, that is selected for a recovery operation is determined as follows:

1. The highest priority is given to the volume (clone or original volume) that has a

complete, non-suspect save set status. A complete save set that is suspect has a

higher priority than an incomplete non-suspect save set.

“Changing save set status within the Volume Save Sets window” on page 311

provides information about changing the status of a save set.

2. If the volumes still have equal priority, then priority is given to the mounted

volume.

3. If the volumes are mounted, then priority is based on the media type. The media

types from highest to lowest priority are:

a. Advanced file type device

b. File type device

c. Other (such as tape or optical)

4. If the volumes are not mounted, then priority is based on the media location. The

media locations from highest to lowest priority are:

a. Volumes in a library

b. Volumes in an AlphaStor or SmartMedia controlled library

c. Volumes that are not in a library but are onsite (offsite flag is not set).

d. Volumes that are offsite (offsite flag is set)

Use the nsrmm command to specify that a volume is offsite. For example:

nsrmm -o offsite -V volume_id

The volumes required for recovery appear in the Required Volumes window of the

nwrecover (UNIX) or NetWorker User (Windows) programs. “Viewing the volumes

required for data recovery” on page 324 provides more information.

If you follow the list down comparing the status of the original and clone you should be able to see where the decision to use the clone volume comes from; I don't believe this behaviour has changed in recent versions which suggests the difference may be down to changes in your cloning and/or tape handling policies.

teri.e36

10 Posts

0

January 11th, 2011 09:00

Based on this list, our backup pool tapes and clone tapes are identical all the way down, and they have been for at least the last 5 years. Not sure what could have caused the change in what we're seeing. We've never used the offsite flags (never had a reason to add yet another step to our process until now), so it looks like that's what we'll have to start doing. Thanks for your help in finding that information.

David_Hampson_90e289

243 Posts

0

January 12th, 2011 01:00

I believe there have been some media database changes with regards to clones recently so I'm not too sure if this may have some impact here. Hopefully one of the EMC guys with internal knowledge may be able to comment further....

coganb

736 Posts

0

January 12th, 2011 05:00

Hi,

There was a bug in the software (reference NW119432) which caused the volume selection criteria to be incorrect in NetWorker 7.5.x which might correspond to the change in behaviour that you are seeing. This was discussed here a while back and the patch did solve the issue:

https://community.emc.com/thread/111566?tstart=0

This is fixed in NetWorker 7.6.1 and there is a fix available in the latest cumulative version of 7.5.3 which is available here:

ftp://ftp.legato.com/pub/NetWorker/Cumulative_Hotfixes/

-Bobby

View All

No Events found!