Jump to content

Cygnis

Members
  • Content count

    152
  • Joined

  • Last visited

  • Days Won

    2

Cygnis last won the day on August 15 2012

Cygnis had the most liked content!

Community Reputation

2 Neutral

About Cygnis

  • Rank
    Newbie

Profile Information

  • Gender
    Not Telling
  1. I'm happy to report that catalog compression is now working for this new set, after a catalog rebuild. To keep it compact. We back up our catalogs (via Duplication to other disks and including them in tape backups of the server), and at large sizes, keeping them backed up becomes quite slow and space-consuming. Having said that, I may start excluding the catalogs from some of our scheduled backups, as keeping them backed up probably won't help us in some of the anticipated disaster recovery scenarios. If I do this, compression will probably become unnecessary. Is there a performance benefit to leaving them uncompressed?
  2. Retrospect Support suggested a catalog Rebuild. I did this for the smaller of the two sets, and it initially resulted in a Catalog file of the same size. However, the "Compress catalog" setting in the Backup Set properties had reverted to "Off"... when I set it back to "On" and ran another backup, the catalog compressed properly again, so all is well for that set now. (Prior to the rebuild, turning the "Compress catalog" option on/off had no effect... the catalog file simply wasn't compressing.) Unfortunately, when I tried rebuilding the bigger set, it failed with what appears to be memory allocation errors (e.g. TMemory::mhalloc: VirtualAlloc(246.5 M, MEM_RESERVE) failed, error 8). Then the scheduled weekly Groom of this backup set took place afterwards, and wiped out all but the one Snapshot that had survived the botched Rebuild. Thankfully, I still have the original source backup set online, so I've created another new one by transferring selected Snapshots instead of the entire backup set. This one's catalog is not compressing either! Will try rebuilding it and post back with my results.
  3. Hi all, We are using Retrospect Single Server v7.7.620 on Windows 2003 SBS. We have 'cloned' two large disk backup sets (one 1.4TB, one 1.2TB) to two new disk backup sets, using the "Transfer Backup Set" operation. The resulting new backup sets have MUCH larger catalog files than the originals. One has gone from 750mb to 1.7gb, while the other has gone from 3.2gb to 12.8gb! Catalog file compression is enabled in all sets. The new sets have the same grooming settings, same number of sessions/snapshots, and backup data size on disk as the old sets... it's just the catalog files that are much larger. Details that may be relevant: - Both the original sets and both the new sets were created in version 7.7 - no other Retrospect versions have been involved. - I got a couple of "Backup set format inconsistency" errors during the Transfer operations. I've tried grooming one, but the catalog file size didn't change. Would rebuilding the catalog file help? (If I were to rebuild, would the snapshots all be retained?) Any other ideas, and/or suggestions on what might be the cause of this? Thanks! P.S. I have also submitted a support request, and will share my findings here if/when I receive a reply.
  4. They are stored in the hidden "System Volume Information" folder at the root of your drive(s). I think they hold the 'restore points' created by the "System Restore" feature of Windows. Does anyone know if they can be safely excluded from backups?
  5. Cygnis

    Retrospect 8 - My experience (so far)

    I'm very pleased with the addition of Proactive backup and the extra client licenses (both features I requested a while back), but unfortunately, have already encountered a nasty problem when trying to groom my main backup set. Both times I've attempted to groom it, I've received the message Assertion failure at "grx.cpp-1089", and been unable to do anything with the set without rebuilding the catalog. (I can't even view its properties!) Here is another thread (over in the "Server" forum) started by someone else who has encountered this: http://forums.retros...at-grxcpp-1089/ Not a promising start. I have created another set using version 8 (whereas the problematic one was created in 7.7), and will post my results after attempting to groom that one. As I noted in that thread, I never encountered this issue (or anything like it) in over 2 years of using version 7.7. I hope this is resolved soon, as I'm currently reluctant to install v8 at my workplace (where I have much larger backup sets that will be less practical to recreate than my ones at home).
  6. I received this error the first time I tried grooming after upgrading to Retrospect 8. So I rebuilt my catalog, tried grooming again, and got the same error! Any other suggestions? I never encountered this on version 7.7, which I have used successfully for over 2 years... Edit: Additionally, I cannot even view the properties of the affected Backup Set once this error has occurred. When I try to, I get an error message -2259 (incomplete grooming detected). Looks like I'll be rebuilding it a second time
  7. You can export to a plain text file without restoring anything: (1) Click Restore, then choose "Search for files and folders" (2) Select the backup set whose contents you wish to export. (3) Choose any destination folder (it doesn't matter, since you won't actually be restoring). (4) Clear all search criteria, so that Retrospect will search for everything. (5) Click the button next to "Files chosen", to bring up a preview box. (6) Click File -> Export, then choose a filename/location for the text file. Enjoy
  8. On my computer, I have a file called "Retro_Emergency_Recovery_CD-EN.exe". You could try looking for this via Windows Search. When I run this .exe, it extracts a file called "Emergency Recovery CD - EN.iso" to a subfolder called "Retrospect Recovery CD". Also, if I extract my full download of Retrospect (Retro-EN_7_7_325.exe), it contains a "Recovery CD Image" subfolder containing the same .iso file.
  9. Cygnis

    Retrospect cannot see computers and drives on LAN

    Thanks for sharing your findings. Have you tried installing the Retrospect Client program on the secondary computer? I find it to be much more convenient than backing up via Windows file shares.
  10. Cygnis

    Retrospect not finding Backup Set memer

    No problem. Glad to hear you've had some success. Hopefully it has continued to work since then. This is because you can specify a maximum size for each backup set (a very handy feature, particularly if you need the disk to contain more than just the Retrospect backup set). Therefore, the backup set member's available space could be quite a lot less than the overall disk's available space. You can change this setting here: Configure -> Backup Sets -> (backup set name) -> Properties -> Members -> (select member) -> Properties -> (change the "use at most" setting) If I recall correctly, it is not recommended to allow a backup set to use 100% of the disk on which it resides, since Retrospect likes to have some free space available for temporary use during its operations. I can't remember what the exact numbers are, but I generally use 90-97% (if I am devoting the disk entirely to a single Retrospect backup set) and have not encountered problems so far. You can move them around by changing the properties in the "Members" section of the backup set (accessed as described above). I was going to suggest this as something to try for your original problem, but suggested the Catalog repair/rebuild instead because it sounded like the previous catalog file had problems (e.g. it thinking the backup set was full).
  11. Cygnis

    Retrospect not finding Backup Set memer

    Sounds like the new "Select backup member" dialog (the one without the 'Browse' option) is a prompt for a second drive, due to Retrospect thinking the first one is full. I've never had problems like this before, but here is what I would try: Tools -> Repair Catalog -> Update existing catalog file -> (backup set name) Then if that doesn't help, try: Tools -> Repair Catalog -> Recreate from disks -> All disks -> (select the disk on which the backup set resides, so it is highlighted) -> OK Note that the second operation could take a while, since it would be rebuilding the catalog file from scratch.
  12. Cygnis

    Retrospect not finding Backup Set memer

    Try clicking the "Choices" button, then "Browse". You will be asked for a specific RDB file, which you should be able to find amongst the many RDB files you noticed as being on your drive. Does this work?
  13. Cygnis

    Duplicate Setup

    Thanks for confirming. In that case, you will need to do one of the following: (1) Have a separate script for each folder/destination pair (i.e. duplicate them one at a time), or (2) As Lucky_Phil described, and set up a Selector that is applied to a parent of all the folders you wish to copy. (The resulting script may be relatively slow, depending on how much other content is in the parent folder that does not need to be backed up.) The only other possibility I can think of is to Backup (not Duplicate) the sources to a common backup set, then Restore them to a common destination, but I've never tried that, and am not sure whether it will result in the desired folder structure on the destination.
  14. Cygnis

    Duplicate Setup

    It isn't possible. The point of a Duplicate operation is to exactly copy a single volume (or folder) to another. Do you want to combine multiple source folders into one destination folder? Or, do you want to copy each folder to its own destination folder?
×