使用第三方 VSS 備份加上本機 SQL 備份
我有一個 SQL 數據庫伺服器，它使用R1Soft 備份在 02:00 每 24 小時進行一次伺服器備份。這是一個完整的文件系統備份（裸機加上每日差異，因此包括作業系統等）。
我想增加一些數據庫的備份頻率，這樣在發生故障時，我可以恢復到 15 分鐘的時間視窗，例如
- 04:00 完全備份
- 之後每隔幾分鐘進行一次日誌備份
我無法弄清楚的是 R1Soft 備份（通過VSS Writer完成）是否會導致我的方法出現任何問題（特別是破壞日誌鏈）。我對VSS知之甚少，而且我讀的越多，它就越混亂。
我聯繫了 R1Soft 進行澄清，他們的回應是：
我們使用 VSS 進行 SQL 備份。您可以使用這兩種解決方案，只要它不會同時執行。我們使用 VSS 編寫器將日誌刷新到數據中，然後完全備份數據庫。
這對我來說毫無意義，因為我不知道*“數據”*是什麼意思，也沒有澄清日誌鏈問題。因此，任何有 VSS 經驗的人都可以澄清 VSS 備份是否“干擾”本機完整/事務日誌備份？根據我的研究，我看到了相互矛盾的消息，因為 Microsoft 網站指出：
SQL Writer 不支持… 日誌備份
我不知道我是否應該按照我的建議去做，或者我是否應該這樣做
- 要求伺服器主機將數據庫備份頻率修改為 15 分鐘
- 阻止 R1Soft 數據庫備份，並手動處理，然後讓它只是影子復製備份文件
任何輸入，即使只是為了突出我應該問他們的問題，將不勝感激。我讀得越多，我就越困惑。
根據答案更新
database_name backup_start_date backup_finish_date expiration_date backup_type backup_size MB logical_device_name physical_device_name backupset_name description is_copy_only is_snapshot checkpoint_lsn database_backup_lsn differential_base_lsn first_lsn fork_point_lsn last_lsn --------------- ----------------------- ----------------------- ----------------- ----------- ------------------ ----------------------- --------------------------------------------------- --------------- ------------- ------------ ----------- --------------------- --------------------- ---------------------- --------------------- ---------------- --------------------- myDb 2017-09-13 02:00:04.000 2017-09-13 02:00:05.000 NULL Full 1525.43896484375 NULL {D827E1B8-FDB7-4AE5-9264-08D4CA29536A}1 NULL NULL 1 1 12207000004436400001 12207000004429300036 NULL 12207000004436400001 NULL 12207000004436700001 myDb 2017-09-13 00:11:00.000 2017-09-13 00:11:01.000 NULL Full 1525.44726562500 NULL {9B33317C-CABA-42DD-9839-9D4599A91205}1 NULL NULL 0 1 12207000004429300036 12207000003990700036 NULL 12207000004429300036 NULL 12207000004431300001 myDb 2017-09-12 02:00:13.000 2017-09-12 02:00:14.000 NULL Full 1525.32031250000 NULL {57B7F13B-9461-48C2-8BB3-3DA651485DC6}1 NULL NULL 1 1 12207000003995300034 12207000003990700036 NULL 12207000003995300034 NULL 12207000003996900001 myDb 2017-09-12 01:11:28.000 2017-09-12 01:11:29.000 NULL Full 1525.32226562500 NULL {924FE276-544D-40F6-93A2-C2375868DB07}1 NULL NULL 0 1 12207000003990700036 12207000003659900164 NULL 12207000003990700036 NULL 12207000003992700001 myDb 2017-09-11 13:33:08.000 2017-09-11 13:33:25.000 NULL Full 1526.40234375000 NULL D:\HostedFiles\Autobackup\bak\20170911_myDb.bak NULL NULL 1 0 12207000003837600221 12207000003659900164 NULL 12207000003837600221 NULL 12207000003846900001 myDb 2017-09-11 00:07:59.000 2017-09-11 00:08:00.000 NULL Full 1525.28271484375 NULL {713D7A36-D4F2-4B2F-A0C1-B079DE03F396}1 NULL NULL 0 1 12207000003659900164 12207000003645600222 NULL 12207000003659900164 NULL 12207000003666600001 myDb 2017-09-10 02:00:17.000 2017-09-10 02:00:17.000 NULL Full 1525.25146484375 NULL {3C42FCFF-BF45-49D6-AD78-57039DB7B4DA}1 NULL NULL 1 1 12207000003657200001 12207000003645600222 NULL 12207000003657200001 NULL 12207000003657500001 myDb 2017-09-10 00:05:34.000 2017-09-10 00:05:36.000 NULL Full 1525.29394531250 NULL {AC33EA68-9B40-4CE6-A2E5-76DE908AD813}1 NULL NULL 0 1 12207000003645600222 12207000003613700036 NULL 12207000003645600222 NULL 12207000003654600001 myDb 2017-09-09 04:06:22.000 2017-09-09 04:06:23.000 NULL Full 1525.26367187500 NULL {6BCA937F-7F1C-4A43-92D8-42366D36FA17}1 NULL NULL 0 1 12207000003613700036 12189000000394000087 NULL 12207000003613700036 NULL 12207000003616500001 myDb 2017-09-09 02:00:04.000 2017-09-09 02:00:21.000 NULL Full 1525.28076171875 NULL {6CD064AC-D2DC-4F84-97A7-88C3D959FEF4}1 NULL NULL 1 1 12207000003607000144 12189000000394000087 NULL 12207000003607000144 NULL 12207000003613500001 myDb 2017-09-08 02:00:04.000 2017-09-08 02:00:07.000 NULL Full 1524.68896484375 NULL {92C322C7-AB8A-4747-A765-4D63A86BDC50}1 NULL NULL 1 1 12189000000855600001 12189000000394000087 NULL 12189000000855600001 NULL 12189000000855900001 myDb 2017-09-08 00:30:00.000 2017-09-08 00:30:17.000 NULL Full 1525.38671875000 NULL D:\HostedFiles\Autobackup\bak\20170908_myDb.bak NULL NULL 1 0 12189000000846800208 12189000000394000087 NULL 12189000000846800208 NULL 12189000000855600001 myDb 2017-09-07 07:42:05.000 2017-09-07 07:42:06.000 NULL Full 1524.51806640625 NULL {77D9CBB9-60E4-4D19-99CF-B92499E33BA7}1 NULL NULL 0 1 12189000000394000087 12188000005293700036 NULL 12189000000394000087 NULL 12189000000397700001 myDb 2017-09-07 02:00:05.000 2017-09-07 02:00:10.000 NULL Full 1524.54052734375 NULL {4D94E390-FBCD-42D5-9191-A7AE9CED4932}1 NULL NULL 1 1 12189000000384900197 12188000005293700036 NULL 12189000000384900197 NULL 12189000000393200001 (14 row(s) affected)
我曾兩次發布與您的問題相關的答案。
- 我的回答在這裡
如何使用 Windows Server Backup 備份 SQL Server 數據庫？
- 我的回答在這裡
檢查第 3 方備份
基本上，您必須檢查
msdb數據庫中的備份歷史記錄，以了解如何使用第 3 方軟體創建數據庫備份。使用以下腳本，您可以檢索一些與進一步調查相關的資訊：
SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS SRVNAME, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_start_date, msdb.dbo.backupset.backup_finish_date, msdb.dbo.backupset.expiration_date, CASE msdb..backupset.type WHEN 'D' THEN 'Full' WHEN 'I' THEN 'Diff' WHEN 'L' THEN 'Log' END AS backup_type, msdb.dbo.backupset.backup_size / 1024 / 1024 as [backup_size MB], msdb.dbo.backupmediafamily.logical_device_name, msdb.dbo.backupmediafamily.physical_device_name, msdb.dbo.backupset.name AS backupset_name, msdb.dbo.backupset.description, msdb.dbo.backupset.is_copy_only, msdb.dbo.backupset.is_snapshot, msdb.dbo.backupset.checkpoint_lsn, msdb.dbo.backupset.database_backup_lsn, msdb.dbo.backupset.differential_base_lsn, msdb.dbo.backupset.first_lsn, msdb.dbo.backupset.fork_point_lsn, msdb.dbo.backupset.last_lsn FROM msdb.dbo.backupmediafamily INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id WHERE 1 = 1 ORDER BY 2,3 desc重要資訊是
is_copy_only和is_snapshot列。
IS_COPY_ONLY如果數據庫備份歷史將標誌
is_copy_only設置為，1則後續備份不需要這些（第 3 方）備份將數據庫恢復到一致狀態。這是因為：僅複製備份是獨立於正常 SQL Server 備份序列的 SQL Server 備份。通常，進行備份會更改數據庫並影響以備份份的恢復方式。但是，偶爾為特殊目的進行備份而不影響數據庫的整體備份和恢復過程是有用的。僅複製備份用於此目的。
參考： 僅複製備份 (SQL Server) (Microsoft Docs)
IS_SNAPSHOT如果數據庫備份歷史記錄的標誌
is_snapshot設置為，1那麼您知道此備份是使用觸發SQL Server 編寫器（SQL Server 的 VSS 服務）的第 3 方軟體執行的，這允許第 3 方軟體幾乎立即備份數據庫.從關於什麼是快照備份的官方文件：
SQL Server 快照備份是與第三方硬體或軟體供應商或兩者合作完成的。這些供應商使用專為此目的設計的 SQL Server 功能。底層備份技術創建正在備份的數據的即時副本。瞬時複製通常通過拆分一組鏡像磁碟或通過在寫入磁碟塊時創建磁碟塊的副本來完成。這樣可以保留原件。在還原時，原始磁碟立即可用，並且底層磁碟的同步在後台進行。這導致幾乎即時的恢復操作。
參考： 快照備份(Microsoft Technet)
使用此功能創建的備份也幾乎可以立即恢復。
概括
第 3 方備份應標記為
is_snapshot = 1和is_copy_only = 1。這些備份不會與使用本機 SQL Server和BACKUP DATABASE...語句執行的其他備份步驟/過程發生衝突。第 3 方數據庫備份不屬於現有備份集。BACKUP DATABASE ... WITH DIFFERENTIAL....``BACKUP LOG...回答您的問題
供應商正確地指出，在（快速）快照備份期間，不應執行其他備份。
我們使用 VSS 進行 SQL 備份。您可以使用這兩種解決方案，只要它不會同時執行。我們使用 VSS 編寫器將日誌刷新到數據中，然後完全備份數據庫。
當第 3 方軟體觸發SQL Server VSS Writer服務時，本機備份可能會遇到問題，這主要會導致
IO FrozenSQL Server 中出現消息ERRORLOG。此時執行本機備份可能會導致錯誤。然後你注意到了
SQL Writer 不支持… 日誌備份
正確的。SQL Writer 服務僅針對備份快照觸發，對於使用普通語句的本機 SQL Server 備份不需要。數據庫的備份快照是觸發 SQL Writer時數據庫的事務一致狀態。
差點忘了…
根據我在回答中進一步給出的描述，任何
is_copy_only設置了標誌的東西都不會破壞備份鏈。解決方案
- 為災難場景保留您的第 3 方快照。它們是一致的，並使數據庫快速恢復聯機。
- 根據您的要求對數據庫進行額外的 FULL、DIFF 和 LOG 備份。將這些備份儲存在安全的地方，以確保當您必須將數據庫恢復到 FULL、DIFF、LOG 或時間點時可以訪問它們。
問題編輯後的附加資訊
您可能想要跟進數據庫備份（完整、差異、tlog）並
copy_only閱讀以下文章：SQLskills.com
一般來說：
COPY_ONLY當您想要在正常備份序列之外進行額外備份而不破壞任何內容時，建議進行備份。您的正常備份順序不應基於COPY_ONLY備份。