Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About gosub

  • Rank
    Occasional Forum Poster
  1. gosub

    Upgrading 7.0.249 --> 7.5

    Quote: "I did search the forums. Assume things much?" Ok, I went and un-installed my current retrospect, installed 7.0.249 as you can see here. I also created some scripts. I then installed the 7.5.508, the scripts were still in the manage scripts tab. Once I changed my time from AM to PM( i accidentally set the scripts to the wrong time ) They ran correctly. I hope this can help you in some way. I don't see any official documentation on this, so i figured I would give it a try and see how it turns out. Hi Jeff, I can't even begin to say how much I appreciate your amazing feedback. Seriously... it's absolutely fantastic that you took the time to run through and document the process as a specific answer to my post and questions. Thank you SO much for making that effort. As I said in my post to Russ above, I wasn't trying to be a jerk in my earlier posts, I just wanted to try and cut through it all and see if I could get some solid feedback on the issue. And you made the effort to provide that solid feedback, so I thank you again. Looks like I'll be performing the upgrade at some point tihs week, and I'll post back here my experience. Thanks again, Jeff, for making the effort you did. Just wanted you to know I appreciate it. Finally, I agree with Russ' comment above that this is exactly the type of information that needs to be documented somewhere. Certainly it'd be nice if it were in the included produce docs, but at the very least, compile it together as a sticky in the forums. Thanks again!
  2. gosub

    Upgrading 7.0.249 --> 7.5

    Quote: gosub, I'm not an EMC employee, never have been, so, of course, I can't state anything official. And I have not done the specific version-to-version upgrade that you are trying to do. I have, though, been using Retrospect since 1992, and the Read Me documents for each upgrade have always addressed the upgrade issues of which I needed to be aware, although I have sometimes seen (and reported) bugs in the new version. I have several times seen the issue that earlier backup sets become locked and unwritable (but still readable), and I've seen a few times the "required catalog rebuild" issue. Grumble. But I've never had a script or settings become unusable. Perhaps my scripts are simple, but we do have a server and a network of client computers. Not that this helps your particular concerns, and I wasn't trying to blow you off, just trying to be helpful. Candidly, I never trust anyone's upgrades/updates for our server, and I always do a "RAID 1 mirror image split" (with all services off, so that the databases are consistent) just prior to doing any upgrades/updates to our server, just in case things go badly (and they have, rarely; never with Retrospect, though). And I always test thoroughly before deploying the server back into production. Russ Hi Russ, I'm a long time on-and-off-again Retrospect user from my early 90s Macintosh days as well. I have such fond memories of the early Retrospect solution that I used to back up my servers and network, back when the phrase "Information Technology" wasn't even born. Good to see another old timer. :-) I appreciate your honest and clear feedback. I wasn't trying to be a jerk in my earlier posts, I just have been striving to cut to the heart of the matter and get some answers. Thanks again for your feedback!
  3. gosub

    Upgrading 7.0.249 --> 7.5

    Quote: Search the forums a bit next time. This user who made this thread practically asks the same thing. http://forums.dantz.com/ubbthreads/showf...true#Post106428 -jeff I did search the forums. Assume things much? I read that thread earlier, but there's no real confirmation in there about the upgrade process. The OP asks pretty much the same thing I'm asking, but there's no real confirmation one way or the other about rebuilding scripts/config. In that thread, "rhwalker" implies that scripts/config don't need to be rebuilt, but he links to the ReadMe for proof like everyone else, but nothing in that ReadMe clearly states that I won't have to rebuild everything. Plus, the OP talks about moving a file around to get it working, but there is no confirmation from anyone that moving the file is actually required, and beyond that, it hardly seems like a best-practice recommendation. Again, I have read NOTHING that explicitly states I won't have to rebuild my scripts and config after I run the update. I see a great deal of dancing around the issue and people pointing to the ReadMe file, but again, there's nothing that explicitly states one way or the other. What I'm asking for is the recommended upgrade process that other 7.0 --> 7.5 upgraders have followed. Is there an official recommendation somewhere, because I'm not eager to run the process and find that I have to spend hours rebuilding everything.
  4. gosub

    Upgrading 7.0.249 --> 7.5

    Quote: Everything is covered in the Retrospect 7.5 Read Me: http://kb.dantz.com/article.asp?article=8331&p=2 Study it carefully. I've already read through that and found nothing in there to answer my questions. The only useful blurb I found was this... Quote: Upgrading from a Previous Version of Retrospect Older Backup Sets: If you are an upgrade customer, you can use your older Backup Sets with Retrospect 7.5. However, once you use a Backup Set with Retrospect 7.5, you can no longer access it from earlier versions of Retrospect. See Tips and Late-Breaking Information for information about grooming disk Backup Sets created with Retrospect 7.0 or earlier. Upgrading from versions of Retrospect prior to 6.5: Upgrades from versions prior to Retrospect 6.5 are not supported. Uninstall the previous version of Retrospect, then install Retrospect 7.5. Your configuration information will be lost. But none of the above tells me whether or not I can install the 7.5 upgrade over my existing 7.0 install, whether or not I have to recreate my scripts, etc. I've read through it several times. Is there something I'm missing?
  5. gosub

    7.5 Client Licenses with 7.0 Pro Application?

    Quote: Hello; Here's an easy question. I have retrospect 7.0 professional (windows) and want to add a couple of client licenses to it. Can I buy the 7.5 licenses and have them work with the 7.0 application? Thanks, Steve If I'm understanding your question correctly, yes, you can run the 7.5 client with the 7.0 application. I'm doing that right now. Hope this helps!
  6. gosub

    Upgrading 7.0.249 --> 7.5

    Hey folks, I've been reading through the forums, and while I hate to create another "upgrade" post, I need to make sure I'm clear on the upgrade process before I begin. If there's info posted that will answer my questions below, please link me to it. I'm running Pro v7.0.249 on WinXP Pro SP2 (fully updated), that backs up the local XP machine as well as two network computers (v7.5.116 client). I have purchased and received the 7.5 update. What's the best way to perform the actual upgrade? Can I upgrade v7.0 in place? If so, will I need to recreate my scripts, reset prefs and everything? I've read conflicting info on whether or not I have to first uninstall v7.0 before installing the v7.5 upgrade. I assume I should immediately apply the most recent .508 patch, yes? Thanks in advance for your feedback!
  7. Quote: Quote: So what you are saying is that automated backups are out of the question under Vista. I never said this. I said the opposite of this. If Retrospect is manually launched, ALL automatic Backups will happen at the scheduled time and complete as expected. You are overreacting to the issue. Retrospect runs as the System Account. Microsoft made a major change to how user accounts work in Vista. This means that when a program wants to run as "another user" or as "system account", the currently logged in user can't see anything running under the "other" account. This is an unfortunate change made by Microsoft, and we can't easily workaround the fundamental change to how Windows works until the Retrospect engine is separated from the interface. If you are unhappy with this behavior or the workaround I have offered, then I would suggest backing up this computer as a client and running Retrospect on XP or any other version of Windows which uses the traditional user account methods. First off, I don't believe creagin is overreacting at all. This is a major functional shift that, had I known about, I wouldn't have spent the money on the Vista upgrade. I use this software in a home/office environment, with Retrospect running on and backing up my machine and two others. I am unwilling to keep Retrospect running in the background so my automated backups run properly. I also can't run this software from any of the other network machines, nor do I have an XP box I can dedicate to the effort. That being said, you never addressed creagin's curiosity about possible development to deal with the issue, other than to say it's difficult. Are you indeed working on, or at least planning to work on, separating the engine from the interface? I'm in the same boat as creagin: if a true solution isn't going to be offered, then I'd like to know that so I move to another product. I realize EMC doesn't want to lose customers, and I would prefer to remain a customer, but I've been a Retrospect user since 1995 and would appreciate a certain amount of respect and honesty when it comes to a situation like this.
  8. gosub

    Catalog backup?

    Hi Ken, I realize I'm a bit late to the party on this one, but as mentioned above, regardless of whether you backup to disk or tape, it's very simple to tell Retrospect to automatically store the catalog file wherever you want. That way you don't have to bother with setting up a second script to duplicate the catalog file. I backup my data to an external drive and store the catalog right there on the same drive. Piece of cake. You specify where to store the catalog file during the backup set creation process. Here's a screenshot from Retrospect Pro v7.0... Hope this helps! -Stever
  9. gosub

    scheduled backups not working

    I think I get it now. I just wish I knew how the red (x) got enabled in the first place. Maybe I did click it. Who knows. My script is working fine now, so I'm happy. I do think it would be nice if these activities were logged for future reference. Regardless, thanks so much for your help!
  10. gosub

    scheduled backups not working

    I'm trying to understand the way this functionality is supposed to work. Is that button separate from the "skip" checkbox in the script setup? Does that button get enabled when "skip" is enabled? If so, why doesn't the button get disabled when "skip" is disabled. I guess I'm confused about how this is all supposed to work. Since all I had to do was enable the "skip" check box to skip scheduled executions, I expected that all I had to do was clear that checkbox to re-enable executions, but that wasn't working. I'm 99.999% sure I did NOT manually click that red (x) on the toolbar to enable it. Unless I was clicking around and accidentally did it, I'm pretty sure I didn't. So, if we assume I didn't, how else would that red (x) get enabled? See, now I'm sitting here testing, and when I manually click to enable the red (x), it tells me it's going to defer scheduled executions. That's great, but when I go into the script, it doesn't say "deferred" like it did before under the schedule. I don't understand how all of this is supposed to interact. It's like I had two different things going on. Basically, I had originally enabled the "skip" function inside the script, and under the schedule it said 'deferred'. Problem was, I could never get that cleared. I would go into the script, clear the check and ok/apply out, but when I'd go back in, under the schedule it still said 'deferred', only that check box was cleared. All along, I never noticed that red (x) was enabled on the toolbar until reading this thread, so when I disabled that, my script ran and now 'deferred' is gone from the schedule. Ugh. I don't mean to be difficult about this, I'm just concerned that, since I don't understand how this is supposed to work, I'll somehow manage to disable my script again. All the above being said, how should I be disabling a script on a temporary basis? Is the red (x) the manual way to do it? Is the "skip" checkbox meant to be a way of disabling a script but then have it automatically renable at a specific date? If that's the way it is, I guess that's where I'm confused because my script never re-enabled itself (I only set the skip for like a week but it wouldn't run for a month) and it wouldn't clear itself up until I disabled the red (x). Thanks for your help!
  11. gosub

    scheduled backups not working

    Quote: Look for a litlle red (x) in Retro's menu bar and click (unselect) it. Sorry to hijack this thread, but what does that little red (x) do? Several weeks ago I set my only script to skip scheduled executions, and since then I haven't been able to get it to run automatically to save my life. I've gone in and cleared the "skip" checkbox multiple times, but everytime I go back in to view the script, it kept saying "deferred". No matter what I did, I couldn't change that. I ran across this thread, noticed that my little red (x) was enabled, and as soon as I click to disable, the script launched. Will my script now run normally or is there something else I need to look at? Thanks! Edit: FYI that the reason I'm asking about this is because I'm off-site, don't have the docs handy, and even though Retrospect generally shows pop-ups on mouse-over, I'm connected to my backup server remotely with RemoteAdmin, which doesn't let me see mouse-over pop-ups. Just wanted you to know I'm not being lazy about this.
  12. gosub

    Pro 7 & Grooming

    Okay, so let's say I create a new backup set without encryption so I can do grooming. My original question still stands... If I set it to keep the last 50 backups, when it starts deleting the oldest backups, will it leave the initial full/normal in place? Since the first normal is the "full", if that gets deleted, the following normals (incrementals) are fairly useless. Thanks for your help!
  13. gosub

    Pro 7 & Grooming

    There's no grooming at all when encryption is on? Can someone explain to me why that is, because it seems danged silly to me. Also, can someone point me to a place in the manual that clearly points this out, because I was going through the manual again last night and couldn't find anything. I can't believe I have to basically lose four months of backups because I have to reset the thing due to encryption.
  14. gosub

    Pro 7 & Grooming

    I ran a search here in the forum and found some good info on Grooming in Pro 7 but I need a bit more info. I have encryption enabled in Retrospect (7.0.249), so the only grooming options I have are to set the amount of disk space to use either in GB or as a percentage. I'd rather be able to set keep the last "n" backups, but I can live with the options I have. I've set my storage limit to 225GB on a 300GB external USB hard drive. What I don't understand is exactly how Retrospect will choose which data it will delete once it hits the storage limit. I'm about 30GB away from that threshold and should hit it in the next week or so of normal backups. What I'm hoping will happen is that Retrospect will look back at all the old "normal/incremental" backups and start deleting the oldest first, leaving the very first "normal/full" backup intact. If it deletes the very first "full" backup, that would seem to ruin the entire deal. I'm hoping it doesn't do what the built-in help says is Retrospect's defined policy... "Keep according to Retrospect's defined policy: When the backup drive fills up, Retrospect uses its own grooming policy to delete old backups. At a minimum, Retrospect's policy retains two backups for each source. Retrospect keeps the last backup of the day for each source from the two most recent days on which each source was backed up. If the disk has enough space available, Retrospect keeps a backup of each source for every day in the last week, a backup for each week in the last month, and a backup for each previous month." I'd appreciate any feedback you folks can give to help me understand what's going to be happening once I hit that storage limit in the next week or so. I absolutely do NOT want it do do what is stated above as Retrospect's defined policy. I want it to simply start deleting the oldest first (FIFO), leaving the very first "full" backup intact. Finally, in lieu of Retrospect's automatic grooming, can I manually go in and start deleting old backups myself to make space? I'm looking at the properties for the backup set right now and can't seem to be able to delete sessions. Thanks in advance for whatever help you can provide. -Stever
  15. gosub

    Retrospect 7 and the dreaded 519 error

    Hi Kevin, I'm new to Retrospect 7 but have been running the older versions for quite some time. Hopefully my comments can help. What time during the day does the remote computer get accessed by the script? Does the scripted backup of the remote machine ALWAYS fail? When the backup fails, at what times does it fail? Are these times close together or far apart? When you've run your manual backup successfully, is it at the same time during the day as the scripted backup? Have you run several manual backups of the remote machine to make sure it's not failing once in a while? What I'm wondering is, maybe there's something happening on the network at the time the script is running that futzes with the network backup. If you can consitantly run a manual backup of the remote machine at the time the script normally runs, then maybe that might indicate otherwise. But if you're running a manual backup at a time different than when the script is running, then maybe there is something going on at the time the script is running. I know this may sound crazy, but I once had a network admin who had, unbeknownst to me, set a router to bounce power every night at 2:00am for some reason or another, and that was killing a network backup going through that router. It took me forever to figure that out simply because only that admin knew about it and wasn't forthcoming with the info. That's a fairly extreme example of what might screw up a network backup, but then again, it never occurred to me at the time that it might be the cause of my problems either. Go figure. Hope this helps! -Stever