If you haven't tried this already, you can use SQL management studio to do scheduled backups of the database files. I've never tried such a large file to a remote site, but I've had it handle remote sites and much larger files than 50 GB fine, on separate jobs.
Or, failing that, have you tried robocopy? Robocopy should work "fine," is easily scriptable, and while you're scripting the job up in VB or Powershell (or whatever), you may as well throw in some email notifications for success and failure.
Or for that matter, DFS? (You don't say what version of Windows, but DFS is much improved under 2003 and 2008.) I'd honestly be tempted to put up a DFS share for the sole purpose of transferring differential changes of the database from the server to a remote backup location. Transferring a few hundred MB worth of changes a day, in the background with BITS seems like a much better solution than moving the whole 50 GB file every time you want to get a copy.
EDIT: I didn't say it explicitly earlier, though after a bit of thought, I think maybe I should... you absolutely DO NOT want to create a DFS namespace in SQL's working folder, where the database file is currently located. If you go the DFS route, you'd want to do a local copy/backup of the database file and share that location over DFS. (And set the backup/copy job to over write the existing file, or DFS would end up replicating the whole file every time, rather than just the changes.)
As a bonus, all these options should be available to you within Windows, rather than relying on third-party tools.