Unsolved
29 Posts
0
3290
November 24th, 2019 12:00
Scan Needed in Networker DDboost volume
Hi All,
I have a question and I hope anyone can help me.
We did a Disaster Recovery to migrate a Networker server, everything went well, backups running without problem, even successful restorations, we retrieved indexes with nsrck -L7, anyway.
Recently we are encountering certain things. Backups are made to Ddboost devices, and the DataDomain is filling up. Thoroughly investigating I see Volumes Disk in Scan Needed state, which is avoiding the recycling and recovery of space in these devices, I think that is why my DD is filling.
Looking for solutions, and taking the fact that we coming from a DR, I see that I have to launch a #scanner -m to update the media database with the exact volume information mounted there, right?
And after this, he would have to proceed to unmount the device, change his flag to Scan Not Needed, mount it and after all this, I will have to start seeing space claim in those volumes. I am right?
Also My Questions:
- Can the scanner -m be executed while backups are running? It is an environment with critical backups all the time.
- The backups made from the DR until the scanner is made, will be lost?
I hope I have explained myself and hopefully some help me out of the doubts.
It is an Networker 8.2.2.5 environment, about to be updated.
Thanks
Gonzalo Reyes



crazyrov
4 Operator
•
1.3K Posts
0
November 24th, 2019 23:00
@gonzalo.reyes,
First try resetting the flag on the device after un-mounting the volume on that device. NetWorker wants to make sure that the volume is consistent with the media database, if after resetting the state if it again flags the device as scan required then you might want to go ahead and scan that device.
I would not recommend running a scan and write to a volume at the same time even though it would work. it is best you get a volume out of the pool so that it is not used for backup and then run a scan on it assuming you have other devices in that volume. The scanner simply reads the data on the said device and populates the media database with that information, so no data will be lost as long as that data resides on the DD device. Avoid running the filesystem cleaning on the DD until all these tasks are complete to avoid data-loss in case of backup that are run after the bootstrap backup.
bingo.1
2.4K Posts
0
November 25th, 2019 00:00
Hi Gonzalo,
the scan flag shall remind you that the volume may contain save sets which have been created since the last bootstrap and are consequently not listed in a bootstrap backup yet. As a precaution, NW will not expire any save set on that volume. To 'resync' the data in the media db, you should use scanner -m -S ssid(s). Unfortunately, as NW has no information about the unknown save sets, you do not have any chance but to scan the whole media. NW will add any 'new' save set appropriately. Once you have done that, you can safely unset the flag for that media.
Yes, you can run scanner on your active backup volume at the same time but as crazyrow already mentioned, this is not really recommended. It is better to create a new device & volume for that pool and set the old one to 'readonly'.
gonzalo.reyes
29 Posts
0
November 25th, 2019 08:00
Thank you @bingo.1
So about your recommendation, is better to run first the #scanner -m , right? Then, unset the flag
Again, thanks a lot.
gonzalo.reyes
29 Posts
0
November 25th, 2019 08:00
Thanks @crazyrov
My doubts are more clear.
bingo.1
2.4K Posts
0
November 25th, 2019 09:00
You can of course use the "-i" option right away - it will save you some time, depending on the size of your volume. The question just is whether you need the CFI or if you just rely on save set recoveries.
gonzalo.reyes
29 Posts
0
November 25th, 2019 10:00
Ok @bingo.1
The -i only build the CFI, but -m only de Media Database? Or -i do both??
bingo.1
2.4K Posts
0
November 25th, 2019 11:00
Well - think. Then you can easily answer the question yourself. What would the CFI information be worth if you do not have the save set/volume info as well?
But the best learning curve would be if you verify that on a small volume yourself ...