Jump to content

twickland

Members
  • Posts

    1,685
  • Joined

  • Last visited

  • Days Won

    39

Posts posted by twickland

  1. Within the same execution of Retrospect, I do not know how to quit and relaunch the console (I suppose I could look it up). 

    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.

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

    • Like 1
  3. 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:

     

    post-2992-0-24726900-1448291907_thumb.png

     

    post-2992-0-34268600-1448292535_thumb.png

     

    (The huge  and incorrect total capacity figures listed for certain tape media sets is due to the lock-unlock ratcheting bug described here.)

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

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

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

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

    1. Create a new backup script to back up a small source to the desired media set (in your case, that would be "BIGBROTHERS2DISK").
    2. 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."
    3. 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.

  8. For testing purposes i have two backup scripts.

     

    The first script backups a particular folder on my local hard drive to the tape machine

    The second script backups a particular folder on my NAS to the tape machine

     

    So both are a manual selection

     

    When i click on the first script there is no rule selected

    When i click on the second script the rule "all files" is selected

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

  9. When i do a backup of a local folder and do a manual select, no rule is selected...

    That's because the manual selection you made is the rule you're using.

     

     

    I did a manual select of a folder when starting the backup but when i look at the script "all files" is selected.

    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?

  10. Ok... In my last post i said that data was copying from NAS to Tape...

    But the thing is that this time i only selected one folder on the NAS that was 5Gb.

    Nevertheless it started to copy the whole nas.. The whole 48Tb! No matter which folder i select, it copies all the files on the NAS... :(

    So instead of 5Gb, it copied 3Tb last night...

     

    The deselecting of the option "match source files against the Media Set" did help with copying actual data but now it copies everything instead of the "manual files selection"... :(

    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 i click on my script and then on "rules" i see this: (screenshot attached)

    Maybe that's not ok? How can i select only the manual file selection?

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

  11. The tape says (Empty)

    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.

  12. Here is (most likely) your problem, you have not (manually) selected any files

    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.

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

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

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

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

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

     

    post-2992-0-86217000-1441723434_thumb.png

  18. We have all of our Retrospect clients authenticated with passwords. Managing and securing the passwords is becoming a big task, so I am contemplating going to private/public key authentication. If I generate a key pair and start using it to add new clients, will this interfere with the existing clients using passwords?

    No, there will be no interference between the clients with different authentication methods.

     

     

     If I update a (passworded) client with a newer version, with the public_key in place for the client install, will the server switch to authentication with the key?

     

    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. Let me see if I'm understanding how this script scheduling works. Every X hours/days, Retrospect will check to see if the current time is between From and To. If it is (and if Allow Early Backup is unchecked, only if it is), Retrospect will initiate backup of the sources. If it is not, Retrospect will wait another X hours/days and check again.

    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.

     

    There could be a setting to either continue until the backup finishes or stop when the To time occurs. If this is not how it works and others agree, I'll send feedback to the company.

     

     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.

     

    I've now set the script to backup every hour every day at all times. 

     

    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.

     

     Unfortunately, since the media set is the same for all five sources, and Retrospect treats them as five separate backups, it doesn't seem to know how to run them in sequence. It initiates one and the others report that the media set is in use, and then that they will wait until the next backup.

     

    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.

×
×
  • Create New...