Jump to content

henry-in-florida

Members
  • Content count

    122
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by henry-in-florida

  1. In Mojave, using the new client, the icon no longer appears by default. Clicking the checkbox on or off accomplishes nothing on the menu bar.
  2. Web page seems wrong KB page describing full disk accesses in Mojave 10.14 . States that the app (note that apps only are allowed). The article states, "Client: Please add /Library/PreferencePanes/Retrospect Client." The screenshot has others shown... What's the right story and where do we find the described file(s)? Hint: not where it's stated or shown! Oh, by the way how to install Instant Scan?
  3. henry-in-florida

    Full Access Mojave

    Nige, Yep. Sorry I just posted a section of my window for you. It's the same. I had other stuff enabled. My client(s) are OK for awhile. One is running now with out an error. I have had clients that show up a -519 communications error where I've had to delete and re-add the client for unexplained reasons, however.
  4. henry-in-florida

    No more instant scan on MacOS?

    I got that feedback from support recently as well and reported it in another post here. Frankly, when using SSD's in clients, I don't see a huge advantage to ISA. Whether in incremental or full backup. It is a CPU hog and space hog. Maybe also duplicates processes already in place (in the case of APFS). I will compare again in 15.6 with ISA disabled to confirm this. Once turned off, intend to leave it that way. Locally, on HFS+ formatted (HDD) drives, maybe some advantage, but since the server does its thing quicker locally and is essentially unattended, I don't care too much. My 2¢... Henry
  5. henry-in-florida

    Full Access Mojave

    Just went to do the update. Found two issues with it. While available from the Retrospect.com web site, there is no update notice in the old app download a new update. While the text in the new KB version is correct but the screen shot for the Client install in Privacy settings is incorrect. It should look like mine not theirs. I previously reported issues like this and Lo! Still a small issue on the new one... FYI...
  6. henry-in-florida

    Full Access Mojave

    David, Thanks for that info. Not quite what I was told but similar and seems to be the ultimate fix. Will try it soon. There have been a lot of interesting followups to my post. Thanks, all! I hope that Retrospect people were likewise entertained.
  7. henry-in-florida

    Full Access Mojave

    Well, I heard from Retro Support that Instant Scan will be going away. And as some have said on this thread, there is a new client coming that will fix the issue, not waiting for Apple to do anything further. At least that's the gist of my understanding from the conversation I had with support. Since then, I did work around the exclusions for now and have my client running w/o the exceptions, on Mojave. But no Instant Scan. They say that the speed issues have been worked around and will be completed without the need for Instant Scan functionality, which I never really liked anyway (CPU hog, among other issues). Henry
  8. Certain partitions fail on clients with two different, strange errors: On an APFS formatted volume (internal SSD) on MacBook Pro 2017 backing up the entire drive. On MacOS Journaled drive, network timeouts occur in accessing the source. The ONLY [systems Preferences>Energy Saver>Power Adapter [Energy Settings] settings that work for me are shown. Unchecking "Prevent computer from sleeping," will result in these timeouts. I don't see where that's clear in your manual or other instructions. Seems that this condition used to be known as "deep sleep". I haven't had that issue in MacOS before 13.x not in Retro before 14.5 (do not know or have any ideas as to which version of OS or your software causes this, do you?). See the attached picture/screen shot. As to item # 1, here is log pertaining to this event. Using Instant Scan data for RAID 4 SSD on MyNewGenie_MBP 10/3/17 03:00:35: Found: 363376 files, 201365 folders, 1.1 TB 10/3/17 03:00:41: Finished matching 10/3/17 03:00:59: Copying: 743 files (2.5 GB) and 0 hard links [*] soccRecv: recv failed, error 60 !Trouble reading files, error -559 (network connection timeout) 10/3/17 03:02:55: Execution incomplete Remaining: 695 files, 1.7 GB Completed: 48 files, 818.3 MB Performance: 416 MB/minute Duration: 00:02:54 (00:00:56 idle/loading/preparing) As to item # 2, here is log pertaining to this event. - 10/2/17 07:14:44: Copying VM on MyNewGenie_MBP Scanning incomplete, error -1,101 (file/directory not found) 10/2/17 07:14:58: Execution incomplete Total performance: 705 MB/minute Total duration: 00:50:09 (00:15:00 idle/loading/preparing)
  9. With a MacOS Client (See MBP2017 information below, I am receiving error timeouts accessing the backup client times out during the scanning cycle. Also, separately getting errors when backing the APFS volume partition VM (unable to back up that partition (claims a virus error code on that partition, if selected to backup). It seems like this only occurs with this machine and may have something to do with APFS volumes compatibility. Retro_Errors.rtfd.zip
  10. My client didn't run automatically because for some unknown reason, the Multi-cast shows as the port turned off after a normal restart and could not be re-enabled manually from the client's preferences. I had to do one of the following (chose the first one) to manually run a backup. Seems to happen whenever this laptop is taken away from the port used in a fixed set up on my LAN: Direct access entry port assignment instead of Multi-cast. Uninstall client and reinstall thereby re-opening the port. Remove the client at the engine or Retro Server and reinstall it there. I cannot see a way to troubleshoot the cause further. If anyone has ideas on this forum, please advise. I consider the above no more than work-arounds to the actual problem. I believe this problem goes back a long, long while. However this is the first time it has reared it's ugly head in a while.
  11. I have a client that regularly gives me error code -530, backup client not found. It seems what is actually meant is that there is trouble with the media, I'm presuming. Here's why, the log. Please advise if that's what it means and if this loss of backup functionality error - 530, has other possible causes. When I restore the client (remove and reinstall) it works for awhile, then fails again. It seems from the log entry that this refers, not to the client but to the backup media. Isn't this a bit confusing? I know that it confused me. 11/8/15 15:08:50: Execution completed successfully + Normal backup using Daily JaneMac [iMac] at 11/8/15, 15:08:55 (Activity Thread 1) To Backup Set iMac Backup... Can't access backup client apple’s iMac, error -530 (backup client not found) 11/8/15 15:11:22: Execution incomplete IFaceIPUpdate: gethostbyname error 1, (Authoritative Answer Host not found), hostname = ML-server.private IFaceIPUpdate: gethostbyname error 1, (Authoritative Answer Host not found), hostname = ML-server.private As to the media not being available... Seems OK to me. Tried a repair and got the following... + Executing Rebuild at 11/8/15, 16:40:13 (Activity Thread 1) To Backup Set iMac Backup... Scanned /Volumes/LaCie Backup 9-1/Retrospect/iMac Backup/1-iMac Backup up to backup set data file index 893 11/8/15 16:40:20: Finished scanning backup set data files Adding to 479.9 GB of backup set data, starting at file index 894 11/8/15 16:40:21: Execution completed successfully Duration: 00:00:06 Repairing the database of the drive as above resolved the problem temporarily. Will it hold? It hasn't in the past. Is there something I can do?
  12. I get 'MD 5' errors in backups, verify and most recently in restore. You can see in this thread that I'm not the only one, seems to occur in various platforms of Retro and with several different types of files. I can pin down the history on this particular occurrence since it was a recent failure and was noted in subsequent backup from a newly started (recycled) backup through the next incremental backup and lastly with a restore of that backup to a working drive. See the long standing thread comments from others and myself in context here: http://forums.retrospect.com/index.php?/topic/151903-md5-digest-calculated-incorreectly/ I have not yet verified the specific files with errors listed to see if somehow the files are OK. Suppose it's possible that the files are OK and that this 'error' is really a warning that the files were being modified when the backup was running (hence not the most current version). However that is not my understanding of what the MD5 error means. Which is the last point. If that is indeed the case and the error codes prove inconsequential to the quality of the files recovered then at least, the error codes and their meanings posted elsewhere are BADLY outdated. At least they should be thoroughly updated with current numbering and descriptions... Post of the entire cycle (Backup, Verify, Restore):Retro_MD5 Errors_Backup, Verify, Restore.rtf Thanks for your attention to this matter.
  13. henry-in-florida

    MD5 digest calculated incorreectly??

    Had similar issues and have ignored them, so far. However on restores it might not be so trivial. I had to use a backup for restoration which contained errors. On restore, I got an error as well on many of the same files, plus a few more. Here's an example of an error on the restore. If Retro cannot reliably back up and restore without error then that's not good. Luckily I also use an alternate file based backup system in case of such an eventuality (call it a lack of trust and an abundance of drive space...). This, if it truly botches files, is a truly discouraging situation if it proves to affect the files in question. Maybe an epic fail for me in the future as this issue has previously been discounted (literally, I've been told by support to ignore it!) by Retro support when it occurs during the backup. I've never seen it in restores before! !An error occurred during the verification step. The MD5 digest for the file "/Volumes/LaCie 10/iPhoto Library_old.migratedphotolibrary/Masters/2009/0902006_Select lowrez/IMG_2006_LOWREZ.JPG" did not match, error -1,129 (MD5 digest mismatch) !An error occurred during the verification step. The MD5 digest for the file "/Volumes/LaCie 10/*MyPicturesLibrary/2009/2009-02-28/IMG_2059.CR2" did not match, error -1,129 (MD5 digest mismatch) BTW, the history on this backup is that it started from the previous backup as a recycle event on 26 JUN 2016 and the next day finished another backup (27 JUN 2016). Thereafter, the source drive failed and I needed a restore to new media over the next days. Found the errors on restore yesterday and again today (tried again, just to be sure)
  14. henry-in-florida

    Retrospect Multi-Server v12.5 Error -641

    The remaining problem was my confusing message. Backups run without error after the recycle backup completed. In other words, it was only the recycle that did the trick, all the diagnostic checks came back OK on both the client AND Retro server. Drives tested without problems, servers has been working OK with other clients and with this one. Now, to update to V13... My system is described in the signature line below. You'll see the update to new versions when my install is complete, tested and working.
  15. Have been getting a "Chunk Checksum Error -641" for several days now on a previously working script (out of six backup scripts that I run on 3 clients): + Normal backup using Bi-Weekly JaneiMac at 3/16/16, 22:00:00 (Activity Thread 1) To Backup Set iMac_Backup... - 3/16/16 22:00:00: Copying Macintosh HD on Jane's iMac 3/16/16 22:03:39: Found: 1351965 files, 317745 folders, 345.4 GB !Trouble matching Macintosh HD on Jane's iMac to iMac_Backup, error -641 (chunk checksum didn't match) Here's what I did so far: Repeated the script a couple of times to verify that the backup didn't take place and checked the drive condition to make sure the backup drive is operable. A very sensitive external test, DriveDX says there isn't a problem (SMART check). Haven't found the error code in Retro's own KB. Can't troubleshoot the issue further. Tried to perform a Recycle Backup manually. It seems not to run without the error so far... Does anyone know how this error started? Why it isn't documented anywhere? This situation seems typical of odd errors that occur from time to time. Don't seem to have any cause and when ignored seem to go away on their own. Sometimes a simple workaround like starting over clear it. Sometimes too a drive issue is the cause. That's why i went to SMART testing to confirm these kinds of drive related possibilities. Not so much in this case. H
  16. henry-in-florida

    Retrospect Multi-Server v12.5 Error -641

    Thanks Lennart. It's so new and an SSD that it didn't occur to me to check the client (the error reported seems to me to be unclear in pointing to the device). I wonder if Disk Utility will even find a problem, but it's worth a try (and also with Drive DX). No reported errors in Disk Utility, Live Mode. Note the differences in OS X 10.11 drive check. Drive DX indicates no SMART errors, lots of life in the SSD. Again, the recycle backup working (although it hasn't completed yet) certainly should also leave out the client from the cause as well. Or am I missing something? I thought that you'd say the catalog as a possible issue. That would be my next target on further failures. Recreate, delete?
  17. I'm noticing an error in retro whenever the system starts up: 11/21/15 19:28:18.385 retropds.25[744]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.2 instead of 10.11.2. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number. Call location: 11/21/15 19:28:18.387 retropds.25[744]: 0 CarbonCore 0x00007fff823b6c9b ___Gestalt_SystemVersion_block_invoke + 113 11/21/15 19:28:18.387 retropds.25[744]: 1 libdispatch.dylib 0x00007fff9303d33f _dispatch_client_callout + 8 11/21/15 19:28:18.387 retropds.25[744]: 2 libdispatch.dylib 0x00007fff9303d237 dispatch_once_f + 67 11/21/15 19:28:18.387 retropds.25[744]: 3 CarbonCore 0x00007fff82342b47 _Gestalt_SystemVersion + 987 11/21/15 19:28:18.387 retropds.25[744]: 4 CarbonCore 0x00007fff82341ddb Gestalt + 139 11/21/15 19:28:18.387 retropds.25[744]: 5 retropds.25 0x0000000100020de3 fscImportVolInfo + 174 11/21/15 19:28:18.387 retropds.25[744]: 6 retropds.25 0x0000000100020b07 CVolUpdate + 879
  18. henry-in-florida

    Recurring error on Mac OS X "El Capitan" client in Retro 12.5.0

    None of the above. It isn't a network cable. It keep getting messed up. It usually happens when the client is being woken up while asleep. Once it happens (the error), I have to forget the client, uninstall/reinstall Retro Client from scratch, set it up for first access. Then it's good for a while, until the next time. The client is always visible from the network, but not in Retro. Any other advice? It seems isolated to one client. H
  19. henry-in-florida

    Recurring error on Mac OS X "El Capitan" client in Retro 12.5.0

    All I did to get the client to work was to rebuild the client's database. It seems to be OK now. It wasn't the issues you mentioned (unavailable). I always could see it via Bonjour in Retrospect or elsewhere.
  20. I keep noticing errors in a client's Console output that may be related to Retrospect and version numbering. It doesn't appear on Retro's log, should I be worried? Operation seems fine. Here is the snippet: 11/16/15 07:24:15.608 retropds.25[6763]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.1 instead of 10.11.1. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number. Call location: 11/16/15 07:24:15.608 retropds.25[6763]: 0 CarbonCore 0x00007fff8a26f79f ___Gestalt_SystemVersion_block_invoke + 113 11/16/15 07:24:15.608 retropds.25[6763]: 1 libdispatch.dylib 0x00007fff8b9343c3 _dispatch_client_callout + 8 11/16/15 07:24:15.608 retropds.25[6763]: 2 libdispatch.dylib 0x00007fff8b9342bb dispatch_once_f + 67 11/16/15 07:24:15.608 retropds.25[6763]: 3 CarbonCore 0x00007fff8a1fc09c _Gestalt_SystemVersion + 987 11/16/15 07:24:15.608 retropds.25[6763]: 4 CarbonCore 0x00007fff8a1fb8b0 Gestalt + 139 11/16/15 07:24:15.608 retropds.25[6763]: 5 retropds.25 0x0000000100020de3 fscImportVolInfo + 174 11/16/15 07:24:15.608 retropds.25[6763]: 6 retropds.25 0x0000000100020b07 CVolUpdate + 879
  21. Retrospect forcibly dismounts (forcibly ejects) external USB drives when completing a backup. This happens at the conclusion of a backup caused by my script. I see no options to do this. Other externals (connected by FW) are NOT dismounted, only USB drives. The maker of the product says the fault pins to Retro, since it doesn't happen in other Backup or normal Finder uses (tried on CCC without error). Naturally they never heard of this before. To recover from this, I need to manually reconnect the drives- remove and reconnect the USB cable. The device is a 4 port USB drive interface for bare SATA drives from Startech.com (SATDOCK 4 U3E). Happens with Retro running on Yosemite, and other OS's. Is there some setting or other preference controlling this. It has been happening regularly and seems to have followed the last version update (V12). Please note: the Eject tapes and discs option in the script is NOT CHECKED.
  22. I spoke with support on this one, and their advice to me was: Retro uses Finder to deal with drives via commands issues to access, open and close drives. We didn't go into detail about it but suffice it to say that there is no un-mounting or mounting of drives in Retro. That action could only occur in Finder, according to tech support. Advice on this product since the rep had a similar one and has had issues like mine in the past... Look at USB interface either on the device or on the machine causing issues. Replace the Dock if it proves to be a USB related issue. Try un-mounting (in Finder), physically disconnecting the Dock, rebooting the computer, reconnecting the dock to a different USB port of the the server machine. Then, try a repeat of the Retro backup that causes unmount to see if the drives disconnect by themselves. Well, I tried that with the added step of checking out each drive to see if it would reliably mount and un-mount on it own. Found one drive that was sticky in the regard and repaired it, removed it, and made sure it worked to mount and un-mount from the Finder (and in Disk Utility). Once that was done, tried running the same script again. Seems OK, for now.
  23. I have gotten several strange errors in my log even though most client backups seem to proceed normally. I did have one client come up as reserved (error -505) which is what started me looking for problems. I fixed that by forgetting the source, reinstalling the Client software, and re-adding the Client (First Use). Thereafter the backup scripts proceeded normally. However when I went into the log to see why the client hadn't been backing up for two days, I found this...See attached log snippet. Can someone explain these errors and if they have something to do with the above issue or another affecting operation of the backup. I have not seen the line before, IFaceIPUpdate: gethostbyname error 1, (Authoritative Answer Host not found), hostname = ML-server.private Note that the hostname does seem correct and Retro Server runs scripts using the hostname (possibly by address, since that also is correct). No names have been changed for any reason, ever. You will note that these errors seem to appear in clusters around the dates I started having trouble (6/23/2015) with a client and not before. So far I have reinstalled/restarted that one client. The Server side was restarted by automatic script last Sunday (6/21/2015) on it's normal schedule with no untoward events. My signature line below indicates the current software and configuration information on this system. I am reporting this as a bug, really it's a mystery. If you all have seen it before and have troubleshooting advice, please let me know. This is the issue I have experienced since upgrading to the latest release. Retro Log_150625.rtf
  24. Recently installed upgrade. Unlimited Version 12 (Multi-Server). Worked fine for a day. After I got three clients up and running on one Server, (two had Console running on them just fine) for no apparent reason the next day two remote consoles couldn't log into the remote server (on local network). One user connects on Wi-Fi, the other on wired LAN. Both remote consoles, on each of two clients, have the same issues logging in. Neither IP, nor Server name appear to resolve - spinning wheel all the time on each remote client (they worked the previous day). Yet, the local machine's Retrospect console opens just fine, it backs up to the clients just fine (the clients see the server, back up, show the status, etc.). Tried reinstalling one console on the client, without change. I have not yet tried adding the Engine to another machine to see if I can replicate the issue there, that seems the obvious next choice. Anything else to try?
×