Jump to content
alistair

Database restores failing

Recommended Posts

Hi,

 

I am getting the following error when trying to restore a database from restore server to remote server.

 

Backup server details

SBS2003 SP1

 

Database server details

W2k3 server SP2

MSSQL8 SP3

 

Servers are connected via Retrospect client over Hamachi VPN.

 

Once the backup fails the database is left non-operational as is reporting as being 'restored'

 

I have tried doing full restore (ie diffs & full) and just diff. Also tried new database and leaving non-operational.

 

Where to from here?

 

Cheers

Alistair

 

 

- 4/02/2009 3:15:53 PM: Restoring from MTT HD3

Restore type: Differential

FEncEnd: not started

FEncEnd: not started

vlocRDiskFileOpen: device number = 0x1

vlocRDiskFileOpen: device number = 0x1

T-7: RestoreStart: id='SYSTEM'

T-7: TWDBSqlServer::GetReplacementName:No cluster info, repName = METTROSERVER1

T-7: TWDBSqlDatabase::execSqlRestore: sqlCmd='RESTORE DATABASE [magic3_beesnees] FROM VIRTUAL_DEVICE='dantz_retrospect_vd_magic3_beesnees' WITH REPLACE, NORECOVERY'

T-7: execSqlOdbcCommand: id='SYSTEM'

T-7: execSqlOdbcCommand: Error on SQLExec.

T-7: processSqlMessages: Msg 4,306, SevLevel 16, State 1, SQLState 42000

T-7: (4,306) - The preceding restore operation did not specify WITH NORECOVERY or WITH STANDBY. Restart the restore sequence, specifying WITH NORECOVERY or WITH STANDBY for all but the final step.

T-7: processSqlMessages: Msg 3,013, SevLevel 16, State 1, SQLState 42000

T-7: (3,013) - RESTORE DATABASE is terminating abnormally.

T-7: MapError: unknown Windows error 4,306

T-7: SQL_Vol::BackupWrite: RestoreWrite failed

T-7: ***** BackupWriteClose: total byte restored=5,632 [0x00000000]

Trouble writing files, error -1004 (Database Backup/Restore error)

 

 

Share this post


Link to post
Share on other sites

Are you trying to overwrite an existing database or are you doing a restore to a new path?

 

What method are you using to authenticate to the SQL Server?

 

What do the SQL logs say on the server?

Share this post


Link to post
Share on other sites

Thanks for the quick response.

 

Are you trying to overwrite an existing database or are you doing a restore to a new path?

 

I have tried both. First attempt was to restore the existing database.

 

Then tried letting retrospect create a new database. Same result.

 

When trying a new database the ldf & mdf were created by retrospect.

What method are you using to authenticate to the SQL Server?

 

 

Using SQL Auth with a specially created backup user.

 

This user has all the boxes ticked in the Server Roles tab (ie System Admin, Server Admin etc etc), it doesn't have specific access granted to each db although this should be implied by it's admin roles.

 

What do the SQL logs say on the server?

Checking them out now, will post once I can get onto the server and find the relevant data.

Share this post


Link to post
Share on other sites

Here are the extracts from ERRORLOG.

 

The original database is db_cms_01, the renamed attempts are suffixed with _restored

 

------------

2009-02-04 14:21:44.10 spid88 Starting up database 'db_cms_01'.

2009-02-04 14:21:44.15 spid88 Bypassing recovery for database 'db_cms_01' because it is marked IN LOAD.

2009-02-04 14:21:52.84 backup Database restored: Database: db_cms_01, creation date(time): 2006/07/07(10:51:33), first LSN: 218:17210:1, last LSN: 218:17212:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'dantz_retrospect_vd_db_cms_01'}).

 

2009-02-04 14:37:16.21 spid58 Starting up database 'db_cms_01_restored'.

2009-02-04 14:37:16.28 spid58 Bypassing recovery for database 'db_cms_01_restored' because it is marked IN LOAD.

2009-02-04 14:37:22.57 backup Database restored: Database: db_cms_01_restored, creation date(time): 2006/07/07(10:51:33), first LSN: 218:17210:1, last LSN: 218:17212:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'dantz_retrospect_vd_db_cms_01'}).

2009-02-04 14:55:50.79 spid88 Starting up database 'db_cms_01_restored2'.

2009-02-04 14:55:50.84 spid88 Bypassing recovery for database 'db_cms_01_restored2' because it is marked IN LOAD.

2009-02-04 14:55:57.28 backup Database restored: Database: db_cms_01_restored2, creation date(time): 2006/07/07(10:51:33), first LSN: 218:17210:1, last LSN: 218:17212:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'dantz_retrospect_vd_db_cms_01'}).

2009-02-04 15:10:04.93 spid55 Error: 947, Severity: 16, State: 1

2009-02-04 15:10:04.93 spid55 Error while closing database 'db_cms_01_restored' cleanly..

2009-02-04 15:11:48.70 spid55 Starting up database 'db_cms_01'.

2009-02-04 15:11:50.85 spid55 Recovery is checkpointing database 'db_cms_01' (92)

 

 

2009-02-04 15:35:52.90 spid55 Error: 15457, Severity: 0, State: 1

2009-02-04 15:35:52.90 spid55 Configuration option 'show advanced options' changed from 1 to 1. Run the RECONFIGURE statement to install..

2009-02-04 15:35:52.99 spid55 Using 'xplog70.dll' version '2000.80.760' to execute extended stored procedure 'xp_msver'.

2009-02-04 15:52:59.74 spid55 Process ID 53 killed by hostname MSERVER1, host process ID 5744.

2009-02-04 15:53:40.02 spid55 Starting up database 'db_cms_01'.

2009-02-04 15:55:13.07 spid55 Starting up database 'db_cms_01'.

2009-02-04 15:55:13.12 spid55 Bypassing recovery for database 'db_cms_01' because it is marked IN LOAD.

2009-02-04 15:55:21.23 spid55 Starting up database 'db_cms_01'.

2009-02-04 15:55:21.23 spid55 Bypassing recovery for database 'db_cms_01' because it is marked IN LOAD.

2009-02-04 15:55:23.09 spid55 Recovery is checkpointing database 'db_cms_01' (92)

2009-02-04 15:55:23.49 spid55 Starting up database 'db_cms_01'.

2009-02-04 15:55:26.21 backup Database restored: Database: db_cms_01, creation date(time): 2006/07/07(10:51:33), first LSN: 238:6960:1, last LSN: 238:6963:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'D:\SQL\MSSQL\BACKUP\db_cms_01_20090204.bak'}).

 

------------

 

 

 

Share this post


Link to post
Share on other sites

We have seen that in order for the backup to work (and restores to work), Retrospect's backup user must have FULL administrative rights to each database.

 

I posted a topic about this here:

 

Rights necessary for MSSQL Backup

 

Our database admins weren't too happy about this, but it's the way that Retrospect works.

 

We've found that having Retrospect connecting as a domain admin and using domain authentication (and not SQL authentication) works quite well.

Edited by Guest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×