Jump to content

henry-in-florida

Members
  • Content count

    115
  • Joined

  • Last visited

  • Days Won

    3

henry-in-florida last won the day on June 28 2015

henry-in-florida had the most liked content!

Community Reputation

13 Good

About henry-in-florida

  • Rank
    Retrospect Addict

Profile Information

  • Gender
    Not Telling
  1. 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)
  2. 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
  3. 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.
  4. 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.
  5. 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)
  6. 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.
  7. 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?
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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?
  14. 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.
×