06-29-2012 05:35 AM
Hi,
since a week we notice a high scratch tape consumption. We thoght to find the root cause in large backups by querying the Client Backups.
We actually found some clients with a high number of Kilobytes. But after reducing their backup frequency (static data) we still see high scratch tape consumption.
I would to share some experiences with other NBU 7 admins. Can you recommend a strategy?
Regards,
Fred
06-29-2012 05:49 AM
- do you mean actually "reducing how often their backups take place" or "reducing the frequency in their policies"? They mean totally the opposite things!
Suggestions to reduce tape consumption (would depend on your environment, but a few ideas):
- don't have a lot of different retention periods (NB does not mix retention periods on tape by default)
- use incremental backups wherever possible
- leave media in library longer if possible so data can be appended to
- increase multi-plexing per drive
Did you actually manage to isolate *why* you used more tapes than expected or is that what you need assistance with? To actually identify the media, quickest way initially would be to just sort by "Time Assigned" in the GUI & go from there.
***EDIT***
Another thought! It could also be possible that you're having drive or media issues (or both) resulting in more FROZEN media - maybe worth checking for them too.
06-29-2012 06:26 AM
In addition to Andy's excellent post, you can also compare 'Tapes written report'.
Customize date ranges - run a report for 3 weeks ago, 2 weeks ago, 1 week ago.
NBU keeps logs for 28 days by default, so, depending on whether or no your 'days to keep logs' have been customized, you should be able to go back up to 4 weeks.
As Andy has pointed out - lots of different retention levels will use more tapes.
It is NOT recommended to allow multiple retentions on media - this solves short-term media usage problem, but creates massive headaches in the long-run.
Another factor is the amount of media servers.
The more media servers, the more media will be used.
Media servers do not share media by default. Media usage can be greatly improved by enabling Media Sharing.
06-29-2012 06:52 AM
take a look at this technote: URL http://www.symantec.com/docs/HOWTO33855
Though it claims it 'does not apply to scratch volumes', it can affect Scratch Pool if excessive number of partially full media are allocated for backup.
06-29-2012 07:09 AM
Thank for the updates.
- do you mean actually "reducing how often their backups take place" or "reducing the frequency in their policies"? They mean totally the opposite things!
What I meant here is taking a good look at the type of the data that has to be backuped up. If e.g. 1,4 Tb contains static data (archive) than a daily backup is not needed.
I shall focus 1st on:
In addition to Andy's excellent post, you can also compare 'Tapes written report'.
Customize date ranges - run a report for 3 weeks ago, 2 weeks ago, 1 week ago
Regards,
Fred
06-29-2012 07:22 AM
Again, depending on how you have your environment set up (as you *may* just have one large volume pool), once you've isolated which media are involved you could follow this up with the 'Images on Tape' report to determine which policies/schedules were involved.....
06-30-2012 03:04 AM
It won't be hard to find out which group of clients/policies suddenly consuming more tapes than ever.
Then it comes down to whether:
- Recently change of backup selection to include more data.
- Recently addition of more clients into a single policy
- Frozen tapes in original volume pool - can't reuse causing new backup not able to write into them.
- Incremental backup running like a full backup - this is very common issue, sometimes due to archive bit, timestamp or even Netbackup bug.
07-18-2012 09:40 AM
H Marianne
I would like to enable media sharing. We have 2 NDMP hosts and a windows media server. This uses 10 tapes instead of 4.
If we could get the media servers to append each time it would be great.
So the questions is, how do we enable media sharing.
Your assistance is apprecaited.
thanks
Andy
07-18-2012 09:55 AM
Please create a new thread!