I just picked up a 500 GB USB 2.0 external drive to handle the back ups for my domain controller, application and database server that I run in my SOHO network which runs on a Windows 2003 AD domain (I can't believe that a half terrabyte can be had today for less than $200). My backup strategy has been pretty consistent over the last couple of years; full backup on Sunday and Wednesday with incremental backups every day in between. This allows for fault tolerance in the event of a botched full backup, while providing recoverability up to the day before a potential failure.
The drive came pre-formatted in it's own enclosure, so replacing the existing 80 GB drive was a breeze. The idea was to keep the current backup schedule intact by keeping the same drive letter, etc.
The number one rule of disaster recovery is to test your backups, so the first thing I did was run the full backup job that typically runs on Sunday. Strangely, even though the partition that is backed up is over 30 GB, the bkf file was only 4 GB. Baffled, I tried running the job a number of times interactively with the same result. The file was exactly 4 GB in size.
The first thought was that somehow, the backed up attribute had somehow been set on what, 26 GB worth of files? This made no sense, because a full backup doesn't set (or clear) any flags, but when strange things happen, so too does the mind wander.
Well, it turned out that the drive was formatted at the factory with FAT 32. One of the limitations of FAT 32 is a maximum file size of 4 GB. I formatted the drive using NTFS (which has no such limitation), bringing it inline with the rest of the machines on the domain and the backup is operating as expected, creating a bkf file comparable in size to the source partition.
So, if you ever run into something similar (as rare as encountering FAT 32 these days might be) , check the file allocation scheme on your disk and if possible, re-format in NTFS. Not only does this remove the file size limitations, it is far more efficient and secure.