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.
The log can be forced to grow if you have an old transaction that has not been committed or rolled back, regardless of the size (it could affect a single row). For the database in question, assuming you haven't resolved the problem yet, do this:
DBCC OPENTRAN();
This should show you the oldest active transaction (and there is a good chance this is the one that is preventing the log from wrapping). You can see the last thing they did (but not necessarily the thing that is causing the problem) by (documentation):
DBCC INPUTBUFFER(<spid>);
And if they have a query that is currently running:
SELECT *
FROM sys.dm_exec_requests
WHERE session_id = <spid>;
You can also see from sys.databases what the log holdup is (it could be something else entirely):
SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = N'<database name>';
There can also be reasons why an 80 MB transaction might require more than 200 MB of log space - see Remus' answer here:
And I recommend you read this page in its entirety (perhaps you are not using the right recovery model, and perhaps you should consider allowing the log more space to grow when it needs to, rather than shutting down all activity until you resolve the situation manually):
Related:
Best Answer
Start by investigating what is holding up the log reuse. Read Factors That Can Delay Log Truncation, look at
log_reuse_wait_desc valueissys.databases. Based on what you find there, there could be several potential actions.