Comments
Sort by recent activity
Hi Peter and Chris.
I concurr with Peter.
(It seems after reading this, its what was causing our problems.)
We're using Multiple threads with the backup option. Since the upgrade and subsequent file copy - all restore tests were good.
(And here I was thinking I had to replace my RAID array due to dodgy disks!) Chris - DO the upgrade. For us it was painless and took only minutes. And we are VERY anal about upgrades on production servers!
Adam [image] / comments
Hi Peter and Chris.
I concurr with Peter.
(It seems after reading this, its what was causing our problems.)
We're using Multiple threads with the backup option. Since the upgrade and subsequent fi...
Hi Peter, Success!
The corrupted (missing) file endpoint was the culprit.
After copying and verifying the MD5 Checksums from source to copy, I re-ran the Restore job in EM
It completed quickly. A future enhancement for SQL Backup, would be a nice to have SQL Backup fail on a Restore job after ‘n’ lines of:
Found terminating marker for device 0, position (incrementing number count) or whatever internal code you use to id this message.
This would alert the DBA that a corrupted file has caused the failure and maybe even suggest in the logs to run the MD5 checksum against original and copied .sqb files.
You truly have a fantastic product.
I’m a fan and more so because you’re serious about support and constant improvement.
Kind regards,
Adam [image] / comments
Hi Peter,Success!
The corrupted (missing) file endpoint was the culprit.
After copying and verifying the MD5 Checksums from source to copy, I re-ran the Restore job in EM
It completed quickly.A fut...
Thanks for your continued assistance Peter: The backup script on Production is:
EXECUTE master..sqlbackup N'-SQL "BACKUP DATABASE [ProductionDB] TO DISK = ''D:\Backups\Download\<AUTO>.sqb'' WITH COMPRESSION = 1, COPYTO = ''\\HOTSPARE01\BACKUPS'', INIT, THREADCOUNT = 2"', @exitcode OUT, @sqlerrorcode OUT The restore script on Hotspare is:
master..sqlbackup N'-SQL "RESTORE DATABASE [ProductionFailOver] FROM DISK = ''D:\Backups\FULL_(local)_Production_20080309_180001.sqb'' WITH NORECOVERY, MOVE ''CMS_Data'' TO ''F:\Databases\ProductionFailOver_Data.MDF'', MOVE ''CMS_Log'' TO ''C:\DataLogs\ProductionFailOver_Log.LDF'', MOVE ''CATSites01_1_Log'' TO ''D:\DataLogs\ProductionFailOver_Log.LDF'', REPLACE"'
I will run the MD5 checksum after the production backup file is copied to Hotspare again tonight.
If checksums match, I will then run the Restore again.
Am certain that the missing endpoint in the file is the cause of the problem, and the cause of the Restore job running forever.
If after a successful MD5 comparison and the Restore still fails, what contingency? Are there some further logging options that I can turn on to help debug SQL Backup (during the restore process)?
Adam / comments
Thanks for your continued assistance Peter:The backup script on Production is:
EXECUTE master..sqlbackup N'-SQL "BACKUP DATABASE [ProductionDB] TO DISK = ''D:\Backups\Download\<AUTO>.sqb'' WITH COM...
Peter,
That was the Production Full Backup file.
It was copied to a secondary server for Restoring.
I did run SBaTU.exe on another DB backup file, which was only 6GB compressed and that worked without error.
Is the size a problem for SQL Backup?
Our original (successful) SQL Backup / Restore test was when the production DB was around 40GB (7GB compressed).
And now it is 64GB (11GB Compressed).
Is SQL Backup Lite unable to cope with these larger files?
There are never any errors during the backup phase and the hardware RAID array is working perfectly.
?
Thanks again for your continued help! [image] / comments
Peter,
That was the Production Full Backup file.
It was copied to a secondary server for Restoring.
I did run SBaTU.exe on another DB backup file, which was only 6GB compressed and that worked with...
Ahh! I understand now.
I will have to wait before running the check on the production box.
As noted SBaTU.exe seemed very CPU intensive.
During the restore, I would have thought SQB would detect errors and exit 'gracefully', rather than spin its wheels?
I have verified the original file in production: ALL GOOD:
14/03/2008 10:51:29 AM Not encrypted
14/03/2008 10:51:29 AM Multiple device file: 2
14/03/2008 10:51:29 AM Compression level: 1
14/03/2008 10:51:29 AM File size: 11,976,097,280
.. etc
.. etc
14/03/2008 10:54:58 AM File read ended at position: 11,976,097,280
I will xcopy the original file again and see how it goes.
Point to note, doing an integrity check on other sqb files worked fine on that server. Will know more after tonights job.
Thanks Peter!
Adam / comments
Ahh! I understand now.
I will have to wait before running the check on the production box.
As noted SBaTU.exe seemed very CPU intensive.
During the restore, I would have thought SQB would detect e...
Hi Peter (and thanks for the quick reply),
I downloaded and ran the SBaTU.exe against the FULL.sqb backup file.
However!
Not long after running it, the log window displayed a constant stream of:
Found terminating marker for device 0, position 2,578,608,168
Found terminating marker for device 0, position 2,578,608,177
Found terminating marker for device 0, position 2,578,608,186
(this just kept going and going).
Also, CPU on the server was being consumed on both CPU's at around 80%. I had to kill the SBaTU job. There seemed no end in sight for the above incremented errors.
Does this give you a hint about the problem?
Do I need to let the job run? Although if its the same issue causeing the SQL Restore to fail, then it could go on for 24 hours or more. (I cant afford to have this server out of action).
Hope this helps. I'm sweating on this tonight and it will be a nightmare to have to use Native MS Backup Restore (no space!)
Thanks for your expertise in solving this with me.
Adam / comments
Hi Peter (and thanks for the quick reply),
I downloaded and ran the SBaTU.exe against the FULL.sqb backup file.
However!
Not long after running it, the log window displayed a constant stream of:
Fo...
On a parting note, just want to say how brilliant your software is!
"Your software is brilliant!"
One thing that I'd love to see is a "Restore Only" version of SQL Backup.
Really handy for distributing around to all our SQL developers, so they can restore master copies of DB's backed up by PRO or LITE.
SQL Restore Only, cheap licence fee, just a thought!
Keep up the great work. [image] / comments
On a parting note, just want to say how brilliant your software is!
"Your software is brilliant!"
One thing that I'd love to see is a "Restore Only" version of SQL Backup.
Really handy for distribu...
Thanks for the comprehensive reply.
(I was secretly thinking that grabbing the scripts created by Pro would achieve what you have succinctly laid out above.)
Could another option be to use the Wizard on the production server DB, to restore back onto itself (different DB name of course) and then cut and past the SQL Agent Job Steps onto the stand by server running Lite (adjusting the server names and paths accordingly)?
BTW: Ideally we'd love to run PRO on every server, but we're thinking of using SQL Backup across a farm of redundant servers and so its a cost saving exercise to use Lite where we can.
Adam [image] / comments
Thanks for the comprehensive reply.
(I was secretly thinking that grabbing the scripts created by Pro would achieve what you have succinctly laid out above.)
Could another option be to use the Wiza...