Try to run this in a command prompt:

mminfo -av -q "pool=Diskbackup,volume=*a tape*" -r "ssid,cloneid"

Where *a tape* is a tape volume like 000345L3 ro whatever they're called. You might have to repeat this for a number of tapes.

This will reveal any savesets that's ended up on the tape even though they're in the Diskbackup pool.

/tony

Oh yeah, and check you recycle from/to settings. Volumes might have been recycled to a wrong pool.

/tony

Hi

I had taken steps to make sure there was successful backups by bypassing the Diskbackup all togheter.

Have now set it back to make the problem occur again.

Will try the command on the tape it requests and post my findings here.

Thanks

Eivind

Hi again

Recycle to/from is not set.

The mminfo command gives the following output:

6095:mminfo: no matches found for the query

E;>

Hi mridul.singh

mminfo -t "one week ago" -r name,volume,pool,copies,ssid,cloneid -avot

reports all backups in tapebackup pool, but that could be because I'm currently running a script which is emptying the AFTD.

Will try to run a few backups and run the command again.

edit:

All backups which have 2 are on the Diskbackup device

All backups which have 1 are on the Tapebackup device

/edit

1. restrict the devices in the media pool, so that adv_file is selected in diskbackup and Tape is selected in tape backup. This will avoid any backups going to the staging pool.

Diskbackup pool has always only had AFTD and AFTD.RO device selected

Tapebackup pool has always only had the tape device selected

2. Please check that both write and RO device for the adv_file device is selected in the source device list for the staging policy. Also the RO should be enabled and mounted.

Diskbackup pool has always only had AFTD and AFTD.RO device selected

The RO device has always been enabled

3. For the staging rule:

High water mark: 55

Low water mark: 15

Recover space interval: 5 mins

File system check interval: 2 min

Max storage period: 2 days

saveset selection; oldest saveset

Will try setting the rule as above

Thanks

Regards

Eivind

Hi Tony

All SS are in same pool (Tapebackup) they all have one of the following flags: vF vKF or vrF

This morning it was asking for a tape again, I terminated the nsrstage process and I am currently running the following script to see if it will ask for a tape.

set SSIDFILE=SSIDs_to_be_staged.txt

mminfo -r ssid -q pool=Diskbackup > %SSIDFILE% for /f %%I in ('type "%SSIDFILE%"') do (

   nsrstage -vvvvv -b Tapebackup -m -S %%I

)

E;>

If mminfo says no matches found that means there is no backup written to tape or it has been over written by staging.

if you feel that backup is going to tape rather than going to disk, or may be going to both, use mminfo to check where the backups are getting written.

mminfo -t "one week ago" -r name,volume,volumepool,copies,ssid/cloneid -avot

if for any backup the number of copies is 2 it should be on the adv_file volume, and if it is 1 it should be on tape volume/file type device. If mminfo reports the same savesets in the same media pool then definetely there is some issue with the backup/staging.

Coming back to the original problem, if the backup is going to adv_file, then there will be not hb,mb ot tb, because all the savesets will be contained on the same volume. But the same saveset if is big enough to be staged on one volume or if there is less space on the volume, it may be split into hb,mb,tb.

To simplify it, i would suggest the following:

1. restrict the devices in the media pool, so that adv_file is selected in diskbackup and Tape is selected in tape backup.

This will avoid any backups going to the staging pool.

2. Please check that both write and RO device for the adv_file device is selected in the source device list for the staging policy. Also the RO should be enabled and mounted.

3. For the staging rule:

High water mark: 55

Low water mark: 15

Recover space interval: 5 mins

File system check interval: 2 min

Max storage period: 2 days

saveset selection; oldest saveset

If the system starts working then, you may fine tune the staging policy as required.

Ok, let's try to reverse the search then:

mminfo -av -q "volume=*a tape*" -r "pool,ssid,cloneid,client,ssflags" > mminfo.out

Then import mminfo.out into a spreadsheet and look through it and see if anything looks odd. This will take some time, but we need some sort of indicationas to what we should look for.

/tony

Hi

The script has now reached a SS which makes the stage process ask for a tape.

When searching for the SS under "Media->Save Sets" I find that the SS "original" is 555GB and is located on the Diskbackup device.

Diskbackup.001 (0, c)

It has two clones, one from the stage process last night and

one from my script now running

BTK301L3 (1000.0, h), LB0116L3 (8.0, t)

BTK292L3 (1000.0, h), LB0088L3 (100.0, t)

The stage process is asking for tape LB0088L3

When I list the savesets on the tape I find the one it wants to read and it is 33GB in size and has a "tb" flag.

I know if I run a "nsrmm -d -S SSID" and delete the saveset on LB0088L3 and then start the stage process again it will not ask for a tape when performing stage.

I belive the (0, c) on the diskbackup device means it is complete..?

What makes it want to read from a tail of a cloned saveset ?

E;>

Mark the cloned savesets as suspect and then try to do the staging for this particular saveset.