Sizing up your environment for backups to tape

So, you just spent many long hours putting together your latest and greatest creation. Hot off the presses, you have a true work of art. Now what? You are being audited on backups? You realize that there was no money for backup gear in the budget, but having this kind of risk over your head can only be viewed as something to offload to an over-taxed shared services IT department at your org or a chance to play russian roullette with your data? No! It’s time to get an accurate assessment of what you need to backup and get your tape requirements sorted out so that you can present a case for your backups and any needed gear to get the job done. Don’t worry, you may not have to spend 2 trillion dollars on gear (unless you work for the government), especially if you already have a working environment to do your existing backups and just need to find/make capacity on the tape SAN. That being said, you still need to know what you’ll need to do or ask for and how can you do that if you just go to upper management and say, ” I just got an Exadata and I need at least 48×365 = 17520 TB of capacity in my tape backup gear to make sure we are covered for the year. Let’s not be greedy. Even the most novice executive will question the costs needed to satisfy that kind of requirement.

Making the assumption that you are using RMAN, you have already configured your backups to run a weekly full on each database to tape once per week, incrementals daily, and a reasonable amount of archivelogs being generated daily to the Fast Recovery Area, we can proceed to estimate your immediate needs.

If you are running Oracle and you are using RMAN, you can get the sizing numbers you need for your tape requirements somewhat easily if you are already taking backups to your Fast Recovery Area. There are a number of different views that can provide information about your backups, but I have found the most beneficial information can be gathered from the views used here. The helpful script that follows can be run to collect data on all the different types of backups you are currently running and the sizes (this script allows you to feed a list of SIDs):

#!/bin/bash

. /home/oracle/.bash_profile

ORAENV_ASK=NO

for DB in `echo “$DB_LIST”`; do
export ORACLE_SID=$DB
. oraenv $DB >/dev/null

echo “Database: $DB”

sqlplus -s \/ as sysdba<<EOF
set serveroutput on
set linesize 150
set pagesize 300

select ctime “Date”,

decode(backup_type, ‘L’, ‘Archive Log’, ‘D’, ‘Full’, ‘Incremental’) backup_type,bsize “Size GB” from (select trunc(bp.completion_time) ctime, backup_type, round(sum(bp.bytes/1024/1024/1024),2) bsize

from v\$backup_set bs,

v\$backup_piece bp where bs.set_stamp = bp.set_stamp and bs.set_count  = bp.set_count and bp.status = ‘A’ group by trunc(bp.completion_time), backup_type) order by 1, 2;

exit;
EOF
done

You can then look at the history of your current backups and right-size your tape requirements.

You might also check how many archive logs you are generating in a week under full production load:

col gbytes form 999,999.99

select sum(blocks*block_size)/1024/1024/1024 gbytes

from v$archived_log

where next_time > sysdate-8;

Some things to consider when you decide on your tape solution:

The type of tape drives

Encryption needs

The amount of compression

The number of tape drives

The type of backup software (OSB vs Netbackup vs Tivoli)

Your vaulting schedule (number of available media slots)

How fast can your channel send the data to the tape drives

Assuming you already have a tape SAN and you are not given enough money in your budget or enough lead time to get the gear in place before an audit, you might consider looking at what you have now in place and checking to see if you are doing too many backups, you have tuned your backups incorrectly, or if you have a number of backups that would benefit from VTL or dedup technologies in order to free space on your existing tape infrastructure.