Showing posts with label backups. Show all posts
Showing posts with label backups. Show all posts

Friday, March 23, 2012

Frustrating Backup/Restore Issue

Im running SQL Server 2005

I set up 4 maintenance plans:

1) Full production DBS backup every day at midnight

2) Transaction Backups every 10 minutes starting at 12:10 AM ending at 11:59 PM

3) Full System DBS backups

4) Maintenance on production database: index rebuild, stats, etc.

All the files are sucessfully there but when I try to restore the backup to a new database to make sure its valid it seems I can restore the full backup but the transaction logs seem to be completely disassociated with the full backup. Says there not from the same backup set

I tried the same thing earlier just taking a full backup and then transaction logs in two separate plans and it worked fine. Sometimes it seems to sync up and sometimes it does not. Any help on this issue would be much appreciated

Thanks

Scott

What you're attempting should work just fine, so we need to figure out exactly where it's going wrong.

Information that will help us figure that out:

The exact error text, cut and pasted if possible. That allows us to track down what code is generating the error.|||

Okay first and foremost here is the error message I can when I try to restore the full backup with the first transaction log after the full backup. (Im having trouble copying and pasting) its says:

The volume on Device 'S:\Microsoft SQL Server\MSSQL.1\MSSQL\backup\radb\radb_backup_200609281200.trn' is not part of a multiple family media set. BACKUP WITH FORMAT can be used to form a new media set. RESTORE HEADERONLY is terminating abnormally. (Microsoft SQL Server, Error: 3259)

- I am using separate files and separate database maintenance plans (since they need to be schedule at different times) for the full backup and transactional backups

- I am using separate transaction files for each log and not appending

- I am backing up to disk and not directly to tape

- I am using Management Studio and maintenance plans for these operations

Thanks

Scott

|||

It sounds from your description and the error message as if you might be attempting to restore the full backup and the log backup in one command. If that's the case, this is your problem.

You need to restore the full backup first, WITH NORECOVERY, and then restore transaction log backups one by one in order, specifying WITH NORECOVERY until you've got them all applied. At that point you can restore with recovery, and you're done.

|||

Okay I understand what your saying but ...

I have gotten it to work where I can restore and check the full backup with the transaction logs. Its worked twice like that and hasnt worked twice so its the consistency that bothers me. In the meantime I will try to restore the full backup first and then apply the logs.

sql

Frustrating Backup/Restore Issue

Im running SQL Server 2005

I set up 4 maintenance plans:

1) Full production DBS backup every day at midnight

2) Transaction Backups every 10 minutes starting at 12:10 AM ending at 11:59 PM

3) Full System DBS backups

4) Maintenance on production database: index rebuild, stats, etc.

All the files are sucessfully there but when I try to restore the backup to a new database to make sure its valid it seems I can restore the full backup but the transaction logs seem to be completely disassociated with the full backup. Says there not from the same backup set

I tried the same thing earlier just taking a full backup and then transaction logs in two separate plans and it worked fine. Sometimes it seems to sync up and sometimes it does not. Any help on this issue would be much appreciated

Thanks

Scott

What you're attempting should work just fine, so we need to figure out exactly where it's going wrong.

Information that will help us figure that out:

The exact error text, cut and pasted if possible. That allows us to track down what code is generating the error.|||

Okay first and foremost here is the error message I can when I try to restore the full backup with the first transaction log after the full backup. (Im having trouble copying and pasting) its says:

The volume on Device 'S:\Microsoft SQL Server\MSSQL.1\MSSQL\backup\radb\radb_backup_200609281200.trn' is not part of a multiple family media set. BACKUP WITH FORMAT can be used to form a new media set. RESTORE HEADERONLY is terminating abnormally. (Microsoft SQL Server, Error: 3259)

- I am using separate files and separate database maintenance plans (since they need to be schedule at different times) for the full backup and transactional backups

- I am using separate transaction files for each log and not appending

- I am backing up to disk and not directly to tape

- I am using Management Studio and maintenance plans for these operations

Thanks

Scott

|||

It sounds from your description and the error message as if you might be attempting to restore the full backup and the log backup in one command. If that's the case, this is your problem.

You need to restore the full backup first, WITH NORECOVERY, and then restore transaction log backups one by one in order, specifying WITH NORECOVERY until you've got them all applied. At that point you can restore with recovery, and you're done.

|||

Okay I understand what your saying but ...

I have gotten it to work where I can restore and check the full backup with the transaction logs. Its worked twice like that and hasnt worked twice so its the consistency that bothers me. In the meantime I will try to restore the full backup first and then apply the logs.

Monday, March 12, 2012

Frequent Trans Log backups Vs Autogrow

Hi
Im doing some testing on mirroring at the moment, and have found out about
the inherent problems with transaction log size that thie replication
scenario entails. However I have found that frequent trans log backups are a
way around the problem - This sets the vast majority of VLFs in the trans log
to state 0 allowing them to be overwritten by new transactions VLF's.
Accordingly I dont need to autogrow half as often.
The question is which is the most harmful of system performance? frequent
trans log backups or autogrows? if i DO backup frequently i DONT need to
autogrow, and if i DONT back up frequently i DO need to autogrow...
which which people choose?
Cheers
Alastair Jones
Methodology Group
In SQL 2005 autogrows do not cause performance degradation they way they did
in SQL 2000. Backing up your transaction log should not cause performance
problems either. It may cause some performance problems with Full-text
search, but should not cause other problems.
So I normally backup every 15-20 minutes, unless I am log shipping where it
might be more to decrease my exposure to data loss. None of these
considerations should impact database mirroring though.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Methodology" <Methodology@.discussions.microsoft.com> wrote in message
news:83043C4C-1FD2-4F7A-9E9B-9A0C1890908C@.microsoft.com...
> Hi
> Im doing some testing on mirroring at the moment, and have found out about
> the inherent problems with transaction log size that thie replication
> scenario entails. However I have found that frequent trans log backups are
> a
> way around the problem - This sets the vast majority of VLFs in the trans
> log
> to state 0 allowing them to be overwritten by new transactions VLF's.
> Accordingly I dont need to autogrow half as often.
> The question is which is the most harmful of system performance? frequent
> trans log backups or autogrows? if i DO backup frequently i DONT need to
> autogrow, and if i DONT back up frequently i DO need to autogrow...
> which which people choose?
> Cheers
> Alastair Jones
> Methodology Group