Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About PCDr

  • Rank
  1. Thanks for sharing your test results. 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.
  2. Yes, it's worked very well during my testing, with the exception of metabase.bin. That caught me by surprise. 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... ?
  3. Thanks for your reply. 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. 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: 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?
  4. 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.)