Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About dangermouse

  • Rank
    Occasional forum poster
  1. This works just fine for me. I have 5 HD's. Each is a separate Media Set. One is always offsite for several weeks at a stretch, two are online and in use and two more are in a drawer. Retrospect has a proactive script with a number of sources, each backed up daily. Each source gets backed up to the available media sets, alternating between each daily. Once a week I swap out one active disk for one from the drawer. Every few weeks I swap one from the drawer for the offsite one. Retrospect always shows me which sets it thinks are in use and plans to use, but always, at some point after I swap a disk, it spots the change (within 10-15 minutes, maybe?) and shows it plans to use the new disk, which it later does corrrectly. I used to have your problem and would have to stop the first failing run to the no-longer-available-disk, after which it would spot the change and update all other planned backups. A while ago this problem stopped after an update to a newer version. 8.2? I honestly don't remember, but either that or 8.1. Not sure I've helped, but knowing it can work reliably may be useful?
  2. I just had this happen. I believe the source duplicated after the upgrade to 8.2, not sure though. I checked the detailed path to both sources, /Volume/etc..., and both were identical. DF in Terminal also showed only one such volume was mounted. So I went ahead and deleted the source selected for backup, but showing as off-line. I then selected the other one for backup in the same proactive script. The backup ran fine, it recognised the 'new' source was in fact the 'old' one and only backed up a normal, incremental, amount of data. I'm not sure if this is exactly what you did? Or did you delete both references and Add another back in?
  3. I think you must be right. I realised it cannot be the catalogues, since it affects all 3 main backup drives. Then I realised it does not affect the portable drive we use for swapping out for off site storage. The backup to this drive is the same, but omits a large amount of (supposedly) unchanging, archived stuff. So I omitted this from the main backup and all has returned to normal. This is the bulk, but still just a part, of the one volume. So something about this data must have changed somehow. I'll discuss with others, see if anyone has done something. Would reorganising the folders cause it? We have the default settings with regard to matching by location, but I'm not sure I understood those options properly. Thanks for the advice, at least we have resolved the main problem and backups can run again.
  4. Retrospect has been backing this volume up for many weeks. After the initial backup it has been incrementing as expected quite happily. Now suddenly it wants to back up all (well, nearly all, about 450GB of 500GB) of the data again. The source volume has not grown, indeed it cannot have done since this is about the size of the data on the volume to begin with. Why might Retrospect have done this? This volume is backed up in turn to three separate backup drives. These are not members of a set, they are three separate sets, each offering a full backup. The full backup is being attempted to all three drives / sets, so it cannot be a catalog error? Another volume backing up to these same sets are also not having this problem. It seems retrospect now thinks this volume is not the same volume it has been seeing up till now. The volume as mounted did become appended with a -1 a few weeks ago, but Retrospect did not mind this at the time, so I don't think that's the fault. Any suggestions? I can (and to get an up to date backup have, on one set) recycle the backup sets and just start over, but don't want to lose any history of backups. Thanks for reading!
  5. dangermouse

    Retrospect 8 Users Guide

    I am happy to think this is not true, but can you really be surprised people worry about this? The release of a product without a manual is extraordinary. It's been promised for ages and not appeared. I seem to remember someone questioning it's lengthy delays before and being rebutted quite forcefully, only for months to pass with nothing appearing. The third sticky item (I think that's what you'd call it) in this very forum is titled "Retrospect 8.1.525 released ", so this makes the site look very poorly maintained, referring to an old version superseded several times. EMC now owns Iomega, who, after weeks of waiting for an update for the Rev drive drivers to work with Snow Leopard, simply stated there is an incompatibility which 'will not be fixed'. This, too, is extraordinary. A current product still on sale simply drops an entire platform on a whim. People have invested heavily in this Retrospect / Rev solution for backup, and it just gets summarily dropped? Why, in the face of these issues and the attitude revealed by this last point, would people feel confident? Even if a company has every intention of continuing with something, they have to be a viable business to do so. At the very least these issues have irrefutably shown you have significant resource limitations, and one has to wonder why. I do hope things will improve. The product itself sees to be far the most viable, yet it is still not good enough and having to guess how it works seriously undermines its usefulness and reliability.
  6. Didn't try a database restore, no. Didn't seem worth the risk! I guess I wasn't confident enough the restore would go to the recovery group. I did try restoring to a couple of other mailboxes, same result.
  7. Hi All, We're trying to recover just the Inbox of a single mailbox. We get the error 'Exchange Mailboxes on msexchange is in use by another operation. Wait for it to be available?' Retrospect is not doing anything else. We have set up a Recovery Storage Group, with restore allowed. Restore is not allowed to the actual Mailstore. Any idea where we've gone wrong? Thanks.
  8. dangermouse

    Engine crashes seconds after launching

    The disk is set to groom automatically, so how much space is left is down to Retrospect. It began the groom in the middle of a large backup of over 20GB. So I think there was a fair bit before that. I think the spare room requirement you mention is when the catalogue is on the disk? My catalogues are not on the backup disk, so there should be no problem? Of course Retrospect should automatically see to this itself if there is an issue. If only I could find that manual, I must have misplaced it.
  9. dangermouse

    Engine crashes seconds after launching

    Thanks very much, removing the catalogues allowed it to run. I identified the individual catalogue that was causing the problem. Then found even that catalogue could remain, I just had to remove the accompanying .rbc.log file of the same name. I presume this arose from the problem that occured while grooming. Then within Retrospect, accessing that backup still caused a problem, but I then asked it to repair it, which it quickly did and all was fine. The disk had only 9kb free, so obviously the grooming got nowhere. I presume I could groom again, but am not at all confident that this 10 hour plus process would work or could be trusted. I therefore now recycled that media. Grooming appears to remain particularly fragile in Retrospect 8. And it takes so very much longer than the version 7 under Windows. Fingers crossed this months update will fix this stuff!
  10. Been working fine for some time, but just started crashing as soon as it launches. If I start it and then launch the console, they communicate for a moment before the engine dies. The engine crashed whether I launch the console or not. The last thing I was aware the engine was doing was grooming a disk. I have restored the Config80 files from a backup and also reinstalled the engine. Neither of these has helped. I attached one of the crash logs. Any ideas? Many Thanks.
  11. dangermouse

    Grooming error -2260

    Thanks. I asked it to Rebuild, which took something like 18 hours. I then asked it to groom the set but when presented with the Groom/Cancel buttons it would not let me click Groom. That button would highlight but when I released the mouse button the highlight returned to Cancel. I looked in the Activities and saw another backup was in progress to another set. I waited for this to finish and then a new activity 'Retrieve Snapshot' or something appeared and this went through pulling in a whole history of snapshots. I assumed this was part of the groom? Or part of the Rebuild? Nothing said so but I waited. Eventually Retrospect crashed. I restarted the engine and the console, there were no activities listed and all sorts where missing. I waited a while before restarting both again. This time everything was back to normal. I then tried to unlock the media set so I could groom it. It would not unlock. No error messages or anything, just no response. I looked at the catalogue file on disk and saw it was 18GB. I was expecting 500MB or so. It's normally compressed, was this just big because it was uncompressed? I have now asked it to rebuild the set again. Look forward to seeing the outcome tomorrow, I guess. Begin rant, look away now! Often, the interface does not say what's going on. I think it often appears to ignore requests when it's busy doing something else and only when finished does it update the activity list, instead of putting your request in as a pending entry. Plus the apparent ignoring of the Groom button is very misleading an I've seen similar behaviour elsewhere. When I entered the password earlier, it said nothing about what might be wrong. I just tried entering a deliberately wrong password to unlock other sets, and sure enough there is no message to say why it hasn't unlocked. The combination of an uninformative or misleading UI plus no manuals makes this program very hard to get on with. Plus the fact it still can't get through 2 days work without my help makes this even worse. I'm not sure if the new release has fixed my need to restart the engine almost daily, but my impression is that it has not. It seems to me version 8 has been out long enough now that a lack of manuals is extraordinary. The remaining UI issues likewise. The UI sped up enormously in a recent release, which is very welcome, but I really think there should be no really basic issues by now. I cannot think of any other software with no manuals at release, never mind after all this time. I do refer to Windows 7.5 manuals as far as possible, but this only helps with general understandings. End rant. Thanks for reading. Hello?... Oh, OK.
  12. I think I have it, but would someone please verify or correct the following? 1. A file that still exists on the source is not groomed from the backup no matter how old it gets. Only files that are no longer on the source are ever groomed from the backup. 2. If you groom according to Retrospect policy, files removed from the source will hang around indefinitely on the backup and only be deleted as space is required. So if the disk is large relative to the data being backed up, files 'lost' from the source may well remain in the backup for quite some time. 3. Up until now I have Recycled disks when full. Grooming is better because it will only delete files as space requires and does the oldest first, so the window of opportunity for recovering a file is more consistent, whereas Recycle wipes all files whether 'lost' on the source ages ago or just yesterday. Having written it down, the answers look obvious. But I have learnt that, with backups in particular, assumptions and reliance on what seems obvious are very dangerous things! Thanks!
  13. dangermouse

    Grooming error -2260

    I tried to groom a disk (USB HD 1TB) and got the following error: Grooming Media Set failed, error -2260 ( can't groom disk Media Sets created with Retrospect 7.0 or earlier) This is with Retrospect 8 (.622 version) on a disk created with an earlier, perhaps first, version of 8. Is this a bug in .622 or just an inaccurate message and I'll never be able to groom this disk?
  14. dangermouse

    Release Notes for 622?

    more specifically, from the 'fixes' section of the release notes: 23215: Need to handle compressed files in Snow Leopard for restore I took it to mean this issue is addressed. I hope so as I just updated my scripts to include the entire HD instead of just the Users folder.
  15. Does this version, which I now installed, fix the Snow Leopard compressed files issue? Also, dragging and dropping the update (console) to applications gave me a permissions error. I dragged somewhere else instead, then copied the expanded folder over my original installation in Applications. Seems to work, was that ok?