24 a)可以通過WITH STOPAT參數在完整備份和差異備份的基礎上還原到特定時間點 當然不能。雖然這個語法看上去貌似能的樣子，但這個語法的最佳實踐是你在進行日志還原到特定時間點時帶上，這樣你的還原就不會超過這個時間點（譯者注：比如說還原的第一個日志備份中不包含這個時間點，但你帶上這個參數則這個日志備份會被全部還原，直到你還原到包含時間點的日志備份而不用擔心還原過頭）,對此我之前的一篇文章會更有幫助:Debunking a couple of myths around full database backups。
24 g)可以將數據庫還原到任何更低版本的實例 不能，這是一個普遍存在的誤區。低版本的實例對于高版本的數據庫的部分內容有可能無法理解（比如sql server 2005的數據庫就無法理解SQL Server 2008數據庫的一些內容）。
24 h)可以將數據庫還原到任意版本的SQL Server中 錯誤，比如說SQL Server 2005,一個含有表分區的數據庫只能還原到企業版中。在SQL Server 2008只能還原到企業版的數據庫包含了如下特性:分區，透明數據加密，CDC,數據壓縮。有關這里我已經寫過一篇文章，請看:SQL Server 2008: Does my database contain Enterprise-only features?。
24 i)WITH STANDBY參數會破壞還原鏈 不會，這個參數的作用是使得在還原的過程中，保證數據庫事務級別的一致性。從還原順序的角度來說，With Standby參數WITH NORECOVERY并無區別。你可以在還原的過程中停止N次。這也是事務日志傳送的機制。經常有人會問在事務傳送的輔助服務器進行日志恢復的過程是否能訪問，至此你應該知道是可以只讀訪問的。同時，這個選項也可能造成一些詭異的問題，請看:Why could restoring a log-shipping log backup be slow?。
24 m)你可以還原到在備份的日志范圍之內的任何時間點 這是不對的。如果日志中包含了那些那些僅僅少量日志的操作(比如批量數據導入操作)，這類操作具有原子性，要么全部還原，要么不還原。這是由于這類操作對于區的進行了修改，但備份集中并沒記錄何時修改了這些區。你可以通過如下腳本查看日志備份包含的信息量：New script: how much data will the next log backup include?。
24 n)只要備份成功，就可以利用這個備份集進行還原 No,no,no。備份集只是存儲在IO子系統的文件，就和數據庫的文件一樣。它也有損壞的可能。你需要定期檢查備份是否被損壞，否則當災難發生后的驚喜怕你是承受不了。請看:Importance of validating backups。另外一點需要注意的是避免額外的完整備份破壞恢復順序，這個例子或許會給你一點警示：BACKUP WITH COPY_ONLY - how to avoid breaking the backup chain。
24 o)所有的SQL Server頁類型都可以通過單頁恢復進行還原 不，一些分配位圖的頁（譯者注：比如GAM,SGMA,FPS頁等）不能通過進行單頁還原(這類頁可以通過SQL Server 2008 的鏡像進行自動頁修復)。詳情你可以看我這篇文章:Search Engine QA #22: Can all page types be single-page restored?。
24 p)RESTORE ... WITH VERIFYONLY選項會驗證整個備份集 不，這個選項僅僅檢查備份的頭是否正確。只有使用WITH CHECKSUM才可以完整備份集的校驗和檢查。
