Jump to content

dthede

Members
  • Content count

    40
  • Joined

  • Last visited

Community Reputation

0 Neutral

About dthede

  • Rank
    Occasional Forum Poster
  1. Yes. Here is something similar trying to rebuild a catalog from a disk-resident backup. "[ ]" contains my input. Tools > Repair Catalog > Recreate from disks [OK] All Disks > [My Computer] > [DiskXYZ (N:)] > Select a Backup Set to recatalog [users_Backup_Set][OK] Several Notes about the preceding line: (1) that "Users_Backup_Set" is a defunct backup set that hasn't been used in 10 years (?), has no scripts using it, etc., has been "forgotten" AND, (2) that the actual backup whose catalog I'm trying to rebuild, has a name totally different name; AND (3) no other name besides "Users_Backup_Set" appears anywhere in the various dialog boxes from Retrospect. Apparently I am forced to use that name, no matter what. Continuing with procedure, then: Are there any more disks in this Backup Set? [NO] Backup Set Users_Backup_Set appears to be encrypted. Please enter the password: [Password] Saving Backup Set Catalog File Retrospect Catalog Files (No items match your search.) File name: Users_Backup_Set.rbs (autofilled by Retrospect) [click SAVE] Message: "The Backup Set data file name is invalid, cannot recatalog the set using these files." Note also, the surprising History entry: History Tab > Rebuild Operations Log + Executing Rebuild at 6/18/2012 11:34 AM To Backup Set Users_Backup_Set 6/18/2012 11:34:14 AM: Execution completed successfully I'd like some help on this, too.
  2. dthede

    Can I run Retrospect Professional in safe mode?

    You might try using msconfig.exe to disable startup items, and then systematically renable them in groups, "binary search style."
  3. Re: Additional Problem. I don't know how to fill the gaps you are referring to. (That's something I'd like to know!) However, Retrospect will allow you to control whether duplicates are added to the resulting Backup Set. In the Transfer script you create look for OPTIONS button, then go to MORE CHOICES. Click on MATCHING and figure out which of the 3 boxes (or combo thereof) meet your requirements. Use the HELP to understand the implications of "a match."
  4. From time to time, perhaps all too frequently, I get messages that a particular chunk of a backup set is either corrupt or from another backup set. Accordingly I have to declare the chunk missing; as other users will know, sometimes it requires declaring several chunks missing. (1) Is there a reader which can directly read the chunks as they exist, (corruptions and all) whether they be compressed or uncompressed? 600MB of unusable data in compressed format represents a significant loss. (2) In some cases I would be willing to sift through the file to attempt to do partial recovery. Are there any File Recovery softwares which others have tried to use with Retrospect backup sets? Didrik
  5. dthede

    Backup set password

    posting moved
  6. dthede

    Backup set password

    Is there a way to change a password on a backup set? SOP requires changing the password on a regular basis. It appears uncertain how to change a password on a backup set.
  7. No subtle reason; simply a mistake.
  8. dthede

    Software Compression Not Happening

    As others have stated, I also have a backup script (back to disk) which specified Backup Set compression. When looking at the Op Log History Tab, however, it shows zero percent compression. I've gone back and checked the script to verify that my SOP of using compression was indeed selected. The target Volume being backed up is spongy so I would expect about 30% compression, as on other backups for this volume under a different script, not zero. Any helpful thoughts regarding software compression under Retrospect version 7.5.14.102 in the Win XP Pro SP2 environment? (The response that there is simply 0% compression on average is not helpful, since the same target files typically report back 29% compression under the original script.) Since this is a first backup under a new script, (All Files selected) it's easy to compare bytes backed up in the Backup Set to the bytes in the source Volume.
  9. I have a backup script (back to disk) which specified Backup Set compression. When looking at the Op Log History Tab, however, it shows zero percent compression. I've gone back and checked the script to verify that my SOP of using compression was indeed selected. The target Volume being backed up is spongy so I would expect about 30% compression, as on other backups for this volume under a different script, not zero. Any helpful thoughts regarding software compression under Retrospect version 7.5.14.102 in the Win XP Pro SP2 environment?
  10. It would be helpful if in the ACTIVITY MONITOR we could see where in the Backup Set Transfer Source the transfer operation was currently. Currently it shows simply the source Set and the Destination Set and file. It would be helpful to know the Snapshot and the Session from which the file is currently being pulled, so projected space requirements can be made more accurate.
  11. Same problem(s). No solutions yet. Except that my .iso image is 723.6 MB ...
  12. I have exactly the same problem(s), using the same patched version. It does not seem to be a permissions thing. Could it be because the .iso image file is larger than 700MB? That is, does Retrospect "think" it's actually writing a CD-R and has exceeded the media capacity, hence "cannot write" even though I have told it to "continue."?
  13. dthede

    Can't restore from rdb files

    Assuming that the rdb file is actually not corrupt, the entire Retrospect use of file list box and the way it points to a backup set member is non-standard by any understanding of Windows. What it's actually asking for is the folder enclosing the folder named "Retrospect" not the backup set. Misunderstanding this on an occasional basis -- say incorrectly pointing to the set after receiving a notice that the backup set cannot be found -- has led my installation to have some infuriatingly goofy hierarchical structures. For example, J:\Retrospect\Main_Backup_Set\1-Main_Backup_Set and J:\Retrospect\Retrospect\Main_Backup_Set\2-Main_Backup_Set as well as J:\Retrospect\Main_Backup_Set\Retrospect\Main_Backup_Set\3-Main_Backup_Set These can be properly sorted out but it takes time and patience and complete understanding of where that dialog points and where Retrospect "thinks" it points. Ultimately one simply asks "What was development thinking when they set it up this way?" They simply decided to make words mean what they wanted them to mean. (Every software I've used has such peculiarities.)
  14. dthede

    Retrospect Optimal Use

    It would help to have an authoritative document or other authoritative posting on the optimal deployment of Retrospect 7.5. Here's why: There are 34 issues returned on a search of "backup time" under the Professional forum, and 15 or so topics referring to "optimiz" (the root). In my case, the actual backup time is much less than the building snapshot time and the closing time. There must be more experienced users than I, who know the best balance among: backup size, catalog size, backup time, closing time, building snapshot time, and comparing time. For example: A typical backup that requires 10 minutes for building a snapshot, and 4 minutes for closing time, but only 3 minutes for backup, might indicate that the catalog has simply grown too big relative to the file "churn" for the backup period under consideration. Maybe it indicates that a new catalog should be started. Or, from a strategic point of view, perhaps it indicates that the backup set is itself too broad in scope; i.e., the actual churn is typically in a small region of the catalog, but the it still necessitates Retrospect manipulating the entire 800MB catalog. One would think that EMC / Dantz, etc. would have some typical "phase diagrams" for optimizing performance. Perhaps a rule of thumb guide that speaks to the percentage of a backup set (&/or catalog) that is updated during a typical backup, would be helpful. Naturally, it would be completely unhelpful and would really duck the issue to say that every installation is different and performance would vary so much that generalizations are not possible. It would be as silly (and unhelpful) as saying that there are so many different file types that no one software can back all of them up. We will recognize that "our mileage will vary."
  15. Another characteristic may be that I went from build .285 to .370, skipping the .324 build linked by Robin Mayoff in one of his posts. Could it be that something in .370 relies upon a change made in .324, such that the Catalogs are perceived as corrupt if one skips the .324 update?
×