Jump to content

dan.jordan

Members
  • Content count

    47
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by dan.jordan

  1. Am I correct that there is no way to see what backup data is on a particular tape in a tape set? I would like to mark as "missing" a couple tapes at the end of the backup set (though they aren't really missing), but I don't know where the last backup ends that I want to keep on the tape set. Dan J
  2. Thanks, guys. Now to my next challenge: to find out why I'm still marked here as a "newbie" even though we've been using Retrospect since the days it was an EMC product...
  3. We inadvertently appended a backup to those tapes that should have gone to a different backup set. The tapes it used to do that I wanted to free up again, but can't tell which tape the incorrect job started on. No quick, easy way to tell, evidently. Thanks.
  4. I second what Lennart said. We live in both the Restrospect and Rapid Recovery worlds. Particularly when the system is capable of bare metal restores, one of the best things that ever happened to us was the fact that Rapid Recovery does not allow the admin to pick and choose any files to include or omit; that is just too big an opening for human error. You must back up all files on a volume, or none. Yes, it will require more backup disk capacity but that is the trade-off for the extra insurance against human error that this affords. And as most of us who have been in this business awhile know, human error needs no invitation, it walks in and tries to wreak havoc whenever it gets the chance.
  5. The forum has showed me as a "newbie" since we became a Retrospect customer in 2008. What's it take to no longer be called a newbie?

  6. The following sentence in this link may explain what you observed: "When transferring snapshots or backup sets containing block level incremental backups of a file, the complete chain of prior increments leading to and including the full version of that file is automatically transferred."
  7. Does anyone know how long a wait there may be after a bare metal restore reaches 100% before the screen indicates the job is complete? After a half hour the *Stop* button is still enabled but I'm afraid to click it. The device to which I am restoring is a Surface Pro 3 with Windows 8.1. There's also a *Finish* button on the client (Retrospect BMR Boot CD program) but I'm not sure I should click that in order for the Retrospect restore to finish... Dan
  8. dan.jordan

    Bare metal restore at 100% but appears hung

    The screen did come to life a couple more times and then finished successfully. I was able to successfully boot the Surface Pro 3 thereafter. Nice.
  9. dan.jordan

    Bare metal restore at 100% but appears hung

    Lennart, So it sounds like I definitely want to keep my hands off the Stop button and just let the Restore Wizard finish those two steps. Thanks, Lennart.
  10. The performance hit is on the defrag software, not Retrospect. Microsoft defrag want 15% free space to do its thing, Auslogics wants 10% free space. Otherwise they suggest not running them until that amount of space is available. Ultradefrag, at some point, will have the same problem, as indicated under General Usage in their FAQ.
  11. The reason for wanting to do this is its a handy way (compared to rearranging things via Retrospect) to free up space on a disk that has become too full for defrag to run, for instance. The correct, longer term solution is of course to allocate space to Retrospect in such a way that there's *always* available space on the volume. I had failed to do so in the case of the one disk volume. My testing confirms your suspicion that this won't work. The rebuild announces that the first volume of the two volume backup set is either corrupt or is from another set, and kicks it out of the set. Ah, well. it's something I've wondered about for years. Next time I'll just transfer the backup set to a new backup set in which space has been properly allocated. Thanks for your response, Lennart. You've been a valuable member of the newsgroup.
  12. A related question: If I have a backup set spread across two drives can I move, say, the last 5 RDB files from the first drive in the backup set to the 2nd drive in the backup set and then do a rebuild? (Note: I've have learning that this technique won't work if you take RDB files from the middle of the first drive in the backup set and move them to the 2nd drive in the backup set. Rebuild doesn't like that.)
  13. You're not alone. Our response to this Retrospect shortcoming is to backup our large collection of PST files only once a week and to only retain the two most recent of those weekly backups. The bottom line is that Retrospect is poorly suited for large files in which only a few bytes change from day to day. Restated, Retrospect needs modern deduplication capability but I doubt that lies in the near future, given that we've hoped for deduplication capability for the six or eight years we've used this product but it hasn't happened.
  14. dan.jordan

    Volume restore

    Caution: We have found USB drives to be bad news when used in association with Retrospect.
  15. Years ago we had bad luck doing Retrospect backups to servers across the network. The suggestion by tech support was that our network was not "robust", though they couldn't tell us in what way it was not robust. Our solution was to stopping backup up to targets across the network from Retrospect. I suspect that what is not robust is Retrospect's ability to compensate for network slow-downs, etc. that may normally occur across networks? If you do not have similar problems backing up to disks on the Retrospect server itself then maybe similar causes are afflicting you?
  16. I agree w/Lennart's response but with a clarification: In my experience the data in the backup set doesn't often become corrupted, and if it does it's a relatively small portion that does. The catalog file that indexes that data, however, becomes corrupt more often. Mercifully, that has become less of a problem than in earlier versions of Retrospect, but we have had to rebuild one or two catalog files this year. Tech support can never explain why these corruptions occur; they just tell us to run the catalog rebuild tool. My experience suggests that if the backup set is on some other server than the Retrospect server then corrupt catalog files become much more likely. Proceed with much caution when considering that scenario, even though the user manual makes it sound like putting backup sets across the network is a completely acceptable thing to do. Maybe the latest versions of Retrospect are more robust in that regard, I'm just not willing to go to the pain of finding out.
  17. According to Retrospect tech support (during our conversations with them over the last several years) you definitely may need multiple media sets. Though there is nothing to be found in the (aging) Retrospect user manuals about backup set size limitations, tech support has indicated rough guidelines to us as follows: Be aware that the bigger you allow your backup sets to become then the bigger your headache should you find you want to do, for instance, some of the following: rebuild catalogs -- the bigger the catalog is the longer it'll take to rebuild -- this can mean several addition hours *or days* for a rebuild to complete. manually deleting snapshots from a backup set may take significantly longer, the bigger the backup set (and associated catalog) Although tech support has told us a backup set can get to the vicinity of 12 million files before it starts to run into problems they have actually recommended keeping the count below 7 or 8 million. We, accordingly, aim to keep the count below 3 or 4 million, thus we have several more backups sets than we otherwise would want. By the same token we limit the size, in gigabytes, of our backup sets. Should you want to move some but not all your backup data to a different physical disk you have a bigger job in front of you if your backup sets are not broken into smaller, more manageable sizes. I suspect catalog files are more susceptible to corruption the bigger they are. We would love to be able to backup our data to larger, fewer backup sets; Retrospect management becomes much more complicated if you're having to have more backup sets than what your needs dictate; but experience, certain limitations of Retrospect, and informal recommendations from tech support have taught us that fewer, bigger backup sets is the path to madness.
  18. Per this link it appears to be qualified for Retrospect use. You might look for a similar doc regarding windows 7.
  19. dan.jordan

    Moved files - can use the same Backup Set?

    A tip you may find useful: When you wish to see how Retrospect is going to handle files that you think are matching files I think you can create an "Immediate Backup" (under Backup on the left columnar menu bar). It has a "preview" function whose results will tell you which files/folders it is going to backup and which ones don't need to be backed up because they are already in the backup set. Play with that a bit and see if you agree. As you test don't be surprised if your results are confusing -- in past tests I've done it really wasn't always clear what logic Retrospect is using to determine if two files -- that you are certain *do* match -- were considered a match by Retrospect.
  20. dan.jordan

    Automatic increse disk

    Retrospect will not automatically add disks (e.g. "members") to a backup set, and it won't go beyond the % you've specified as available from each member for Retrospect to use -- even if there is more available space on that member. Grooming: if you have specified you want to retain, say, 20 snapshots then Retrospect will retain 20 snapshots (see Snapshots tab when viewing backup set properties) if you've allocated enough space for it to do so. These are your "active" snapshots. It will also retain a number of snapshots beyond what you've specified you want retained --- again, *if* you've allocated enough space for it to do so (see the Snapshots tab, and then the Add button, to see those additional, "inactive" snapshots). In other words it doesn't groom out inactive snapshots if there's space for them. If Retrospect detects space is getting tight then it will start automatically grooming out the inactive snapshots as needed. It will not groom out active snapshots; it'll just quit taking any more data and hopefully pop up a message that it needs more space. When viewing the Members tab in snapshot properties it tells you how much space is "free" (in GB and in %). What I don't know is if that figure includes the inactive snapshots along with the, in this example, 20 active snapshots.
  21. I'm not familiar with the "autoaddedgroup" function. What I do know is that when a backup "source group" gets created tech support has instructed me to delete the "source groups container" object that will show in that new source group. I am accustomed to creating Source Groups and then manually dragging Subvolumes I've created from the Backup Clients higher up in the Volumes Database window to the Source Group(s) I want it in. I have generally not had the "ASAP" problem with this practice. I dunno if this helps you but I'm throwing it in.
  22. dan.jordan

    Cannot Connect to Client

    Try pulling the client since the push-upgrade isn't working. From the client PC you need to either load the 8.2 CD/DVD and run the client install from there or drill down to wherever you have the 8.2 client install files downloaded. So I recommend (1) uninstalling the current client, (2) rebooting the client, (3) delete the client from Retrospect ( Configure/Clients), (4) install the 8.2 client, then (5) make Restrospect aware of the client (Configure/Clients/Add). (6) See if things are talking they way they should, now. I went through similar motions on a few clients during our upgrade from 8.0 to 8.1.
  23. The boot question aside, we have found the use of Western Digital MyBook) USB drives with Retrospect to be terribly unreliable. We're still doing it a bit but recommend against it.
  24. dan.jordan

    Delete multiple snapshots simultaneously

    The last post to this thread is almost a year old but I'll pipe up long enough to say that in the nearly year since then this capability hasn't made it off the feature list. I've been requesting this change for six or eight years (since whenever this thing was owned by EMC). Sowen222, your final sentence has pretty much been my position for years, but how long does a guy have to wait for an appreciable improvement to the basic product in return for the years of renewing the maintenance and support contract? The product has been out of Roxio's hands for, what, three years now, and still no evolution I can discern in the meat and potatoes functionality of this product. Sure, support for virtual is nice, but I'm still stuck without an efficient, practical way to do manual grooming of multiple snapshots in a manner that is sane. Fortunately the boss has approved our getting into Microsoft DPM 2012 (we presently divide backups between DPM 2007 and Retrospect). My eye is on the prize of migrating our Retrospect stuff into the big, new DPM 2012 server we'll soon be acquiring. This particular donkey is about done chasing after the Retrospect carrot. It's a shame, too: the base product is good.
×