Jump to content

twickland

Members
  • Content count

    1,679
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. It sounds like what you want to do is to run a backup without actually backing anything up; i.e., you want Retrospect to scan the source(s), match to the catalogue, and then stop, while still reporting all of the matching results in the log. I can't think of any way to do that. One partial solution would be to run the script and not have the required tape member in the drive; the Activity window would report how much data was due to be backed up. Unfortunately, that would only be useful for the first source the script was accessing, as it would then stop until the correct media was inserted. We rely on past experience with each source as a general guide as to how much data is likely to be backed up.
  2. Selecting all three options should do what you want, since the duplicate files have different directory paths.
  3. That is the output you would expect if Retrospect engine was not actually running at the time you entered the unload command. (The command lines that fotmasta cites are the same in Yosemite.)
  4. Client version 12.5 still uses retroclient.state. It does take a short while after the client installation completes before the client preference pane indicates that the client is ready for login, but the file retroclient.state should be created immediately, even when the preference pane still indicates that the client is off. Are you using a keypair or password for client authentication? During the installation process, do you see the appropriate window (either notification of keypair use or request for password)? Have you successfully used this exact same client installer on any other computer? If not, it might be worthwhile to re-export the client installer, just in the unlikely case that something got corrupted during the original extraction.
  5. This sounds like a bug to me. It would be good to report it when you have a chance.
  6. The only way I can think of to stop the error messages would be to mark those first four members as being found (i.e., uncheck the "Lost" box). You could then do what would have been the best way for you to start a new media set: perform a New Media backup. Here's how we do this: Create a new backup script to back up a small source to the desired media set (in your case, that would be "BIGBROTHERS2DISK"). Add a scheduler for a single (non-repeating) backup to run sometime in the next few minutes, and choose the media option "Start new Media Set." When the script runs, it will create a new media set (in your case, it would be named "BIGBROTHERS2DISK [001]") and will ask you to select the first member and where you want the new catalog to be stored. The best thing about running a New Media backup is that it will automatically change all of your scripts that used to reference that old media set so that they now will reference the new media set. Because you have already started backing up to member 5 in your old media set, you would need to decide whether you want to retain any of that newly-backed up data. If you don't care, you could just mark member 5 as lost and erase and reuse the media. If you need to save the data that's on BIGBROTHERS2DISK member 5, you would first need to mark members 1–4 as lost, and then copy from BIGBROTHERS2DISK to BIGBROTHERS2DISK [001]. After doing this, you would mark member 5 as lost and uncheck the lost box for members 1–4.
  7. I'm confused. In your first post of October 20, the screenshot of the Backup Assistant window clearly shows that you have manually selected the folder DATA (10.0.0.110) on volume admin@10.0.0.110, which you've described as your NAS. Are you saying that after that Backup Assistant script ran and you examined that script in the Scripts window, the selection criteria differs, and now says "All Files?"
  8. That's because the manual selection you made is the rule you're using. This seems to contradict what you said earlier about making a manual selection of a folder on the NAS, and the related screenshot you attached. Has Retrospect's behavior now changed, or did you do something different with this latest backup?
  9. Well, that certainly isn't what should have occurred! There is clearly some weirdness going on with the communication between Retrospect and your NAS. We don't have a NAS, but other users have reported issues with Retrospect accessing certain brands of NAS devices. You may want to search the forum archives to see if others have had trouble with your particular NAS. Instead of selecting a particular folder in your backup script, you might try defining a "favorite folder" for this NAS in the Sources window and see if backing up just that favorite folder gives a different result. When you click on "Rules," you will only see those rules you have defined (in Preferences>Rules) or that are Retrospect's built-in rules. To perform a manual selection, you need to highlight the source and click on "Browse."
  10. That would indicate that the last time the tape drive communicated to Retrospect, it reported that the drive was empty (no tape inserted). Turning the tape drive off and back on, and/or stopping/restarting the Retrospect engine, will often reestablish communication between Retrospect and the tape drive. If those fail, you may need to reboot the backup computer.
  11. In my experience, you cannot see the "manual selection" option unless you browse the source and select at least one file. Wimgrandia says he/she manually selected a large folder. The script performed a matching operation and then backed up 0 files. This should be the case only if all the files in the selected folder had previously been backed up. I wonder what would happen if you deselect the backup matching options. Try that and see if you get a different result.
  12. There are two issues here. I wouldn't worry about the listed capacity of the media set. That figure is only an estimated one, and Retrospect does not do a particularly good job of predicting total capacity for tape media sets. The true capacity of a tape varies depending on a lot of factors, including the amount of data compression, the rate in which data is suppled, etc. What's important is that Retrospect will use each tape member until it is actually full. The fact that no data was backed up, and that it took essentially no time to match the data, indicates that something must be wrong with the selection criteria you used in your backup script. (The results look essentially like the selection rule was "No Files.") Can you post a screenshot of the actual rule that you used?
  13. It's not a good idea to create a second media set with the same name as an existing media set. To do that, you must have stored those media sets' catalogs in different locations. Even so, I'm surprised that Retrospect was able to copy data from one same-named set to the other (though I must say I haven't ever tried that). The normal procedure to use when you need a new media set but want to continue to use your existing script(s) is to run a backup script with the media action set to create a new media set. In your case, performing such a new media backup would have created the media set LabDataB2 [001], after which all of the scheduled events in all of your scripts that pointed to LabDataB2 would automatically begin pointing to LabDataB2 [001]. To get to where I think you want to end up, this is still the way I would go. I would actually write a new script with a single small source, backing up to LabDataB2 with the media action set to "start new Media Set." After that script ran, you would then perform a copy media set from LabDataB2 to LabDataB2 [001], which would take care of everything in the most-recently active set LabDataB2. You would then need to deal with the data in the buried media set. The way to do that would be to remove LabDataB2 from the media sets list, and then click on "Locate" and navigate to the location where the catalog for the buried LabDataB2 is stored. If that catalog is unavailable, you would need to re-create it from the media. Once you've found the catalog for this data, you would run your copy media set script again, copying from buried LabDataB2 to LabDataB2 [001].
  14. Please supply a bit more information. It's not completely clear exactly what you did. It appears likely that you were attempting to copy from some other media set on a different hard drive volume to media set LabDataB2; is that correct? If so, does the 543 GB in the lowest-level Retrospect, LabDataB2 and 1-LabDataB2 folders accurately reflect what was in the source media set, plus what was recently backed up to LabDataB2? (That would confirm that the "buried" version of media set LabDataB2 is what Retrospect considers the proper version.) Do you want to save the recently backed up data to LabDataB2? Also, the top level Retrospect folder displays as containing 1.55 TB while the top level LabDataB2 folder shows only 1.38 TB. Is there another media set in the top level Retrospect folder? If not, what are those extra files?
  15. From your last screenshot, it appears that this unit is a tape library, correct? If it is, you should see the library and the drive as separate devices. However, I notice that, per your screenshots, neither device shows as a target device in the MacOS system report, nor do they show in the ATTO Config Tool, which would indicate that the ATTO HBA card is not seeing your tape drive or library. I notice too that you have the RAID version of the 680 HBA, which uses different drivers and firmware than their standard 680 HBA. I would reconfirm that you have installed the correct driver for your card and that you are running the latest version of the ATTO Config Tool. I would then update the flash for the ATTO card. You might also try updating the firmware for your tape library, if it's not at the current version. (By the way, I wouldn't count on Retrospect, Inc's testing old versions of Retrospect to confirm that they will run properly on whatever is the latest MacOS version.)
  16. twickland

    MOVE a 9.0.2 installation ...

    The folder you want is the root folder /LIBRARY/Application Support/Retrospect, not the user folder ~/LIBRARY/Application Support/Retrospect.
  17. If you go to the Members tab for Media Set Blue and click on the edit pencil, what information does Retrospect display regarding the allowed percentage and capacity of the destination volume? If less than 100%, you can change that figure. While you're at it, note whether the total allowed capacity differs from the Space Total displayed for that media member, and/or for the media set as a whole (assuming that the set has only one member)? We have found that the total capacity for a media set member that's displayed in the console can be obviously incorrect, as in the screenshot below for a 4 TB member. We've also observed that the allowed capacity displayed in the edit window can differ from the displayed total capacity for a single-member media set. I'm not sure what all this means, but the variation does not inspire confidence.
  18. No, there will be no interference between the clients with different authentication methods. You can't just update the client. You would need to uninstall the old client software on the client machine and then install the new client version. For Mac clients, after you run the uninstall script, be sure that the file retroclient.state no longer exists at /Library/Preferences; if it does, trash it before installing the new client software.
  19. If the leader pin is damaged, the cartridge is presumably not usable as is. Seems to me you have nothing to lose by attempting to fix it. Are you sure that the pin is actually damaged? We have dropped a few LTO cartridges in our time, which has resulted in the pin being dislodged and jamming. By carefully loosening the case screws, we were able to get the pin back in its proper place so we could continue to use the cartridge. Good luck.
  20. No, that is exactly backwards. Retrospect will check the source during the time window between From and To. If the source is available, and if X hours/days have elapsed since the last backup, Retrospect will initiate a new backup of the source. In other words, the X hours/days setting determines how frequently the backups will occur. The From/To settings determine only when the backups are permitted to run. If you don't care when a backup actually runs, you should set the From/To schedule to allow backups at any time, as you have done in your screenshot above. That would be a nice feature, and it used to be included in Retrospect 6 and earlier. Since Retrospect 8, when the To time is reached, any backup that is running will simply terminate. What should happen with this setting is that Retrospect should attempt to perform 24 backups of each source every day (i.e., once every hour). In practice, this will not actually happen unless the total backup time required for all sources is less than an hour, but you get the idea. I suspect this is not what you want. With a proactive backup, you don't get to tell Retrospect in what order the sources will be backed up. However, each source will be backed up in turn, and will not have to wait until the next backup interval. To see when the next backup of a particular source is scheduled to occur, go to the Activities> Proactive window. If a scheduled backup time has passed and if the proactive script is active but the source is not eventually backed up, that would indicate a problem. It's most likely to be corruption in the Config80.dat file, located at Library/Application\ Support/Retrospect, but it might also be an issue with the Retrospect Engine process. If you don't have a recent good backup of Config80.dat, I would first try reinstalling the engine, since starting with a clean Config80.dat would require you to manually recreate all your scripts, custom rules, and source lists.
  21. I note that all four volumes are on the same client. I'm wondering whether the client reserved messages for "admin" and "conf" are being caused because Retrospect is already in process of backing up "share." Note that according to the log, the script launched at 5:00:00 and the backup of "share" also began at 5:00:00. If that's the case, this would seem to be a bug.
  22. That would indicate that the "Back up every X hours/days" interval is either set too long or is not being properly recognized. If the repeat interval is indeed set to what you want (we use 20 hours as the interval for daily backups), that would suggest that the script has somehow gotten corrupted. We have a schedule of allowed operation for all of our proactive scripts, and they all run just fine within the set time windows.
  23. If you were prompted to install the engine, that should do it. The alternative is to go to Retrospect's preferences, select the Console tab, and export and run the server installer. Did reinstalling the engine have any effect?
  24. I recently discovered that there is nothing to prevent Retrospect from backing up a media set to itself! I was creating a test backup script and inadvertently selected as a source the volume that contained the destination media set. When the script ran, it dutifully began copying the various .rdb files belonging to the media set into new .rdb files in the same media set. It seems pretty obvious that this process would continue until manually stopped or until all available blank media was filled. It would seem to be a good idea to have Retrospect perform a check to ensure that this kind of loop cannot occur.
  25. You will need to create four schedulers, each one repeating at 4 week intervals, which is the full length of the cycle you are proposing. As an example, scheduler 1 could back up to media set A beginning on August 9; scheduler 2 would then back up to media set A beginning on August 16; scheduler 3 would back up to media set B beginning on August 23; and scheduler 4 would back up to media set B beginning on August 30. With a four week repeat interval, scheduler 1 would then back up for the week beginning September 6, and so on.
×