Transaction log is growing very fast
While taking a full backup of the database, SQL Server is unable to reuse the transaction log for the duration of the backup, even if the database is in SIMPLE recovery. If your database is very busy, or backups take a long period of time, this can require a large transaction log,  even if the database is in SIMPLE recovery.

 Why does SQL Server need to do this?

Think of the database as a bookshelf containing a set of encyclopedias, and each table is a book in that set. SQL Server is the bibrarian. The librarian needs to make a copy of every book in the set to get a snapshot of the set. 

The librarian (SQL Server) starts copying books (tables) at one end of the shelf (database), and makes it's way to the far end. This takes time. If the data within the books is changing (ie, database transactions), getting a consistent (that's the "C" in ACID) snapshot becomes a challenge.

Consider this timeline:


The librarian copies book A.
The librarian copies book B.
Books A &amp; Z are updated.
The librarian copies book C.
The librarian copies book D.
Books C, X, Y, Z are updated.
The librarian copies books E-Z. The backup is complete.


The librarian's backup is not consistent. It has some of the old data (Books A &amp; C, and some of the updated data (Books X,Y,Z). In order for the data to be consistent, the librarian could keep track of what changed in books A &amp; C, then roll forward those changes on her backup copy. 

It might be OK for the librarian to have an inconsistent backup, but it's not ok for SQL Server to have an inconsistent backup. SQL Server's backups must be consistent to a single point in time.

How does SQL Server do this?

When SQL Server begins backing up data pages, it also starts keeping track of transactions, via the transaction log. After it has backed up the last data page, it then also backs up all of the transactions that occurred during the data backup. Upon restore, it will then roll those transactions forward or backward, as necessary, to ensure a consistent image is restored.

Backing up busy databases in Simple Recovery

Based on OP's comments, the database in question is 7TB, and takes 20 hours to back up. That means that the transaction log for this database must be large enough to accomodate 20 hours worth of transactions. Depending on the amount and type of activity, the amount of transaction log needed could very quite a bit. 

To reduce the amount of transaction log needed, you can either try to make your backup go faster, or take your backups during a time of reduced write activity, or both.