In addiditon to the excellent suggestion from chscag, here is a bit of explanation of why he made that recommendation: Consider how you are backing up. If you are using Time Machine, the drive will have on it a folder and inside that folder is a folder with the name of your system and inside that folder are the incremental backups you have made, each with a name of the date/time of the backup. TM manages these backups for you, with each folder only holding the files that changed after the previous backup and links to the older files. So the FIRST backup is everything, then later ones just what changed. So the backup size grows slowly over time. When it runs out of space, it will start deleting older backups to make room. The smaller the backup drive is, the sooner that culling process begins. So if you partition, or if you use the drive for other things, you are bringing that culling process forward in time.
If you are using a clone product like Carbon Copy Cloner, or Super Duper!, then how the backup is made is more configurable. By default, I believe, CCC and SD! will archive changed files as they perform the clone and put in those archives the changed files from the previous clone. So, much like TM, you can go back in history a ways. They, too, cull when they run out of room. However, you can turn that archiving off and do a simple clone, erasing changed files and any other files on the clone that are not on the source and replacing them with the changed files. No history kept. The clone only grows if the source drive grows, not because of any archiving. Also, in this clone, you can't use the backup for anything else because the clone process makes the backup look EXACTLY like the source, including deleting any files it finds in the backup not on the source.
Finally, another factor in the use of the drive is the size of the backup. You didn't give us the size of the internal drive in your iMac, nor how much space you have used, so I'll have to theorize a bit. The general "rule" is that the backup should be twice the size of the source drive. That is the suggestion because of the incremental history that slowly grows. And if the drive is more than 50% full, that's an excellent rule to follow. However, if the drive is not so full, that rule can be more flexible. I generally look for the backup drive to be twice the size of the space used (on average) on the source drive. So a 1TB source with 250GB on as an average needs about 500GB for the incremental backups. But if you are cloning without the history archives, then the backup only needs to be as large as the source, or the expected size of the source, so you might be able to get away with a 250GB clone, as long as you don't exceed the 250GB on the source, even if the source is 1TB in size.
Now generally there are two types of user: The user who fills up the internal drive pretty full and wants to move stuff off the source to make room for new stuff and the user who doesn't store much at all on the source. The first user both needs to make room and needs a pretty big backup drive, so partitioning isn't really going to be useful, unless the external drive is huge. That user would be better served by having one drive for the backups and another for the archives. The second user doesn't need to move things off because he/she has a large internal drive with plenty of space, so partitioning isn't needed. Bottom line, neither user really needs to partition an external drive.
That's a long-winded explanation of what chscag said so succinctly.
