I would suggest following: do query with mminfo for that group and list all ssids with start/end times and ssid flags. This will also give you a clue which timestamps to check first in NW. My first thought was that something failed and perhaps you have retry attempts set to 1 or higher so it is doing it again (and completed status at this stage might be bogus), but we won't know for sure unless mdb data and daemon.raw is crosschecked. You can also find some details in /nsr/logs/sg/ and perhaps data there can make few things more clear.
Fact that you DR ssid failed may suggest that VSS on the box is acting funky and these can also impact sometimes fs backup as well.
I believe that this is because the DISASTER_RECOVERY:/ has swanned the C, D and WINDOWS ROLES AND FEATURES saveset and since WINDOWS ROLES AND FEATURED failed the DISASTER_RECOVERY:/ is assumed failed and has been retried again. This in-turn has initiated the entire backup again.
Fix the issue with WINDOWS ROLES AND FEATURED and the entire issue should go away.
Bring the group reties to 0 and then run the backups again. This will provide you a better error, that we can work with. Or, in case you have a email notification set up you should see the error there.
bingo.1
2.4K Posts
0
January 22nd, 2016 05:00
These are not the same save sets as they are started on different days.
Obviously, the major issue is that your savegroup runs longer than 1 day.
Why? - I have no idea. Could potentially be a configuration error but also a NW bug.
Which NW version do you run?
Let me also comment ...
1. The backup of D:\ lasts more than a day due to the huge number of obviously small files.
This means that the data rate is low causing the drive to reposition all the time which decreases the backup speed
even more.
Consequently you should consider to backup to disk (and to stage from here).
What you do right now is nothing else but "shoe-shining". This will stress your tape drive, your media ... and yourself.
2. The backup size for C:\ is strange as it switches between 2G and 20GB.
Looks weird, especially as the number of files do almost match exactly.
ble1
4 Operator
•
14.4K Posts
0
January 22nd, 2016 05:00
Hey bingo,
D is also double - see that one currently running
I would suggest following: do query with mminfo for that group and list all ssids with start/end times and ssid flags. This will also give you a clue which timestamps to check first in NW. My first thought was that something failed and perhaps you have retry attempts set to 1 or higher so it is doing it again (and completed status at this stage might be bogus), but we won't know for sure unless mdb data and daemon.raw is crosschecked. You can also find some details in /nsr/logs/sg/ and perhaps data there can make few things more clear.
Fact that you DR ssid failed may suggest that VSS on the box is acting funky and these can also impact sometimes fs backup as well.
crazyrov
4 Operator
•
1.3K Posts
0
January 22nd, 2016 23:00
Hi billma ,
I believe that this is because the DISASTER_RECOVERY:/ has swanned the C, D and WINDOWS ROLES AND FEATURES saveset and since WINDOWS ROLES AND FEATURED failed the DISASTER_RECOVERY:/ is assumed failed and has been retried again. This in-turn has initiated the entire backup again.
Fix the issue with WINDOWS ROLES AND FEATURED and the entire issue should go away.
billma1
2 Posts
0
January 24th, 2016 18:00
Hi Crazyrov
Then how can fix this issue?
crazyrov
4 Operator
•
1.3K Posts
0
January 25th, 2016 05:00
Bring the group reties to 0 and then run the backups again. This will provide you a better error, that we can work with. Or, in case you have a email notification set up you should see the error there.