If the logs are full, then yes you will probably be looking at needing the same space to backup them up.
If you're running SQL Server 2008 Enterprise then you may find that enabling backup compression will save you plenty of space, unfortunately the only way to really find out how much is to run the backup (do you have a dev environment where you could restore a copy to?).
The other option if you don't need the ability to restore to a point in Time previous to when you do this, would be to:
put the database into Simple Recovery mode
Checkpoint
put database back into Full Recovery
Take Full backup
Start taking log backups.
By putting the database into Simple Recovery you break the log chain, so when you move back to Full Recovery there will be no log as such for the first log backup to take. Don't forget to take the Full Backup so that SQL Server can start a new log chain.
As mentioned this will mean you'd lose the ability to recover the database to 15:25 21/10/2012 for example. But you'd still be able to restore to a full or differential backup.
Added 03/06/2013
Sorry, I completely forgot this option as well:
Do you have any remote storage options? You can just backup the transaction logs to a UNC path. This may be a bit slower depending on your network but it'll mean you'll have a full transaction backup covering the previous period and can then start taking smaller regular backups.
Since you are using Standard Edition, you cant use TDE. So other options are
Using encryption keys at instance/database level :
SQL Server has two kinds of keys: symmetric and asymmetric. Symmetric keys use the same password to encrypt and decrypt data. Asymmetric keys use one password to encrypt data (called the public key) and another to decrypt data (called the private key).
SQL Server has two primary applications for keys: a service master key (SMK) generated on and for a SQL Server instance, and a database master key (DMK) used for a database.
Also, you can have encryption at column level by creating a MASTER KEY ENCRYPTION along with CREATE CERTIFICATE and then CREATE SYMMETRIC KEY.
An example of how this can be done is described at Encrypt a Column of Data
Reference : SQL Server and Database Encryption Keys (Database Engine)
At Drive level :
Using BitLocker as it is a Drive Encryption data protection feature available Windows Server 2008 R2. Refer to : BitLocker Drive Encryption Overview There are many opensource or third party software to do the same job but at additional cost.
Note: The most important bit is ALWAYS backup your encryption keys.
You can use third party software like Redgate's sql backup which allows you to encrypt backups using passwords.
Depending on what level you need encryption will determine if it is worth upgrading to enterprise edition or not. You have to evaluate native TDE encryption vs encryption keys and certificates vs open source vs disk encryption.
Best Answer
This is just my input, but I have supported most of the major players in the 3rd party backup vendors. I have supported clients that utilize Idera, RedGate, Dell LiteSpeed, NetBackup (which does not really have compression but is 3rd party), and a few off-the-wall vendors that I can't remember anymore.
The improved compression you may or may not get with 3rd party products have a trade-off....CPU workload. I have seen Dell's (LiteSpeed) product run in SQL Server 2014 environment against a database that is right at 500GB, and using high compression kills the CPU. The result was only a backup file of around 64GB. It ended up causing SQL Server to stop providing resources to the backups since Dell's product uses the VDI API. The compression level had to be dropped down from 7 to about 3, this brought the backup size down to about 82GB. We took a native backup with compression enabled of same database, and it was right at 84GB in size. So is the trade off and cost worth it?
test, test, testI seem to recall a client I had a few years ago was using Idera's product and I had constant issues with the backups for their medical databases that were 1TB+ in size. I think some of it had to do with the disk subsystem the backups were being written to, which again is why you need to test. Overall Idera's GUI interface is not inviting to me, and could use great improvement. I would chose RedGate or Dell over Idera any day of the week.
You also have to remember that most 3rd party backup products are going to use the VDI API to SQL Server. This in and of itself can cause problems as well, frequent to often "BackupVirtualDevice" or "BackupIORequest" errors showing up in the error log. I have some of these be false positives (backup actually did occur) and some where legit failures. Make sure to read through the vendor support article or forums. RedGate and Idera have very good support systems in place and are very good about getting back with help. Dell I have not had to make any support calls with their product so far.
The one last thing I will bring up is the format of the backup taken by the 3rd party product. If you get into a DR situation are you going to have a standby server licensed with the product as well? I believe Dell allows you to install LiteSpeed without a license to do a restore, but it has to be licensed to do any backups. I think most of the vendors also include a utility to convert a vendor specific database to a SQL Server native backup file, in case of emergency.