Backing up MS SQL Server database creates a huge transation log I'm hosting a SQL Server 2012 database server with about 100 databases.  I use the standard maintenance plan to backup all user databases daily and do hourly transaction log backups.

One database, which is about 80 MB, backs up fine at 6 AM but the following transaction log is typically 1-2 GB.  I've checked and the transaction log is getting properly truncated on the full backup but it immediately fills up after the backup.  I've tried switching to simple recovery, shinking the transaction log file, then re-enabling full recovery.  That all works fine and the .log file goes down to 4-5 MB.  However, within a day it's already up to 2 GB - most of which seems to happen when I perform the full backup.  The log has gotten up to 10 GB even though it gets truncated daily.

The database is only accessed through a single web application which doesn't appear to have anything hitting the database during the time where the transaction log balloons out.

I've attempted to query the transaction log itself but can't see anything obvious.

How can backing up an 80 MB database create a 2 GB transaction log? How can I find out what data is actually in the log and determine where it's coming from?
The statement "transaction log is getting properly truncated on the full backup but it immediately fills up after the backup" is not how backups operate though.  All transaction log truncation is done during the first transaction log backup after the full backup, the truncates are deferred until the full backup is completed.

What happens to transaction log backups during full backups?

If you are seeing a bigger transaction log after a full backup but before the first transaction log backup, that's typically by design.  However if you are saying you have almost no activity going on during the full backup which would cause a gig of activity then I would immediately start by looking at your jobs.  Often a reindex will cause a lot of logging but it would be odd for that to be the main culprit.  Carefully monitor what happens during that period and run the same queries.  Feel free to profile what is going on during that time as this could be a compound issue.