Jump to content

Don Lee

Members
  • Content count

    564
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by Don Lee

  1. For what it's worth, I have changed my scripts so that none of them uses the "recycle" option at start of the copy. Since this change, I no longer see the error on any of my rotations. This is strong evidence that the bug is not linked to recycling the source at completion time, but linked to the recycle operation at the start of the script. I plan to convert a few more scripts to operate this way - with a separate script doing the recycle op of the target, and enabling the "recycle source on completion" option. If this changed set of scripts continues to run error free, at least the option causing the problem will be clear. It's the "recycle target at start" op that somehow cripples the target of the copy.
  2. I noticed today something that I really like. I had to swap out a backup disk with a bunch of media sets on it. Several versions ago, when you did this, you would not only have to re-connect scripts to the new media sets, you would also have to carefully write down the scipt schedules, because the script schedules were somehow tied to the target media sets. Today, I re-connected the new media sets on the new disks to the existing scripts and the scheduling info was PERSERVED. Very nice. Thank you.
  3. I have seen this now several times, but I don't know how to reproduce it. It is with retro v 9.0.2 (107), both engine and console. Setup is the console running on Macbook Pro laptop running 10.5.8, and engine running on Mini with 10.6. The problem is that if I connect to more than one engine, if I leave the console open a while, the console will end up showing the wrong info in the various windows. For instance, if I look at the scripts, it will show scripts for both engines in the same window, as though it has merged the lists. Clicking on one of the scripts will show the wrong source and destination media sets/sources - again, with names that are consistent with being from the "other" (wrong) engine. I have been unwilling to "play with" the console in this state, being unsure what it might actually do to my backup data while obviously confused. I have not run v10 enough to see if this happens there, too.
  4. After reconnecting, I revisited the screen with the error, and it looks like this (looks correct)
  5. Sorry to say, it's BAAACCCCKKKKK! Screen shot enclosed. This screen shot is my console running on my laptop (with external screen) running X 10.8. Retro 12.5 I have two clients attached and active. Both are v 12.5 engines. I'm looking at the scripts panel, and looking at the sources tab. If you look in the list of Sources, you will see 4 sources that are correct for the engine called "BarryMini". The last one, "Witsend", is my laptop (?). Witsend also shows up in the list of sources of the "virtue" engine. Note in the second screen shot what SHOULD be displayed for the list of sources for "BarryMini"
  6. I this fixed in the 12.5 update? I recently updated, but have not "tried it" yet.
  7. FWIW, I upgraded the engine, console and client on the "problem machine" to 12.5.0.111 today. We'll see if it keeps failing.
  8. I have an odd problem with a Retro client. All Retro install is latest - 12.0.2 (116). Client OS is Mac OS X 10.7.x (up to date) The problem is that I have several volumes/favorites that I run on this client on a daily schedule, and at least once a week, the scripts do not run (they fail) with "client unavailable or un use" or this morning it was "client not found". These are transitory problems. By the time I get to chcking on this problem, the engine can "see" the client, and I can browse its filesystems from the console. There are no other scripts on that client that are not finishing or getting stuck. This is the only activity on this Retro client. I have tried twiddling options on the client, from the "sources" pane in the console. Noting that the options were all "turned off", I "turned them on" (Client can "turn off", "exclude itens", "stop running backups" ,etc) No difference. The latest thing I noticed is that the retro client control panel on the client says "Retrospect Client (32-bit)". This is a Core-2 DUO machine. It has 64-bit capability. Is this "32-bit" thing normal? It is the only Intel machine I have that shows this "title". Why do my backups fail randomly?
  9. Hit this again this morning, after a week or two of not seeing this. The log: (via copy/paste from console) + Normal backup using daily_mercy_nfs at 9/25/15 5:00:01 AM (Activity Thread 1) To Backup Set v9_daily_mercy_nfs... Can't access volume admin on Humor, error -505 (backup client reserved) Can't access volume conf on Humor, error -505 (backup client reserved) Can't access volume share on Humor, error -505 (backup client reserved) Can't access volume home on Humor, error -505 (backup client reserved) 9/25/15 5:00:03 AM: Execution incomplete timerCallBack: cancel email sending CFWriteStreamWriteFully: Timeout has occurred. E-mail notification failed: error -597 (mail server not found) I looked in the Retro logs for clues. In /var/log/retropds.log, I found this: 2015-09-24T05:00:37: FreeAsyncServ: elapsed=0s work=0s inQWait=0s outQWait=0s 2015-09-24T05:01:42: FscGetFSRef: FSMakeFSRefUnicode(/Volumes/Export_cs/home/user/www/stats/icompute/) failed, uni_name->length = 10, encoding = 0xffff, error 1 2015-09-24T05:01:45: FreeAsyncServ: elapsed=8s work=4s inQWait=6s outQWait=1s
  10. It would be really nice to be able to drop and re-add a client somehow without going back and re-adding the client to potentially multiple scripts. If a new client could be equated to an old one, or we could keep the old entry and "connect" it to a new client, I would have less hair pulled out.
  11. I had another incident with this problem this morning. I paste a copy of the log below. Note that the script backs up 4 volumes, and the first two failed, and the last two worked. Note also that there is an odd error message in the log (CFWriteStreamWriteFully - possibly irrelevant): + Normal backup using daily_mercy_nfs at 8/26/15 5:00:00 AM (Activity Thread 1) To Backup Set v9_daily_mercy_nfs... Can't access volume admin on Humor, error -505 (backup client reserved) timerCallBack: cancel email sending CFWriteStreamWriteFully: Timeout has occurred. E-mail notification failed: error -597 (mail server not found) Can't access volume conf on Humor, error -505 (backup client reserved) - 8/26/15 5:00:00 AM: Copying share on Humor 8/26/15 5:00:50 AM: Found: 1231 files, 84 folders, 28.1 MB 8/26/15 5:00:52 AM: Finished matching No files found for block level incremental backup. 8/26/15 5:00:52 AM: Copying: 0 files (0 and 0 hard links 8/26/15 5:00:54 AM: Building Snapshot... 8/26/15 5:00:55 AM: Checking 84 folders for ACLs or extended attributes 8/26/15 5:00:55 AM: Finished copying 0 folders with ACLs or extended attributes 8/26/15 5:00:55 AM: Copying Snapshot: 2 files (416 KB) 8/26/15 5:00:56 AM: Snapshot stored, 416 KB 8/26/15 5:00:57 AM: Execution completed successfully Duration: 00:00:57 (00:00:52 idle/loading/preparing) - 8/26/15 5:00:57 AM: Copying home on Humor 8/26/15 5:01:37 AM: Found: 127288 files, 15104 folders, 12.8 GB 8/26/15 5:01:39 AM: Finished matching Backing up 2 files using block level incremental backup. 8/26/15 5:01:45 AM: Copying: 1061 files (381.4 MB) and 0 hard links 8/26/15 5:01:57 AM: Building Snapshot... 8/26/15 5:01:57 AM: Checking 15,104 folders for ACLs or extended attributes 8/26/15 5:01:57 AM: Finished copying 0 folders with ACLs or extended attributes 8/26/15 5:01:58 AM: Copying Snapshot: 2 files (37 MB) 8/26/15 5:02:01 AM: Snapshot stored, 37 MB 8/26/15 5:02:02 AM: Execution completed successfully Completed: 1,061 files, 381.4 MB, with 75% compression Performance: 1,906.9 MB/minute Duration: 00:01:04 (00:00:52 idle/loading/preparing) - 8/26/15 5:02:03 AM: Verifying v9_daily_mercy_nfs 8/26/15 5:02:04 AM: Execution completed successfully Completed: 1,061 files, 381.4 MB Performance: 22,883.199 MB/minute Duration: 00:00:01 (00:00:01 idle/loading/preparing) 8/26/15 5:02:04 AM: Execution incomplete Total duration: 00:02:03 (00:01:46 idle/loading/preparing)
  12. I have also seen some odd behavior with duplicate names. In my case, it was setting favorites and being unable to navigate and select favorites in a duplicate file tree on another disk that was a near-duplicate. Unfortunately, my notes are not handy.
  13. I work pretty hard to make sure my backups run "clean", so I haven't seen any "long" logs lately. Sounds undesirable, if we can't see the whole log. Does cmd-L show full logs? If not, that's an issue.
  14. Thanks for the replies. The client has a static IP, and no firewall(s). Besides, if the port were not open, it would fail consistently. In my case, it fails about twice a week, on a daily script. The unique thing about this one is that the client is running Mac OS X 10.7, and the script is NOT pro-active. It is on a schedule, running every morning at 5 AM, and backs up 4 sub-volume "favorites". I'm about to set up a pro-active script that runs right after the current script, to make sure that the backup happens every day. (The current script runs at 5 AM. I'll do the "fallback" pro-active script by setting the permitted run-time to 5:30 AM-8 AM, and setting the backup interval to 23 hours. That way, I should get the pro-active to fire every morning at 5:30. If the regular script works, it won't do much.) I could also simply switch to the pro-active script, which judging from the other machines I have running without problem, but I think something's broken, and it would be much better to have it fixed.
  15. I hit this again on the Aug 1 rotation with v 12.0.2 (116) One of the three rotations failed. It was a "disk" to "file" copy op. This month I ran an experiment. Those 3 copy ops all had the "recycle target" option, but the "recycle source on completion" was *disabled*. September 1, I will try with a separate op to recycle the target before the copy starts, but turn on the "recycle source on success *enabled*, and see what happens. Given that I have quite a bit of experience doing these media set copies with the separate recycle op preceding the copy, and consider those copies completely reliable, it looks like the "recycle target" is the culprit. My Sept 1 rotations should confirm (and on Oct 1 as well, if it all runs without error)
  16. Don Lee

    MD5 digest calculated incorreectly??

    Example (from verify op): - 7/30/2015 4:15:18 PM: Verifying UserSet !Generated MD5 digest for file "/Volumes/BarryMiniHD/Users/barry/Library/Caches/TemporaryItems/dftmpIHPFNLBNnpnkkkkk--------" does not match stored MD5 digest. Completed: 118155 files, 24.7 GB Performance: 3669.9 MB/minute Duration: 00:07:30 (00:00:36 idle/loading/preparing)
  17. There is a long list of bugs fixed in Retro 12. I recommend upgrading. v12 runs on Mac OS X 10.6.8.
  18. FWIW, I have seen behavior on my tape drive (HP DDS drive) where certain operations cause the tape drive to go "catatonic" for several minutes. When I wait those 3-mumble minutes, the tape "re-appears" and all is well. I don't recall the details of this, whether restarting the engine and/or power cycling the drive made any difference, but as I recall, it appeared to be a problem with the driver/engine getting "stuck". The op I recall doing this was cleaning the drive. After a cleaning, the drive was unusable for those 3-mumble minutes. Try waiting. My notes here: http://forums.retrospect.com/index.php?/topic/147857-3-minute-delay-after-tape-drive-cleaning-console-hang/ Last I checked with newer versions of Retro, it still happened.
  19. The console displays event times in the local time of the console, not the time zone of the engine. I'm 2 time zones away today, and this threw me a bit. I think the times reported in the console should match the logs (which also are displayed), and be displayed in the timezone of the engine. One could argue that it should be as it is, but I think the time zone of the engine is more appropriate and consistent.
  20. I also see a similar problem, and it is a mystery to me, too. One of my clients backs up with a scheduled script every morning at 5 AM. About every 3-4 days, the script does not run with: + Normal backup using daily_nfs_bk at 6/18/15 6:00:01 AM (Activity Thread 1) To Backup Set v9_daily_nfs_bk... Can't access volume mercy_daily on Humor, error -505 (backup client reserved) Can't access volume smile_daily on Humor, error -505 (backup client reserved) 6/18/15 6:00:02 AM: Execution incomplete I don't reboot the client, or do anything else. I don't think I've ever seen it fail two days in a row, but I would certainly like to see this work more reliably. Server/Engine is retro 12.0.2 (116) on X 10.8.5. Client is Mac OS X 10.7.x (X client, latest) with Retro client 12.0.2 .116 Client is used as NFS server. It just sits there and serves NFS. A user is logged in all the time, and sleep is disabled.
  21. The "file" sets have advantages, but the "disk" sets do, too. The demands for "media" are probably caused by your setup. You are probably using disk sets, and not giving them enough space. Another possibility is that the volume you are using may be disappearing when you log out the user on the machine running the engine. That's a Mac thing, and it's a pain. If you mount an AFP disk, and then log out, the finder/OS unmounts i, and Retro can no longer use it. When responding to demands for more media, the Retro dialogs are not helpful. You would expect to be able to select the file it is naming, but that does NOT work. You usually have to select the top-level folder of the set - the one that contains the "Retrospect" folder instead. It's counterintuitive, and when you select the wrong thing, Retro is not helpful. It either gives odd errors, or worse - simply creates "orphan" member files. I recommend experimenting with small "favorites" and media sets, just to the experiments don't take a lot of time. I run everything unattended, and there should be little in your setup that should cause problems (I think) I'm surprised that support was not more helpful. Hope this is solved by now.
  22. More information is helpful if the lurkers on this forum are to be helpful. Have you run a check on the disk using Disk Utility to make sure the filesystem is OK? Have you posted the text of the log of the "stuck" operation? When you say the "data backs up fine", but the boot disk "just stops"… what does that mean, exactly. Do you get the spinning pizza and the machine freezes, or does the backup operation stop making progress once it starts on the boot disk? What phase of the backup is it in when it stops making progress? What have you done to "free up" that process? If you stop the "stuck' backup with the stop button from the console, does it stop, or do you have to restart the machine? Are you patient enough? Sometimes the scan phase can take a while (minutes+) Is it actually doing its job, but you're not giving it enough time? Many questions to be answered. This could be operator error, or a bad disk, or a Retro bug, but I'm betting one of the first two. More information would help to pinpoint your problem. Post more precise information about what hangs and how, and then add logs and screenshots for starters.
  23. This is a cosmetic problem, but should be noted and fixed. If you scroll the dashboard up and down lines appear at the bottom of the window. They are erased in a second or two. They appear to be an off-by-one error in the scrolling code. I include a couple of screen shots showing the problem. I'm running Retro 12.0.2.116, Mac OS X 10.8.5
  24. Works for me. Updated today. ???
  25. Depending on how many machines you are backing up, how important it is to do backups frequently, and other factors, the cost varies, and the importance of upgrading to get *correct* backups varies. I don't know how much upgrading to v12 will cost you (see above), but I can tell you that the list of improvements/fixes between Retro v8 and Retro v12 is very long. If you are backing up Mac OS X newer than 10.8, you are not even getting correct backups. In my opinion, a few hundred dollars for an upgrade is dirt cheap if you value your data and your time. You may have already burned more time keeping v8 running than it's worth. Even if you are evaluating other solutions, just getting today's backups to be correct would be well worth the cost. Buy yourself some time. Just my opinion. No, I don't work for Retrospect. ;->
×