I have been asked to move a DB to new hosting, and from SSMS=10.50.2500 SSMS=10.50.4021, and from dedicated server in data centre to a virtual machine on the cloud.

Went to copy the latest FULL Backup to the new Cloud VM and found it was a month old ... on checking it appears that the TLog backup has been failing for a month (which, due to the way the tasks are scheduled, has prevented the FULL backup running and, luckily!, old stale backups have not been cleared down).

I ran a TLog backup and got:

"BACKUP detected corruption in the database log. Check the errorlog for more information.BACKUP LOG is terminating abnormally."

and got no output at all - no errors. (It took 12 minutes to run, so I assume it did do something!)

DBCC was run on the original machine, I've copied and restored (without error) a FULL backup from earlier today onto the new Cloud server and then a "final" DIFF backup (after the DIFF backup got to 100% there was then a further 10 minute delay - I am assuming that was committing transactions in the DIFF - the DIFF file was 3GB, which is a huge amount for a single day's differences [compared to normal running])

So ... hopeful that MDF is OK ... I was going to try a Single File Attach next. I took the restored DB (on new Cloud server) offline and am now copying the 50GB MDF file somewhere safe, plus the 52GB LDF file too (I guess its been stockpiling transactions for a month to have grown that big!!) in case I need to have a second go.

This morning I found that the Log Backup task was complaining ... I hadn't realised that sp_attach_single_file_db created Log File as SIMPLE Recovery Model. Fixed that now (and all the palaver for pre-initiaising the Log re: VLFs) ... although that required yet-anther-full-backup to kickstart the TLogging.

Blinking slow the virtual machine that the client has chosen ... no wonder its cheaper than what they had before; backup is 16.581 MB/s instead of the 62.592 MB/s they had before.