Jump to content

twickland

Members
  • Content count

    1,679
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. As far as I know, Retrospect always scans the busses automatically when you first click Configure : Devices, start to run a backup, etc. (You should see a little popup window that says Retrospect is scanning the busses.) This sounds like it may be an issue with the host SCSI controller. Have you updated to the latest version of the device's driver software and/or firmware? Is the card compatible with the G5 and 10.3.8? You should also update to the latest version of Retropect (6.0.204) and install the most recent Driver Update. If the problem persists, it may be that the AIT drive simply needs to be polled twice after a reboot to get its attention, so to speak.
  2. twickland

    Selectors

    To back up a folder with a specific pathname, I've found it's better to define that folder as a Retrospect subvolume (in the Configure:Volumes menu). You can then either set Configure:Client to back up those specific volumes, or you can create a list in the Volumes menu and use that as your list of sources for your backup script. The only hassle is that you need to configure the subvolumes and backup parameters for each client separately.
  3. You will need to search for "Enclosing Folder contains...." rather than "Enclosing Folder matches..." unless you append the extension ".app". However, a caveat: Since Retrospect sees packages as folders, if you have multiple versions of an application package in your backup set, a retrieved package will contain all of the earlier file variants inside the package. You would then need to go through and select only the latest version of all these files, including the ones in any subfolders, before performing the retore. It will be a lot easier and safer to restore a package by using a Snapshot (i.e., "Restore files from a backup" or "Restore entire disk"), rather than using Search for Files and Folders. To restore folder structure, select any option other than "Retrieve Just Files" in the Destination window. After the matching has been completed and the Restore window appears, go to "Files Chosen." Application packages will show as folders with the name [application].app. Select and highlight what you want to restore.
  4. This is a known issue. The solution is to uninstall the v6.5 Windows clients, and then install client v6.0.
  5. My guess is that you may have directory corruption on the local HD. Try booting from the system CD and running Disk Repair, or even better, purchase or borrow a copy of DiskWarrior.
  6. In my experience, when Retrospect searches for a package, it shows it as an enclosing folder, but when the folder is restored, the Finder shows it correctly as a package. When I have performed a Restore, I searched for the package under Name (File/Folder), not as an Enclosing Folder. I also performed the Restore to restore folder structure, not "Just Files."
  7. By default, a "Normal" backup in Retrospect is an incremental backup. An incremental backup is a Good Thing because you can go back days, weeks, or months to get the file version you really want. The downside, as you've discovered, is that the file eventuallly gets to be too big. You could edit your backup script to always perform a recycle backup instead of a normal backup, but I wouldn't recommend this. Instead, create a new script to run a recycle backup every X weeks or months to keep the size of the backup set under control. Alternatively, whenever your backup set gets too big, go to Configure : Backup Sets: [highlight desired backup set] : Configure : Options : Media Action... and select "Recycle" to manually reset the backup set. All the old data in that one backup set will no longer be recoverable, but that won't matter because you have been following Dantz's advice to back up to multiple backup sets, haven't you?
  8. There should be no problem creating a separate recycle backup set on your external drive. However, it seems to me you are already putting too much reliance on that single external hard drive. By creating and rotating through several backup sets on different media, you reduce the risk of a disaster should one piece of media fail. Purchasing another external drive or two to accomplish this would be cheap insurance.
  9. Does your product license entitle you to have 3 clients? Some desktop editions only allow 2; you would have to purchase an add-on to increase the number of clients. If your license permits, and if you can connect manually in the Network window, Retrospect should also connect automatically when you want to back up, restore, scan a disk, etc. If there's a problem connecting automatically, you should swap ports on your hub, and maybe swap cables to see if the problem lies with the computer, the hub, or the cable.
  10. Quote: This is the first reference I've seen to Dantz acknowledging a media change error with a Windows 6.5 client and Mac OS X host 6.0. Is it posted anywhere? Among other locations in Dantz's Knowledgebase, it's included in the latest Retrospect 6.0 for Macintosh Read Me.
  11. We have experienced all the problems described above. Dantz has acknowledged the Win client 6.5 media change bug and recommends the 6.0 client downgrade as a workaround. Dantz does not acknowledge a similar bug with OS X clients, and in fact seems to willfully deny the possibility of a bug. After experiencing a flurry of piton protocol errors at media changes for OS X clients under Retrospect 6.0 (we upgraded on November 1), I retrieved operations logs covering the past 13 months. I discovered that under Retrospect 5.0 / OS 9.2.2, Retrospect 5.1 / OS 10.2.8, and Retrospect 5.1 / OS 10.3.x, EVERY piton protocol error that was reported corresponded to a media member change (we use DDS tapes). Under Retrospect 5.x, only about half of the media member changes that occurred while backing up an OS X client generated a piton protocol error. Thus far under Retrospect 6.0, every media member change that has occurred while backing up an OS X client has generated a piton protocol error. I find it hard to believe that everyone who has reported this error is experiencing network problems. In our network, each office is served by two routers. It's easy to shift the Ethernet cable from one router's jack to the other. The fact that the problem remains tells me that it is almost certainly due to one of three reasons: 1) a faulty network interface in the backup Mac; 2) the configuration of our routers (they are, for example, configured to block subnet broadcasts across them); or 3) the Retrospect software itself (either client or backup); specifically, how the software handles paused backups in certain network configurations. The preponderance of evidence suggests it's probably option 3. Dantz would do well to take this issue seriously and start compiling a history of these problems. Since they are the only ones who know how the proprietary piton protocol works, they are the only ones in a position to develop insights into how the problem may be being generated. For example, every time a user reports a piton error, start by having the user check the backup set configuration and determine whether a media member change occurred at the time.
  12. If you trash these files, Retrospect simply creates them again, so I can't see any reason to back them up.
  13. Are you saying that you can't edit your backup script so that its schedule shows the days you want, or are you saying that Retrospect ignores the schedule you created in the script when executing it? We rotate through three backup sets, with different actions depending on the day of the week, and have never had a problem creating scripts to suit, or having them execute properly.
  14. Dave: You raised an interesting question about piton protocol errors, so I checked the logs and found that the only piton protocol errors we have gotten since 10/29/2003 occurred at the time of media requests with OS X clients (though not every media request during an OS X client backup generated an error). These errors happened with Retrospect 5.0 under OS 9.2.2, and Retrospect 5.1 under OS 10.2.8 and 10.3.x. Of the 66 media requests under Retrospect 5.x between 10/29/2003 and 10/29/2004, 12 occurred while backing up OS X clients, with half of those generating piton errors. Of the 11 media requests under Retrospect 6.0 since 11/1/2004, 4 occurred while backing up OS X clients, and all 4 generated piton errors. Due to the hassle of dismantling client computers and dragging them down to my office, and due to the relative infrequency of the piton error problem under Retrospect 5, we did not pursue an investigation at the time. Since the problem has occurred with clients in four different subnets, and assuming it is not due to a bug in the Retrospect software, the problem would seem to lie either with the backup computer itself or its subnet router, unless there is some issue affecting all of our routers, such as how they are configured. If the problem persists, I may change my mind about investigating further. However, since the error is fatal only to a single night's backup of an individual client and, unlike the Windows client problem, does not stop the execution of the rest of the script, we may just live with it.
  15. I was wondering whether other users find Retrospect 6.0 less functionally usable than 5.1. We have been running 5.1 on Panther, putting up with the inability to autolaunch, until it was time to create new backup sets (we do this at the time change). Since upgrading to 6.0.204, we've had a variety of problems that did not appear under 5.1: • Lots of 515 piton protocol errors with OS X clients, which were rare under 5.1. Does 6.0 use different networking protocols than 5.1? • Retrospect often hangs when adding a DDS tape member with Windows 6.5 clients. Shame on you, Dantz, for not spreading the word on this bug! We updated all of our Windows clients to 6.5 just before upgrading to Retrospect 6.0. Reverting clients to v 6.0 through Retrospect is a hit-or-miss prospect. • After reboot, one Windows client looked like it had successfully reverted (it showed as client v 6.0 via Retrospect). However, at the client itself, the only visible version of the client software was 6.5, and the control panel said it had not loaded. After conducting a search of the hard drive, which showed no other versions, we were forced to uninstall v 6.5, which apparently eliminated the invisible 6.0 client as well, and then manually reinstall the 6.0 client. •It looks like we will need to manually uninstall and reinstall the client software for most of our Windows computers. • When Retrospect hangs, rebuilding the catalog has caused problems. • After one catalog rebuild (which claimed to be successful), we could not add to the backup set, apparently because, although it had been named, the latest DDS member (where Retrospect had hung) was otherwise still blank. Error 212, media erased (DUH!)--a new one on me. I thought, "No, problem; just forget that last member." Wrong. Forgetting the last member reset the entire catalog, which then had to be reconstructed from the tapes. • After another catalog rebuild, we couldn't add to the backup set because the "catalog was locked." Luckily, quitting and relaunching Retrospect fixed that one. It seems like every Retrospect upgrade has had problems, but 6.0 seems worse than most.
  16. We've found that Retrospect 5.1 will not reliably autolaunch under Panther. The solution is to launch and not quit the application. Any automated scripts should then run. Based on our experience, I'd be cautious about upgrading to Retrospect 6.0 (see my related post).
  17. Rather than using complex selectors tailored to each client, I'd be inclined to use a more generic selector and then use the Configure : Volumes window to define specific folders as subvolumes for each user. After doing this, you would need to go to the Configure : Client : Configure window for each client, change the backup setting at the General tab from "Client Desktop" to "Selected Volumes," and then highlight only the desired subvolumes at the Volumes tab. The main reason for taking either route is that you're trying to save space on the backup media, or save time in performing the backups. However, unless you're really using a lot more of either than you can afford, I'd consider backing up a higher-level enclosing folder, even if that includes more files than you need. The fewer subvolumes you need to define, or the less complex you need to make your selector, the easier it will be for you.
  18. You are using the wrong Boolean argument. You want "OR," not "AND." They way you constructed your selector, all of the pathnames need to be true at the same time for any file to be backed up, which is, of course, impossible, since a file can have only one pathname.
  19. • Lots of 515 piton protocol errors with OS X clients, which were rare under 5.1. Does 6.0 use different networking protocols than 5.1? I have discovered the source of all the piton protocol errors. These are generated when Retrospect changes to a new media member while backing up OS X clients (at least with client v 6.0.108). Clearly, Retrospect 6.0.204 does not handle DDS media changes gracefully with either Mac or Windows clients. Comments, Dantz?
  20. As described above, while editing the script, be sure that Options : Matching is set to the default configuration ("Match source files to catalog" and "Don't add duplicates to backup set.") Also, if you are backing up Windows clients, they use a different means of tracking date and time. With the switch from DST, all files will appear to have a different modification time by one hour, and so will be flagged for backup.
  21. In the Retrospect Directory window, go to Special : Preferences : Media Erasure and check the box for minimal erase confirmation.
  22. I believe that Retrospect 5.1.177 already incorporates the SCSI update, as the SCSI Update Installer says it's the "wrong version" to update. I am using 68 pin cables throughout. I have swapped out cables and terminators; zapped PRAM, etc As a test, I just installed a basic version of Retrospect 6.0. In its device configuration window, Retrospect 6 shows both tape drives with their proper SCSI targets, and will identify tapes inserted in either drive. However, it is only able to read or write from the first drive in the SCSI chain (the same drive that is the only drive that Retrospect 5.1 can see). When attempting to access a tape in the second drive, all appears to be well at first, but then the "rotating gear" cursor spins forever and the drive never starts up. Sounds like I need to turn the heat up on ATTO's tech support.
  23. In trying to access SCSI DDS tape drives In Retrospect 5.1.177 using an ATTO UL4S SCSI adapter and Panther 10.3.4, I find that all devices in the Device Status window show the SCSI target ID as 0. Only one drive shows as being accessible in the Available Storage Devices window. The drives display the correct SCSI target using the ATTO Configuration Tool, but no target ID appears in Apple's System Profiler. ATTO claims that the System Profiler is unreliable, and that the problem the drives do not appear in Retrospect is the fault of the Retrospect software. I am using the latest versions of the ATTO driver (3.1.0) and firmware (1.4.2f1). I also have an Adaptec 29160 SCSI card installed. Using this card and the most recent available driver (1.2, not certified for Panther), the target IDs of the tape drives are visible in both the System Profiler and in Retrospect. Question: Does what ATTO is saying regarding Retrospect 5.1 and the System Profiler make sense, or are they just shifting blame? Incidentally, I upgraded to Retrospect 6.0, but then downgraded back to 5.1.177 for two reasons: I was not ready to start a new catalog file (as 6.0 requires), and I was unable to successfully restore from version 5.0 tapes.
  24. I should have noted that I was previously running v 5.0 release 205 without experiencing the problem on quit. I did uncover a third-party software conflict that consistently triggered my problem with release 236. When I updated, I thought the problem had gone away. Unfortunately, it has only gone from consistent to sporadic. I am currently suspicious that it may be related to simultaneously running several Microsoft applications that use the same shared libraries. (These applications occasionally interact with one another such that, for example, I cannot delete a mail message in Outlook Exchange until I quit Word.)
  25. I recently updated to release 236, running on OS 9.2.2. The good news is that this release may finally have solved the communication problems we've been having with our OS X clients. There has been one peculiarity, however. When quitting Retrospect, if I have the program check media (DAT tape) at quit, the entire quit process seems to proceed normally, except that I then get a Finder message saying that Retrospect unexpectedly quit with a Type 2 error. This is true even if, after checking media, I click "Don't Quit," go back to the Directory, and then finally quit without rechecking media. If I quit without checking the tape, no error message is generated. When the Type 2 error message is generated, it's non-fatal and there seem to be no residual problems. Retrospect will autolaunch and automatically shut down the computer as normal, even if the computer is not restarted after the error. Has anyone else experienced this issue?
×