I'll guess that this is a single, non-robotic drive directly attached to some server. And there's no budget, or practically no budget. Your options are:
Go through the source data and see if you can delete or exclude parts from your backup set.
- PRO: costs and backup job definitions stay what they are.
- CON: whatever is deleted is gone; whatever is excluded doesn't get backed up; if data grows in "excluded" areas, it will also be silently excluded which might not be what you want
Figure out how to split the backup into two jobs and run the two jobs on different nights on different tapes.
- PRO: everything that needs backing up gets backed up.
- CONS: cost (tape footprint doubles); having two jobs means someone has to put the right tape in the drive at the right time twice as frequently; two jobs means you have to be careful how things grow to ensure both that A) neither job grows disproportionately; and B) new things are actually caught by only one of the two jobs
Buy a bigger tape drive (hello, LTO-4!)
- PRO: puts off the job-splitting or data-deletion decision for a while.
- CON: cost++; possibly not reverse-compatible with the media you already have history on which means you have to keep the old drive around and working just in case.
Buy a robot that will auto-change tapes for you.
- PRO: if your software can handle tape-spanning jobs, you no longer have to worry about such pedestrian concerns, just keep shoveling media into it; such software can probably handle your existing drive as well, which gives you potential access to your history; this solution will scale up at much better than any single drive solution (ie solves the problem for the next three years, not just the next six months)
- CON: cost+++ (at the very least you have to buy the robot, which is expensive; you probably will have to buy robotic slot licenses for your software, which are expensive; you might have to totally replace your software with something that can handle tape-spanning jobs and robots, which is expensive and risks you not having access to your current history)
Find some backup-over-the-internet scheme.
- PRO: your hardware, media, storage and retention issues become someone else's problem.
- CON: your internet connection needs to be able to upload at a reasonable data rate so that your backup can finish in a reasonable time frame; your internet connection should have a transfer limit which will permit you to perform these backups; backups will be slow; restores will very probably be just as slow; cost (since the service provider is undoubtedly doing this to a modern backup facility, which means you are paying for all that plus a profit for the backup service provider)
Backups are something that many people have written essays on.
You have to know what the window of recovery is -- it ranges from "I want to recover the file I deleted ten minutes ago (or six months ago) NOW!" to "eh, if I have to wait a week for a tape to be delivered from offsite, that's cool."
You have to know if these are backups for disaster recovery (ie the building burned down!) or auditing (proof of state on a certain date) or user-level recovery (someone deleted account X instead of Y) or file-level recovery (some secretary accidentally pasted a Facebook entry over the company's financials). The answers to these questions will drive how backups are done.
If there are rules to backups, they are usually:
- backup everything
- keep it forever
- keep it offsite
Budgets will limit how much of each you can actually do, but the people in charge of the company need to know what is and is not being backed up and what the implications of those facts are. Backups are important to a company's ability to survive technical (and sometimes personnel) failures. They need to be approved by someone delegated this responsibility from a C-level.
You can't win. When you are asking for robots, media, and software, they will say "we don't need to back up X." However in an emergency, they will be yelling at you "why didn't you back up X?"
At my customers, every six months I prepare a document that details exactly what is being backed up, and I note every important set of objects (that I know about, heh) that are NOT being backed up, and I email it to the customer and then spend 30 minutes with them to review it. That way they know what is being backed up, what I think isn't being backed up, backup run time and data requirements, data retention policies, offsite details, a review of the major problems (and hopefully solutions) from the past six months, plus anything else I think is important. I ask them if they are aware of anything else that needs backing up. If any changes are required, I make them, re-send the document, and file those emails away as proof I sent them the documents. Realistically if something important isn't being backed up my ass will still be in a sling, but in most cases it will have company.
Backups are a huge, expensive, complex can of worms.