MetaBase.bin not restored with system state

[PCDr]

I am using Retrospect Professional 7.6.123.

 

I am testing its use for a full restore after loss of the hard drive. The Disaster Recovery CD will not work -- the ISO image is too large.

 

I've thus opted for a method that involves a temporary installation of my current OS (XP SP3), installation of Retrospect, restoration of a small "secondary" OS on another partition, a boot to that alternate OS where Retrospect is already installed, deletion of the temporary XP install, and, finally, restoration of the primary OS, apps and data to their respective partitions.

 

I was surprised (and disappointed) to see that when Retrospect restores the system state from the secondary OS to the primary OS (which contains a WINDOWS directory tree), the restore claims to have succeeded but it does not restore the registry to system32\config. Apparently, the system state restore has to occur from within the primary OS. (This is counterintuitive.) So, I used a manual registry backup (made routinely with ERUNT) to allow the primary OS to boot and restored the system state with Retrospect from within the primary OS. Again, the restore claimed to be successful. The History pane shows 0 files restored, which doesn't make sense. SInce the system state is backed up via an API, there are 0 files backed up, but there are certainly files restored, the registry hives among them.

 

After the reboot, the registry had indeed been rewritten, but MetaBase.bin (a system state component in the system32\inetsrv directory) was not restored. (I have now added it to my manual registry backups so it will be available in case of a calamity.)

 

Is there a complete list of the files that are rebuilt by a system state restore? I need to ensure via this trial run, that all of the files are restored. If not, I need to ensure that they're backed up manually.

 

(When I searched for "system state" or "registry" or "metabase.bin" in the knowledgebase, I found nothing useful. In Retrospect, "Help" had little to say.)

Edited April 1, 2013 by PCDr

[Scillonian]

I've thus opted for a method that involves a temporary installation of my current OS (XP SP3), installation of Retrospect, restoration of a small "secondary" OS on another partition, a boot to that alternate OS where Retrospect is already installed, deletion of the temporary XP install, and, finally, restoration of the primary OS, apps and data to their respective partitions.

 

Why are you going through these temporary and secondary OS installs? Why not just install the primary OS and restore directly to it? It may be because of the roundabout method you are using that some files are not getting installed.

 

Through trial and error over many years of using Retrospect I have found the following to work reasonably well:

 

• Periodically take a image of the system using Clonezilla (other imaging applications are available) :-)
   
  Backup regularly.
   
  If a total system failure occurs then restore the image then let Retrospect take care of the changes since the image was taken with a restore.

 

Before using this I would do a reinstall of the OS, install Retrospect then do a complete system restore.

[PCDr]

Thanks for your reply.

 

Why are you going through these temporary and secondary OS installs?

 

The secondary install is very quick and complete. It allows me to reinstall the primary OS without it having to overwrite itself, except for the final system state restore step. If I get a list of the files implicated in this step, I'll restore the files instead.

 

I have found the following to work reasonably well

 

FOA, I'm glad you have a procedure that works for you.

 

I do not image my hard disk. I back up files. That's why I use Retrospect.

 

I have never used System Restore -- I have never needed it. I have restored an older version of the registry on occasion from the secondary OS.

 

Secondly, I sure would have appreciated a pointer to an answer to the question I raised in my post:

 

Is there a complete list of the files that are rebuilt by a system state restore?

 

It appears that Retrospect has a bug. MetaBase.bin is part of the system state, yet it's been overlooked when the system state is restored. Are there any other files that may have been overlooked by Retrospect?

[Scillonian]

The secondary install is very quick and complete. It allows me to reinstall the primary OS without it having to overwrite itself, except for the final system state restore step. If I get a list of the files implicated in this step, I'll restore the files instead.

 

Before we go too far, has this procedure ever worked?

 

From my experience of restoring Operating System (OS) installations using Retrospect I don't think it can work.

 

When a restore is made of the backed-up OS it has to be made a running system. When Retrospect encounters open or locked files during the restore the files from the backup are written to a temporary folder. At the end of the restore the System State data is also written to this temporary folder and a boot time script is created and you are advised that the restore is complete and to restart the restored system. When the system restarts the boot time script is run and the open or locked files and the System State are replaced from the temporary folder. When the script is finished the system restarts again and is be back as it was at the time of the backup.

 

I have never used System Restore -- I have never needed it. I have restored an older version of the registry on occasion from the secondary OS.

 

By 'system restore' I was meaning to restore the system using Retrospect, not Windows System Restore.

 

It appears that Retrospect has a bug. MetaBase.bin is part of the system state, yet it's been overlooked when the system state is restored. Are there any other files that may have been overlooked by Retrospect?

 

According to Microsoft the files and settings that constitute System State on Windows XP are:

The System State data comprises only the registry, COM+ Class Registration database, files under Windows File Protection, and boot files. (http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntbackup_system_state.mspx?mfr=true)

From what I can find the data that is backed-up for System State is whatever Microsoft has defined for that version of Windows. As MetaBase.bin is part if IIS it doesn't look as though it is included in System State on Windows XP.

[PCDr]

Before we go too far, has this procedure ever worked?

 

Yes, it's worked very well during my testing, with the exception of metabase.bin. That caught me by surprise.

 

When a restore is made of the backed-up OS it has to be made a running system

 

This is not my experience. My system drive is backed up with the system state. During these tests, it is restored in its entirety to an empty partition, but Retrospect omits the system state -- the system32/config folder is devoid of hive files and, on reboot, there is a message about "SYSTEM" missing. If I restore the system drive and then restore the system state, Retrospect tells me that the restore was successful, that 0 files were restored, and the system32\config folder is as empty as it was before. (IOW, the restore of system state from a secondary OS does not work.) I thus restore a backed-up registry (as well as metabase.bin), which allows the system to start up without error on reboot.

 

I have a little cleanup to do (drive assignments), but the system appears to function normally. I'll probably opt to restore the system state backed up by Retrospect in a followup step from within the restored OS -- I'm not sure what it does but it doesn't do any harm. I remain concerned about files that Retrospect may be omitting.

 

As far as what's included in the system state, I use Metabase Restore Procedure and Backing Up and Restoring System State as references. Both explicitly mention metabase.bin. Also, when XP's own NTBACKUP.EXE is used to back up the system state, metabase.bin is included -- it's mentioned in the log file.

 

Metabase.bin is absent from most XP installations. IIS is only included in XP Pro and it's rarely installed by users. Nevertheless, if Retrospect chooses to omit metabase.bin (there's no obvious reason for it to do that -- I believe it was an oversight), it should throw an error during backup ("metabase.bin is open and could not be backed up") and the documentation should state that the file is ignored. Manual backup of metabase.bin is trivial, but I had never done it, since I assumed that Retrospect was doing it for me.

 

Again, I'm inquiring in this post about other files that need to be manually backed up because Retrospect does not include them during a restore of system state. What are the files whose contents are backed up via the system state? Which of those files are not recreated when Retrospect restores the system state? Metabase.bin and... ?

Edited April 3, 2013 by PCDr

[Scillonian]

Have tried using the trial version of Retrospect 8.1 Professional to do a backup and restore. Retrospect 7.6 is now quite old and it would appear that Retrospect 7.6 will only restore the System State when done from the primary OS.

 

Using Retrospect 8.1 Professional I have been able to restore a Windows XP Professional SP3 system to a blank disk. Other than having to manually restore the MBR (which I was expecting to do anyway) the system was fully functional. As I don't have IIS installed (on any of my systems) I can't say whether MetaBase.bin would be restored.

[PCDr]

Thanks for sharing your test results.

 

As I don't have IIS installed (on any of my systems) I can't say whether MetaBase.bin would be restored.

 

That's the killer, though. MetaBase.bin is part of the system state and Retrospect 7.6 doesn't restore it. (I believe, but cannot prove, that it does back it up, because Retrospect omits MetaBase.bin from the inetsrv directory listing.)

 

If it was confirmed that Retrospect 8.1 correctly handled MetaBase.bin, I'd upgrade.

 

As it stands now, I stop the W3SVC and IISADMIN services, copy MetaBase.bin to a separate directory, and then start up Retrospect.

 

My question is whether I need to back up something else that Retrospect neglects to restore from the system state.

 

Thanks again for your response.