Jump to content

twickland

Members
  • Posts

    1,684
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. The -43 error indicates that Retrospect can't find the folder on the destination volume to which it wants to restore certain files. In your example, the folder was supposed to have the name "...!!!" which is not allowed under OS X because it begins with a period. My guess is that Retrospect sent the command to create the folder but because the name was illegal, the folder was not created; Retrospect's subsequent command to write a file to that folder failed because the folder did not exist, generating the -43 error. Your log suggests that this folder was originally created under OS 9, so perhaps it isn't necessary for you to restore it at this point. My first thought is that you may be able to solve your problem by changing your settings in System Preferences> International to enable file/folder names with the correct characters. Alternatively, you might perform your restore by deselecting those folders that seem problematic. You don't say what kind of restore you were performing. If it was "restore entire disk" or "replace corresponding files" and if your subsequent restore is one of those types, Retrospect will recognize the files that were restored previously and will not try to restore them again. (If, on the other hand, you were restoring to a new folder, you would then need to define that folder as a destination subvolume for your subsequent restores in order to avoid restoring everything a second time.) To deselect unwanted files, initiate a restore from a backup, choosing either "restore entire disk" or "replace corresponding files" on the destination. When the matching has completed and the restore window appears, click on "Files chosen" and uncheck any folders you don't want to restore. (Those files already restored will have a diamond in front of the name.) Keep us posted as to whether you have success.
  2. I would first make sure that your tape drive is qualified for the Retrospect version you're running (which you haven't told us). You can check things out here. You may need to update your Retrospect version and/or download a new RDU file. Theoretically, Retrospect 6.x should be able to happily read 4.x backup sets and rebuild their catalogs, but some users have reported difficulties accessing old data. I haven't experienced such problems myself, but I haven't had much need to retrieve old 4.x data, and I've never tried to rebuild an old 4.x catalog while running 6.x. Good luck and let us know how you make out.
  3. A recycle backup simply resets the catalog before beginning the backup. If, as in your case, the recycle backup misses one or more source volumes, there is no need to perform another recycle backup. In fact, to do so would reset the catalog again, causing you to lose the data from the volumes that did get backed up. From this point forward, you should perform Normal incremental backups, which will add the data from the missed volumes, as well as new and changed files on the volumes that were backed up earlier. Perform a recycle backup only when you want to clear the decks and start again from scratch. By the way, your version of Retrospect is getting long in the tooth. You may want to download the latest version here; it's free.
  4. You don't say which computer(s) were subject to the OS reinstall. If it was the client computer, I would try using the client software installer to first uninstall and then reinstall the Retrospect Client software on this machine. In your "reinstall," you didn't happen to upgrade the machine to 10.6, did you? Retrospect 6.1 won't work with 10.6. If you need further information from us, please give us more details about your setup, including which version of Retrospect 6.1 you're using, any installed Retrospect Driver Update file, and the exact hardware in use.
  5. A couple of things come to mind: -Did you use exactly the same selection criteria and backup options in your 2:15 PM incremental backup that you used in the 7:19 AM backup? -Is there any chance that the files that were not backed up in the morning were deleted before the afternoon backup attempt? If you have time, you might want to dig into the files that were backed up in the morning session to see if you can find any files on the source that were missed. (Go to Reports> Contents and select the backup session in question.) In all my years of experience with Retrospect, I have never run into a situation where Retrospect did not back up files that were missed earlier, no matter what the reason for the initial failure. If that did indeed happen in your case, it would be a serious bug. You can force Retrospect to completely back up GazXserve2 without resetting the catalog. First, make a copy of your usual backup script (for safety's sake). In this backup script copy, modify the sources to include only GazXserve2. Go to Options> Matching and deselect the options "Match source files to catalog" and "Don't add duplicates to backup set." You might also want to adjust your selection criteria to eliminate certain files you obviously don't want to back up again. Then, perform a single backup of your source volume using this special script.
  6. Unfortunately, yes. Worse, Retrospect 8, which will run on 10.6, stupidly won't read earlier backup sets. Your only real option is to locate a computer that will run 10.5 or earlier, install Retrospect 6, and attach an external disk drive that you can restore to. Once you have done this, you'll be able to mount the external volume on your new Xserve. If you need the files on an internal volume, you can copy them in Finder. I wish there was a better option I could suggest.
  7. Retrospect 6.x (either the client or main app) is not compatible with Snow Leopard. If you can't (or don't want to) downgrade the OS version on the client computer, you will have to bite the bullet and switch to Retrospect 8.
  8. I haven't seen a -36 error under those circumstances; it's typically either a -53 (volume off-line) or -35 (volume doesn't exist) error. However, note the difference in lead-in ("Can't access volume..." vs. "Trouble matching..." or "Can't save catalog..."). These latter errors would seem to be referencing the volume that holds the catalog and file backup data. I think you'll find that your destination volume is failing.
  9. Are you referring to your source drives here? If, as I suspect, you have a problem with the volume on which your destination file backup set and its companion catalog are stored, that volume would have to be mounted for you to be able to access the backup set. Please clarify what you mean by drives not being online. Retrospect pushes hardware to the max. It will often reveal problems with a failing hard drive long before Disk Utility detects any problems.
  10. This would seem to indicate that the file Retro.Config (6.0) was deleted or ended up in the wrong place. The proper location is /Library/Preferences/Retrospect. When you installed Retrospect 6.1, did you ask to import your previous configuration information, or did you select "Use Default?" If the latter, your old configuration items would have been deleted. If you can't find your previous Retro.Config file (try searching in Finder), you will either need to restore it from a backup or reconstruct everything by hand. The Retro.Config file from 6.0 is compatible with 6.1. However, your backup sets from 6.0 are read-only under 6.1, due to changes in the catalog structure, so you will need to create new backup sets.
  11. An external drive can make a perfectly serviceable destination for a backup set. However, your post may win the record for containing the least amount of information about your problem. If we're to be able to help you, please tell us: What version of Retrospect you're using and any driver updates (RDUs) you've installed. What hardware you're using and what OS version you're running. What type of backup set you were trying to create (File, Removable Disk, etc.). Whether you have had any success creating and writing to any other backup sets.
  12. Can you see the Atto card and the tape drive in Apple System Profiler? Can you see the tape drive using the Atto Configuration Tool? If not, Retrospect will never be able to see it either. Do both your old and new computers have the same type of PCI bus? Did you update the system software before you tested things? One thing to consider is that you may have damaged the SCSI cable during the swap. In particular, those LVD SCSI plugs have many fine pins and it's not too difficult to accidentally bend one when connecting the cable. (Been there; done that.) A bent pin can usually be gently straightened back to where it ought to be using tweezers.
  13. Assuming you're talking about the Xserve, this might suggest some sort of a hardware problem. When you moved Retrospect 6.1 from the G4 to the Xserve, did you copy over the Retro.Config file (located at /Library/Preferences/Retrospect)? If so, that file may be corrupt. Unfortunately, this file contains all your scripts, lists, and custom selectors, so if it is corrupt, you would have to reconstruct everything by hand. As Russ notes, Retrospect 6.1 is broken under Snow Leopard. Some users claim to be able to make it work, but I don't believe any of them has ever confirmed to this list that they were successfully able to back up and restore files. Your best bet is probably to try and figure out how to make Retrospect 8 work in your system.
  14. Retrospect 6.x for Mac cannot back up Windows files that are in use by another application. You should examine the files that were not backed up to determine whether you would consider them important. For example, you may well not care about all those temporary files. (We use a selector in our backup scripts that specifically excludes temporary files.) For files that are important, your users will need to be instructed to periodically quit the relevant applications so that the files can be backed up.
  15. What kind of backup set are you retrieving from? What OS version are you running? What is your hardware setup?
  16. Retrospect is seeing the files as having changed in some way and is therefore copying them again. You don't say what OS each of the computers is running; if her machine is running 10.6, that might be an issue. If ACLs are enabled on your wife's computer and you haven't configured your script to ignore extended attribute modifications, that could also cause files to be backed up more frequently than expected. If your wife's computer is somehow losing track of the correct time or time zone (such as if the backup battery is failing), that would also cause files to appear to have changed. Since you are performing duplicates rather than backups, you won't have a nice catalog history to dig through; you'll have to manually compare the files on the source and destination to see how they differ over time.
  17. Be sure that the correct RDU (6.6.101 for Retrospect version 6.0.204) is installed in the same folder as the app. If you don't have it, it's available here.
  18. After you have set up a subvolume on a client computer, there are two ways to back up just that subvolume: Include only that subvolume as a source in your backup script. Follow the method Russ describes above, which allows you to add the client computer itself as a source in your script but back up only the desired subvolumes. We find the second method to be most convenient in our situation, where we have lots of scripts, multiple subvolumes on each client computer, and have defined a number of client source groups.
  19. It has 2 channels - 1 & 2. I am presuming channel 1 is the internal connector and 2 is the external connector. For future reference, the UL4S indeed calls the internal connector "Channel 1" and the external connector "Channel 2."
  20. To achieve backup redundancy, you need at least two separate backup sets on physically different media; we use three. You then need to establish a schedule that rotates among your various backup sets. More frequent rotation means that you won't lose as much new data if a particular piece of media is damaged, but also means more work and inconvenience in swapping out the backup set media, especially if you always take care to keep one of your backup sets off site. Only you can decide what's the appropriate tradeoff between safety and convenience. In our case, we have chosen to run backups seven days a week and to rotate sequentially among our backup sets every weekday, so that we won't lose more than one day of new data (or up to three days over the weekend). Our scheme requires 15 different schedulers in the backup script because the backup pattern repeats only once every three weeks. A simpler arrangement might rotate between two backup sets on alternate weeks or use one backup set for Monday-Wednesday backups and a second for Thursday-Sunday. We perform a New Media backup whenever the backup set becomes inconveniently large to perform restores. (We back up to tapes and retain all of our old backup sets so we can recover ancient data as needed.) If you plan to use file backup sets, you're more likely to be performing a Recycle Backup when the destination volume approaches being full, though you could always choose to introduce a new media volume and store the previous hard drive volume for a while. If you do recycle your backup sets, don't recycle both at the same time; alternate your recycling so that you always have at least one complete and reasonably recent backup at all times.
  21. Here's a workaround: Go to Configure> Backup Sets> Configure [your_backup_set]> Members Note the date and time that the desired member was first written to, as well as the date and time that the following member was first written to. Follow the usual steps for performing an Immediate Restore, searching for all files/folders in the backup set between the above two dates/times. Since you won't actually be performing a Restore, you can enter any accessible volume as a dummy destination. When the Searching and Retrieval window appears, click on "Files Chosen" to view the files on your desired member. Hope this helps.
  22. You should post this in the Retrospect 8 forum. The forum you're currently in is for Retrospect 6.1 and earlier.
  23. If Access Control Lists (ACLs) or other extended attributes are set up on one or more of your machines, Retrospect will want to back up the files anytime this metadata has changed. This is good if you are actually using the ACLs or other metadata. However, if ACLs are enabled by default and you are not not actually using them, you may be backing up your files more often than necessary. This may depend on how brave (or reckless) you are. One user reported success in backing up client files for clients running Snow Leopard. To me, "unsupported" means "you're on your own." If you did want to try this, I would perform a whole series of test backups and restores involving all your important file types in various sizes. If you are able to do so successfully, this may mean that such backups will work in your particular present setup. Me, if the tests panned out, I'd then have reasonable comfort backing up, say, users mp3s; for enterprise-sensitive data, not so much. When introduced, Retrospect 8 did not have any ability to import anything from Retrospect 6.1. This ability was supposed to be added "eventually," but to my knowledge "eventually" hasn't happened yet.
  24. As Russ notes, there is no special way to ensure that Retrospect will not back up these files again. However, you will have the best chances if the matching options you've chosen in your backup script are the minimally-restrictive ones. This means saying YES to "match source files" and "don't add duplicates;" NO to "match only same location" and "use attribute modification date." If the files' original creation and modification dates (as well as file sizes) were not preserved when they were transferred from the old machine, there is no way to prevent them from being backed up again that is both (a) practical, and ( avoids the possibility of excluding other files that you actually want to have backed up.
×
×
  • Create New...