Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


DavidHertzberg last won the day on November 1

DavidHertzberg had the most liked content!

Community Reputation

43 Excellent

About DavidHertzberg

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
  • Location
    New York, NY
  • Interests
    Retired applications programmer, with a few Macs at home.

Recent Profile Visitors

1,248 profile views
  1. DavidHertzberg

    Assertion failure at elem.cpp-1096

    sowen222, According to the head of Retrospect Tech Support, "Fast Catalog Rebuild is turned on by default with all Disk Backup Sets. We don't have an option to turn it off/on because it is always enabled." Again according to the same person, "The .session files help Retrospect perform faster catalog rebuilds. We made the changes to help cloud backup users with catalog rebuilds. [new paragraph] Retrospect will read these files during a rebuild process. If you want to perform a through rebuild, you can delete all .session files before catalog rebuild and Retrospect will create new .session files from the original backup set data." I suggest that you file a Support Request, specifying a Feature Request that a Thorough Catalog Rebuild option be added to the "Recreating a Disk Catalog" dialog that is now shown and discussed on pages 453-456 of the Retrospect Windows 15 User's Guide. That option would delete all existing .session files and create new ones. The code for doing that used to be the default for the operation up until Retrospect Windows 11. 
  2. DavidHertzberg

    Assertion failure at elem.cpp-1096

    A search of the Forums doesn't show a report of an assertion with this particular number. Here's why and how to file a Support Request. If you just upgraded to Retrospect Windows 15 you may be entitled to personalized phone support, but I understand the European Retrospect Tech Support representative doesn't know very much.
  3. Cabling my "backup server" directly to the MoCA adapter in my bedroom, which I mentioned I had done at the end of the second paragraph here, resulted in a -530 Bug 2 scenario when I booted the Mac Pro "backup server" four hours after the scheduled time for the daily Backup of my MacBook Pro this morning. That means both the "sacrificial" NoOp script and the "real" Backup script failed with -530 errors. I was then able to do a two-second Locate of my MBP, and run the "real" script manually. I have accordingly just re-connected my bedroom MoCA adapter to my Mac Pro through the 5-port 1Gbps Ethernet switch in my bedroom.
  4. 1. It did, but Multicast also did that. 2. Yes, of course. 3. As per above, when run 2 hours past the scheduled time, the "sacrificial" NoOp script failed within a few seconds with a -530 error, and immediately after that—with no manual intervention—the "real" Backup script ran fine. This is the -530 Bug 1 scenario, as I have named it, which has occurred frequently since early February 2017. 4. I followed those steps nearly two years ago. The only exception is that "Make sure the client has the most recent version of the Retrospect client software" no longer applies, because—as I stated above—going more recent than the Retrospect Mac Client 14.1 makes the "real" Backup script also fail with a -530 error—an intermittent situation which I have named -530 Bug 2. 5. As stated in the preceding paragraphs of this post.
  5. henry-in-florida, Unfortunately it's not "very old news" when it affects what we can discuss in these Forums. I suggest you read the last two substantial paragraphs in that same post I linked to concerning the person who is the head of Retrospect Technical Support. I only have one router in my LAN, and that is my Verizon-provided Quantum FiOS "gateway". That router is directly connected to a full-up 8-port 1Gbps Ethernet switch in my study. That switch is in turn connected to a MoCA 2.0 adapter, which via a length of coax cable is connected to an identical MoCA adapter in my bedroom. Until a few minutes the adapter in the bedroom was connected to a 5-port 1Gbps Ethernet switch, but only one of the ports on that switch is in active use—connected to my Mac Pro "backup server". In order to eliminate a possible source of timing delay, I have just now cabled the "backup server" directly to the MoCA adapter in the bedroom. It works fine for a test NoOp backup; we'll see whether it makes any difference in eliminating the -530 error I got for the "sacrificial" NoOp script run two hours after its scheduled time early this morning (the "real" backup script scheduled directly after it ran fine). My LAN is totally wired. A few months ago I tried running a "real" Backup script via 802.11g (the fastest speed the wireless built into my old Mac Pro supports). It ran at around 20% of the normal speed, probably partly slowed down by the three layers of sheetrock and one concrete column between my router (a DSL one at the time) and the Mac Pro.
  6. henry-in-florida, First, the person you mentioned in the first sentence of your post immediately above has for years been the head of Retrospect Technical Support—not the head of Sales unless there has been an unannounced management upheaval. He's worked in T.S. since 1994 (and still will until at least Wednesday according to this announcement), and lived through the "near-death employment experience" I discussed in the first substantive paragraph of this post. As I discussed in the second substantive paragraph of that same post, he's IMHO a prime example of "Retrospect Inc. PTSD"—so for the last year or so I've had a policy of never mentioning his name on the Forums (because I'm convinced he does a daily search of the Forums looking for a mention of his name in a post by me). Nevertheless he's a good man doing a very difficult job, and I admire him even though I think 24 years in T.S. have made him just the least bit crabby. My intermittent -530 error problem has endured through two MacBook Pros and two pairs of Ethernet switches, so it's not a simple hardware problem. My best guess is that it's related to the fact that the switch in my study—where my two "clients" are located—and the switch in my bedroom—where my "backup server" is located—are connected via an installed-when-the-apartment-was-built stretch of coax cable with a MoCA adapter at each end. I'd love to replace that with a stretch of Cat5e Ethernet cable, but I couldn't do that without either tearing up an interior hallway floor or running a 100-foot-long Cat5e cable just underneath the ceiling of 3 sides of that hallway. At a cost of $120 I replaced the MoCA 1.1 adapters with MoCA 2.0 adapters about 6 months ago, but that doesn't make any difference. IMHO there's a bug in the Retrospect Multicast code that makes it vulnerable to timing delays, particularly when the "backup server" has just been booted and immediately needs to run a scheduled script. I even started a thread about that on the Ars Technica Networking forum, but nobody had an answer.
  7. henry-in-florida, First, sorry for misreading your second post in this thread. I saw "The only relevant IP's are clients at .70, .64 (TWO CLIENTS), .86 (the Server)", and thought you were saying you had two clients at .64. Second, thanks for probably solving a problem I have had for nearly two years with -530 errors on Backup script runs. I wasn't having any problems with Adding my two Mac clients, but I have been intermittently getting -530 errors for the first client (a MacBook Pro) when I run scheduled daily scripts that back it up. My closest approach to a remedy has been to schedule a "NoOp" script 5 minutes before the "real" script; the "NoOp" script is a duplicate of the "real" script that adds the No Files rule. Because the -530 errors are intermittent—indicating IMHO that the error is hardware-related, sometimes the "NoOp" script immediately gets an error but the "real" script runs OK, sometimes both scripts run OK—especially when both my "backup server" and my MBP client are booted before the scheduled time for the "NoOp" script, and sometimes the "NoOp" script sits there past 3 minutes trying to Find the MBP. My cure in the latter case is to Pause the "NoOp" script, do a Locate—which always works—of the MBP, and then do a Stop of the "NoOp" script; at that point the "real" script always starts and runs OK. I long ago submitted a Support Request for this problem, and twice Retrospect Tech Support has given me test versions with extra logging so that I can help the engineers find the bug. I am permanently stuck running the Retrospect Mac 14.6.0 Engine and Console and the 14.1 Client, because the test versions indicated that engineering had introduced a "fix" in 14.6.1 that actually made the problem worse. I'd like to be able to upgrade to Retrospect Mac 16 next spring so I can upgrade my Mac Pro "backup server" and MBP "client" to macOS 10.14 Mojave to get the benefits of APFS; maybe switching from Multicast to Subnet Broadcast—which I have just done—will enable me to do that. If Subnet Broadcast makes my intermittent -530 errors go away, that would be IMHO a sad day for Retrospect Inc. unless Retrospect 16.0 introduces an explicit fix for Multicast. If the fix isn't in Retrospect 16, Retrospect Inc. will have to distribute a very-prominent document (for Retrospect Windows, too, because some administrators have reported -530 errors with that variant) that says "Don't add your 'clients' with Multicast anymore, because it creates errors for some administrators. Instead use Subnet Broadcast; we know it's going to be tougher for you to learn how to do that but you're stuck with it." I don't think that will ease Tech Support's workload; quite the contrary, since they may have to process additional product returns from disgruntled customers.
  8. bradp015 got an answer by first making this post in the Server, SBS and Multi Server forum. His Retrospect Mac 9 success report, including methodology, is 2 posts below it.
  9. henry-in-florida, 2. Tomorrow is "Make Friends With Your Router Day". Start by getting the MAC addresses for each of your "client" machines from Apple Menu->About This Mac->Ethernet Cards, and writing them down. Then proceed with connecting to, logging in with your password (if you haven't changed it, it's probably on a label attached to your router), and phoning your ISP's Tech Support (not Retrospect's). Once you've done that, you want to ask the T.S. person how to navigate to setting a fixed IP address for each client machine that you actually still have. On my Verizon Quantum Gateway, that's Advanced-> IP Distribution->Edit (assuming your "client" machines are booted, so they show the default IP addresses in the router). Enter the MAC address for each machine that you do have, and checkmark the box or whatever to make the listed dynamic IP address the static IP address. If any machines are listed that you don't have, find out how to delete them. 3. You said in your second post that you have two "client" machines with the same x.x.x.64 address. That's obviously a problem; look in System Preferences->Network for each of the "client" machines, and change the duplicate to a different IP address. Make sure that the static IP for that machine is changed accordingly in your router. 4. Do not set a static IP address for your "backup server" machine. That advice came from Alan in 2015.
  10. DavidHertzberg

    can't link to

    redleader, What kind of machine is FS SERVER? Is it some kind of NAS that runs under Linux or Windows? If so, try repairing that with the appropriate software. Also Retrospect 15.6.WHAT.WHAT? Try upgrading your "backup server" and Client(s) to Retrospect Mac, which doesn't seem to have the "bad release" problems of 15.6.0.
  11. henry-in-florida, First, have you updated your "backup server" machine and your Mac Clients to 15.5 and 15.6.0 seem to have been "bad releases", at least for Retrospect Windows. Second, I was told years ago by the now-departed-from-Walnut-Creek Alan that the "backup server" should not have a fixed IP address. The one time I tried violating that, I had problems. Third, surely you shouldn't have two "client" machines assigned the same fixed IP address—such as .64.
  12. DavidHertzberg

    Backups "freeze" part way with no error

    x509, If you want scripts doing Backups of the same LAN "client" drive to run concurrently, they must be backing up different Subvolumes of the same "client" drive. Even that is new for Retrospect Windows 12.6, as noted here. As j-polasektamu.edu's OP in that thread said nearly 3 months before 12.6 was released:
  13. After a little creative searching on Wikipedia, I found this. YMMV; I haven't had a Windows machine in my home installation since I gave back the Windows 95 desktop to my employer upon being laid off in 2004. Up to that point, I was getting my Windows tech support from IT in our New Jersey office.
  14. DavidHertzberg

    Backups "freeze" part way with no error

    JamesOakley and x509, I caught onto the new Desktop Edition feature on 31 October, based on JamesOakley's having noticed it, and got DovidBenAvraham to put an announcement in the Wikipedia article—which I mentioned in the second paragraph of this post. In that mention I said From what you're saying, it seems Product Management was so reluctant to mention the new feature that they didn't tell Support about it , which must be why Support told x509 to rename his config files to something else etc.. In two posts immediately subsequent to the one I linked to in the first paragraph of this post, I discussed the results of a thread I started on the Ars Technica Linux Kung Fu forum regarding the technical feasibility of Retrospect Inc.'s implementing a future painful new feature that I think this new feature is a prelude to. I won't repeat that discussion here, one reason—besides the sin of double-posting—being because its results are sensitive enough that they might IME cause the head of Tech Support to delete this and/or other posts.
  15. henry-in-florida, You should look at the cumulative Release Notes. For 15.1 they say : "Mac Client: Fixed issue where client did not prevent macOS from going to sleep during backup (#7273)". Also for, an emergency release you may not have upgraded to, they say: "Remote Backup: Fixed issue where remote backup connection was incorrectly closed (#7735)". I'm pretty sure you are not using Version 15's new Remote Backup capability, but the fix for #7735 may also have fixed your problem. Try installing it, and file a Support Request if your problem is still not fixed.