Jump to content

twickland

Members
  • Posts

    1,684
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. Have you checked the condition of the disk volume using Disk Utility or Disk Warrior? When you got the "rebuild anyway" message, did you continue the catalog rebuild or did you cancel? You haven't by chance moved either the data and catalog files in this backup set to a different location, have you? With file backup sets, the data file and catalog file need to reside in the same directory folder. If the files are where they belong, if the file structure on the disk volume checks out OK, and if you still can't repair/rebuild the catalog, you may be out of luck.
  2. The first thing I notice is that you were getting a lot of 205 "Lost access to storage medium" errors. These are almost certainly hardware errors. The fact that you had better luck with your friend's Quantum LTO drive suggests that your IBM drive may have problems. Other potential problem areas might be a defective SCSI cable or your UL4D SCSI card. Russ's advice to update your ATTO driver and firmware is good (be sure to update the driver and the ATTO Configuration Tool before you update the firmware). It looks like what you are trying to do is restore the catalog that "disappeared" when you performed that Recycle Backup on December 23. When you did that, you also overwrote the old data on tape member 1-SET_2009_BACKUP_01, as you seem to have discovered. When you were using your friend's LTO drive, are you absolutely sure that Retrospect "froze?" The recatalog operation from tapes 2 and 3 will be time-consuming and during the process, Retrospect is likely to be unresponsive for long periods of time, which is not the same as a freeze. The log shows you have been force-quitting Retrospect a lot. If you force quit while rebuilding the catalog, you will certainly not end up with a complete catalog, and the partial catalog may not be usable. Here's my advice: Assume for starters that the IBM drive is the problem, and that the setup using the Quantum LTO is OK. Then, be patient during the catalog rebuilding process, knowing that Retrospect may stop showing activity for many minutes at a time before the process continues. If Retrospect really does freeze, or if you continue to get 205 errors, you will need to dig deeper in your troubleshooting. Try swapping out the cable or SCSI card. Are there any other devices in your SCSI chain? Try removing them to see if there is any change.
  3. When you say the catalog "disappeared," do you mean it was deleted by mistake? Did you try searching for the catalog in Finder? The reason I'm asking is that files do not disappear by themselves unless there is a serious problem with the hard drive volume. If there is a problem with the volume that caused the file to actually disappear, you may not be able to write your new catalog to it. Please list all of the steps you performed when you attempted the catalog rebuild. When I say "all," I mean everything. What window you opened, what buttons you pressed, which tape you inserted, and so forth. Also please give us the entire text of the Retrospect log for the rebuild.
  4. Consistency errors almost always indicate a problem with a Retrospect file, usually either a catalog or Retro.Config. You say you just rebuilt your backup set's catalog just before the problem began. Why did you do that? Was there another problem you were experiencing? It's pretty easy to check Retro.Config. With Retrospect not running, drag Retro.Config from its home folder (/Library/Preferences/Retrospect) to the desktop; then launch Retrospect, which will force creation of a new default copy of Retro.Config. You'll need to re-enter your license code and all of your scripts and lists will be gone. Try and see if you can then successfully get through a backup. If you can, that would indicate problems with your old Retro.Config file. If you still can't get a successful backup, I would try repairing the catalog again, this time under the new default configuration.
  5. That may not indicate a problem. If you have lots of custom data and complex schedules, Retro.Config can be pretty big. Ours are all in excess of 100 MB.
  6. You'll need to tell us a bit more about your system hardware and OS version. Also please confirm your Retrospect and RDU version numbers. Also, what type of DVD is it and was the DVD created on the exact same system you're now trying to read it on?
  7. It's highly unlikely that 3 catalogs would be corrupted simultaneously. Much more likely is that the configuration file Retro.Config (located at/Library/Preferences/Retrospect) has become corrupted. With Retrospect not running, drag this file to the desktop (for safekeeping) and then launch Retrospect, which will force creation of a clean default configuration. You'll need to re-enter your license code, and all your scripts and lists will be gone. Try a test backup and see if the problem has gone away. If it has, install a good backup copy of Retro.Config (if you have one); otherwise, you'll need to recreate everything manually. Replacing Retro.Config may also fix the failure to autolaunch or to autorun your scripts. If it doesn't, trash the file "retrorunfile," also located at /Library/Preferences/Retrospect. Launch Retrospect and then immediately quit, which will force creation of a new copy of retrorunfile.
  8. OK, now in understand; thanks. Here are my thoughts: If you trash the [059] data before the [060] backup completes, you could end up in an unhappy place. On the other hand, because both backup sets reside on the same HD volume, you'll be in trouble in any case if the disk decides to fail. Personally, I'd be inclined to add another HD and alternate between the two volumes for my New Media backups because I always feel much better having more than one backup available. If you choose not to go this route, I think your proposal to trash just the data file will probably work. To confirm that, I would perform the following test: Create a new file backup set, back up some convenient amount of data to it, and manually separate the catalog and data files in Configure> Backup Sets if Retrospect hasn't already done so automatically. Then trash the data file and see what happens when you perform a manual New Media media action.
  9. I don't fully understand your question. Unlike all other types of backup sets, a File Backup doesn't have media members. It has to exist as a single data file plus a catalog file. The data file and its catalog need to reside together in the same folder (directory) on a single disk volume. If you want to be able to span multiple members, you need a different type of backup set: tape, CD, removable disk, etc. You can perform a New Media backup with a file backup set, which will do the following: 1. Create a new destination file and associated catalog with a subnumber appended to the backup set's name (i.e., [001], [002], etc.). 2. Seamlessly begin using the new file as a backup destination in your existing scripts in place of the old backup set, and 3. Preserve the backup data from your old backup set. It's pretty clear from your description that you did perform a New Media backup (or you manually did this in Configure> Backup Sets), and that you achieved the expected results. What's not clear is what you had hoped would happen. An alternative to a New Media backup is a Recycle backup, which will erase all your old data and use the existing backup set and catalog as a destination for your subsequent backups. Because this approach does erase all your old data, I wouldn't recommend it unless you have more than one backup set; otherwise, you'll have a period of time when you are without any backup. Not a good idea. If your issue is insufficient hard drive space, you could always wait awhile and then delete the old data file and its associated catalog. You can also move the data file (and its catalog) to another folder or disk volume, which will still give you the ability to access the data in the future (you will, of course, have to tell Retrospect the new location of the file at that time). You can move just the old data file if you want; however, you will not be able to access the data until the catalog has also been moved to the new location. Your post seems to suggest you may be backing up the volume on which the old data file resides. If this is your problem, it would be a simple issue to create a selector to exclude that file from your backups. An easy and flexible solution would be to create a new folder (call it "Old Backups," say), drag the old data and catalog files to this folder, and then write a selector to exclude the enclosing folder "Old Backups" from your backup script. You could also write a selector that would allow you to back up the old catalog while excluding the data file, but I don't see any particular advantage to this. If the data file is lost or damaged, the catalog file is useless by itself. (Having a backup copy of the catalog portion could speed up a catalog rebuild if you ever had to do that, but since you are no longer writing to the old data file, I can't see that a backup of its catalog would be particularly useful.) If the above is not helpful, please let us know more about your setup and what you are trying to achieve.
  10. You are almost certainly looking in the wrong place, because if that file and folder did not exist, Retrospect would create it when it was launched. (I suspect you are trying to find it in /Users/[your_username]/Library/Preferences/.) In Finder, highlight your boot hard drive volume. You should then see listed such folders as "Applications," "System," and "Users" in addition to "Library." It is this root-level Library folder that you want to look in.
  11. With a Removable Disk backup set, each disk volume becomes a sequentially-numbered "member" of the backup set. Retrospect will back up to the first member until it is full, then move on to the second member, etc. If the hardware is fine, you should have no trouble recovering the data stored on that volume. Retrospect definitely needs the catalog for your backup set. This catalog will have been stored somewhere other than on one of the HD volumes you are using as backup set members. Retrospect will not overwrite the catalog for the backup set unless you perform a Recycle Backup, or unless you recycle the catalog manually in Configure> Backup Sets. What you will need to do is tell Retrospect about the failed member. Go to Configure> Backup Sets> Configure [your_backup_set]> Members. Highlight the failed member and select "Set Missing." Then, the next time Retrospect performs a backup, it will back up anew those files that were on missing member #1, provided of course that those files still exist on your source volumes. As you've found out, backups are useful only to the extent that the backup media remains intact. Because all media will eventually fail (if at some point far in the future), it's important to perform backups to multiple backup sets so that you have redundant copies if/when a media member becomes unreadable. There are a number of strategies for doing this, some of which are discussed in the User's Guide. Let us know if you'd like some suggestions from this group as to what we're doing.
  12. A bit more information would be helpful. By "crash," what do you mean? That Retrospect quits unexpectedly or something else? You seem to imply that you are using File Backup Set(s) as destination(s). Is that correct? Do you have more than one destination backup set? Do the external drives each contain only one disk volume? Are the external volumes being used as sources, do they house the destination backup sets, or both? In order to create a Run Document, you must have written at least one backup script. Are you saying that if you choose to run that backup script immediately, it runs fine? If you have more than one backup script, can you successfully save a run document for any of them, or does it fail for all backup scripts? On which volume are you trying to save the run document?
  13. Or you might simply consider starting a New Media backup set if everything has been working well up to now.
  14. How did you determine that the volume had gotten corrupted? A Retrospect backup can give hard drives a real workout, and so can sometimes reveal a failing drive mechanism, weak power supply, etc., before other tests do so. You don't mention the brand of your drive. I do know that LaCie drives a few years ago were known for having flaky power supplies. If your unit has an outboard power supply brick, you might try a replacement. The fact that you're experiencing trouble with just one drive is pretty suggestive of a hardware problem. Big hard drives are pretty cheap these days, and at some point, it'd probably be worth your while to purchase a replacement rather than to spend a lot of time and effort in diagnosing the problem.
  15. Assert errors can also be caused by a corrupt Retro.Config file (located at /Library/Preferences/Retrospect). You might try this: With Retrospect not running, drag Retro.Config to the desktop. (Do this rather than trash the file, so that you can drag it back if it turns out not to be at fault.) Then relaunch Retrospect, which will force creation of a clean default Retro.Config, and see if you can get through a test backup without encountering the assert error. Retro.Config contains all your scripts and lists, so if it does turn out to be corrupt (and if you don't have a good backup copy), you will need to recreate all of those items from scratch. At least that would be easier than reformatting the whole drive.
  16. How much total data is there in your backup set? Retrospect 5.x had a limit of 1 TB for any backup set. I believe Retrospect 5.0 had a limit of 2 GB when backing up Windows clients, but your post suggests you are backing up only Macs. Retrospect 5.0 is pretty ancient, as Russ's answer implies. It was designed to run on OS 9.x or 10.1.x and may well not be happy under Tiger.
  17. Unfortunately, you have experienced one of the "features" of Retrospect 8: it won't read backup sets created by earlier versions. Stupid, yes; pathetic, yes; but unfortunately, true. You can download a copy of Retrospect 6.1 here but you'll need your license code. If you've lost the code, I would try calling EMC Customer Service to see if they have it on record. In the worst case, you may need to purchase a new copy of Retrospect 6.1 in order to recover your old data.
  18. The safest assumption would be that Retrospect did uncompress the files. Given the change in modification dates, there is evidence that that did indeed happen. If you experience any difficulties, I would recommend reinstalling the system software.
  19. What you're in effect asking is, can you use a HD volume as a member of a tape backup set. The answer is no. The media types are too different. To run your incremental backups to a HD, you would first need to perform a full backup to a file backup set on the HD volume, or to a removable disk backup set using that HD as the first member.
  20. Is it possible that you have inadvertently switched the keyboard layout from something other than the US layout? If you type into a document after the problem occurs, do you see any unexpected characters? If you log out rather than reboot, are you able to log back in using your usual password? If you can successfully log back in, can you then access Retrospect?
  21. Personally, I'd be pretty happy with 1.6 GB/min on a busy server. As for the total time, don't forget that Retrospect is actually making two passes on your data: once for backing up and the second for comparing the backup with the source. You could cut the time by not performing the comparison, but that's not something I'd advise.
  22. How did you update? Did you just drag the new Retrospect app and RDU to the folder where the old ones had resided, or did you perform an Uninstall first? The reason I'm asking has to do with the configuration file, Retro.Config. The evidence you present does suggest a problem with one of your HD volumes, as Lennart proposes. However, it could also be a problem with Retro.Config. If Disk Utility doesn't report any problems, or if the repairs don't resolve your issue, try this: 1. With Retrospect not running, go to /Library/Preferences/Retrospect and drag the existing Retro.Config file to the desktop (to save it in case you need to move it back). 2. Launch Retrospect. This will force creation of a new default Retro.Config file. You'll need to re-enter your license code, and any your scripts and lists you previously created will be gone. 3. Write a new backup server script that will be sufficient to test Retrospect's behavior and see if your problem goes away. Alternatively, if you have a backup copy of Retro.Config from a time well before the problem began to occur, you could try restoring it to a new folder on your boot volume (use Search for Files containing "Retro.Config") and then drag it to/Library/Preferences/Retrospect. If that solves your problem, you'll save yourself the trouble of recreating all your scripts and lists by hand if your tests show that the current Retro.Config is corrupt.
  23. Here's what we do: 1. Go to Configure> Backup Sets. Find the starting date and time for the member in question, and also for the following member (not necessary in your particular case, as you're looking at the last member). 2, Prepare to run an Immediate Backup, using Search for Files. Use as your search criterion the files between the two dates/times. This will find the files on the tape member in question, which you can view by clicking on "Preview." Kind of klunky, but we find it to be the best available approach, given the limitations of Retrospect. We have taken to writing the exact starting date/time on each tape's label to expedite the process.
  24. There is another solution that we use. The reason Retrospect is creating member "2-Backup Set 4" is because member "1-Backup Set 4" is full. Whenever a backup server script is running, Retrospect will try to rotate among the various destination backup sets and, having written to Backup Set 5 for awhile, it will prefer to write to another available backup set. One solution is to create member "2-Backup Set 4" yourself by running an immediate backup of a few files to Backup Set 4. Then remove member "2-Backup Set 4." The next time, Retrospect should create and write to "2-Backup Set 5" when there is blank media available (unless there is another backup set that is also waiting for a new member). Be aware that, under a backup server script, Retrospect will always choose on its own to name the next backup set member if there is more than one destination backup set awaiting a new member. If you wish to control exactly which backup set Retrospect is using at a given time, you may prefer to use a standard backup script rather than a backup server script.
  25. No, there is no comparison step after the transfer. Although the process should be pretty safe, I guess this really means we're trusting to luck. Only the catalog snapshots are copied. If you wanted older snapshots, you would first need to retrieve them from the backup media before performing the transfer. It means that only the snapshots already in the source backup set's catalog are copied to the destination backup set's catalog. Older snapshots on the source backup set's media will be lost. A backup "session" is the backup of a single source volume (or subvolume) at a particular time. If you go to Reports> Contents, you will see a listing of all the backup sessions for your backup set. "Merge sessions" means that the record of all those separate sessions would be lost. I think that could affect your ability to search for files by source volume; while I'm not absolutely sure about that, I personally wouldn't want to risk it. I would only use this option if I had only a single source volume. There should be no effect on the files actually being transferred There is an option for transferring only the most recent version of each file. This may be more in line with what you'd like to do.
×
×
  • Create New...