Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by twickland

  1. Click on Configure> Backup Sets> Configure....[name of backup set]> Members> to see the amount of data stored on each member.
  2. If there are a lot of members (tapes) in your backup set, you might consider an alternative and just copy and erase the members which contain the client's files. The catalog does not indicate which member contains a particular backup, so unless you have an extraordinary memory, you would need to identify the dates and times of backup of the files in question (easiest way to do this would be to run a mock Restore), and then compare this information with the date and time that data was first written to each backup set member (listed in Configure> Backup Sets> Configure...[name of backup set]> Members> ). Then, after you perform the Transfer, instead of forgetting the entire catalog of the old backup set, you would return to Configure> Backup Sets> and mark the copied tape members as "Missing" before erasing them.
  3. You cannot remove individual files from a tape. To fulfil the demands of your client, you would need to use Tools> Copy> Transfer> to transfer all other files from your old backup set to a new backup set. You will need two tape drives to accomplish this in one step. You can either define criteria for selecting files to be excluded from the transfer, or you can manually select the files before performing the transfer. Once you've done this, forget the catalog of your old backup set and erase the tape(s) that were members of the old set.
  4. "Lock Application" and "Run Unattended" both mean the same thing. I use both, and tend not to distinguish one term from the other. However, as Dave points out, the menu option "Lock Application" is available only when a script is not running. When a script has been launched, the option you want is "Run Unattended." Sorry for any confusion my too-quick reply may have caused.
  5. Quote: Then i tried to have a look at the volume snapshots and - THEY WERE EMPTY or had rather nothing than one or two folders. How are you looking at the volume snapshots? I was not aware that one could browse the snapshot contents in the Mac version of Retrospect. (If you could view the contents, each snapshot should list the entire directory of the volume at the time of backup.) Did you instead mean "sessions," as are found in Report> Contents> ? If so, these do indicate only the files backed up at a particular time. In a normal incremental backup, a session will only contain files that have changed AND that meet the selection criteria set for the backup script. That could be a small number of files. I would check and see if the selection criteria are what you intend. If you are using a defined Selector, you can test it independently in edit mode to see if it behaves as you expect. If you run an Immediate Backup using the same selection criteria, do you back up all the files you expect? What if you select "All Files" instead? If the behavior continues to be anomalous, it may mean that your Retro.Config file is corupt.
  6. Quote: Does retrospect support multiple drives under Server 6.0 for OS X? Yes. Until recently, we used 3 DDS tape drives on a SCSI bus (mostly) happily. Once, when we replaced the host adapter card (switching from Adaptec to ATTO), the new card would only see the first drive on the SCSI chain. This turned out to be due to corrupt firmware on the host adapter, which was solved when the card was repaired by ATTO. Be sure you have installed the latest Retrospect Driver Update for your OS and application versions.
  7. At what point do you get the error message and what exactly does it say? Also, what version of Retrospect are you using? (The current version is 6.0.204.) Some of the earlier versions of Retrospect 6 had problems with pre-6.0 backup sets While it's true that pre-6.0 catalogs are read-only, this should not preclude restoring from the associated backup set.
  8. You need to check two things: First, go to Special> Preferences> Run Control and be sure that the option "Stop on Errors" is not checked. Second, you need to be sure that the Retrospect app is running in unattended mode. You can tell this because the cursor changes to the moving checkerboard pattern. This should happen automatically with a scheduled script, but must be selected manually ("Lock Application" in the Run menu) when running an Immediate Duplicate.
  9. I'll assume you're performing an Immediate Duplicate. When the "Ready to Execute" window appears, click on "Selecting" and then "More Options." This will enable you to create the file selection criteria you need. Excluding the built-in Selector "Music" will probably do the trick for you. You could also exclude the specific name (or pathname, if more than one folder has the same name) of the unwanted tunes folder.
  10. You should be using Retrospect 6.0.212 and Driver Update 6.4.102 on your backup server with Tiger. When I said "local hard drive" I meant your internal drive. That suggestion was to enable you to use another piece of hardware instead of your FW drive. However, if you indeed are able to back up successfully to a new file backup set on the external FW drive on a consistent basis, there is no need to perform a test using your internal drive as a destination unless the problem returns.
  11. You haven't supplied much information for us to go on. What OS, Retrospect, and Retrospect Driver Update versions are you using? Is the external drive a FireWire or USB drive? Does the error occur repeatably, with all clients, and/or when performing a backup of a local hard drive? If you haven't changed anything (hardware or software) recently, your external hard drive may have a corrupt directory or be failing. Try repairing the directory with Disk Utility. If the error is readily repeatable, try creating a subvolume on your local hard drive and backing up to the subvolume to see if the error goes away. If it does, that would suggest problems with the external drive, the interconnecting cable, or the interface.
  12. Things can get confusing if you include one selector inside another If you create a selector--call it Selector A--that excludes files matching another selector--call it Selector B--that itself also excludes files, be aware that what will happen is that all the files NOT excluded by Selector B WILL be excluded by Selector A, and thus will not be backed up. This may be just the reverse of what you intended. If you want both selectors to function "normally"--that is, for files excluded by either selector not to be backed up--Selector A must be written to INCLUDE files selected by Selector B. Another thing which may or may not be an issue: version 6.0.212 is intended only for use on a machine running Tiger. You are using it on a Jaguar system, which is not recommended.
  13. Quote: my hard drive has two fire wire ports. If I connect both directly to my computer will this improve the speed? That would be a bad idea. Devices need to be in a single chain.
  14. Chunk checksum failures usually mean that the catalog is corrupt, but if you're having problems with multiple backup set catalogs, perhaps another Retrospect file is corrupt. Try temporarily removing the Retrospect folder containing the config files from /Library/Preferences and then perform a fresh install of Retrospect. If the problem goes away, you can try returning the config files to see whether they or the previous copy of the Retrospect app was corrupt. If the problem doesn't clear, you will need to rebuild the relevant catalog files from the media.
  15. twickland

    Duplicate Backup

    Louise: To be safe, I would try booting from your FW drive after the duplicate to be sure that all appears well.
  16. Quote: I am having similar problems. I have a twin 500 G4, running Retrospect 6.0.212. I've been using backup to file rather than duplicate, with much the same result. Did you have the same problem before upgrading to Tiger? If pre-Tiger worked fine, see Paul Tansley's comment above regarding the FW bus under Tiger.
  17. Yes, Backup will write everything as one file that requires Retrospect to retrieve the portions you want. Regarding the speed of Duplicate vs. Backup, in our usual case (copying a small number of large files; replacing entire contents), Duplicate runs considerably faster than backup-- about 1100 MB/min to a FW hard drive (G4 Graphite, 450 MHz DP, OS X 10.3.9, Retrospect v6.0.204, RDU 6.4.102). If you are copying a large number of small files, no matter what the method the process will be slower. Try defining a single folder as a subvolume in Configure> Volumes and using that as the source for a duplicate. Compare the time for duplicating the folder in Retrospect with the time it takes to make a Finder copy. Does it take a lot longer?
  18. You don't give any information about your system, Retrospect version, etc. I'll assume you have the latest version of Retropsect and Driver Update for your OS version. Here are some suggestions for troubleshooting: Offhand, it sounds like it may be a corrupt file or HD directory. Try booting from the system CD-ROM to repair your boot drive. If that doesn't help, try eliminating various root folders from your backup script, starting with your Applications folder. If you can isolate a problematic root folder, you can then work to narrow down what interal folder or file is causing trouble. Try copying to a folder on your boot drive (if you have enough room) to rule out problems with the FW drive. There may be an issue with Retrospect or its configuration. Try temporarily relocating the Retrospect preference and config files (/Library/Preferences/Retrospect and /Users/[username]/Library/Preferences/com.dantz.retrospect.plist) to force Retrospect to use default settings, and/or try reinstalling the Retrospect app itself. If the backup always fails at about the same number of files, no matter what files are involved, you may have bad or marginal RAM.
  19. Twenty minutes for 75MB sure doesn't sound right. The <2 minutes for 500 MB we experience includes the time for preparing, copying, and comparing. How is your script configured? Are you replacing the entire contents of the destination subfolder? If you duplicate to a subfolder on a local hard drive, does it run much faster than over the network? What does the log say regarding how much time was spent preparing, copying, and comparing? If you run an Immediate Duplicate, what do the progress windows indicate? Are there any noteworthy pauses or indicated communication difficulties?
  20. Try defining the source and target folders as subvolumes, and then use the relevant subvolumes as source and destinations in your Duplicate script. This will eliminate unnecessary scanning of the entire hard drives. A 500 MB duplication from one OS X subvolume to another in our setup takes less than 2 minutes.
  21. Your question is incomplete, so it's not perfectly clear what your issue is. One way to maintain an offsite copy of a backup set is to create a second set and use the Tools> Copy> Transfer> function to copy files from the first set to the second. Another is to perform backups to multiple backup sets, periodically rotating one set off-site. If instead you were considering whether to duplicate (using some other software) the actual members of a backup set and then to use the copies interchangably with the originals as if they belonged to that backup set, I would not recommend it. Retrospect is set up to have a single set of media dedicated to a given backup set. Even if it were possible to fool Retrospect into accepting a copied CD as an original member (it isn't with the media we use), to do so would run the risk of confusion between versions if future sessions are added.
  22. Quote: Ok, so I go to Configure/Volumes/Client/Browse, the server goes out to the client to find the files to browse, it hangs at 77 folders, 19 files, then it tries to reconnect to the client. My guess is that it's a corrupt file or disk catalog on the client machine. I'd be inclined first to repair the disk with DiskWarrior or Apple's Disk Utility and then try again. If you are still unable to browse or backup, you will need to do some detective work. I assume you have never had a successful backup of the client, since you don't mention it. Try excluding root folders from an immediate backup and see if it runs OK. I'd try excluding the Applications folder first, since your browse results suggest it may be involved. If that doesn't help, continue excluding root folders until you identify the one that's problematic. (You may find it faster to exclude 1/3 of the remaining root folders at a time.) Once you have identified the root folder wherein the problem file lies, continue the process to find the next level folder that's problematic, and so on. Stop at the point where trashing the offending folder and reinstalling it (and everything in it) is less of a hassle for you than continuing the search.
  23. I was attempting to use a 500 GB FireWire hard drive as the first member of a removable disk backup set. However, when the backup was about to begin, I received an error message, "Couldn't erase disk; error 102 (trouble communicating)." This drive is a brand-new warranty replacement for an older, failed drive that had once worked just fine with the disk backup set. Assuming the worst--that the new drive was also hosed--I performed some tests and found that the new drive worked fine with Finder copying, Carbon Copy Cloner, and Retrospect file backup sets; it only bombed with removable disk backup sets. I'll spare you the gory details, but what I found out for the cause of this problem was that I had RENAMED THE RETROSPECT APPLICATION FOLDER from the default "Retrospect 6.0" to "Retrospect 6.0 ƒ." When I changed the folder name back and forth, the application would repeatably start or stop working properly. Oddly, this naming peculiarity affected only the ability of Retrospect to erase the removable disk backup set. Once the member had some files in it, the application in the "ƒ" folder could access it and read/write just fine. It does leave one wondering what other oddities in Retrospect may be attributable to pathnames containing high-ASCII characters.
  24. 6.0.204 will use the same RetroConfig file as 6.0.178. That being said, you should always routinely back up your config files, as with any other important files, as part of a Backup or Duplicate script.
  25. You should try to get satisfaction from whoever you purchased the the bad RAM to replace or upgrade it. You may have gotten an obviously faulty module. However, some RAM is marginal and will exhibit problems when pushed by a demanding application (like Retrospect) even though it technically meets specs (barely). Best advice is not to buy the cheapest modules available, and to purchase from a reputable dealer who will stand behind their product. Needless to say, be sure that the speed and type of RAM is spec'ed properly for your machine.