Backup Central

Hello

The raid controller issue is resolved, but the problem persists.

I've been trying to figure this one out, but I'm really stuck.

NW server Win 7.6.3
One AFTD device (Media pool "Diskbackup")
One Library (LTO-3) with one drive (Media pool "Tapebackup")

Staging policy (have tried different settings, but this is current)
Source: AFTD "Diskbackup"
Target: "Tapebackup"
High watermark 50%
Low watermark 10%
Max storage period 4 days
Recover space interval 15 minutes
File system check 20 minutes

Ok, so heres the problem:
Backup writes to "Diskbackup" media pool on the AFTD
The AFTD reaches watermark and starts to stage.
When the staging starts it requests to read from AFTD "Diskbackup" and (!!) a tape in the "Tapebackup" media pool.

The "Tapebackup" tapes should only contain already staged savesets.
The mediapool "Tapebackup" is not target for anything except the staging policy.
So, if the AFTD ran out of space it would request a "default" media and not write to the "Tapebackup" tapes, or am I wrong ?

Why would the stage process need to stage already staged savesets ?

I've checked the savesets on the requested tapes and sometimes they contain head,middle or tail savesets, and sometimes not.

I've tried to set "recover space" interval down to 1 minute, because I've seen that NW sometimes only "recover space" from 30 Savesets at a time.

Because there is only one drive in the library this problem causes the
server to halt all backups, waiting for space on the AFTD and for read from the mentioned tape.
This in turn causes the Exchange server to halt when the logs fill up, among other things.

Any suggestions ?

Thanks
Eivind


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 2. desember 2011 10:24
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hi

Thank you for your reply.

I don't see how it can write the tail of a backup to a tape when there is only one drive and it is used to receive the stage job.
None of the savesets have other flag than 'c'

But, there is an issue with the raid controller on the backupserver and I will wait for it to be resolved to see if it may somehow be the casue.

Thanks
Eivind


-----Original Message-----
From: Small, Joshua [mailto:joshua.small < at > citi.com]
Sent: 24. november 2011 01:06
To: 'NETWORKER < at > LISTSERV.TEMPLE.EDU'; Eivind Antonsen
Subject: RE: staging problem

There was some changes in 7.6 that changed the way AFTD volumes work.
Previously, if your AFTD filled up during a save, the save would wait for space to become available in that volume.
Now, AFTDs are handled like a tape volume, and will continue the saveset on another volume.

Maybe your AFTD ran out of space, and the tail of the saveset was written to a tape?
So when you stage that ssid, it would need to read the start of the saveset from AFDT, and the end of it from tape - because staging acts on savesets, not chunks of savesets in a volume.

You could identify any continued savesets with 'mminfo -av', the 'c' flag in the output is complete, h is head (start of saveset), m is middle and t is tail.
Those last three flags all indicate that more than one volume is needed for that saveset.

Or, something like this will grab a list of all ssids on your AFTD volume, and then check what volume types and names contain each saveset

$ mminfo -av -q 'volume=your_aftd_volume_name' -r ssid | perl -ne 'chomp;system("mminfo -q ssid=$_ -xc, -r ssid,type,volume|grep -v ssid");'
(but won't work in a windows environment unless you've got perl/grep available, there's probably ways to do the same thing from windows with different tools though)

Regards,
Josh




7.6.2.681 (server and client)

The staging starts and requests to read from AFTD and a tape(!!)

What could make it need to read from a tape ?
How can I locate which savesets on this tape that it is trying to stage ?




via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

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_cloned.txt
mminfo -r ssid -q pool=Diskbackup > %SSIDFILE% for /f %%I in ('type "%SSIDFILE%"') do (
nsrstage -vvvvv -b Tapebackup -m -S %%I
)



-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 30. januar 2012 09:25
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hello

The raid controller issue is resolved, but the problem persists.

I've been trying to figure this one out, but I'm really stuck.

NW server Win 7.6.3
One AFTD device (Media pool "Diskbackup") One Library (LTO-3) with one drive (Media pool "Tapebackup")

Staging policy (have tried different settings, but this is current)
Source: AFTD "Diskbackup"
Target: "Tapebackup"
High watermark 50%
Low watermark 10%
Max storage period 4 days
Recover space interval 15 minutes
File system check 20 minutes

Ok, so heres the problem:
Backup writes to "Diskbackup" media pool on the AFTD The AFTD reaches watermark and starts to stage.
When the staging starts it requests to read from AFTD "Diskbackup" and (!!) a tape in the "Tapebackup" media pool.

The "Tapebackup" tapes should only contain already staged savesets.
The mediapool "Tapebackup" is not target for anything except the staging policy.
So, if the AFTD ran out of space it would request a "default" media and not write to the "Tapebackup" tapes, or am I wrong ?

Why would the stage process need to stage already staged savesets ?

I've checked the savesets on the requested tapes and sometimes they contain head,middle or tail savesets, and sometimes not.

I've tried to set "recover space" interval down to 1 minute, because I've seen that NW sometimes only "recover space" from 30 Savesets at a time.

Because there is only one drive in the library this problem causes the server to halt all backups, waiting for space on the AFTD and for read from the mentioned tape.
This in turn causes the Exchange server to halt when the logs fill up, among other things.

Any suggestions ?

Thanks
Eivind


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 2. desember 2011 10:24
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hi

Thank you for your reply.

I don't see how it can write the tail of a backup to a tape when there is only one drive and it is used to receive the stage job.
None of the savesets have other flag than 'c'

But, there is an issue with the raid controller on the backupserver and I will wait for it to be resolved to see if it may somehow be the casue.

Thanks
Eivind


-----Original Message-----
From: Small, Joshua [mailto:joshua.small < at > citi.com]
Sent: 24. november 2011 01:06
To: 'NETWORKER < at > LISTSERV.TEMPLE.EDU'; Eivind Antonsen
Subject: RE: staging problem

There was some changes in 7.6 that changed the way AFTD volumes work.
Previously, if your AFTD filled up during a save, the save would wait for space to become available in that volume.
Now, AFTDs are handled like a tape volume, and will continue the saveset on another volume.

Maybe your AFTD ran out of space, and the tail of the saveset was written to a tape?
So when you stage that ssid, it would need to read the start of the saveset from AFDT, and the end of it from tape - because staging acts on savesets, not chunks of savesets in a volume.

You could identify any continued savesets with 'mminfo -av', the 'c' flag in the output is complete, h is head (start of saveset), m is middle and t is tail.
Those last three flags all indicate that more than one volume is needed for that saveset.

Or, something like this will grab a list of all ssids on your AFTD volume, and then check what volume types and names contain each saveset

$ mminfo -av -q 'volume=your_aftd_volume_name' -r ssid | perl -ne 'chomp;system("mminfo -q ssid=$_ -xc, -r ssid,type,volume|grep -v ssid");'
(but won't work in a windows environment unless you've got perl/grep available, there's probably ways to do the same thing from windows with different tools though)

Regards,
Josh




7.6.2.681 (server and client)

The staging starts and requests to read from AFTD and a tape(!!)

What could make it need to read from a tape ?
How can I locate which savesets on this tape that it is trying to stage ?






via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

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;>


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 31. januar 2012 12:06
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

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_cloned.txt
mminfo -r ssid -q pool=Diskbackup > %SSIDFILE% for /f %%I in ('type "%SSIDFILE%"') do (
nsrstage -vvvvv -b Tapebackup -m -S %%I
)



-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 30. januar 2012 09:25
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hello

The raid controller issue is resolved, but the problem persists.

I've been trying to figure this one out, but I'm really stuck.

NW server Win 7.6.3
One AFTD device (Media pool "Diskbackup") One Library (LTO-3) with one drive (Media pool "Tapebackup")

Staging policy (have tried different settings, but this is current)
Source: AFTD "Diskbackup"
Target: "Tapebackup"
High watermark 50%
Low watermark 10%
Max storage period 4 days
Recover space interval 15 minutes
File system check 20 minutes

Ok, so heres the problem:
Backup writes to "Diskbackup" media pool on the AFTD The AFTD reaches watermark and starts to stage.
When the staging starts it requests to read from AFTD "Diskbackup" and (!!) a tape in the "Tapebackup" media pool.

The "Tapebackup" tapes should only contain already staged savesets.
The mediapool "Tapebackup" is not target for anything except the staging policy.
So, if the AFTD ran out of space it would request a "default" media and not write to the "Tapebackup" tapes, or am I wrong ?

Why would the stage process need to stage already staged savesets ?

I've checked the savesets on the requested tapes and sometimes they contain head,middle or tail savesets, and sometimes not.

I've tried to set "recover space" interval down to 1 minute, because I've seen that NW sometimes only "recover space" from 30 Savesets at a time.

Because there is only one drive in the library this problem causes the server to halt all backups, waiting for space on the AFTD and for read from the mentioned tape.
This in turn causes the Exchange server to halt when the logs fill up, among other things.

Any suggestions ?

Thanks
Eivind


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 2. desember 2011 10:24
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hi

Thank you for your reply.

I don't see how it can write the tail of a backup to a tape when there is only one drive and it is used to receive the stage job.
None of the savesets have other flag than 'c'

But, there is an issue with the raid controller on the backupserver and I will wait for it to be resolved to see if it may somehow be the casue.

Thanks
Eivind


-----Original Message-----
From: Small, Joshua [mailto:joshua.small < at > citi.com]
Sent: 24. november 2011 01:06
To: 'NETWORKER < at > LISTSERV.TEMPLE.EDU'; Eivind Antonsen
Subject: RE: staging problem

There was some changes in 7.6 that changed the way AFTD volumes work.
Previously, if your AFTD filled up during a save, the save would wait for space to become available in that volume.
Now, AFTDs are handled like a tape volume, and will continue the saveset on another volume.

Maybe your AFTD ran out of space, and the tail of the saveset was written to a tape?
So when you stage that ssid, it would need to read the start of the saveset from AFDT, and the end of it from tape - because staging acts on savesets, not chunks of savesets in a volume.

You could identify any continued savesets with 'mminfo -av', the 'c' flag in the output is complete, h is head (start of saveset), m is middle and t is tail.
Those last three flags all indicate that more than one volume is needed for that saveset.

Or, something like this will grab a list of all ssids on your AFTD volume, and then check what volume types and names contain each saveset

$ mminfo -av -q 'volume=your_aftd_volume_name' -r ssid | perl -ne 'chomp;system("mminfo -q ssid=$_ -xc, -r ssid,type,volume|grep -v ssid");'
(but won't work in a windows environment unless you've got perl/grep available, there's probably ways to do the same thing from windows with different tools though)

Regards,
Josh




7.6.2.681 (server and client)

The staging starts and requests to read from AFTD and a tape(!!)

What could make it need to read from a tape ?
How can I locate which savesets on this tape that it is trying to stage ?








via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

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;>


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 31. januar 2012 12:06
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

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_cloned.txt
mminfo -r ssid -q pool=Diskbackup > %SSIDFILE% for /f %%I in ('type "%SSIDFILE%"') do (
nsrstage -vvvvv -b Tapebackup -m -S %%I
)



-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 30. januar 2012 09:25
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hello

The raid controller issue is resolved, but the problem persists.

I've been trying to figure this one out, but I'm really stuck.

NW server Win 7.6.3
One AFTD device (Media pool "Diskbackup") One Library (LTO-3) with one drive (Media pool "Tapebackup")

Staging policy (have tried different settings, but this is current)
Source: AFTD "Diskbackup"
Target: "Tapebackup"
High watermark 50%
Low watermark 10%
Max storage period 4 days
Recover space interval 15 minutes
File system check 20 minutes

Ok, so heres the problem:
Backup writes to "Diskbackup" media pool on the AFTD The AFTD reaches watermark and starts to stage.
When the staging starts it requests to read from AFTD "Diskbackup" and (!!) a tape in the "Tapebackup" media pool.

The "Tapebackup" tapes should only contain already staged savesets.
The mediapool "Tapebackup" is not target for anything except the staging policy.
So, if the AFTD ran out of space it would request a "default" media and not write to the "Tapebackup" tapes, or am I wrong ?

Why would the stage process need to stage already staged savesets ?

I've checked the savesets on the requested tapes and sometimes they contain head,middle or tail savesets, and sometimes not.

I've tried to set "recover space" interval down to 1 minute, because I've seen that NW sometimes only "recover space" from 30 Savesets at a time.

Because there is only one drive in the library this problem causes the server to halt all backups, waiting for space on the AFTD and for read from the mentioned tape.
This in turn causes the Exchange server to halt when the logs fill up, among other things.

Any suggestions ?

Thanks
Eivind


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 2. desember 2011 10:24
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hi

Thank you for your reply.

I don't see how it can write the tail of a backup to a tape when there is only one drive and it is used to receive the stage job.
None of the savesets have other flag than 'c'

But, there is an issue with the raid controller on the backupserver and I will wait for it to be resolved to see if it may somehow be the casue.

Thanks
Eivind


-----Original Message-----
From: Small, Joshua [mailto:joshua.small < at > citi.com]
Sent: 24. november 2011 01:06
To: 'NETWORKER < at > LISTSERV.TEMPLE.EDU'; Eivind Antonsen
Subject: RE: staging problem

There was some changes in 7.6 that changed the way AFTD volumes work.
Previously, if your AFTD filled up during a save, the save would wait for space to become available in that volume.
Now, AFTDs are handled like a tape volume, and will continue the saveset on another volume.

Maybe your AFTD ran out of space, and the tail of the saveset was written to a tape?
So when you stage that ssid, it would need to read the start of the saveset from AFDT, and the end of it from tape - because staging acts on savesets, not chunks of savesets in a volume.

You could identify any continued savesets with 'mminfo -av', the 'c' flag in the output is complete, h is head (start of saveset), m is middle and t is tail.
Those last three flags all indicate that more than one volume is needed for that saveset.

Or, something like this will grab a list of all ssids on your AFTD volume, and then check what volume types and names contain each saveset

$ mminfo -av -q 'volume=your_aftd_volume_name' -r ssid | perl -ne 'chomp;system("mminfo -q ssid=$_ -xc, -r ssid,type,volume|grep -v ssid");'
(but won't work in a windows environment unless you've got perl/grep available, there's probably ways to do the same thing from windows with different tools though)

Regards,
Josh




7.6.2.681 (server and client)

The staging starts and requests to read from AFTD and a tape(!!)

What could make it need to read from a tape ?
How can I locate which savesets on this tape that it is trying to stage ?








via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Hi

This morning it is asking for a tape again.

It seems it always is an Exchange saveset which is the culprit. (not sure though)

The original saveset is on Diskbackup.001 (0, c) Savetime 31.01.2012 23:16:32 (Pool Diskbackup) 555GB

There is a cloned saveset on two tape volumes
LBL0116L3 (1000.0, h) 493 GB , LBL0088L3(100.0, t) 64 GB Savetime 31.01.2012 23:16:32 (Pool Tapebackup)

It starts to stage from the Diskbackup AFTD and for some reason in the middle of the stage process it wants to clone the tail saveset on LBL0088L3 which has already been staged to the Tapebackup pool.

I am clueless here.......

..and the script I was running is just for troubleshooting, it is not an option to be used as a solution.

E;>

----------------------


From: DE VENTE Gert
Sent: 1. februar 2012 08:32
Subject: nsrstage

set SSIDFILE=SSIDs_to_be_cloned.txt
mminfo -r ssid -q pool=Diskbackup > %SSIDFILE% for /f %%I in ('type "%SSIDFILE%"') do (
nsrstage -vvvvv -b Tapebackup -m -S %%I
)


Try

mminfo -r ssid -q "family=disk,copies<3"

This will handle only savesets which have only 2 copies on the ATFD (RW + RO). Your selection does not check for this and as the cloneID for tape-clone is less than the RW or RO, a saveset selected from tape will be staged based on the SSID.


With kind regards,

ing. Gert de Vente

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 31. januar 2012 12:46
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

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;>


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 31. januar 2012 12:06
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

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_cloned.txt
mminfo -r ssid -q pool=Diskbackup > %SSIDFILE% for /f %%I in ('type "%SSIDFILE%"') do (
nsrstage -vvvvv -b Tapebackup -m -S %%I
)



-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 30. januar 2012 09:25
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hello

The raid controller issue is resolved, but the problem persists.

I've been trying to figure this one out, but I'm really stuck.

NW server Win 7.6.3
One AFTD device (Media pool "Diskbackup") One Library (LTO-3) with one drive (Media pool "Tapebackup")

Staging policy (have tried different settings, but this is current)
Source: AFTD "Diskbackup"
Target: "Tapebackup"
High watermark 50%
Low watermark 10%
Max storage period 4 days
Recover space interval 15 minutes
File system check 20 minutes

Ok, so heres the problem:
Backup writes to "Diskbackup" media pool on the AFTD The AFTD reaches watermark and starts to stage.
When the staging starts it requests to read from AFTD "Diskbackup" and (!!) a tape in the "Tapebackup" media pool.

The "Tapebackup" tapes should only contain already staged savesets.
The mediapool "Tapebackup" is not target for anything except the staging policy.
So, if the AFTD ran out of space it would request a "default" media and not write to the "Tapebackup" tapes, or am I wrong ?

Why would the stage process need to stage already staged savesets ?

I've checked the savesets on the requested tapes and sometimes they contain head,middle or tail savesets, and sometimes not.

I've tried to set "recover space" interval down to 1 minute, because I've seen that NW sometimes only "recover space" from 30 Savesets at a time.

Because there is only one drive in the library this problem causes the server to halt all backups, waiting for space on the AFTD and for read from the mentioned tape.
This in turn causes the Exchange server to halt when the logs fill up, among other things.

Any suggestions ?

Thanks
Eivind


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Eivind Antonsen
Sent: 2. desember 2011 10:24
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] staging problem

Hi

Thank you for your reply.

I don't see how it can write the tail of a backup to a tape when there is only one drive and it is used to receive the stage job.
None of the savesets have other flag than 'c'

But, there is an issue with the raid controller on the backupserver and I will wait for it to be resolved to see if it may somehow be the casue.

Thanks
Eivind


-----Original Message-----
From: Small, Joshua [mailto:joshua.small < at > citi.com]
Sent: 24. november 2011 01:06
To: 'NETWORKER < at > LISTSERV.TEMPLE.EDU'; Eivind Antonsen
Subject: RE: staging problem

There was some changes in 7.6 that changed the way AFTD volumes work.
Previously, if your AFTD filled up during a save, the save would wait for space to become available in that volume.
Now, AFTDs are handled like a tape volume, and will continue the saveset on another volume.

Maybe your AFTD ran out of space, and the tail of the saveset was written to a tape?
So when you stage that ssid, it would need to read the start of the saveset from AFDT, and the end of it from tape - because staging acts on savesets, not chunks of savesets in a volume.

You could identify any continued savesets with 'mminfo -av', the 'c' flag in the output is complete, h is head (start of saveset), m is middle and t is tail.
Those last three flags all indicate that more than one volume is needed for that saveset.

Or, something like this will grab a list of all ssids on your AFTD volume, and then check what volume types and names contain each saveset

$ mminfo -av -q 'volume=your_aftd_volume_name' -r ssid | perl -ne 'chomp;system("mminfo -q ssid=$_ -xc, -r ssid,type,volume|grep -v ssid");'
(but won't work in a windows environment unless you've got perl/grep available, there's probably ways to do the same thing from windows with different tools though)

Regards,
Josh




7.6.2.681 (server and client)

The staging starts and requests to read from AFTD and a tape(!!)

What could make it need to read from a tape ?
How can I locate which savesets on this tape that it is trying to stage ?










via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

I would also look at the save set status because by default, NW does not read a suspect save set.

There is a known issue with NW cloning/staging a disk backup at least for NW 7.6.1 & 7.6.2:
When encountering a write problem, NW will set all remaining save sets in his worklist to suspect.
You are right - as this is a write problem, it should not happen to the source (disk) media but in fact it does. Now, depending how you clone/stage, let's assume that this could only occur for a single save set. Before you start a retry, you must first clear the suspect flag. If not, it would be obvious for NW to use a save set from another media during a retry. And the only chance it has is a(n incomplete) tape instance.

I would at least look in this direction.