Jump to content

twickland

Members
  • Content count

    1,684
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. Did you really mean to say client version 6.0.1? The latest client version for pre-Tiger OSX is 6.0.108; for Tiger, 6.0.110. Earlier client versions would often disconnect or spontaneously turn off, resulting in the error you describe.
  2. If you take out the new RAM does the backup complete successfully? If you then take out your original RAM and replace it with the new RAM, does the backup then fail? If both the above occur, you can be sure that one of your new DIMMs is marginal or faulty.
  3. twickland

    Error 109

    I've never seen a 109 error myself, and, judging from the lack of mention in the forums and in the Knowledgebase, I suspect it's pretty rare. The type of error and the fact that it's intermittent does suggest a hardware problem. However, corrupted Retro.config files or backup catalogs can also cause odd errors. I would try some routine troubleshooting. Temporarily relocating the config file out of /Library/Preferences/Retrospect will force Retrospect to create a new file the next time it's launched. In addition, you could try reinstalling the Retrospect software. Create a test script (or perform an immediate backup) to write to a new backup set. As a source, use a client or volume that has been implicated in a prior occurrence of the error. if the problem recurs with a clean install and a new backup set, it would certainly cast suspicion on your backup device, SCSI cable, terminator, or SCSI host adapter. However, with an intermittent problem, it might take some time for the problem to appear.
  4. twickland

    Error 109

    More information is needed. What kind of backup device are you using, and on what kind of bus? How long (if ever) have you had successful backups with this device? Have you changed anything (hardware or software) recently? Does this occur only with scripted backups, or also with immediate backups? If you create a new backup set as a test, does the problem still exist?
  5. We have not experienced much difference in searching old vs. new catalogs for Restores. We currently access catalogs from v4.0, 4.3, 5.0, 5.1, and 6.0. Searches have typically been on the order of 2 to 4 minutes both now and with earlier versions of Retrospect, unless we're at a very early point in a new backup set, with few files and sessions. The searched catalog sizes can vary widely, from 350,000 files in 1,700 sessions (38MB compressed catalog file) to 2.5 million files in 1,000 sessions (891 MB uncompressed catalog file).
  6. Once or twice when performing an immediate backup, I have inadvertently clicked on the parent volume name instead of the client name when adding the source, with exactly the results you describe. From time to time I have also had Retrospect inexplicably (and unrepeatably) back up volumes it shouldn't have. In our case, Retrospect was set to back up the client desktop and it sometimes also backed up read-only volumes (CD-ROMs and even music CDs). It may be that a similar glitch was operating in your case.
  7. Copying data between backup sets is time consuming. You could achieve the same results by duplicating your script for Set A and using the duplicate script for Set B, changing the starting dates in the schedule accordingly. Alternatively (this is what we do), perform a New Media instead of a Recycle backup when you want to switch. You then only need one script. Retrospect will automatically number the backup sets "Set A [001]," "Set A [002]," etc. When you no longer want to retain an old backup set, have Retrospect forget it, and then erase and reuse the media. You may want to think about your plan to use only one backup set for 6 months, though. If something happens to the media, you could be left with only a backup that's 6 months out of date. Better to rotate through 2 or 3 sets of media, backing up to each at intervals that will minimize the pain in case of a problem. We use 3 sets, backing up Monday through Friday. Week one uses sets ABCAB, week two CABCA, week three BCABC, then repeat. This does require creating 15 schedulers for the script (5 days X 3 weeks), each repeating once every 3 weeks, but that's not necessarily a huge hassle. Using the same backup set for a whole week will only require creating one scheduler for each backup set. By the way, you posted to the Mac OSX forum. For Windows-specific answers, you'll want to post to a Windows forum.
  8. If you have specific client volumes designated as sources in the backup script, these will override the client configuration. I assume, though, that if this were the case, you would have noticed this when you reviewed your script. Does the problem occur when you run the script manually or as a scheduled backup? Do you have the same problem when running an Immediate Backup?
  9. Are you running a Normal Backup script? How are you determining which files are being backed up? If you are just looking at individual backup sessions via Reports> Contents, these will differ with a normal backup because Retrospect only backs up files that have changed since the last backup. The Snapshot for a particular backup session will, however, include the files from that session as well as all files backed up in previous sessions that are still on the source drive. The easiest way to see all the files on the source drive that have been backed up is to go to Immediate> Restore> Restore from a backup and select the desired Snapshot. After preparation is complete, click on Files Chosen.
  10. Write two scripts, one for the HDD and the other for the DAT. Schedule the DAT script to run 5 minutes later than the times/dates you choose for the HDD script. The HDD script will complete, and then the DAT script will run.
  11. We are using a LaCie 500 GB d2 Big Disk Extreme FireWire drive as a removable disk backup set. This drive has been in service for three months. Beginning a couple of weeks ago, when the backup set reached about 300 GB in size, we began to get a few 206 Media Failure errors during Compare. These became interspersed with bad backup set header errors, and quickly increased in number. At first I thought we may have reached a bad spot on the drive, but when I tried to verify the backup set, I got 206 errors almost immediately. I then erased the drive using Disk Utility and did a regular, high-level, non-journaled format. Everything seemed fine for a couple of days, but then the 206- and bad backup set header errors started in again. According to LaCie tech support, if there were an I/O or bad sector problem with the drive, this should have appeared in the console log and not just in Retrospect, and I should also have seen a system error pop-up window. The LaCie tech also said that if I did a low-level format of the drive (Option> Zero all data), this should report out any problems with bad sectors, etc. He said if I was successful, this would eliminate the disk interface or the disk medium as a source of the problem. I'm now in the middle of reformatting the drive, thus far without apparent problems. Does what LaCie says make sense? If so, that would seem to imply that the error would then have to be a software problem (Retrospect?). Incidentally, we also back up to DDS tapes, which have recently been working just fine. Whenever we have gotten a 206 error with a tape drive in the past, it has always meant that the drive has needed repairs. Mac G4 450 dual processor, OS 10.3.9, Retrospect 6.0.204
  12. You can use Tools> Copy> Transfer to copy the discs to a new backup set. You will need two drives: one to read and the other to write. By noting the date and time that each CD member was first written to (in Configure> Backup Sets), or by temporarily marking the earlier members as "Missing," you can perform the transfer in convienient chunks instead of copying all 21 CDs in one session. In the future you may want to alternate between two backup sets. This is likely to be less onerous than copying. I would also recommend performing a New Media backup to create a new backup set before your current backup set becomes too unwieldy.
  13. Quote: Also, is there a way to update the most current back up set snapshot to show all files that are on the tape, even from previous sessions of the same set? A Snapshot shows all the files/folders that were on the source volume at the time of a particular backup. That could include folders backed up a long time ago, if they haven't been modified recently. The easiest way to see all of the files in a backup set, whatever the source volume or backup date, is to go to "Immediate> Restore> Search for Files and Folders" and enter the desired search parameters. Unless you are actually intending to restore files, you can specify any local volume as the restore "destination."
  14. This has been an issue for a long time. It is not related to 10.3.9. We have experienced it with OS X clients while running Retrospect 5.0 under OS 9, Retrospect 5.1 under OS 9 and OS X, and Retrospect 6.0 under OS X. It does appear to be related to backing up clients across a router or switch. Since Dantz seems to have its head in the sand on this one, we have simply learned to live with the problem. We use multiple individual tape drives rather than an autoloader, so I don't know whether that might be part of the problem. Our backup machine is a older DP G4 (450 MHz). I haven't had the time or the inclination to try a different configuration. Fortunately for us, since we downgraded our Windows clients to v 6.0.110, we don't have a problem with tape change while backing up those clients. (The Retrospect application itself used to hang under client version 6.5, rather than logging a 515 Piton protocol violation.) Since we have twice as many Windows clients as OS X clients, and since the Windows clients typically have larger files--meaning that most tape swaps occur when we're backing them up--we have not experienced the impact on our backups that you have suffered.
  15. Nate is assuming that the existing catalog file is hosed. Rebuilding the catalog from the tape will create a fresh catalog to replace the old corrupted one.
  16. You can also use USB or FireWire HDs as "removeable" disks for a regular backup set if you select that option in Preferences> Media Handling.
  17. Did you use "ls -al" to show invisible files?
  18. With one modification, the standard canned selectors "Applications" and "System Folder" should do what you want. You will need to add an "OR" condition to the System Folder selector: "enclosing folder name matches 'System Folder.'" Then create a new selector for your backups, to exclude files matching either of the selectors "Applications" OR "System Folder."
  19. Unless you are restoring from a new, full backup, the speed of a small sample restoration is likely not to give you an indication of the length of time the complete restore will take. If your backup set has many members and there are a lot of files that belong to other users or are superseded versions, it's likely your restore will be slow at first, since it will be skipping over a lot of files on the tape that aren't needed. Large files will be restored the fastest, followed by smaller files that are contiguous on a given tape member. Slowest of all will be restoring small files scattered here and there (as is often the case when beginning a restore from a backup set that's been in use for a while).
  20. Yes. Just use Update Existing to continue the rebuild process.
  21. Dave suggested something to try, which is to create a new, empty folder on the drive that is normally your source drive. Define that folder in Configure> Volumes as a subvolume, and plan to use that as the destination for a test backup. Then define one of your problem folders as another subvolume, and use that as the source volume in the test backup. See if the creation dates still change during the test backup. BTW, I don't understand what you're trying to say regarding the QuickTimeComponents file. As you describe it, the Retrospect and Finder dates/times are the same, within the degree of precision that Finder reports.
  22. I would definitely recommend having multiple backup sets, as media members can fail, get damaged, or become lost. We rotate through 3 backup sets at a time, and keep adding to the sets until they threaten to become unwieldy. Then we either Recycle or shift to New Media.
  23. Quote: Seeing that almost everything has been replaced other than the SCSI card and cable... I think you answered your own question about what to try next. Have you examined the cable closely? Those 68-pin HD cables are pretty delicate. You can mash a pin if you don't insert it perfectly aligned. If a pin is bent out of position, you may be able to straighten it with tweezers. As for the host adapter, have you contacted ATTO support? We had a problem where firmware and NVRAM became corrupted during an update and the card had to be sent back to be reflashed.
  24. Your message is somewhat confusing. You first say that it's a problem with a particular xServe, but then you say it has been an issue on "several machines." If so, were the latter all xServes? I notice you are not using the latest version of Retrospect and the Driver Update for Panther (6.0.204 and 6.2.102 respectively). Maybe you'll be lucky and the thing will work after you update. However, if you really been having problems on various computers, it sounds more like a hardware problem with the autoloader itself. Have you contacted Exabyte?
  25. I'd recommend an ATTO ExpressPCI UL3S host adapter. We have an HP StorageWorks DAT 72 and use the 68HD SCSI cable that came with the drive. Keep the scanner and the Zip drive on your old card if they work.
×