Jump to content

twickland

Members
  • Content count

    1,679
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. twickland

    Copy Rules Between Machines

    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.
  2. 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.
  3. 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.
  4. 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.)
  5. Have you tried stopping and restarting the Retrospect engine process? That will often get things back to normal.
  6. 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.
  7. twickland

    Compression question

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

    Compression question

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

    Compression question

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

    Compression question

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

    Retrospect Client Backup

    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?
  12. twickland

    Retrospect Client Backup

    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. "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. Have you purchased and installed the Windows Open File Backup add-on?
  15. 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.
  16. I'm not sure in what version the problem first appeared, but it is definitely present in v11.5.2. If one is creating a new Copy Backup script or modifying a script created in an earlier version, it is very difficult to change the source options. For example, the default option is "Copy most recent backups from each source." If one attempts to change this option to anything else (for example, "Copy backups from each selected source"), it will consistently revert back to the default option when the script is saved. If one fiddles with changing the source media set and the source options and attempts to save after each change, one can eventually get the options to stick. Unfortunately, this new configuration then becomes the default, and it is impossible to change the source media set and source options to anything else without some additional amount of fiddling and save attempts before the changes will eventually take. Furthermore, when browsing the source list for a given media set, the initial condition as to which sources appear as selected seems to be random. Most often, all of the sources appear as being selected. However, sometimes the source list for one media set will show the sources that were previously selected for a different media set, and sometimes the source list will have no sources selected. The worst case I've seen when clicking on "Browse..." is that the source list will seem to have no sources selected. Then, when clicking on the selection checkbox, a checkmark will briefly appear and then disappear. When in this state, highlighting the entire source list via one of the name columns will cause checkmarks to appear for all the sources, suggesting that the sources were always actually selected even when they appeared not to be. I haven't checked (and I don't have the time to explore) to see how the script actually behaves after I have gotten source changes to stick, so I don't know if the script changes that appear in the console will govern the actual copy operation. However, given the problems with Copy Backup and Copy Media Set scripts that iCompute has recently documented (http://forums.retrospect.com/index.php?/topic/150511-nasty-bug-scheduled-copy-media-set-only-copies-fraction-of-data/ and http://forums.retrospect.com/index.php?/topic/151499-copy-media-set-does-not-copy-old-backups/) the bizarre behavior I experienced in trying to edit Copy Backups scripts does not inspire confidence.
  17. 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.
  18. 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.
  19. 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.
  20. 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?
  21. 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.
  22. For those times when the graphic display is incorrect, have you tried quitting and relaunching the console to see if the display changes? I'm wondering whether the errors you see are a failure of the console to update properly with the latest data from the engine, which is a problem we frequently observe.
  23. RetroISA files are intended to keep track of the files that need backing up so that Retrospect doesn't need to take a lot of time scanning the source disk at the time of an actual backup. Unless you're talking about many hours to scan the source volume (and maybe even in that case as well), there is no reason they need to be included in Time Machine backups. Regarding Time Machine and Retrospect, you would need to determine whether you can foresee ever wanting to restore a file to a state that existed between Retrospect backups of your main HD volume, and what the consequences would be of not having a particular intermediate version of a file. If you decide that having that capability is not essential, or at least that it's not essential that you retain that capacity deep into the past, I would say there is no need to back up your Time Machine volume at all.
  24. We don't make a lot of use of the dashboard, but I can confirm that it does not always display correctly, in ways that are actually more extreme than what you have described. (See the attached screenshots for Retrospect 12.5.0 (111) running on OS 10.10.5.) The first screenshot was taken after the console had been up and running for several days; the second, a minute or two later, after the console was quit and relaunched: (The huge and incorrect total capacity figures listed for certain tape media sets is due to the lock-unlock ratcheting bug described here.)
  25. twickland

    multiple copy scripts

    Retrospect is not able to perform activities that require simultaneous access to the same source or destination; i.e., when it considers the source or destination to be "busy" or "in use." You can determine what Retrospect is thinking by going to the Activities window. If the script activity appears in the Waiting pane, you can highlight each activity to view exactly what it's waiting for. In your case, since the sources are different, the waiting is likely due to all scripts having the same destination. Have you tried defining different favorite folders on the destination volume and having each copy script copy to its own destination? I haven't tried that myself, but that approach would seem to have the best chance of success.
×