Jump to content

Don Lee

Members
  • Content count

    564
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by Don Lee

  1. I will likely move to v12. When I do, I'll keep trying it in a cautious way. With luck, I can figure out exactly what triggers it so it can be fixed. I see the "secret prefs" are available. I might be able to use those to ferret out some useful details. For that mater, I'm already set up in v 11.5.3. I'll keep futzing with that, too. I can't reliably reproduce it either. Every time I try to develop a "test case" it works flawlessly. Frustrating.
  2. I'm not clear on what's happening. "I did not see a single reference in the mail logs" ?? Does this mean that Retro did not (attempt to) connect, or is it that Retro did not connect with a SINGLE attempt (with AUTH)? The log excerpt above shows the un-AUTH v12 sequence, and only a smaller snippet of the AUTH (v11) snippet, without the preceding AUTH portion. That said, I have no idea what might be wrong. @bdunagan - The positioning of the checkbox, between the "requires AUTH" and the "supports SSL", especially on Mac, because it implies that the user/pass is an attribute of SSL, not of AUTH. I think the "supports SSL" should be first, and the "requires AUTH" should be second, next to the user/pass in the prefs. (or maybe after the user/pass, I suppose)
  3. Don Lee

    v12 Update Issue

    Sounds like the client is "stuck". When a client is already known to the engine, it doesn't show up in the "locate" window, and won't allow you to "add it" again. (it's already there!) so some of what you describe is sort-of normal. I have seen a problem in the past when I tried to re-register an existing machine, and retro got confused, knowing about a client, but refusing to use it. I would encourage un-installing the client, removing it from the sources, then re-installing and re-adding it. However, I'm not familiar with the mechanics of how the public keys work. (I don't use them) The un-install should be thorough. Make sure it's really gone. Re-boot the client after the un-install to make sure any stray processes die, too. You might even want to kill off the "retroclient state" file. I don't remember where it is on Windows, or what flavor un-install removes it, but removing it can ensure a "clean" un-install. There is probably a KB article about this...
  4. I'm not clear on exactly now this is all set up. It sounds like you have the engine on a machine on the local network, and (at least) 3 clients (as in client machines intended to be backed up). Some of these "client" machines also have the Retro console running on them, and the retro client can "see" the engine (server), but the retro consoles running on these same machines cannot see/resolve the server. Right? I would not try moving the engine. That will likely produce far more confusion than clarity. The engine initiates the connection to the clients to do its work. The Console initiates the connection to the engine to do its work. It sounds like there is something wrong in the DNS and/or networking in your installation. Is the engine on a machine that gets its IP from DHCP? The engine really needs a static IP. Is the DNS OK? Are you using "local" DNS on a 10.x.x.x or 192.168.x.x network? Sometimes this gets things confused. I would check to see if the backups are working. If so, then moving the engine is unlikely to solve anything. Next, I would recommend to delete and re-add the *engine* from one of the misbehaving consoles, and see if the console can "find" the engine. If not, there may be a firewall on the server/engine machine. (or on the client, for that matter) Try adding the engine by IP rather than DNS name. If the IP works, and the DNS does not, the DNS is your problem. Judging from what is written above, this feels like a netorking environment issue, but it's hard to tell.
  5. Does the "fast catalog rebuild" apply to "disk" sets as well - putting a copy of the catalog at the front of every "member"?
  6. Those who run their own mail servers should have access to the mail server logs and be able to be more detailed in what is going wrong. What, precisely, is retro doing in v12 that is different, and is failing? Is this a situation where v11 is falling back to un-authenticated? It may be taht the AUTH never worked, and v12 is just catching the error. It seems to me that there was something in the v12 release notes about this….
  7. What are the chances that this is fixed in v12? I don't see anything explicit in the release notes?
  8. I'm puzzled. Why would Retro refuse to do a backup because a rebuild was in progress? If the destination of the backup set is different from the media set that is being rebuilt, then I would not expect them to interfere with each other. Is Retrospect constrained to a single execution thread. (you can change that in prefs) Do tell...
  9. Another one failed, too. This is another of the few I set up with "test" settings to recycle the destination set, and recycle the source if successful. I include screen shots of the "bad" and "good" versions. "Good" is the "temp" copy I did without the recycles, and the "bad" is the result of the scheduled copy WITH the recycles, of the same source media set. Nothing touched the set between the two copies.
  10. I'm sorry to report that this is still broken in v 11.5.3 In last night's rotations, I had set up a fairly elaborate set of scripts to "catch" this problem without losing any of my data. The failure appeared in one of the rotations (so far - I have not yet checked them all) The copy op that I want is from v9_daily_EIMS to v9_daily_EIMS_last. I want the copy to happen, and if successful, recycle the v9_daily_EIMS set. What I have found is that if I check the "recycle source if successful" option, it will do a "short" copy, recycle the source, and report no error. What I did to catch this is to set up an extra copy, where I have a scheduled script that simply recycles a "temp" destination, then another script that copies v9_daily_EIMS to the temp set. I then set the "real" rotation script to do the copy to "last", and recycle v9_daily_EIMS. Below is the log from the copy to "temp", and also from the "real" (failed) copy. It should have copied some 9000 files, but only copied 380. This is with retro v 11.5.3. I hope this can be fixed. I have been working around it, but it's a pain to have to do the extra scripts and checking to make sure the rotation has not destroyed my backups. First the "good" copy. (note that there is no other activity on these sets between these scripts, though there is lots of activity on other sets) + Executing daily_EIMS_rotate_tmp_copy at 3/1/15 3:40:09 AM (Activity Thread 2) To Backup Set v9_daily_EIMS_tmp... - 3/1/15 3:40:10 AM: Transferring from v9_daily_eims 3/1/15 4:59:35 AM: Execution completed successfully Completed: 9,118 files, 169 GB Performance: 2,268 MB/minute Duration: 01:19:25 (00:03:06 idle/loading/preparing) - 3/1/15 4:59:35 AM: Verifying v9_daily_EIMS_tmp 3/1/15 5:30:41 AM: Execution completed successfully Completed: 9,118 files, 169 GB Performance: 5,856.1 MB/minute Duration: 00:31:06 (00:01:33 idle/loading/preparing) 3/1/15 5:30:41 AM: Script "daily_EIMS_rotate_tmp_copy" completed successfully Now the "failed" (short) copy op: + Executing daily_EIMS_rotate at 3/1/15 6:09:37 AM (Activity Thread 2) To Backup Set v9_daily_EIMS_last... 3/1/15 6:09:39 AM: Recycle backup: The Backup Set was reset - 3/1/15 6:09:40 AM: Transferring from v9_daily_eims 3/1/15 6:12:55 AM: Execution completed successfully Completed: 385 files, 9.3 GB Performance: 3,014.8 MB/minute Duration: 00:03:15 (00:00:04 idle/loading/preparing) - 3/1/15 6:12:55 AM: Verifying v9_daily_EIMS_last 3/1/15 6:12:55 AM: Execution completed successfully ! 3/1/15 6:12:55 AM: Recycle of Media Set v9_daily_eims 3/1/15 6:13:03 AM: v9_daily_eims was recycled 3/1/15 6:13:03 AM: Script "daily_EIMS_rotate" completed successfully A little speculation on my part: Where does Retro come up with the incorrect "385" file count? It so happens that the most recent two backups on the set have file counts that add up to 385 (screen shot enclosed) Thanks for your help,
  11. Let me take a crack at this. Your screenshot implies to me that something is not quite right. When I create a "disk" media set called "MEDIASET", it has a structure of and ENCLOSING folder containing a folder called Retrospect. I generally put the catalog file into ENCLOSING (though it can go elsewhere). "Retrospect" contains a folder called "MEDIASET". Inside MEDIASET is a folder for each member called "1-MEDIASET" and "2-MEDIASET", etc. When Retro wants me to "select" the member, I find that I have to select "ENCLOSING", NOT Retrospect, or MEDIASET, or "x-MEDIASET". This is unexpected, and worse, Retrospect is unhelpful with its error messages when you select the "wrong" folder, but that mostly works for me. Your screenshot is a puzzle. It contains disks named "1-DailyBackupV2", and "2-DailyBackupV2". If these are "members", they should be enclosed several levels of folder, as outlined above. If not, you can't select the corresponding "ENCLOSING" folder. I don't understand how you end up where you are, but from my experience, it looks like a dead end. I would create a folder on each drive, and select the folder to place the members. Retro should create a structure in the folder. If on the other hand, Retrospect has some sort of special handling for whole disks as members, that is beyond my experience.
  12. The following log is for a media set copy beetween FW disks. Log for Script: daily_user_rotate_last_tmp_copy Date: 2/1/2015 + Executing daily_user_rotate_last_tmp_copy at 2/1/2015 2:37 AM (Execution unit 2) To Backup Set v9_daily_user_last_tmp... - 2/1/2015 2:37:44 AM: Transferring from v9_daily_user_last !Bad Backup Set header found (0x044801bf at 1867514) 2/1/2015 3:37:41 AM: 1 execution errors Completed: 507563 files, 103.6 GB Performance: 1782.9 MB/minute Duration: 00:59:56 (00:00:29 idle/loading/preparing) - 2/1/2015 3:37:41 AM: Verifying v9_daily_user_last_tmp 2/1/2015 3:59:59 AM: Execution completed successfully Completed: 507563 files, 103.6 GB Performance: 4753.2 MB/minute Duration: 00:22:18 2/1/2015 4:00:03 AM: Script "daily_user_rotate_last_tmp_copy" completed with 1 errors I see no evidence that the "error" reported has caused any problems. The source verifies without error, and so does the copy. What, exactly, doe the error mean? Is this likely to be a transient error caused by the inherent less-than-perfect electronics and the enormous amount of data being transferred? Are the "headers" re-calculated" when the new file is written? If transient, when getting such an error, does Retro re-read the data to ensure that the subsequent read does not get the error? Do tell. I would like to know more about exactly what this error means. I do not want to lose confidence in the media sets with this error. OTOH, if this IS a real error, I want to re-do the operation and/or track it down. Thanks
  13. I sometimes find that I can't change a script. In this case, I had a script that was set up to copy the latest backups from my "old" set to the cumulative "2015" set. The schedule is to do this once every three months for archive purposes. The old script had the "2014" destination set, and all I wanted to do was change the destination to the "2015" set. I would open the script, click the new destination, set the schedule, and hit "save". It would revert to the old destination set. I tried this a bunch of times. It turns out that the schedule is irrelevant. I click on the new destination, hit save, and the destination reverts back. I tried stopping and re-starting both the console and the engine, and made sure nothing was running. I tried deleting and re-creating the destination media set (empty, as of today). The only thing I found that would allow me to change this script was to delete the script, and then re-add the script. THEN it would let me set the destination as I wished. I smell a bug, although I don't know how to reproduce it. I've seen this before, but I can't pick out the pattern (yet!)
  14. One possibly relevant circumstance is that the original script being modified may have been active copying backups while I tried to change the destination - intended to apply only to _future_ runs of the script. From what I've seen, it appears that Retro does not "run" a "copy" of a script, but runs the "original", and somehow locks it down to prevent problems with it changing while being run. This would explain a couple of my other reported bugs, and also this one. But, I don't know. I'm only guessing.
  15. Metadata is more than a hash of the data and the access time. Proper restoration of a filesystem includes the owner and group, the mode bits, the ACLs, and as Lennart points out, a few other things that change depending on the filesystem/mount point. (something I was not aware of) Retro is pretty good at this, and tries very hard to restore ALL the metadata. The downside is that the files appear to have changed, and get re-copied when some of this more obscure metadata changes.
  16. Don Lee

    Smart Incremental Backup Mystery

    This is core functionality, and has never failed me. I'm betting that the restore options/techniques being used are not the ones you want to get your files back where you want them. Retro has a number of options, and you have to use the right ones.
  17. Yes, you can do this. If the media set is a "disk" set, you have to locate the catalog, and then find the member(s). I hope there is only one. Locating the members is not intuitive. If there is a folder "backups" containing your "catalog_file", you need to select "backups" when telling Retro where it is. For the members, the same rule applies. If you put your members in the same directory as the catalog, as I do, you will have a "Retrospect" folder in "backups". Inside "Retrospect is a couple more levels of directories, but you should stay out of there. As far as Retro is concerned, the "members" are in "backups". In your case the members look like they are in "RAID". I have complained that this is not obvious, and that the feedback from Retro is poor (or missing), but this should allow you to "find" your media set. Remember that when you click on the catalog, Retro may have to read it, and that may take a while. (I think)
  18. I got an error on a restore today. The log: Log for Script: Restore Assistant - 1/17/15 12:15 AM... Date: 1/17/2015 + Executing Restore Assistant - 1/17/15 12:15 AM at 1/17/2015 12:17 AM (Execution unit 1) To volume Shared_Files2... - 1/17/2015 12:17:55 AM: Restoring from v9_SharedFiles, Snapshot root, 1/10/2015 1:01:06 AM FScSetWhichNodeInfo: USetWhichNodeInfo failed: -5000 1/17/2015 1:45:31 AM: Execution completed successfully Completed: 1018 files, 36.6 GB Performance: 428.6 MB/minute Duration: 01:27:35 (00:00:21 idle/loading/preparing) 1/17/2015 1:45:31 AM: Script "Restore Assistant - 1/17/15 12:15 AM..." completed successfully The restore seems to have worked, but the error message gives me the creeps. What operation failed? It would be nice to list which file/directory/operation actually failed. If it did fail, why does it say the script "completed successfully"? The the failure is irrelevant (script successful, right?) then why list it? Inquiring minds want to know. ;->
  19. or even all at the same time? Give them all the same thread if you want them to run one at a time.
  20. Don Lee

    More failures of console to update.

    For what it's worth, I have noticed a dramatic speedup in v 11 when dealing with remote engines over long-latency links, like when managing remote customer engines from my main office. The apparent optimizations often carry the risk of missing corner cases. I hope the "fix" to this doesn't take away the speed. If given the choice between having to restart the console from time to time versus the downright snappy response on remote connections, I'll take the speed any day of the week.
  21. Thanks for the note. I always add the backup volumes to the "privacy" pane in spotlight prefs, but this might be better yet. I'm on it.
  22. To complete the picture on the console and engine: The console machine is a Macbook Pro with 8 GB memory running 10.8.5. The machine with the engine is running on a Mac Mini with 16 GB of memory and Mac OS X 10.8.5 as well. Both console and engine are version 11.5.3 - latest released as of today.
  23. I had a couple of old scripts where the source and destinations had been deleted. I tried to copy and modify one of them, to add source and destination to use it. What I saw was really odd. The number of available backups for restore ops should be large (50+?). I saw 7. I looked at other restore scripts, and they all seemed to show just the same 7 restore options. (2 screenshots attached) I then tried to delete the script. The "really delete" dialog came up, but the script would not go away. I tried several times. I restarted the console, and the backups reappeared, and the scripts could be deleted. Bug. Not sure if I could reproduce it.
  24. I'm rolling this out carefully and gradually with my environments. I'll watch for it, and if I reproduce it, I'll take notes and report back. Happy new year!
  25. I just upgraded a client to 11.5, and none of the backups worked! After a bit of debugging, I figured out that the problem is that the path to the catalog and the members all contain the bullet (option-8) in the path. I moved the sets, updated the sets in the retro console, and it seems to work now. This was an upgrade from 10.5 to 11.5. This was working fine in 10.5, so the bug was introduced at 11.x version.
×