>>I used a simpler approach: wrote a script which runs the backup, packed that in a little vfp .exe, and scheduled it to run about 30 minutes before the regular system backup. It wasn't a matter of not trusting the system backup, we simply needed to have the data available elsewhere, and a few hours' delay was OK. Another app downloaded the zipped backup, unzipped it, restored.
>
>
>For ourselves and our clients we always use either a SQL Server Agent Job, a SQL Server Maintenance Plan backup (along with integrity check, etc), or run a SQL Backup script as a scheduled task.
>
>Once the backup file is created it is automatically renamed to include database name, date, and time, and copied to a remote backup location (workstation/NAS/USB Drive/etc).

I'd have used something like that, but the specific situation required zipping (the backup was about 1G, zip about 120M), and transport via FTP to a remote location, which even so took about 45 minutes. The zips names were date coded. Along the way, I was shrinking the database - because otherwise it would grow uncontrollably. The app which filled it was written in Access :).