Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


DaveD last won the day on July 27

DaveD had the most liked content!

Profile Information

  • Gender
  • Location
    Central Virginia, USA

DaveD's Achievements


Rookie (2/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges



  1. As (hopefully) a final entry in this thread, a couple things: Nigel mentioned making a new script and a "Preview" option. Yes, I found that this does exist when making a new script, but not on an existing script. I chose not to make a new script on the cloud backup because the script and backup set definitions are complex. In any case, it worked somewhat properly, but not totally. Where Retrospect weekly backs up 2-3GB to the cloud, the backup I finally did yesterday backed up 50-something GB out of total backup selection size of ~180 GB. I don't know why it didn't backup either the whole 180GB or, as normal, 2-3GB, but I will settle for that. As for the local backup, after redefining the backup source disk as the real system disk (C:), it did indeed backup only changed data as it usually does. I also found that the local backup from the wrong disk (the old C drive, now the E:) can be "forgotten" and Retrospect will groom it out of the backup set. That is a nice feature and a good way to recover from an "oops"! ...Or, I believe it is a nice feature. Retrospect is as I write grooming an "oops" from last night, the first incremental to my USB drive after swapping the offsite and onsite disks, which I do every few weeks. Again, I forgot to redefine the backup source when I brought the second drive in. But grooming the bad backup from last night is taking a while so I don't know how successful it's going to be.
  2. Nigel, the only "Advanced mode" I find is in the Backup Wizard; I use that mode, and the only option there is a check mark icon at the top of the screen that has Retrospect inform me about whether the script appears valid or not. While there, I can also check media. This gives me no indication as to which or how many files will be selected. Am I missing something? Note that I simply redefined the source volume as "C:", checked my selectors, and ran it manually. It did indeed work as we thought it should, doing an incremental backup in the same manner that it did in the old drive. So yes, it works as it should once the source volume is redefined.
  3. Unless I get a more definitive answer I will have to try a manual version of the nightly backup. This backup, to a local USB drive, doesn't matter so much space-wise, as the 4TB backup disk has enough open space to hold the 500GB or so that a full backup will take. But Retrospect does an incremental backup of only my data to cloud storage, approximately 180GB, every Thursday night. That incremental backup normally consists weekly of 3-4GB, but if it backs up all the data would take many hours and exceed my allocated bandwidth. So I must be sure! Any additional thoughts?
  4. Thanks Lennart. I got it working by uninstalling Retrospect, downloading the archive copy again, and reinstalling. I suspect that the cause of the problem was that I had not downloaded the correct version; perhaps I had downloaded a non-USA version. In any case it is working now.
  5. I changed the laptop account to the same as the desktop. This did not help. Someone, please. I've got to get the laptop back in operation. I have a recent Retrospect backup that I can't get to.
  6. I had to reimage the C drive on my Windows 10 laptop yesterday and after doing so installed the version of Retrospect Desktop I am using. The first step after installing the zip file is to enter the license code in the "Getting Started with Retrospect" window, which I did, many times--upper case, lower case, dashes, no dashes. It always returns the message "Sorry, that code failed. (needs code for Retrospect Desktop or similar application)". I even checked for an upgrade to 18 on the Retrospect website from the desktop by entering this license code, and it is valid. Could this rejection be caused by my use of a different account ID on the laptop versus the desktop (.outlook on the laptop, .gmail on the desktop)? If so, how do I make it work? I need to restore the system to this laptop quickly and move on.
  7. Retrospect, Windows 10 desktop. I replaced my out-of-space C SSD drive yesterday with a new one and used Samsung's cloning software to duplicate the old drive to the new. That appeared to work flawlessly, but when Retrospect did its nightly incremental backup, it went to the E drive where the old SSD now resides instead of the new C and, thankfully, backed up nothing. I can redefine the backup script to go to the new C drive, but I'm concerned that it will do a full backup first time through, and I would rather that didn't happen--I would like to continue doing incremental BUs, since the new drive appears to be identical to the old except for drive ID, or whatever it is that causes Retrospect to follow the physical drive regardless of the drive letter it currently has. What will happen when I redefine the source drive on the script? And if it will by default do a full backup, any way I can change that? Or must I settle for a full BU?
  8. I just upgraded to Retrospect 8, but I believe this problem existed in 7.7 also. I would like to use Firefox instead of Internet Explorer when I access online sites from Retrospect. Firefox is the default browser on my XP system. What can I do to make Firefox the default browser from Retrospect? Thanks, DD
  9. John, thanks for your response. You answered my questions, and well. I will now plan to go to disk backups, starting with the next recycle. Then I'll play with it a bit to further satisfy myself that that type of backup is at least as save as a file backup, including after grooming. I may even update to the latest Version 8, although I'm not sure that there is much in the way of enhancements over 7.7 in this area. DaveD
  10. Thanks for the reply, Jim. Your insight and experiences are helpful, but you really didn't answer my questions. I'm sure a member of this community must have the experience that would enable him or her to answer these questions. How about Retrospect support? I believe the differences between and confusion about FILE vs. DISK backups, as is evident by other threads in this forum, is worth a comprehensive answer. This is the type of subject that used to result in the generation of a "white paper" (when that term was in vogue). I'm a bit afraid of moving forward to DISK backups until I feel that my backups are safe and complete, especially when culling parts of them with the groom option. Thanks, DaveD
  11. Environment: Desktop with Win XP Pro SP3, Retrospect Pro 7.7.620, nightly local FILE backup to USB drive, two 1TB BU drives with one off-site, swapped regularly. I recycle the BU sets when the BU disks fill up, approximately once a year. This Retrospect BU strategy has worked well for at least 10 years now, with successful file recovery many times and system recovery twice. I had previously stayed away from DISK backups, but don't remember why (perhaps support of DISK backups in earlier versions wasn't that robust?), and I understand that over the last several years the whole concept and support of DISK backup sets has improved, so now that type of backup is recommended over a FILE backup, even with my 7.7 level. Perhaps I'm sort of stuck in the past and need to rethink this FILE vs. DISK strategy. That concern really came to my attention a few weeks ago when my on-site backup, then several hundered gigabytes in size, became corrupted for unknown reasons. It was not recoverable; I had to recyle it and start over. I just started using a DISK backup for my new laptop, and notice that it consists of many files instead of a single large file with the FILE backup. I suppose that is what makes it groomable? So I am strongly considering going to a DISK backup strategy for my desktop. But I have a few questions that I haven't been able to answer through Retrospect support of this forum. 1. In the instance above, would I have potentially avoided the corruption of my entire backup if it were a DISK backup? Losing one or more of these smaller backup file would have cost me what? 2. In my environment, is one backup type fundamentally more desirable than the other? Advantages/disadvantages of each? 3. The "grooming" concept is a bit difficult for me to understand, not having done it. When I groom, will I still have a complete system backup to restore from, a backup that is simply missing some of the sessions, or nightly backups, in the larger backup? Or will I have to exercise caution when I groom to make sure that I am not ending up with a partial backup, one that would not allow me to do a full system restore to, say, last night's image? Thanks, Dave D
  12. In my opinion, the fact that I am running an older level of Quicken, still supported by the operating system, doesn’t mean that Retrospect support should conveniently choose to ignore my problem, as appears to be the case here. I believe that Retrospect support should be assisting with any application problem that results from a backup made by a supported version of Retrospect. But once support learned that I am running an older level of Quicken, this thread went silent and I had to solve the problem myself. Just in case anyone cares and would like to know just how this (apparently) works, I am appending the results of my experience here. I believe that earlier versions of Retrospect provided an option to not reset the archive attribute, but it isn’t clear that this could have been the case because, as I stated in an earlier append, if the user chooses to back up file security information (in an NTFS environment), Retrospect must interrogate the state of the archive attribute to determine whether file security information has changed. In any case, when I did my upgrade from Retrospect 7.0 to 7.7 several days ago, my ability to verify the options regarding that attribute on the earlier release were gone forever, so I cannot tell for sure. But in the event the user has selected the option to back up file security information, it is clear that in order to not uselessly back up information that hasn’t changed, Retrospect must turn off the archive attribute once the backup has been made. So what changed when I moved to 7.7? The upgrade retained all of my existing automation, including my backup scripts. Was my problem rooted in the selection, on my backup scripts, of the option to back up file security information and, if so, did the upgrade process turn on this option in error or did I perhaps, without later remembering the action, change that option myself after the upgrade was complete? In any case, repairing Quicken and turning off this option solved the problem—Quicken is now working properly after doing normal Quicken updates and a couple nights of Retrospect backups. Retrospect is also no longer turning off any archive attributes. But as I mentioned above I had to repair Quicken for it to work properly. This consisted of restoring the entire QUICKENW Program Files directory and its subdirectories from the last backup I had made pre-7.7. Only then did the customizing—screen make-ups, financial and retirement planning—and other Quicken functions return to pre-7.7 backup settings. So even though there were no changes to any of the files in the Quicken directories (it also makes use of many .ini files and none of those were changed either), the Quicken operational characteristics were drastically altered after the 7.7 backup, and restored when I restored the pre-7.7 environment. This did not include restoring the Quicken data files themselves, as I had done that earlier (and turned on the archive flags), allowing Quicken to run but not restoring the earlier operational environment. I can only conclude that Quicken makes use somehow of the NTFS directory structure to store information about its operational environment, and that information is altered by a Retrospect backup, especially when Retrospect is told to back up file security information. Can that be so? So I ordered the latest Quicken 2010 and will go through the time and effort to upgrade, even though Quicken 2001 gives me everything I need. It has to be done eventually, and hopefully Quicken will have fixed its archaic file structure. But I wouldn’t bet on it, and I’m not looking forward to the potential upgrade hassle. All this is not to imply that Retrospect has a code defect and that is isn’t working as it should be. My problem is that the Retrospect help files and user documentation aren’t nearly as up to date as the Retrospect software is, and along with the fact that it doesn’t get as deeply as it should for a professional version of a product (many small enterprises bet their life on backup software like Retrospect and need detail), it can be confusing and misleading. Retrospect support should be making up the difference between current code and current documentation, and at least providing additional in-depth information as needed. Ignoring the problem doesn’t make for happy customers. My experience after forty plus years in the information technology industry is that many customers have no choice but to run what we called (several years ago when I retired) “legacy†applications, and these applications, just like everything else in their enterprise, are central to their business and to their survival. The backup and restore of those legacy applications by Retrospect needs to be as vigorously supported as the rest of the mix of software that Retrospect touches. DaveD
  13. Sorry, wrong product. This is Quicken 2001. I know, it's really old, but it does the job well and, as you can see, upgrading software is not without its challenges. My wife is the exclusive user of Quicken and, even more than I, doesn't like change and the hassle that often comes with change. So we stay there until forced to move forward by loss of operating system support. Regarding the previous post, the question about backing up the workstation's file security information still applies. I don't have to back that up; I can turn that option off. But I would do so only if Retrospect then leaves the archive flag alone. DaveD
  14. Just upgraded to 7.7 and that maintenance level last week. Previous release was last maintenance to 7.0, and I didn't have this problem. It may be that I was able to tell 7.0 to not turn off the archive bit, or maybe it left it on by default? Reading a bit more about this, it appears that Retrospect 7.7 turns off the archive bit for at least one valid reason, that being to tell whether, if the option is enabled, it needs to back up a workstation's NTFS file security information, as Win XP will turn the archive bit on whenever the file security information is changed. If I am digesting this correctly, would it then _not_ mess with the archive flag if I _don't_ tell it to back up the workstation NTFS file security information (this option is off by default)?? Make sense? DaveD
  • Create New...