More client error messages in Retrospect 18.1?

[twickland]

Prior to version 18.1, we would get -519 (network communication failed) or -530 (backup client not found) errors only during regular scripted backups and not with proactive backups. This of course makes sense, since the whole purpose of proactive backups is to catch and back up clients when they appear on the network.

Since upgrading to 18.1, Retrospect is consistently reporting a -530 error for one backup client and a -519 error for another. (These are not the same two clients described in my recent post about storage groups.) Because a proactive backup script constantly pings clients to see if they're online, the Operations Log is filling up with hundreds of these spurious and useless error messages. Thank goodness, this is an issue for only two of our 24 backup clients. While not a fatal problem, it sure is annoying.

Update: While typing this entry, I just started getting -519 errors for two more clients. I'll need to see if these become consistent, like the other two have been.

Has anyone else seen this?

[DavidHertzberg]

twickland,

You're in luck, because the Retrospect engineers appear to have fixed this bug—along with one other—in a more-recent Retrospect Mac 18.1.1.120 release on 24 June 2021.  In the cumulative Release Notes, it's listed as "Fixed  ProactiveAI: Fixed issue where failed activities would appear for disconnected data sources with -530 errors (#9486)".  That doesn't say anything about -519 errors, but maybe the cause and the fix for those is the same as for the -530 errors.

[twickland]

Thanks, David, for the heads-up. The update release seems to have fixed the problem. After updating, there was one last gasp from the client with the -530 error, and since then, it's been back to normal; no further -519 or -530 errors for proactive backups.

[DavidHertzberg]

You're welcome, twickland.

Let me just note that the cumulative Release Notes show the original and later releases of Retrospect Mac 18.1 seem largely devoted to fixing errors and omissions in features that were "New" or "Improved" in 18.0.  Given no knowledge whatsoever of the code, I'd bet an old programmer's nickel (US$0.05) on your problem being an error in "ProactiveAI: Fixed issue where ProactiveAI could not back up from cloud data sources (#9437)" in the original 18.1.0.113 release—even though your "clients" weren't cloud sources.  If I were to utter anything about an appearance of testing having been rushed, the head of Retrospect Tech Support might accuse me of "posting derogatory information about any member of Retrospect/StorCentric", so I won't utter that. 🤐

[iodigitale]

After the upgrade to Retrospect 18 for the Mac I get a lot of error -519 (network communication failed) not only in proactive backups but also normal backups.

We get this error from a lot of clients in different locations (we have a multitenant service with about 10 servers and 200 clients).

The version we have installed is 18.1.1.120

[DavidHertzberg]

3 hours ago, iodigitale said:

After the upgrade to Retrospect 18 for the Mac I get a lot of error -519 (network communication failed) not only in proactive backups but also normal backups.

We get this error from a lot of clients in different locations (we have a multitenant service with about 10 servers and 200 clients).

The version we have installed is 18.1.1.120

iodigitale,

First I must ask, in the immortal words of Nigel Smith, "what else changed?" when you upgraded your installation to Retrospect Mac 18.  Did you also upgrade to any "improved" networking hardware—because a forced upgrade in early 2017 to an "improved" Ethernet switch gave me -530 errors for a "client" ?  I must also ask if your "clients in different locations" are defined with the Subnet Broadcast access method (per page 82 of the Retrospect Mac 18 User's Guide)—because the permanent fix for my -530 errors was re-defining my "clients" with Add Source Directly (also per page 82)—which unfortunately might be a pain in the a*s for your "multitenant service"?

Second, I suggest that you consider downgrading your "backup servers" to 18.1.0.113, based on my guess that the hurried (1 week after) release of 18.1.1.120 might not have been thoroughly tested for network communications other than for the one ProactiveAI bug it fixed.  If that doesn't solve your problem, consider downgrading your "backup servers" to 17.5.2.103—for which you'll have to get a license from Retrospect Sales.

(Disclaimer: Anything I may say about the intentions of Retrospect "Inc." in this or any other post is merely the result of "reading the tea leaves", the "tea leaves" being documentation and public announcements supplemented by an occasional morsel from Retrospect Sales.  I have never been paid a cent by Retrospect "Inc." or its predecessors, and I pay for my upgrades. Any judgements expressed are—obviously—mine alone. The same is true of Retrospect's history, especially with references to here.  Any apparent aspersions I cast are meant to apply to the widest applicable group of Retrospect "Inc." employees, not to an individual employee.)

[iodigitale]

Thanks David. Nothing changed when I upgraded to Retrospect Mac 18. We have different customers in different offices (we are resellers and manage our clients backup).

I'll try to downgrade because the problem is huge... too many clients with no backup.

I tryed to remove and add again 2 clients directly... but it’s not acceptable for us reconfigure all clients and scripts… we have a large amount of clients and a lot of them set in dhcp... at this time we have 3 working days spent and cannot charge our customers 😞

[iodigitale]

Thanks David. Nothing changed when I upgraded to Retrospect Mac 18. We have different customers in different offices (we are resellers and manage our clients backup).

I'll try to downgrade because the problem is huge... too many clients with no backup.

I tryed to remove and add again 2 clients directly... but it’s not acceptable for us reconfigure all clients and scripts… we have a large amount of clients and a lot of them set in dhcp... at this time we have 3 working days spent and cannot charge our customers 😞

[DavidHertzberg]

iodigitale,

I intended to add one more suggestion (before the disclaimer) to my preceding post in this thread, but my Web cache for these Forums became corrupted and—by the time I cleared it (following the direction of a Filipino 😲  Retrospect Support person) —I needed to get to the bank and then to the post office before they closed. 

The suggestion is that you create a Support Case for a bug; here's how to do that (since I wrote that linked-to post, Retrospect 18 was released with mandatory ASM, so you've paid for personal assistance).  Here are some facts:

• Retrospect 18 was released on 25 May, 2.5 months behind the customary first-week-in-March schedule. 
• Another thread of mine—which was locked by the head of R.T.S. because of my "insulting members of the staff with these kinds of comments"—described 18.0-related errors on the Retrospect website that were not fixed until 14 July (nearly 3 weeks after 18.0 was released) following my Support Case #79825. 
• Fully-updated versions of the version 18 User's Guides were also not put on the Retrospect website  until 14 July. 
• Here's a post by another administrator reporting a bug in a previously-working feature when he upgraded Retrospect Mac 17.5 to 18.0.
• Here's a post by you reporting a bug in Retrospect Mac 18.1.1.120, which is a bug-fix release to the 18.1.0.113 bug-fix release a week earlier.

My inescapable conclusion from these facts is that there has been a distinct lack of coordination and thorough alpha-testing in Release 18.x so far.  I think  your "We have different customers in different offices" and "we have a large amount of clients and a lot of them set in dhcp" means many of your "client" machines are in fact defined with the the Subnet Broadcast access method (per page 82 of the Retrospect Mac 18 User's Guide), and that release 18.1.1.120 has messed that up.  Here's are questions you need to explicitly answer in your Support Case—and to any R.T.S. person you phone:

• What major version of Retrospect Mac was your installation using before you upgraded to Retrospect Mac 18?
• Are the -519 errors exclusively for "client" machines defined with Subnet Broadcast access?  If so, can you redefine one of these "client" machines with Add Source Directly and see if you still get a -519 error backing up that "client"?
• For one of the "client" machines that gets a -519 error, if you select it in the Sources panel of the Retrospect Console and click the Refresh button at the top of the panel, does the dialog show that machine?
• Are any of your scripts using features that are new or improved in Retrospect 18.0 through 18.1.1  (blue or green tabs in the cumulative Release Notes for those releases)?  If not, would you be willing to demand a downgrade to your preceding release—with a consequent refund (the prospect of having to give a refund tends to concentrate a salesperson's mind wonderfully—encouraging rapid action on the part of R.T.S.)?

And please post your answers to those same questions in this thread.

Edited September 2, 2021 by DavidHertzberg
Change third question in second bulleted list from using the Locate button to using the Refresh button.

[DavidHertzberg]

iodigitale,

Before following the suggestion in my immediately-preceding post, you should consider another possibility I thought of yesterday.  It is possible that there isn't any Retrospect Mac 18 bug, but instead that—in upgrading your installation in which "we have a large amount of clients and a lot of them set in dhcp"—your provisions for Subnet Broadcast access per page 82 of the Retrospect Mac 18 User's Guide were messed up.

The reason I think you use that access method is,  because "we have a multitenant service with about 10 servers and 200 clients", you have no way of ensuring that names of "client" machines are unique except within a particular "tenant".  Therefore you must be distinguishing between "tenants" by putting them in separate subnets based on designated ranges of IP addresses.  Subnets are designated in Retrospect Mac by defining them per "Configuring Network Interfaces and Subnets" on page 83 of the User's Guide.  You give each subnet an Interface Name, and then define its range via the Subnet Address and Subnet Mask.  I don't have any subnets defined on my small home network, but I gather that—per "Adding Retrospect Clients to Sources" on page 69 in the User's Guide—you specify the "client"'s subnet in theleft-hand  Sources from Interface pop-up menu and  specify Use subnet broadcast in the right-hand pop-up menu (not mentioned in the UG—another example of deficient Retrospect documentation).

The way to test whether this is the problem is

• For each of the "client" machines that gets a -519 error, if you select it in the Sources panel of the Retrospect Console and click the Refresh button at the top of the panel, does the dialog show that machine?

If not, then your subnet designations must have gotten messed up.  Talk to your IT people and fix them, instead of submitting a Support Case.

If the dialog does show that machine, OTOH, there's another possibility that doesn't involve a Retrospect Mac 18 bug.  That's if you have more than one Retrospect "backup server" running scripts.  Your Console may now be be running scripts on a "backup server" for which some sources in the script are not defined.

 

[iodigitale]

We have different customers (we are resellers) each one with in different office so different lans. So we have different server installations in different lans. Yesterday we tried to set each client of a single little customer (10 clients) in direct mode (each one has a stati ip on the lan) but we got 519 error in 4 backup executions. 

[DavidHertzberg]

iodigitale,

If this setup—which wasn't clear to me from your preceding posts—worked with your previous version of Retrospect, then there's a bug in Retrospect Mac 18.  What I don't understand is why other installations haven't reported the same problem.  Maybe you're among the first to upgrade to Retrospect Mac 18.1.1?

Did any of your backup executions work using 18.1.1?

P.S.: Further questions about your customers' setups that need to be answered regardless of whether or not you submit a Support Case for a bug:

• So you're saying each customer has a "backup server" at his/her location? 
• Do you check at the customer sites whether the scripts have run?
• Do you personally make all hardware and software changes to these "backup servers" and to the "client" machines they back up?
• Have the OSes running on the "client" and/or "backup server" machines been upgraded? 
• Have network switches at the customer locations been upgraded? 
• What OSes do these machines run?

Edited September 3, 2021 by DavidHertzberg
Add P.S. of Further questions that need to be answered regardless of whether or not you submit a Support Case, as bulleted list.