How can we help you today? How can we help you today?

Unable to restore version 4 backup file

I copied a sqb file from our production serevr to the test server where versipon 5 is installed. I select Restore and then browse for files. I click on the copied file and a screen comes up saying Retrieving File information. This screen stays up forever and I never progress to the next step. If I use sqb2mtf to expand this copied file it works fine and I can then restore from this file. I don't really want to have to convert the file though. Both server are Windows 20o0 Professional. I am using SQL Server 2000 SP4
fhanlon
0

Comments

6 comments

Sort by
  • wallacea
    Hi Francis,

    Thanks for the feedback, and sorry about the problems. SQL Backup 5.0 should be fully backwards compatible. Could you please tell me a bit about the backup you are trying to restore? Is it encrypted? What level of compression are you using? How large is the sqb file?

    Thanks
    Alan.
    wallacea
    0
  • HJoyce
    Could you please restore the header only? e.g. run the following query:

    master..sqlbackup '-sql "RESTORE HEADERONLY FROM DISK = [...] " '

    This will test if the backup file is valid.

    If it is valid, what is the result if you restore only the file list from the backup file? e.g.

    master..sqlbackup '-sql "RESTORE FILELISTONLY FROM DISK = [...] " '


    thanks
    HJoyce
    0
  • bill.wehnert
    I too am having problems with the UI - it starts the "Retrieving History" - the agent then goes to 30% CPU and never comes back.

    This file was backed up with the current version of SQL Backup, with compression, but no encryption.

    I am trying to use the command line restore now. There is no indication if it's doing anything, so I can't tell if it's in the same infinite loop or not.

    I did just check the directory to where the file is being restored and it has increased the size of my data file to the full size of the DB, so perhaps it is working.

    I know recently when I tried to restore a backup over a smaller version of the file (the original size was 20gb on my dev server, and now my production DB is at 50gb) - it took a long time (like an hour) before it actually started to restore the database. I'm hoping it's not going to take that long now. This was all with version 4.x of the software - no cross versions going on and it was all on SQL2000. I'm now restoring that same backup to my SQL2005 on my local PC.
    bill.wehnert
    0
  • Jason Cook
    Both the command line and extended stored procedure will create the full size of the file before it performs the restore - this can take some time if the changes in file size are significant.

    Unfortunately the beta version does not give any feedback on the progress of creating the file, but I will raise this with the developers and see if it is possible to include for the final release.

    If the files already exist and are a similar size to the current files being replaced then the "file creation" step will be very short (a matter of seconds) before it moves onto the next step - it's entirely dependent on the amount of disk space that needs to be allocated.

    ===

    As for the Retrieving History comment, can you perform the steps that HJoyce described in the post above yours? Does that return anything, or does that never return?

    Thanks,
    Jason
    Jason Cook
    0
  • bill.wehnert
    It took 1263.665 seconds to do the full restore, but it did finally work.

    I haven't tried the step recommended above to restore the header, that's not going to mess up my database - is it?

    If not, I'll test it to see what happens. :)
    bill.wehnert
    0
  • Jason Cook
    The restore header steps are designed for diagnostic use. The two commands provide different information about the backup:

    HEADERONLY returns information about the backup itself, including the database that was backed up, Server and SQL Server instance name, LSN information and more.

    FILELISTONLY returns a list of the logical and physical files that are in the backup, and some basic information about each file (LSN information, size and so on).

    Given that you have established the restore is working fine, there is no need to try the above commands (since they can be used as the first step to identify if the file has been corrupted)... but if you do wish to try them, they will not touch the database, and will not change the backup file.

    As for the performance... 20 minutes for a 50GB database restore seems to be in the right ballpark (about 40mb/s)... it will depend on what compression and encryption levels you were using.

    Hope that helps,
    Jason
    Jason Cook
    0

Add comment

Please sign in to leave a comment.