Comments
1 comment
-
Can you really restore a VSS backup to a specific point in time other than the actual times the backup was taken, given that it does not support transaction log backups? My understanding was that if you took a VSS snapshot at 10 am, and another at 11 am, you cannot restore to a point in time anywhere between 10 am and 11 am, unlike regular transaction log backups. So if your database had errors introduced at 10:59 am, you would have to restore the 10 am database and re-do the work until 10:58 am. With non-VSS backups, you just have to restore the transaction logs until 10:58 am.
Not being able to back up transaction logs also prevent you from:
- log shipping databases to one or more standby servers
- inspecting individual transactions when the need arises i.e. to find out who made what changes, when
Add comment
Please sign in to leave a comment.
I think they finally understand why we can't use both at the same time (broken backup chains). I'm still having a hard time explaining to them (and my boss) why VDI tools like SB are better than VSS tools. They argue they can restore our databases to point in time (I'm skeptical, given our past troubles with Veeam and it's non-VSS file system backup problems). I say StorageCraft's use of VSS is a black box, with not enough visibility into and granular control over backups and restores, and while SB is also a black box, it's less black for those same reasons. :-)
What is Redgate's company line...sales pitch...to a company weighing a VSS-based SQL Server backup solution vs. a VDI/file-based solution like SQL Backup? Please help me convince my boss (and these MSP folks).
Thanks!