仅分段恢复一个文件组,不恢复主文件组

Avi*_*Avi 0 sql-server backup filegroups restore sql-server-2017

我有一个简单恢复模型的数据库,并定期进行完整、差异备份。

该数据库还有每个月的文件组。每个文件组只有一个 NDF 文件。

像这样:

FileGroup: PRIMARY
File: Primary.mdf

FileGroup: FG201801
File: 201801.ndf

FileGroup: FG201802
File: 201802.ndf

FileGroup: FG201803
File: 201803.ndf

etc
Run Code Online (Sandbox Code Playgroud)

我的目标有两个:

  1. 能够按分区级别进行备份。正如我所读到的,只有当我将文件组标记为只读时才可能。所以我已经分离了部分备份BAK文件。 https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/partial-backups-sql-server

  2. 第二个目标是(我的问题在这里),能够仅恢复一个文件组,而无需恢复主文件组或触及任何其他文件组。

有可能吗?

据了解,如果我只想恢复 FG201802 ,而 PRIMARY 和其他文件保持不变,那么首先我必须恢复包含 PRIMARY 文件组的完整备份,然后我可以恢复 FG201802 的部分备份。如何在不恢复 PRIMARY 的情况下恢复 FG201802?

有人可以向我指出一个可以演示这一点的在线资源吗?网上的所有文章(我发现)总是开始恢复主完整备份,然后一一应用其余的部分备份。

我只想恢复部分备份,怎么办?

谢谢你!

Han*_*dyD 5

如果不恢复 PRIMARY 文件组,则无法恢复文件或文件组。鉴于您的情况,造成这种情况的原因有很多:

  1. Under SIMPLE mode, a Partial Backup always contains the PRIMARY filegroup and all read/write filegroups. You would need to switch to FULL recovery to utilise file/filegroup only backups that can exclude the PRIMARY.
  2. If no PRIMARY filegroup existed, the system tables and metadata for your database would not exist, so no database users, no schema information, nothing that SQL Server needs to know about your data, files and filegroups would be available.
  3. Under SIMPLE, no log backups are taken, so you cannot replay the transactions against the non-PRIMARY read/write filegroups meaning they must be restored from a backup consistent with PRIMARY.

Even under FULL recovery, the primary filegroup must be restored to allow you to restore individual files/filegroups because all the core metadata about your database is there.

The idea of Partial Backups and Piecemeal restores is to allow you to get back online in a disaster quicker by restoring the essential filegroups needed for the database to be operational, and you can restore additional filegroups later.

I would suggest you look at making some changes to your database:

  1. Move all user objects and data out of the PRIMARY filegroup so that restoring it is less time consuming.
  2. Switch to FULL recovery mode and implement separate filegroup backups and frequent log backups.
  3. Mark any filegroups that should not be updatable as READ ONLY.

These change will allow you to simplify your restore process. Assuming you'd made the above changes and wanted to restore the file you've mentioned, the process would be:

  1. Take a tail-log backup
  2. Restore the primary filegroup from backup
  3. Restore all log files with no recovery (except the last restore of the tail log backup, which is done with recovery) (DB is online at this point)
  4. Run "RECOVER" on all the undamaged filegroups (Data in these FGs is now accessible)
  5. Restore the damaged filegroup from backup (DB is now fully recovered)

This would be quicker than partial backups under SIMPLE recovery because the undamaged filegroups do not have to get restored from backup, instead the data files on disk are simply recovered by SQL Server and transactions replayed from the log onto those files as appropriate. If the PRIMARY filegroup is small, and you're taking frequent log backups, the whole process should be quicker than restoring all the read/write filegroups as with partial backups under SIMPLE.