• Another concern I have with replication are the infamous system deletes. MS in their infinite wisdom decided that keeping the publisher and subscriber in sync is more important than transaction durability. If something goes wrong in the replication process, committed transactions can silently be deleted later. This is a headache I don't care to deal with.

    On a different note, I think I may have found a way to run a regular backup of a log shipping standby database. I found this on MS Connect

    https://connect.microsoft.com/SQLServer/feedback/details/466121/allow-backup-of-database-in-standby-mode

    1. Create a new DB with the same number of files as the secondary to be backed up.

    2. Take the new DB and the log shipped secondary offline.

    3. Copy log shipped secondary's files over the new DB's files.

    4. Bring both online.

    5. The new DB is consistent and operational and can be backed up, etc.

    I'm testing it now. One thing I havent understood yet though is why I dont need to do a "restore database NEWDB with recovery" after step 4. I guess it has something to do with the state of the DB in the MASTER database.