Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by twickland

  1. The error message makes it pretty clear that there's a problem with the tape drive or somewhere in the SAS chain (cable or HBA card). I'm not sure what that message about the storage device not being licensed, though; I've never seen that. Is this the same tape drive you were previously using? Has that message ever appeared before?
  2. How did you perform the catalogue rebuild? Did you use Fast Catalogue Rebuild, where all you need to do is insert the last tape member? (You would have needed to have set up the media set in advance to take advantage of this option.) What Retrospect version was the original catalogue created in? Why were you trying to rebuild the catalogue for the "newest" version? Did this member (#17) appear to have contents when listed in the applicable earlier version? (And BTW, member #16 seems unusually small compared to the adjacent tapes.) I would first confirm that there are no problems in communication between the Retrospect Engine and the Console. Try stopping and restarting the Engine to see if the listing changes. I would then perform a new catalogue rebuild using just member #17 (or perhaps #16 as well). Before you do so, drag the existing catalogue to the desktop so you don't overwrite it, and also have Retrospect forget the media set by clicking "Remove" in the media sets window. If these tapes still show small or zero contents, that would suggest that something is wrong with the tapes themselves, I don't know any way for Retrospect to rescan an earlier tape member that it already knows about. If there is actual contents on that tape member, I think you will need to rebuild the entire catalogue. If you did use Fast Catalogue Rebuild, I would try performing the rebuild with an earlier member than you used before, and then perform a catalogue repair to add the subsequent members.
  3. I can confirm that this problem still exists in Retrospect 13.0.0.
  4. Do you mean the contents of a single tape that's a member of a multi-tape backup set? If so, the best way to do that is to search for all files with a backup date and time between the time that the tape was first written to and the time it was last written to. Unfortunately, that's easier said than done, as Retrospect does not make a tape member's date/time information accessible, even though it knows it. What we did (and still do) is label each tape with the date and time it was first written to. Luckily, there is a workaround. Mark all members of the backup set other than the one you want to view as "Missing." Then, prepare to run a restore, searching the backup set using the selector "All Files." (Afterwards, you can set all the members as "Found.")
  5. Rules, along with source lists, scripts, etc., are stored in the file Config80.dat, located at /Library/Application Support/Retrospect, which can be copied to your new machine. Take a look at the section of the User's Guide titled "Moving Retrospect" for more details on what you will need to do.
  6. Actually, I think I was too quick. I had been looking at fix #5044, but I now believe that was referring to the files that were backed up on the date that backup snapshot was made, and not to the file listing within the snapshot. We haven't experienced the issue that you and Ernst Mulder reported, where files that were actually backed up do not properly appear in the backup snapshot. (FWIW, I notice in the latest email advert about Retrospect 13 that they're using a positive quote from Ernst.) Though you should presumably be able to restore the missing files by searching for them individually, needing to do that would undercut one of the main selling points that Retrospect uses: the ability to perform simple point in time restores, even with deduplication.
  7. No, it isn't what's supposed to happen. In looking at the release notes, it looks like this snapshot bug was addressed in version 12.0.
  8. With all you have tried, it sounds like the likely culprit is a corrupt configuration file, Config80.dat, located at /Library/Application Support/Retrospect. You can test this by quitting the Retrospect console app, stopping Retrospect engine, dragging both Config80.dat and Config80.bak to the desktop, and restarting the engine/relaunching the console. If your problem has now gone away, you can confirm that your original Config.80 is the source of the trouble by replacing the new Config.80 with the original file and seeing if the problem comes back. Unfortunately, if Config.80 is corrupt and you don't have a good backup of that file, you will need to recreate all your scripts, lists, custom rules, etc. from scratch. (Many of us have long wished that Retrospect housed all of these items in separate files so that corruption in one area didn't ruin everything.)
  9. Have you tried stopping and restarting the Retrospect engine process? That will often get things back to normal.
  10. How are you attempting to perform the restore? If you are doing a "search for files" type and searching by a volume or host location, Retrospect will only show the location from where the file was originally backed up. In your case, you will want to use either of the two options that begin with the word "Restore," where you have to select a point-in-time snapshot before proceeding. If you are doing the latter and you still can't see the files you want, you should check the rule you're using in your backup script to be sure that you aren't inadvertently excluding some files from the backup.
  11. I don't know of a way to disable hardware compression for an existing media set. You need to deselect that option when the media set is first created. Hardware compression is certainly faster and probably also more efficient than Retrospect's software compression. I wouldn't recommend going that route, but you could experiment with a new tape media set and see if you're happy with the result. We use LTO-5 tapes, and typically get between 1.6 TB and 2.3 TB per tape, depending on what kinds of files are being backed up.
  12. I misunderstood your second question. I thought you were saying that Retrospect was asking for a third tape after backing up only 62 GB to tape #2. Backing up "only" 1.8 TB to an LTO-5 tape is a pretty normal result. If you need more capacity per tape, you will need to move to LTO-6 or LTO-7. If you simply need more capacity per backup and want it to be able to complete without user intervention, you might want to consider a tape library.
  13. That suggests a problem with your tape drive, or that something went wrong during the most recent backup to the media set in question. Do you see any errors in the operations log? All LTO drives that I am aware of have hardware compression. Software compression is disabled when backing up to a device that supports hardware compression.
  14. Tape capacities can only be estimated until the tape is actually full. The native capacity of an LTO-5 tape is 1.5 TB. The advertised capacity of 2.9 or 3 TB assumes 50% compression. If the files you're backing up can't be compressed that much, you will get less data on the tape. Also, backing up lots of small files will waste some tape, as the tape drive is less efficient when it has to shuttle back and forth between writing and reading. Retrospect will write to the tape until the drive reports that the tape is full. 1.8 TB is not an unreasonable total to expect when backing up relatively uncompressible files. If Retrospect asks for a new tape after backing up an unexpectedly small amount of data (i.e., less than the native capacity), that can indicate that the tape drive has encountered a problem writing to the tape.
  15. What OS version is running on the client computer? What are the firewall settings? When you open the client preference pane, what status does it report? Have you tried uninstalling and reinstalling the Retrospect client software?
  16. Which list? The list of Sources or in the Add Source drop-down window? If it is on the Sources list, try deleting the source and then adding it back. If you mean the Add Source window, be sure that the client computer is awake and on the network at the time you are trying to add it. Which method are you using to try and access the client? Multicast, subnet broadcast, or adding directly?
  17. "Retrieve Backup" means that you chose to select a previous snapshot for a source volume, rather than the most recent snapshot, in preparation for restoring the files. To actually get the files back, you need to run a Restore operation, presumably using the backup snapshot you just retrieved.
  18. The security parameters for a media set are set up when the media set is first created. Other than deciding when or whether Retrospect will remember the password, you can't change the security features later.
  19. You will definitely want to save your media set catalogs. The catalogs should not be affected when you run the uninstaller, but to be absolutely safe, you could also drag the catalog folder to the desktop. (The default location for this folder is also in /Library/Application Support/Retrospect.) One thing I hadn't thought of: there is also a user preference file for the Retrospect console, which is located in your user library at ~/Library/Preferences/com.retrospect.Retrospect.plist. I'm not aware of this file causing problems, but it couldn't hurt to trash this file (when the console isn't running) and see if that makes any difference.
  20. Can we assume that you've tried rebooting your iMac? If that hasn't helped, try this: Quit the Retrospect console app and stop Retrospect engine in System Preferences. Then, drag the files Config80.dat and Config80.bak from /Library/Application Support/Retrospect to the desktop. Restart Retrospect engine and launch the Retrospect console app (you'll need to reenter your license code). If things are fixed, that would mean that your old Config80 is corrupt. Unless you have a good backup copy of Config80.dat, you'll need to recreate all your scripts and lists from scratch. If the problem still exists, run the Retrospect uninstaller and then reinstall Retrospect. If all goes well, you may then be able to move your old Config80 files back to /Library/Application Support/Retrospect. By the way, unless you are backing up this iMac from another machine, there is no need to run Retrospect Client. Although it's unlikely to be causing problems, you may just want to uninstall it.
  21. Trying to back up many TB using a relatively slow computer with only 4 GB of RAM that's also doing video processing at the same time seems like a recipe for trouble. It sounds like what you're doing is restoring data from LTO-3 tapes to a hard drive volume, and then backing up that restored data to LTO-6 tapes. Is that correct? If so, how are you backing up the hard drive volume: via Retrospect client, or by connecting the hard drive directly to the Mac Mini? That approach seems unnecessarily complex and time-consuming. A better approach would seem to be transferring data directly from your LTO-3 media set to the LTO-6 media set, which would require connecting the LTO-6 drive to your Mac Pro. You say you can't do that, which leads to two more questions: Assuming that your colleague's Mini isn't going to be the permanent backup computer, how and to what machine is the LTO-6 drive going to be connected in the future? The second question is, what kind of LTO-6 drive are you using that only has a built-in Thunderbolt link? All such external drives that I'm aware of have either FC or SAS, and would require an adapter for Thunderbolt. Finally, regarding your screenshot, was that made while the stalled backup and the video processing were both running? Although the memory pressure indication would still be valid, the Retrospect console app is not what you want to be looking at; it's Retrospect Engine, which is a root, not a user, process.
  22. The past several times I've performed Apple software updates that require a reboot, the Retrospect 12.5 engine has come back up in a condition that is not fully operational. The problems have typically included absent data for one or more media sets and a failure to recognize the correct tape in our LTO drive. Stopping and restarting the engine has always fixed these problems, but I have to remember to do this, or scheduled backups will not be performed. I've encountered this problem only after restarts that are part of updates made via the App Store; if I manually reboot, Retrospect engine always seems to launch and behave properly.
  23. Does the Operations Log for that particular backup also indicate a percentage of compression? Is there any possibility that that backup was performed by a different script?
  24. The Retrospect app is the console. The console is only a user interface to the Retrospect Engine process; the Engine is what actually performs the backups, and is started and stopped via a preference pane in System Preferences. You can quit and relaunch the console app at any time without affecting backups or other activities. The fact that you are rebooting daily is likely avoiding the issues we see where the console miscommunicates with the engine, which typically appear in our case only after the console has been up and running for several days.
  • Create New...