Jump to content

heidnerd

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About heidnerd

  • Rank
    Newbie
  1. In the next update of Retrospect, instead of failing with the message and leaving customers worried about the disaster recovery. Could you please include sentence, popup box, or some kind of link to the section of the manual that covers the alternative live restore? I.e. instead of printing out page that tells you how to use the DR cd, instead print out the alternative process... or ask if they want to run a wizard to help with preparing for that. It would help to eliminate the fear, uncertainty and doubt that is created about Retrospect -- especially when it happens late at night and tech support isn't available. Making the alternative procedure available instead of the nasty -1132 error shows that the Retrospect developers put thought into the boundary condition and they had prepared for it.
  2. That doesn't make sense, since the really the only difference between the DELL OEM WinXP CD and the Microsoft CD is the inclusion of the drivers taht are needed by the DELL laptops for the install. If creating an EMC Retrospect recoverey CD isn't supported with OEM Windows CD's (90% of the current market), how about a knowledge base entry that describes an alternative method. I.E. rebuild PC using the vendors recommended process using their OEM CD but installing an alternative Windows directory - like WIN_RESCUE. Then adding retrospect back onto the machine and restoring all files back on to the PC using the "WIN_RESCUE" image you created with the OEM CD's. We really do need a solution to the "can't create disaster recovery CD problem'.
  3. This thread (-1132 Trying to Create)has been going on for nearly a year. Lots of people with similar problems. But no real resolution or hint of fix either the forum or the knowledge base. Any idea of what the priority EMC might be placing on this? FWIW, like many others I also am using Dell with the OEM CD... and prior to February 2008 it wasn't a problem. I know the recovery disk creation and restore works because I have used it with the Dell previously. The WINNT path that has been mentioned really isn't anything unusual... during the install process MS asks the user where to install and many of us install into directories other than the straight windows directory. Several reasons why -- one of which worms and viruses often are hard coded for C:\windows instead of using %windir% for the path. I also believe that when you discover the cause of this problem you may also find out why the ISO image is growing larger than 680MB. My guess is lots of stuff being placed into WinSxS and that is causing the ISO to grow... plus causing pathname problems, etc... In any case - one year is a little long -- without being able to create a recovery CD, and for several of my family laptops the decision to continue and wait for with Retrospect to be fix or move on to another vendor for backup and recovery is quickly approaching. Since I also have an exchange server... this implies a more wide spread change. So I really hope someone on the retrospect crew is really looking into the problem.
  4. as the pc administrator, start up a windows command shell (start menu, run, then cmd) and check to see if vss is okay by doing a >vssadmin list writers You should see several writers that are enabled for vss and no error messages. for example: >vssadmin list writers vssadmin 1.0 - Volume Shadow Copy Service administrative command- © Copyright 2001 Microsoft Corp. Writer name: 'SqlServerWriter' Writer Id: {a65faa63-5ea8-4ebc-9dbd-a0c4db26912a} Writer Instance Id: {8735cb3a-4e63-4752-b0df-19e42b3de014} State: [1] Stable Writer name: 'MSDEWriter' Writer Id: {f8544ac1-0611-4fa5-b04b-f7ee00b03277} Writer Instance Id: {0ff61f09-fba4-4aac-82d8-5300c9b72324} State: [1] Stable Writer name: 'Microsoft Writer (Service State)' Writer Id: {e38c2e3c-d4fb-4f4d-9550-fcafda8aae9a} Writer Instance Id: {92cada6b-5d15-47f3-8db0-53ff12b04c26} State: [1] Stable Writer name: 'Microsoft Writer (Bootable State)' Writer Id: {f2436e37-09f5-41af-9b2a-4ca2435dbfd5} Writer Instance Id: {8f8e0f54-5261-4d8f-9a19-80a6563cb56a} State: [1] Stable Writer name: 'WMI Writer' Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0} Writer Instance Id: {48e82a02-a300-4303-a651-d64dce1f0c4d} State: [1] Stable Make sure you see "Stable" for each instance. If you have any errors, or they are not stable, check the MS knowledge base for the steps to correct the problem. Checking the event log or running services is really iffy when verifying VSS. Using the vssadmin tool is more reliable.
  5. Just documenting another possible cause for the -1127 error while creating ISO. Error in the retrospec log file is as shown: + Executing Prepare for Disaster Recovery at 5/26/2008 10:20 PM From Backup Set Made_2007_A, Snapshot C_drive (C:) 5/26/2008 3:00 AM To CD-ROM image file Restore C_drive.iso... File "IMAGEHLP.DLL": can't read, error -1127 (data error detected in file using cyclic redundancy check) Trouble writing files, error -1127 (data error detected in file using cyclic redundancy check) 5/26/2008 10:27:00 PM: 2 execution errors Can't continue execution, error -1127 (data error detected in file using cyclic redundancy check) Now explanation: The source for the IMAGEHLP.DLL was the WinXP SP2 CDROM. The physical CD media from MS was okay. It is the CD reader/writer that is flaky. Dirt, lots of use, age wears the things out... only about three years old but in the life of a DVD writer -- that is old. Windows Event log may contain an entry such as: "The device, \Device\CdRom0, has a bad block." Verifying(reading) the WinXP on another PC you do not encounter the bad block error. The solution was to copy the content of the i386 directory from the CD into a i386 directory on the local machine. Than do the create disaster CD using the local (non-CD) file... works okay and rebuilds/restores okay. What I think is happening is that the DVD reader/writer is getting old, the machine was pretty busy grinding away and creating the iso (this is a 3Ghz duo core machine with 2GB ram), but even so the DVD was "spinning up and down" occasionally -- but only when retrospect was creating the iso image. Using explore to copy the CD to disk, kept the CD spinning all the time and thus it didn't have the read errors. Long term solution is to replace the $49 DVD writer with another $29 DVD writer... :rollie:
  6. But is there a retrospect switch, option or EMC tool that will allow your customers to extract at least portions of good data from the big chunks? I've had this also happen and is pretty depressing when your backup tool that you've sold those around you on using - and investing money for ends up failing and you've lost sometimes years of data. Ntbackup for example had switches that you could use to ignore missing tapes that were part of a set. Is there such switch for the retrospect restore?
  7. heidnerd

    Excessive backup

    Another option which may still offer the protection of the system restore points -- but not have the huge backup... is to change the amount of space that the system has reserved for the restore points. On WinXP you used to do that by selecting the properities of my computerr, then system restore, selecting the volume to adjust and then make the change. If you have a huge drive.. it is possible that you have many gigabytes of system restore points and you might only need to have a couple of gigabytes for the restore points...
  8. I also have seen this problem. I think that I may have discovered part of the problem or trigger for it. However I do not have a solution. If you look carefully at the error messages, you may notice that occasionally the same dll file is named multiple times. I.E. mscrt, mfc42, atl, comctl32, msvcp60.dll etc. If you perform a file search for the files listed in the error -- there is a pattern!! The number of errors for each of the files listed by retrospect will match the corresponding number of files found in the windows root directory (i.e. C:\windows) but under the subdirectory WinSxS --AND-- for a select major versions of the library. Really confusing - but case in point is the comctl32.dll, on daughters laptop - it is listed as FOUR errors by retrospect. A search of the hard drive finds TWELVE occurances - BUT in many very different directories. However there are only FOUR entries in the C:\Windows\WinSxS\x86_Microsoft.Windows.Common-controls_6595b64144ccf1df_6.0.2600.xxxxxxxx When I looked at the other files -- same thing. I am guessing that retrospect is running into a limit on the path length somewhere and it is truncating the filename at the .xxxxxxxx above instead of including the additional 16+ characters that would make each of the files unique. So retrospect than thinks the files is exactly the same and gets confused. The WinSxs is the directory that handles the assemblies for many different installed software applications. As such the full filename can be quite long. New updates and patches by MS often add a "build" number after the basic version number of the file.... that "build" is what perhaps is being truncated. Causing Retrospect to think the files are identical. I am hoping that someone from EMC can check and verify this is what is happening. FWIW, this doesn't make much difference which version of WinXP, etc that you are on. This particular laptop was on WinXP SP2, using latest (May 2008) Retrospect updates didn't help, moving to WinXP SP3 doesn't help. Either. It also appears that the extra assemplies are added to WinSxS when you install applications like PhotoShop, or the additional language packs for Office 2003. (I.E. laptop has spanish, german, japanese, etc... also installed.) Meanwhile my daughters laptop is awaiting service by Dell and I can not use Retrospect to create recovery CD's....
  9. heidnerd

    error -1017

    Mostly this is a post for reference, after having spent HOURS trying to find solution to same error with WinXP. The MS Knowledge base entry was written for Win2003. And most of it applies. http://support.microsoft.com/kb/940184/en-us Several points: 1) The -1017, then -1020... and many other errors can occur if there is a problem with the Windows Volume Shadow Service. This service is used to perform open file backups by Retrospect. 2) It is easy to determine if the MS volume shadow service is at fault. To do so, open a command window, [start menu button], then [RUN], enter cmd, then use the vssadmin tool with: >vssadmin list writers You should see multiple entries that are simlar but NOT exactly the same as: Writer name: 'Microsoft Writer (Bootable State)' Writer Id: {f2436e37-09f5-41af-9b2a-4ca2435dbfd5} Writer Instance Id: {ac01d675-561d-4185-a96b-4dae010de8cf} State: [1] Stable Note the "State -- Stable" If you get an error 0x8000FFFF, then the knowledge base entry from microsoft will probably help out. The knowlege base solution from MS will step you through two possible solutions. Their solution is intended for Win2003, but it does indeed work for WinXP with some minor difference. But first - if you use their procedure - it involves editing the registry - so you are supposed to have a backup... ugh, retrospect isn't working!! So becareful. Follow steps 1-5 of KB940184. In step 6, for WinXp you may encounter errors wile restarting the COM+ application, Shadow Copy Provider or Volume Shadow Copy. If so it just means that you will MOST likely need to continue follow the second half of the procedure documented in the KB. (i.e. steps 9 - 11) But before doing so - verify that the volume shadow service is still broken. You can do so with the vssadmin list writers command noted above. If you get an error you will need to follow steps 9 - 11 in the MS KB. With the caveat for WinXP that you WILL NOT be able to register the "vssui.dll" libary as documented. Tryit, if you get a message that vssui.dll does not exist - that is okay -- WinXP remember - NOT Win2003. DO NOT try downloading and adding the vssui.dll to a WinXP workstation - that is asking for problems... just skip and go on. When done with the items listed in the step 9 of the KB, you can verify that the problem is fixed by doing the "vssadmin list writers". Now, what caused the problem to begin with? Several possiblities, over zealous cleaning of registry with "registry cleaning tools", possibly a virus (not likely)... and most likely a bad patch from microsoft. How can you keep from getting in deep dodo with this error? Make it a habit to ensure that you make recovery checkpoints before installing new software and patches. THEN pay attention to the retrospect error logs. As soon as you see one of the -1017 errors - considering rolling back to the prior saved AND working system state.
×