Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Cygnis

  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. 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. 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. 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. 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. 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. 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. 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?
  15. Glad to help. Network shares do not count as extra computers, so you can use any number of them as backup sources / destinations, without purchasing extra client licences.
  16. You may need to give Retrospect a bigger portion of the available disk space to use. Try clicking: Configure -> Backup Sets -> (backup set name) -> Members -> Properties What is the "use at most" section set to? Can it be increased to a larger amount?
  17. I trialed version 9 recently, and had a similar problem when trying to use the 'restore on demand' feature (Retrospect getting stuck, with CPU usage high but seemingly little actually being done). I can't recall whether the same occurred with restores initiated by the server, however.
  18. I, too, am grateful that most of the older forum content has been retained. Thanks very much! I also agree that regular participation from Retrospect staff would be much appreciated. It would be especially nice to be kept better informed of development progress, upcoming releases etc.
  19. You can do all of that with a single Professional licence on computer #3. No need to keep using Express HD. If you only have three computers to back up, you don't need to purchase any extra client licenses. Professional will back up three computers by default (the computer on which it is installed, plus two clients). As far as I know, v7.7 can read backups made by Express HD, but Express HD cannot read backups made by v7.7 (since v7.7 introduced a new backup set format).
  20. You aren't supposed to open the RDB files directly. You're supposed to use them as part of a Backup Set, through the use of a Catalog file. Have you tried re-building a catalog, using Tools -> Repair Catalog -> "Recreate from disks"? I would like to try helping you, even though I do not work for Retrospect. I installed Windows XP and Retrospect 6.5 onto a secondary computer, to try and replicate your problem, but I cannot. If I discard the catalog and move the RDB files around, I am still able to re-build the catalog from whatever location I move them to, then access and restore the contents. I know you said you have "tried everything", but could you please specifically confirm you have tried these exact steps: (1) In Retrospect, click "Tools", then "Repair Catalog". (2) Choose "Recreate from disks", then click OK. (3) Click "All disks". (4) Click the drive where the RDB files are stored, then click "Browse". (5) Find the folder which contains the RDB files. Click it once so it is highlighted (do not double-click it), then click "Select". (6) A list of one or more Backup Set names should appear. Click the one you wish to re-build, then click OK. (7) You will be asked if there are more disks in the same backup set. The answer will be "No", unless you used multiple drives for your backups. (8) You will be asked where to save the catalog to. Generally, the default location for catalog files will be selected, and it is fine to save here. If these steps do not work, please tell us which step gives you problems, and exactly what goes wrong.
  21. Thanks for clarifying. I do not have Express 6.5 (only 7.6), but I do have access to an old copy of Single Server 6.5, so will try to install that onto an old XP machine and see if I can replicate the problem. So far I have tried to do so using a Windows 7 machine and Express 7.6, and all seems to work fine (no problems rebuilding an old catalog from disk), but a lot could have changed between XP/6.5 and W7/7.6. Just to be sure: when you select "Repair Catalog", are you choosing the "Recreate from disks" option? You must choose this if your backup set is RDB-based, and not one of the other options such as "Repair file backup set".
  22. Velox: when you click "Repair Catalog", you need to select the "Recreate from disks" option, NOT the "Repair file backup set" option. Have you tried that?
  23. It works for me (for clients) on Retrospect Single Server on a Windows 2003 Small Business Server machine. 4 Mac clients and 1 Windows XP client seem to wake up fine, in conjunction with Proactive backup scripts. (As far as I know, the feature is not supported for non-Proactive scripts, but I haven't tested.) Note that the actual wake-up may occur a few minutes after you expect it to, which I assume is something to do with the 90-second 'polling' interval of Proactive backups.
  24. By the way, here is a free, easy-to-use Mac program that can be scheduled to wake computers up at particular times: http://www.readpixel.com/wakeonlan/index.html If a Proactive backup script is not suitable for your needs, maybe you could install this on the same computer as Retrospect, and schedule it to wake each computer 5 minutes before its scheduled backup time?
  • Create New...