Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About safreeds

  • Rank
    Occasional forum poster
  1. safreeds

    Error when loading Retrospect

    I am assuming that the machine has not been rebooted since the upgrade. If Retrospect hangs or crashes on launch then either the machine needs to be rebooted or the configuration file has become corrupt. I would start with a reboot. If the reboot still will not allow you to launch then the config file is having an issue and the only option is to restore an earlier version of the config file or start with a blank config. The config files can be found at C:\Documents and Settings\All Users\Application Data\Retrospect and the files are the config75.dat and config75.bak.
  2. safreeds

    Disk Full message

    If I understand correctly, you are attempting to copy a single file 17GB in size? Can you manually copy that file? How much free space do you have on the C: drive of the "retrospect server"? (I know it's an odd question but it makes a difference.)
  3. What operating system is this, what version of Retrospect and is this drive being disconnected to take off site?
  4. safreeds

    invisible files

    This is a Windows permission issue. You don't have access to view the files. You have verified that data exists in that location but you can't see it through the Explorer, most likely because it was created under a different user. You will need to go into the explorer and give your user access to the folder by changing its permissions.
  5. safreeds

    Still needing help with error code 1899

    My apologies but what Robin suggested is dead on, Retrospect 6.0 was never tested with SP3 (SP2 came out almost 6 years ago so it was tested). There is an additional problem though...unless you have created a slipstream image of WinXP with SP3 or you have an original hologram Windows XP with SP3 disk, you are not going to be able to create a disaster recovery CD. If you try to use the I386 folder from a WinXP SP2 disk you are going to end up with a disaster recovery disk for SP2 only. With SP3 I would suggest doing a live restore. That is, install the OS, update just the service pack to SP3 then run a full volume restore over the top of the existing OS.
  6. safreeds

    Any way to migrate restore points?

    You will have to create a new backup on the ReadyNAS. The Retrospect Restore Points backup folders are tied to the destination drive. If you moved them Retrospect would most likely not even see there was a backup in the new location. Sorry
  7. If you ever get a "Getting Started with Retrospect" message DO NOT enter your license code. Do not close Retrospect, yet Go to C:\Documents and Settings\All Users\Application Data\Retrospect and copy the Config75.bak file to your desktop Close Retropsect Delete the config75.dat file (it's corrupt) Rename the Config75.bak file on your desktop to Config75.dat Copy your Config75.dat file from the desktop to the afformentioned Retrospect folder Launch the application and all your settings will be back. When you enter your license code you normally overwrite the Config75.bak file. You can check to see if it has been overwritten by comparing the size of the .dat and .bak files. If you have a backup of the backup server itself you can simply restore the config files from your backup, close the application and drop the restored files in the ...\application data\retrospect folder. This config file corruption often occurs if the Retrospect server machine is forced to reboot during a backup (with automatic updates for example).
  8. I would create file backup sets. Each drive needs to have its own set. You can schedule Retrospect to write to a different backup set on each of your weeks Since each drive needs to have its own backup set when you write to Disk 2 it's going to do a "full" the first time then just write incremental data from there on out. Retrospect will simply write the changes that have happened since the Disk 1 set was last connected. I would suggest gauging how long you can run each drive before it gets full. As an example, let's say you have 500GB of data for your "full" backup. On subsequent incremental backups you back up ~10GB per day (just an example here). Given those numbers if you backup 5 days a week every other week you will fill the drive in approximately 4 months. (10GB/day x 10 (days a month since you are only backing up each drive 2 weeks out of the month) + 100 GB). Your numbers will vary but you get the general idea. Once you know how much you need to backup and how big your daily backups are going to be you could schedule a recycle to happen before the drive becomes full. In the above example you could schedule a recycle to happen every other month to each of the drives and you wouldn't run out of space. Hope this helps
  9. I am sorry that I don't know how to force the drives to always share Z:, however: Retrospect only looks at the drive letter as a secondary verification. When the application is launched and told to do a backup it is going to look for the storage location with the proper disk label (name of the drive) then verify that the Retrospect folder structure exists on that drive. Given that...drive letter should be irrelevant.
  10. Do you have just one flash drive or are you using several different flash drives with the same name and drive letter?
  11. Are you certain the new disk you have installed in the machine is formatted as NTFS and can be seen in the bios?
  12. safreeds

    Error 102

    I am going to assume two things, if this is incorrect, let me know. 1) I assume this is a disk backup set and 2) The catalog file is stored on your local machine and NOT the NAS drive. If both of those are true: I would suggest doing a full catalog rebuild. Go to Tools Repair Catalog Recreate from disks Select All Disks Click Advanced in the browse window then type the UNC path to where the Retrospect folder resides (eg \\iomeganas\public or \\\public) The backup set name should appear, you simply highlight the name and click OK Retrospect will ask if there are any other disks in this backup set, normally the answer is no Retrospect will then tell you a backup set with this name already exists do you want to replace it, you click Ok (or yes I don't remember which button appears there) Then simply click "Save"
  13. The behavior you're seeing in Retrospect is expected. Here's the breakdown of how Retrospect runs on a Vista or Server 2008 box: Because the application is an application AND it runs as SYSTEM or a specified user AND it is not a service, Vista (and 2008) will assume the program needs to run in the protected desktop environment. Call this an incompatibility or whatever you like it is how the operating system treats the application. This behavior only happens during an automatic launch. If one were to open Retrospect and minimize the application to the task bar one could get access to the application and all its tasks at any time. I am currently running Windows 7 on my main machine and minimizing Retrospect (it's just an icon in Win7) means that Retrospect still automatically launch scripts but I still have access to the entire application. Hope that helps.
  14. A restore entire volume will, in fact, remove anything that is not in the snapshot from the drive. I think the problem here may be that at some point (most likely before you created your selector) you backed up the entire C:\ drive including the I386 directory. If you backed it up once it will almost never backup again as it's a static directory. It will therefore appear in any subsequent restore of the entire drive. The only way to test if the selector is working correctly would be to backup to a new backup set with the selector on then immediately check to see if the I386 directory is missing. *Note: I made a couple of assumptions here that may be incorrect based on users I've helped in the past.
  15. safreeds

    Assertion Failure st module.cpp-560

    Just as a heads-up 7.5.387 is not a good version of Retrospect to be using. I would recommend going to 7.5.508 or 7.6.111. Specifically regarding your question: 1) After replacing the config file with a previously working one, are you still getting the same assertion failure? 2) When does the assertion failure happen? At program launch? When backing up a certain client?