這有一個具體例子：如果你有一個單個的出現問題的文件。這個文件有50MB大小，而你的整個數據庫運行著大約有幾十億的字節，這樣的話如果能恢復單個失敗文件的話就顯的非常有意義。這樣的事情發生的一個情景是當文件或者文件組在單獨的驅動器上，而驅動器出現了問題。通常，僅僅恢復單個文件或者文件組會使總的停止時間縮短，因為它明顯減少了需要恢復的總的數據量。

為什么你不選擇這么做呢?這有一些原因：

你需要有事務日志備份。如果你想從備份中恢復一個文件或者文件組，你同時也需要恢復與它們一起創建的事務記錄備份，從而使整個數據庫能夠處于一個一致的狀態。在SQL Server 2000 和 2005中，你需要使用Full Recovery或者Bulk-Logged Recovery模式(也就是說不是Simple Recovery)來使它成為可能。我應該指出SQL Server的實現者們并沒有盡他們的努力來完成判斷從上一次備份一個文件或者文件組是否已經被修改了的功能。如果沒有被改變，那么事務記錄是沒有什么必要的。但是，總的來說，還是需要事務記錄備份的，如果你現在還沒有一個備份事務記錄的恢復或者備份計劃，那么現在就創建一個吧。

在要恢復的文件或者文件組中的表格與數據庫中其他的表格之間的數據不一致性成為需要考慮的一個問題。如果你有相互之間依賴的表格，并且這些表格沒有被存儲在相同的物理文件或者文件組中(這有時是不可避免的)，僅僅恢復一個文件或者文件組可能會導致它與數據庫其他部分不同步。例如，你有一個表格被另一個表格用JOIN關聯，并且這個JOIN使用了一個視圖和存儲過程，這時僅僅恢復一個而不恢復另一個可能會有問題。

當你在數據庫中只有一個文件組。如果你的所有的數據僅僅存儲在一個文件或者文件組中，并且它又不是一個特別大的數據庫時，會發生什么事情呢?那時恢復一個文件或者文件組的努力就變的沒有什么意義了。

選擇性的恢復文件或者文件組的主要原因是當恢復數據庫很大，以至于恢復整個數據庫的代價很大的時候，使得對數據庫的局部損壞的恢復成為可能。在一個非常小的輕量級的數據庫里，和nonproduction系統中，或者數據庫中只有一個文件組的時候，實現選擇性的恢復功能就顯的沒有太大的意義，因為這時恢復整個數據庫和恢復單個的文件或者文件組沒有什么太大的區別。

我發現大多數時候當人們想使用文件或者文件組恢復時，他們實際上是想把一個特定的表格恢復到先前的一個點的時刻的狀態。這在SQL Server中不是一個顯式支特的特性，但是存在這么做的方法，倘若你不介意由于采用這種方法而需要手工的來管理可能產生的不一致(就想上面#2所說的)。如果你手邊就有一個數據庫備份的話，你可以簡單的恢復那個備份，僅僅把它看作是相同數據庫的不同名字的實例。接著，通過事務記錄把數據庫向前滾動到指定的點(如果需要這樣做的話)，然后手工的把當前的數據庫拷貝到目標數據庫中。

我自己已經實驗過這種方法幾次，但是僅僅只有一個表格沒有與相同數據庫中的其他的表格有很大的關聯。我的例子涉及了一個包含了留言版系統的聊天網站。我不得不經常恢復一些在留言版上被意外刪除的消息，這些是自包含的：從留言版表格的數據產生的唯一的JOINs是外部的而不是內部的。因此，我可以隨意的更新表格因為我知道我不會讓那個表格與其他表格不同步的。

在SQL Server 2000和它更高的版本中，當你做一個RESTORE操作的時候你可以使用PARTIAL子句，從而使僅僅需要的文件組數據被恢復。這作為一個時間和空間上的節約開銷的措施是非常有用的：你不需要進行繁重的恢復所有數據的工作，而僅僅只需要對一個表格進行操作。而且很可能也沒有足夠的空間來進行完全的恢復操作。