Filegroup restore from full backup

Hello!
I'm trying to figure out how some things about filegroup restore work.
I have a primary filegroup that is very small (2 MB)
and another filegroup that is rather large (2 GB).
The transaction log if very small (1 MB).
The full backup is about 2 GB.
I'm doing a filegroup restore of only the primary filegroup from the full
backup.
RESTORE DATABASE Test FILEGROUP = 'PRIMARY' FROM DISK = 'C:\Test.bak'
If would expect this to be very fast, but it's not. Could it be that SQL
Server is reading the complete backup file and not only the filegroup that is
needed?
I'm using SQL Server 2005 SP2.
Best regards
Ola Hallengren
Thanks, Tibor. I understand.
I'm thinking about using it in a human data error (a record deleted)
scenario. If you have a really large database and a good filegroup strategy
this feature would be very useful.
Does it work the same way in SQL Server 2008?
/Ola
"Tibor Karaszi" wrote:

> Hej Ola,
> To the best of my knowledge, SQL Server do not have any type of allocation structure in the
> beginning of the backup with which it know where pages from some particular file exist. I.e., it
> will have to read the backup file from beginning to end and for each extent see what page it belongs
> in order to determine whether to write the extent to the database file or not.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> "Ola Hallengren" <OlaHallengren@.discussions.microsoft.com> wrote in message
> news:C1A1452A-2361-49D0-8BF9-05D9A5B9392B@.microsoft.com...
>
>
|||The best way to plan for restoring at the file or filegroup level is to
never place any user objects in the primary filegroup. That is because to
restore any file or filegroup you must always restore the primary filegroup
first and keeping only the system objects will speed this dramatically. Then
place user objects in separate secondary filegroups based on their usage
within the schema. Then you can do individual file or filegroup backups so
that you don't have to read an entire full backup each time. For more
details I suggest you read up on Piecemeal Restores in BooksOnLine.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Ola Hallengren" <OlaHallengren@.discussions.microsoft.com> wrote in message
news:759D0E49-7C55-4DEC-8EA1-8D39C827DF3A@.microsoft.com...[vbcol=seagreen]
> Thanks, Tibor. I understand.
> I'm thinking about using it in a human data error (a record deleted)
> scenario. If you have a really large database and a good filegroup
> strategy
> this feature would be very useful.
> Does it work the same way in SQL Server 2008?
> /Ola
>
> "Tibor Karaszi" wrote:
|||I still think that it would be smart if it was possible to restore filegroups
from a full backup without having to read the entire backup file. (And yes it
is a good practise to only have system objects in the Primary filegroup.)
Thanks.
/Ola
"Andrew J. Kelly" wrote:

> The best way to plan for restoring at the file or filegroup level is to
> never place any user objects in the primary filegroup. That is because to
> restore any file or filegroup you must always restore the primary filegroup
> first and keeping only the system objects will speed this dramatically. Then
> place user objects in separate secondary filegroups based on their usage
> within the schema. Then you can do individual file or filegroup backups so
> that you don't have to read an entire full backup each time. For more
> details I suggest you read up on Piecemeal Restores in BooksOnLine.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Ola Hallengren" <OlaHallengren@.discussions.microsoft.com> wrote in message
> news:759D0E49-7C55-4DEC-8EA1-8D39C827DF3A@.microsoft.com...
>