It isn't just how much data you need to back up, it's also how long you want to keep that backup available, and how many backups you can run at once.
For example, to back up half a terabyte (512 gigabytes) of data twice a month would require a terabyte of storage, plus whatever space you'd need for incremental or differential backups between those base backups.
Another limitation is the number of backup jobs you can run. We currently have four tape drives and a disk array. In theory, we can run four tape-based backups at once and a few disk-based backups at the same time. In practice, though, it is not practical. For one thing, between the campus network and our fibre channel storage network, we have a limited amount of bandwidth. Secondly, we have to worry about the system load of the server handling the backups. The practical limit with our current hardware seems to be any combination of three backup jobs at once, with the exception of the base Causeway Users volume backup, which has a significant impact on the backup system during the seven or so hours it runs.
So we have a scheduling problem - we can only run so many jobs at once, and the jobs take as much time as is needed to transmit the data and write it to tape (slow) or disk (fast). As we add more servers, services and data, the backup system has to grow to handle the number of systems as well as the amount of data.