Sean McCown talks about mirrored backups:
By mirroring backups, you’re saying that you want to backup to 2 locations simultaneously. So let’s say you have the need to backup your DBs to a local SAN drive, but also you need to send them to another data center in case something happens to your local SAN. The way to do that in SQL is with mirrored backups and the syntax looks like this:
BACKUP DATABASE MyDB TO DISK = ‘G:\MyDB.trn’ MIRROR TO DISK = ‘\\DC1\MyDB.trn’
So above you can see that SQL will write both of these files at once, and give you a good amount of redundancy for your DB backups. However, this can go wrong when your network isn’t stable or when the link to the other data center is slow. So you should only mirror backups when you can pretty much guarantee that it won’t fail or lag. And as you can guess that’s a heavy burden to put on most networks. In the situation last week that spawned this blog, the network went down for something like 9 hrs and caused the DB’s log to not be backed up that entire time, and hence the log grew and grew. Now you’re in danger of bringing prod down and that’s clearly not what your backup strategy should do.
Sean talks about alternatives and then talks about how they’ve gotten around the problem with Minion Backup. If you haven’t tried Minion Backup, it is well worth your time; it’s already a great product and I use it in a production environment I support.