Comments
Sort by recent activity
So, if I were to purchase and install Redgate Backup 6.4 on the Failover SQL Server 2005 32 bit server, I would still be unable to restore the production DB backup (64 bit) to the failover 32 bit database, because of incompatibility between those SQl Server versions?
If so, so much for Microsoft's compatibility level selections on creating a database.
Tim Carlisle / comments
So, if I were to purchase and install Redgate Backup 6.4 on the Failover SQL Server 2005 32 bit server, I would still be unable to restore the production DB backup (64 bit) to the failover 32 bit d...
Ok, I will have to do something different to get data updates going to the 2005 failover server. Thanks for supplying the msdn link to the compatibility - version information. Thanks for saving us $800 too!
Tim Carlisle / comments
Ok, I will have to do something different to get data updates going to the 2005 failover server. Thanks for supplying the msdn link to the compatibility - version information. Thanks for saving us ...
I will repeat too, the file does exist in that directory, and the Local System Account has Full access to that directory and file.
I am trying some other things with permissions to try to get this issue resolved. I will let you know how that goes.
Thanks. / comments
I will repeat too, the file does exist in that directory, and the Local System Account has Full access to that directory and file.
I am trying some other things with permissions to try to get this ...
Everything permissions related that I have tried has not resolved the issue. What Next?
Tim / comments
Everything permissions related that I have tried has not resolved the issue. What Next?
Tim
Here is the latest on this thread. After getting the new database restored using a backup generated with the SQL Server backup utility (ugh!) on the old SQL Server 2000 data server, I was able to restore that backup on the new SQL Server 2008 R2 instance.
I then created a backup on the new server using RedGate backup rev. 6.4. That ran sucessfully. I then used that backup to run a restoration using Redgate backup aftert dropping the database and then recreating its DB shell. That restoration was sucessful.
I do not doubt that there may be permissions issues on the files created on the Windows 2003 server location of the Redgate rev 3.4 backup file. I have seen unexplanable permissions issues with files in a mixed 2003 - 2008 Windows server environment previously, and this might just be another one of those. I have a work around, although it is not what I wanted to do in the original project plan. My real concern was that i would not be able to produce the Redgate backup files that will be used to spread the info into the cloud. I have teste that and it will be possible.
Thank you, Peter, for your input.
Tim Carlisle
Systems Manager
Office of the Chapter 13 Trustee
Columbus, GA, USA / comments
Here is the latest on this thread. After getting the new database restored using a backup generated with the SQL Server backup utility (ugh!) on the old SQL Server 2000 data server, I was able to r...
Excuse me, those were the Messages that were returned, the tabular result returned no records. / comments
Excuse me, those were the Messages that were returned, the tabular result returned no records.
FYI,
I ran a backup on the 13Software DB on my failover server (SQL Server 2005) using the built-in SQL Server backup utility. I then copied that to the new SQL 2008 R2 server and was able to restore that backup using the SQL Server 2008 R2 backup restore utility sucessfully.
That indicates to me, that there is something going on under the hood with the RedGate SQL Backup versions. I don't know what that might be. I really need this to work, because I will have to make RedGate backup files available to our case management software vendor that uses RedGate Backup for restoration to the 13Network Data online databases (country-wide) and in turn they provide Bankruptcy data to the National Data Center.
Still looking for a clue...
Tim / comments
FYI,
I ran a backup on the 13Software DB on my failover server (SQL Server 2005) using the built-in SQL Server backup utility. I then copied that to the new SQL 2008 R2 server and was able to resto...
The script result was as follows:
Msg 1, Level 15, State 1, Line 0
Reading filelist of "C:\Backup\13Software.sqb"
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 1
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 2
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 3
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 4
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 5
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 6
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 7
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 8
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 9
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Backup\13Software.sqb): attempt 10
Warning 485: File does not exist: C:\Backup\13Software.sqb
File validation failed: C:\Backup\13Software.sqb
SQL Backup exit code: 840 / comments
The script result was as follows:
Msg 1, Level 15, State 1, Line 0
Reading filelist of "C:\Backup\13Software.sqb"
Warning 485: File does not exist: C:\Backup\13Software.sqb
Validating file (C:\Back...
I am running that script now, 00:03:13 and counting... / comments
I am running that script now, 00:03:13 and counting...
Yes. / comments
Yes.