Combination of Filegroup and Point in Time restore possible?

SQL2K5
Ive been doing some testing this morning and it appears that it is not
possible to combine PIT restores with Filegroup restores, is that correct? I
restore a Filegroup backup, and then the Trans Log backup, but there is no
option to stop at a specific time when doing this. It would sort of make
sense I suppose. It could be argued that doing so would leave the DB in an
inconsistent state if a table that resided outside of the restored Filegroup
had been updated before the restores began, but I just wanted to confirm my
findings(?).
I think the down side to this protection would be that if you are relying on
Filegroup backups/ restores, how would you recover a data loss that had
occured due to human error (someone deletes something they shouldn't have)?
After all, to bring the tables in the restored filegroup online I MUST take a
Trans Log backup and restore it, therefore my accidentally deleted data is
still not recovered.
Does this all sound right, or am I missing something here?
All insights are appreciated.Hi Chris
This sounds like your understanding is correct.
When doing a filegroup restore, SQL Server is assuming that other filegroups
are available, with transactions that might have occurred after the backup
of the filegroup that you are restoring. Restoring a FG requires that you
apply transaction logs to bring the FG up to the same point as the rest of
the database.
The point of FG restore is to recover from hardware errors on a single file
or fg. If you need to recover from user error, you'll need to restore the
whole db.
--
HTH
Kalen Delaney, SQL Server MVP
www.InsideSQLServer.com
http://sqlblog.com
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:9D74B6E1-CE97-4B5F-9E97-C0F946ECA811@.microsoft.com...
> SQL2K5
> Ive been doing some testing this morning and it appears that it is not
> possible to combine PIT restores with Filegroup restores, is that correct?
> I
> restore a Filegroup backup, and then the Trans Log backup, but there is no
> option to stop at a specific time when doing this. It would sort of make
> sense I suppose. It could be argued that doing so would leave the DB in an
> inconsistent state if a table that resided outside of the restored
> Filegroup
> had been updated before the restores began, but I just wanted to confirm
> my
> findings(?).
> I think the down side to this protection would be that if you are relying
> on
> Filegroup backups/ restores, how would you recover a data loss that had
> occured due to human error (someone deletes something they shouldn't
> have)?
> After all, to bring the tables in the restored filegroup online I MUST
> take a
> Trans Log backup and restore it, therefore my accidentally deleted data is
> still not recovered.
> Does this all sound right, or am I missing something here?
> All insights are appreciated.|||Thanks!
"Kalen Delaney" wrote:
> Hi Chris
> This sounds like your understanding is correct.
> When doing a filegroup restore, SQL Server is assuming that other filegroups
> are available, with transactions that might have occurred after the backup
> of the filegroup that you are restoring. Restoring a FG requires that you
> apply transaction logs to bring the FG up to the same point as the rest of
> the database.
> The point of FG restore is to recover from hardware errors on a single file
> or fg. If you need to recover from user error, you'll need to restore the
> whole db.
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.InsideSQLServer.com
> http://sqlblog.com
>
> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
> news:9D74B6E1-CE97-4B5F-9E97-C0F946ECA811@.microsoft.com...
> > SQL2K5
> >
> > Ive been doing some testing this morning and it appears that it is not
> > possible to combine PIT restores with Filegroup restores, is that correct?
> > I
> > restore a Filegroup backup, and then the Trans Log backup, but there is no
> > option to stop at a specific time when doing this. It would sort of make
> > sense I suppose. It could be argued that doing so would leave the DB in an
> > inconsistent state if a table that resided outside of the restored
> > Filegroup
> > had been updated before the restores began, but I just wanted to confirm
> > my
> > findings(?).
> >
> > I think the down side to this protection would be that if you are relying
> > on
> > Filegroup backups/ restores, how would you recover a data loss that had
> > occured due to human error (someone deletes something they shouldn't
> > have)?
> > After all, to bring the tables in the restored filegroup online I MUST
> > take a
> > Trans Log backup and restore it, therefore my accidentally deleted data is
> > still not recovered.
> >
> > Does this all sound right, or am I missing something here?
> >
> > All insights are appreciated.
>
>