為什麼對我的數據庫進行完整備份還原時出現錯誤“RESTORE 只能在還原完整備份時創建數據庫…”？

我已經制定了維護計劃，每天對伺服器上的所有數據庫進行完整備份。我還設置了第二個維護計劃，每 5 分鐘備份一次事務日誌。事務日誌備份作業在晚上 11 點到凌晨 1 點之間停止並重新啟動，以允許進行伺服器級備份（在基礎架構團隊的建議下，可能會重新訪問）。我不認為這應該是一個問題，因為我有另一台伺服器遵循相同的模式，並且它的備份沒有問題。

我正在嘗試驗證我的備份是否正常工作，但每當我嘗試使用之後的任何事務日誌備份恢復完整備份時，我都會立即收到以下錯誤：

我正在嘗試將備份還原到單獨的伺服器（相同的 SQL Server 版本），其主要目的是測試數據庫備份的完整性。我正在嘗試恢復的數據庫目前在該伺服器上不存在。

如果它有任何相關性，這些是我正在使用的還原選項：

在Aaron Bertrand 對類似問題的有趣回答之後，我現在正在使用該RESTORE HEADERONLY FROM DISK命令調查一些事情。首先，這些是我的完整備份文件的結果：

該完整備份中僅儲存一個數據庫/文件。

此外，如果我RESTORE HEADERONLY FROM DISK在最後一次完整備份之後執行我的第一個事務日誌備份文件、完整備份文件本身以及最後一次完整備份之前的最後一個事務日誌備份文件，我會注意到以下 LSN：

我認為DatabaseBackupLSN所有備份的 都應該與FirstLSN這些備份之前的最後一個完整備份相匹配。對我來說奇怪的是，它們似乎都指向較舊的完整備份。

當我嘗試生成 SSMS 嘗試執行的還原腳本時，奇怪的是我得到了與工具提示相同的錯誤，並且它不會給我腳本：

仔細檢查後，當我選擇所有備份（包括完整備份）時，SSMS 會自動刪除完整備份並僅載入要還原的事務日誌備份。我真的認為有一個損壞的備份鏈讓 SSMS 感到困惑：

如果我只選擇要恢復的完整備份，那麼它可以讓我點擊腳本按鈕，這就是完整備份本身的腳本：

USE [master]
RESTORE DATABASE [MyDatabase] FROM  DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_3540051.bak' WITH  FILE = 1,  NOUNLOAD,  STATS = 5

此外，我的維護計劃未設置為“僅複製備份”：

作為參考，這裡是完整備份維護計劃中的一個數據庫的 T-SQL 腳本：

BACKUP DATABASE [master] TO  DISK = N'\\OurDomain\Shares\SQL Backups\Full Backups\master\master_backup_2021_09_19_004931_6111907.bak' WITH  RETAINDAYS = 14, NOFORMAT, NOINIT,  NAME = N'master_backup_2021_09_19_004931_6111907', SKIP, REWIND, NOUNLOAD, COMPRESSION,  STATS = 10

如果我手動編寫完整備份的還原以及在該完整備份之後發生的最接近事務日誌備份的腳本，它會很好地還原完整備份並將數據庫保留在其中，NORECOVERY但事務日誌備份失敗並出現以下錯誤：

這些是我編寫的手動腳本：

USE [master]

RESTORE DATABASE [MyDatabase] 
FROM DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_3540051.bak'
WITH NORECOVERY;

RESTORE LOG [MyDatabase]
FROM DISK = N'P:\MyDatabase\MyDatabase_backup_2021_09_16_223001_4008446.trn'
WITH RECOVERY;

奇怪的是，如果我嘗試恢復在完全備份之前發生的最近的事務日誌備份，我會得到完全相同的錯誤消息，引用完全相同的 LSN。所以就像我的事務日誌備份沒有遵循與我的完整備份相同的備份鏈？

我能想到的唯一其他相關資訊是這些備份維護計劃最初是在 SQL Server 2016 實例上設置的。該實例的伺服器崩潰了，我們使用 SQL Server 2019 實例啟動了一個全新的伺服器。我將所有使用者和系統數據庫從備份（諷刺地）還原到新的 SQL Server 2019 實例。（我必須首先在 2016 實例上恢復系統數據庫，並在它允許我在新的 2019 伺服器上恢復它們之前進行就地升級。）我無法成功恢復到新伺服器的唯一數據庫是master數據庫。到目前為止，其他一切似乎都執行良好。

我們的伺服器級備份軟體 Veeam 顯然被配置為截斷事務日誌。我不知道 Veeam 甚至可以在數據庫級別進行互動，直到明智的 Tibor Karaszi 為我指明了正確的方向：

（這是在我存在之前很久就配置的。旁注，我認為 Veeam 完全沒有理由提供這個糟糕的選項。）

將其更改為備份日誌本身（而不是製定維護計劃）將解決問題。但我更喜歡讓 SQL Server 本地管理備份，因此我們只是在 Veeam Backup & Replication 軟體中禁用了此管理。

在 Veeam Backup & Replication 軟體的Edit Backup Job視窗下的Guest Processing螢幕中，我們取消選中“ Enable application-aware processing ”以禁用它。

作為參考，這是 Veeam關於配置它以管理事務日誌的文件。

底線是您（不幸的是）不能依靠 SSMS 來幫助您進行恢復。因為它做的不對。我有一個案例，我在 2014 年報告了哪個 IMO 不好，其中 SSMS 嘗試將還原序列基於 copy_only 備份，我已經提醒 MS 幾次。這被置若罔聞，所以這對我來說是一個非常明確的資訊。請參閱以下幾個範例：http ://sqlblog.karaszi.com/?s=restore 。

在你的情況下，我們沒有足夠的複制。如果沒有 repro，我們只能說“似乎是 SSMS 中的錯誤”之類的話，我們無能為力。我們不知道您執行了哪些備份，我們不知道您在 GUI 中點擊了什麼，我們不知道您在第二台伺服器上有哪些備份文件。等等。

如果您希望我們測試您是否誤解了 GUI，請給我們一個 repro。

• 所有 T-SQL 命令開始，您在其中生成備份。
• 簡約的複製品和清晰的描述，準確地描述了您擁有的文件。
• 您希望 GUI 生成的 TSQL 恢復命令。確保它們按預期工作。
• 以及您點擊 GUI 的確切方式，以便我們重現您的案例。

也許對你來說是一個艱鉅的任務，但沒有這個，正如我所提到的，我們會留下“似乎是 SSMS 中的一個錯誤”……

引用自：https://dba.stackexchange.com/questions/299788