Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by twickland

  1. Quote: "Mark" isn't enabled for the folder itself, but rather only for the contents of the folder (package). Ah, there seems to be a peculiarity in Retrospect where the"Mark" button is not enabled for a folder if the folder is open, displaying contents (arrow pointing down). However, despite this, if you double-click on the folder, it and its contents will be highlighted and marked. Alternatively, if you click on the folder arrow so the folder closes (arrow points sideways), the "Mark" button is enabled. I usually just double-click, so I never noticed this anomaly before.
  2. The log will indicate what backup script ran; typically, "Normal backup to [script name] at..." Is it the name you expect?. Are you saying that the Automate> Scripts window is completely blank? Can you see the script in the Run menu, the Automate> Check window, or the Automate> Preview window? If you can see scheduled events in the Preview window, try highlighting an event and click on Edit Script. I don't suppose there's a chance someone renamed the script with all spaces or something like that. If all else fails, the configuration file may be hosed. It's found at /Library/Preferences/Retrospect/Retro.Config (6). (Note that this is the library at the root level; not your user library.) Try moving it to the desktop and see if Retrospect behaves better If you don't have a backup of this file and it is indeed corrupt, you'll need to recreate your scripts and lists.
  3. There's no direct way to do this, but you could approximate it by using Tools> Copy> Transfer to copy sessions after a specified date to a new Backup Set. This would require a second backup drive, but for safety's sake you should not be relying on a single backup set anyway. However, once you have a second drive (three would be even better), an even better idea would be to rotate your backups through all the drives. You could then establish a staggered schedule for performing a recycle backup on each drive, at frequent enough intervals such that the drive doesn't become full. That way you will always have at least one copy of the most recent backup sessions.
  4. The only way to back up to whatever drive happens to be attached is to use a Backup Sever script. A standard backup script has to have available whatever media set is scheduled to be used, or it won't run. If you really want to back up 24/7, a Backup Server script sounds ideal. However, if you just mean you want to back up once a day and then quit or shut down, a regular script might be better. I would question your wanting to rotate backup sets only once per month. That would mean you would lose a whole month's worth of data in the event of damage or loss to one of the drives. We use a different backup set every day, which you might find excessive, but even weekly rotations would be a lot safer than monthly. Whatever you want to do, it's possible to add enough day of the week or repeating interval schedulers to a script to accomplish the task. If you really insisted on approximately monthly intervals, I would suggest rotating backup sets every 4 weeks rather than each month, as you would need to create fewer schedulers (12, as opposed to 93). Doing the safer weekly rotations can be done with 3 schedulers. The only downside would be the hassle of swapping out the drive weekly rather than monthly.
  5. Sounds like either the Retro.Config file or the application itself may be hosed, or you may have a corrupt HD directory. I would first reboot from a CD and check/repair your hard drives using Disk Utility or DiskWarrior. If the problem persists, try dragging the config file (/Library:Preferences:Retrospect:Retro.Config (6) ) to the desktop temporarily and see if the application will launch. If it still doesn't, then try uninstalling and reinstalling the Retrospect application. If you have a lot of custom scripts or clients, you may want to save the config file and (assuming it's not corrupt) drag it back to the proper folder once you get Retrospect to launch.
  6. 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.
  7. twickland


    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.
  8. 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.
  9. This is a known issue. The solution is to uninstall the v6.5 Windows clients, and then install client v6.0.
  10. 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.
  11. 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."
  12. 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?
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. If you trash these files, Retrospect simply creates them again, so I can't see any reason to back them up.
  18. 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.
  19. 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.
  20. 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.
  21. 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).
  22. 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.
  23. 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.
  24. • 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?
  25. 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.