August 3, 2011 at 2:22 am
Ninja's_RGR'us (8/2/2011)
Ah darn. Ok, so how often does it happen? I've never heard of bugs in that arena. Have you?
Personally, I have not seen any bugs with regards to SQL Server pulling the data to back up. What I have seen are users' disk systems reporting successful writes to SQL Server, when in actual fact they were not, hence fooling SQL Server (or SQL Backup in my case) into thinking that the backup files were created successfully. So we have users' reporting that backups created using SQL Backup are unusable. However, once they start backing up to a different disk I/O subsystem, everything works fine.
Ninja's_RGR'us (8/2/2011)
Would it be <annally> safer to take that backup on 2 different san arrays just in case 1 of them happens to fail? Then delete the 2nd copy as soon as the verify + restore passes?
I feel it's your recovery needs that'll drive your backup policy. You can't be <annally> safer if your recovery needs dictate that you should do everything possible to ensure your tlog backups are recoverable. The MIRROR TO option is certainly useful in these cases.
SQL BAK Explorer - read SQL Server backup file details without SQL Server.
Supports backup files created with SQL Server 2005 up to SQL Server 2017.
Viewing post 16 (of 15 total)
You must be logged in to reply to this topic. Login to reply