Slightly concerned by tape usage within our Netbackup environment, for the weekly backups (around 65 clients, some RMAN backups, 250GB Exchange dbase, 3 SAN Media servers, 2 media servers), its approximately 2 to 3 TB worth of data, about 1TB of that is being staged prior to being put onto tape). Weekly backups are run onto 16 tapes, (LTO2 drives), which i think is slightly excessive, (its hard within Netbackup to see how much data is on peice of media)
Compression isnt enabled within the policy, it is enabled on the drives though. Should i be enabling software compression aswell?
Retention isone factor to the usage of tapes. The fewer retention levels, the better...
remember each media/SAN media server uses its own tapes and will not share the tapes with any other media/San server. This is a big drawback to SSO/SAN configurations due to the high usage of tapes. You state you have 5 total servers. That would make a minimum of 5 tapes being used. The 16 tapes does not sound unreasonable when you take into account the number of media servers and retention levels.
I do not recommend software compession. It is a load on the server to perform the compression.
In normal circumstances you should not enable software compression. It makes your Backup run slower. There can be several reason for excessive tapes, like how many volume pools you are using. You can not share media between multiple pools. Your compression rate depends upon kind of backup data (db vs MP3 etc).
When NetBackup automatically selects a volume in a robot, it proceeds as follows:
I. Searches the NetBackup media catalog for a mounted volume that meets the following criteria:
* Same retention level as specified in the policy/schedule, unless the ALLOW_MULTIPLE_RETENSIONS_PER_MEDIA option is set * Same volume pool as specified in the policy/schedule * Not in a FULL, FROZEN, IMPORTED, or SUSPENDED state * Media is of the same density specified by the storage unit being used for this backup * Not currently in use * Not written in a protected format
II. If the above search finds no volumes, the same criteria are used and NetBackup searches through all non-mounted volumes in the robot.
III. If the media catalog does not have a suitable volume, NetBackup sends an assignment request to the Media Manager. The Media Manager selects an unassigned volume that must meet ALL of the following criteria:
* Is the correct media type. * Is for the correct robot type. * Is located in the requested robotic peripheral. * Resides on the requested host. * Is in the correct volume pool. * Is not currently assigned (not already allocated to NetBackup). * Is not expired (if expiration date is defined for the media) * Has not exceeded the maximum number of mounts allowed.
IV. If more than one volume qualifies, Media Manager assigns the one with the least mounts. NetBackup then adds this volume to the media catalog and assigns it the specified retention level.
V. If there are no unassigned volumes of the requested type, Media Manager will assign a volume from the scratch pool VI. If there are no appropriate volumes in the scratch pool (or if there is no scratch pool defined), the backup terminates with a status 96 ("no available media")
Couple of side notes:
- If a backup in progress reaches EOM (End Of Media) before the backup is complete the media selection logic is different: 1) Looks for unassigned media in the required pool or the scratch pool. 2) If there are no unassigned media NetBackup will then look at assigned media that meet the requirements.
- During the initial tape selection process NetBackup should not assign new media if the number of assigned media match the number of drives configured in the storage unit. Example: If you have 4 drives configured in the storage unit and 4 assigned tapes that match the criteria then NBU should not assign new media.
Graeme, You can see how much data is on a tape in the Media List Report in (either of the) Console(s). And I'm sure there are command line ways to dig that up too.
That being said, 16 tapes at 200GB capacity each is about 3TB worth of space. That's on the high side of your estimated data, but it's entirely likely that you're not filling up each and every tape.
I'd check the Media List Report and see how full each tape is; maybe you can reconfigure some things to force it to squeeze more data onto the tapes. (multiplexing, number of drives used at once, volume pool configurations, etc)
thanks for all the tips, from experience, i didnt think software compression was the way to go, i was hoping that id be getting close to max capacity on the tapes, especially for the RMAN and Exchange backups, obviously most types of files cant be compressed further (like the majority of the data thats being backed up)
the media list report is misleading, some tapes report over 600GB being used Im going to look into the possibility of doing incremental backups on the file and print servers, at least reduce the daily tape usage
Graeme, Having a report of 600GB used is actually not uncommon/impossible. That reports what the full file size (on disk) is of the files backed up.
If, for example, you backup a swap file, technically the swap file takes X amount of space on disk, but it may actually be using only a small % of that disk space (the rest would be filler space). Thus, the backup gets crazy good compression on it and is able to 'fit' more than 400GB onto a tape.
I have LTO2 tapes too and regularly see >400GB being reported on my Vault Duplications. Sometimes even as high at 800 or 900 GB.
David is right, >400GB on LTO-2 media is not impossible or uncommon. I do get something like this especially backing up the datafiles from database. This is because database like Oracle acquire the space while creating the tablespace but did not fill up all the blocks if there's no data. In another angle, its a sign that indicate the hardware compression of the drives works.
Another way of cutting down the media usage is to limit/lower the concurrent usage of drives in a storage unit. If you have a policy containing 10 clients and it will occupy 10 drives (assuming no multiplexing) once initiated. You could end up all media being half-filled (or less). Having lesser volume pool does help because NB can append its backup to the media if the volume pool defined for the backup are the same. Just another $0.02.