Jump to content

twickland

Members
  • Posts

    1,685
  • Joined

  • Last visited

  • Days Won

    39

Posts posted by twickland

  1. Since upgrading to Retrospect 13, I have twice had a script become stuck for hours or days while attempting to back up a client. (The two instances were with different clients.) When in this stuck state, I was unable to stop the script execution in the Activities window. It was still stuck a half hour after clicking on "Stop." I had to stop the Engine. Here are the activities window and the relevant log excerpt from that window:

     

    post-2992-0-11828900-1462897561_thumb.png

     

    post-2992-0-54907800-1462897688_thumb.png

     

    I suspect the problem occurred when the client computer was taken offline during the backup, and the disconnection was not handled gracefully. In recent versions before 13, Retrospect has in our experience appropriately logged this type of connection failure and moved on in the script.

     

    The following may or may not be relevant to the above issue:

     

    In today's failure, after I restarted the Engine, Retrospect began running a pending script. While this was running, I went to the Sources window and, as an experiment, clicked on the button to browse the particular source (Favorite Folder "Documents and Settings") that had been in the process of being backed up in the stuck script. A window immediately popped up saying that the source was busy (with no numerical error code), even though in actuality that computer was offline. I would instead have expected Retrospect to have attempted to connect for a good minute or so before putting up a -519 error window.

     

    Curious, I then added that "Documents and Settings" source to an immediate backup script and ran it, setting it to back up to a different destination from the other script that was running. The backup appeared in the Activities:Waiting window, saying it was waiting for "Documents and Settings." I then removed the activity, shortly after which the Engine crashed. This time, after the Engine was restarted and I attempted to browse the "Documents and Settings" source, Retrospect's behavior was exactly as expected for an offline source: the attempt to connect for a minute and then putting up the -519 error window.

    • Like 1
  2. 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?

  3. 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.

  4. hi there - can anyone tell me how to view the entire contents of a tape?

    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. 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.

  6. 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.)

  7. 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. 

  8. If I un-enable Allow Hardware Compression in the media set would the software compression work if I set it in the script?

     

    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.


  9. Normal backup using Monthly Full at 2/29/16, 8:00:00 PM (Activity Thread 1)
    To Backup Set M2T Feb 16...
    2/29/16 8:00:00 PM: Recycle backup: The Backup Set was reset
    - 2/29/16 8:00:00 PM: Copying Backup 2 Disk
    Using Instant Scan
    2/29/16 8:00:01 PM: Found: 3187 files, 5 folders, 1.8 TB
    2/29/16 8:00:01 PM: Finished matching
    2/29/16 8:00:01 PM: Copying: 3187 files (1.8 TB) and 0 hard links
    3/1/16 8:48:39 AM: Execution stopped by operator
    Remaining: 112 files, 62.6 GB
    Completed: 3,075 files, 1.8 TB
    Performance: 7,078 MB/minute
    Duration: 12:48:39 (08:29:07 idle/loading/preparing)

    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.

     

  10. It ejects the tape and wants another one for only 62GBs, this has happened on a used and brand new tape.

    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?

     

     

    I'm trying to avoid using the software compression, if this is truly all the tape will hold compressed by hardware then this is my only other option aside upgrading my tape drive to LTO 6

    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.

  11. 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.

  12. When i try to add Source Client I can see it in the list...

    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?

  13. Trying to retrieve files after an SSD died, but I get:

     

     + Executing Retrieve Backup at 15/02/2016, 5:41:37 PM (Activity Thread 1)

    From Backup Set SecuritySpy Backup...

    15/02/2016 5:41:53 PM: Execution completed successfully

    Completed: 1 files, 0 B

    Performance: 0 MB/minute

    Duration: 00:00:14

     

     

    "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.

  14. 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.

  15. 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.

  16. 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.

  17. 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.

×
×
  • Create New...