Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. MrPete

    Yet another -530 client not found error

    Hi all! Sorry for the long delay. The Real World is intense for me right now The following simple sequence has been a 100% reliable workaround for me: 1) AFTER an endpoint is stably connected to a LAN via any mechanism (wired, wifi, etc)... 2) Restart the Retrospect Client service (stop / start as described earlier) The client NEVER gets confused under such conditions, at least in my way-too-extensive testing. Confusion arises when the client initializes at the same time as the computer is initializing various things, including a variety of network-connected startup services etc. And/or if the network connection changes (eg wired to wifi, or to a different wifi.)
  3. Nigel Smith

    Yet another -530 client not found error

    Smart move, IMO! These are deep waters, best left unrippled. Especially when you remember that network communication is not directly via IP address, but is next-hop routing via the mapping of IP addresses to gateway/MAC address in ARP tables. Table updates aren't instant, which is why I can quite easily see why my guess might happen -- step 5 is based on the MAC address of the previously detected client, obviously still "valid" since the interface used wasn't changed (just the IP address). But when we get to step 7 it's aged out/replaced, the IP address is no longer valid, and you get a comms fail.
  4. DavidHertzberg

    Windows 10 Feature Release 2004

    speedyme, You can find your answer in the cumulative Release Notes for Retrospect Windows. But I'll save you the effort of reading the most recent entries; the answer is no.
  5. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, Your 10-step guess as to what might have been happening may be correct, although you got confused about the Location of my first test—it was "Automatic" (X.Y.Z.202) instead of "Retrospect Priority" (X.Y.Z.201). I reran that test yesterday, but—after changing the Location of my MacBook Pro "client" machine—scheduled the backup run 15 minutes in the future and then shut down and re-booted my "backup server". This time the No Files backup ran with no error. 😲 That raised the question of how the Retrospect Engine had been able to find the MBP Source, which I am sure I had defined with Add Source Directly as X.Y.Z.201. The answer seems to be the "magic" of Piton Name Service. When I did a Locate of that Source after the test, it found the MBP via Multicast as X.Y.Z.202. (I intentionally did not do a Locate after re-booting the "backup server" but before the test run was scheduled, because I found 3 years ago that a pre-Backup Locate would eliminate a -530 error that otherwise would occur.) So am I going to investigate this further in my installation, other than possibly making the effort (because of necessary script changes) to Remove and re-Add my MBP as a Source with Use Multicast? No I am not, because of an experience I had with Tech Support over two years ago. As the third paragraph of that post says, T. S. twice gave me test versions of Retrospect with extra logging. I uploaded the results to my Support Case, and got back a reply that said basically "Yes we see a problem, but we can't do anything about it unless we can reproduce it on our own machines—because it seems to be at least partially related to network hardware." I thereupon offered to snail-mail T. S. my two MoCA adapters (for which I had by then bought higher-speed replacements) and a 40-foot length of previously-bought-for-testing Radio Shack coax cable to run between them, but got back a reply that said basically "Thanks for the offer, but we cannot take responsibility for customer-owned hardware." I then suggested they find someone in the Retrospect Inc. organization who had gone far enough in law school to be able to write a deed of gift to Retrospect Inc. that I could sign, but they didn't reply. ☹️ So, as the last paragraph in this up-thread post states, we'll just have to wait until StorCentric discovers the -530 problem for the forthcoming Drobo variant of the "backup server"—and provides Retrospect "Inc." engineers the necessary resources to find and fix the problem. 😢
  6. Last week
  7. Have any versions of Retrospect been certified on Feature Release 2004? Microsoft is now distributing it as an optional update to everyone.
  8. Nigel Smith

    Yet another -530 client not found error

    Not so fast... This is what I think might be happening (and why a WireShark run would help): Client is on "Automatic" location -- x.x.x.202 You switch to "Retrospect Priority", client address now x.x.x.201, and immediately run the server script Server multicasts to all devices, asking for client Client responds, but we know the client doesn't instantly reflect a network change, so says "Yay! Me! Here and ready on x.x.x.202!" Scan gets done By now, the client is listening is on x.x.x.201:497 (or, rather, is no longer listening on x.x.x.202:497) Server initiates the backup "Hey, x.x.x.202, give me all these things!" Silence... More silence... Server assumes network communication has failed and throws -519 Step 4 is total guesswork from me -- all we know is that there must be some mechanism for a multicasted client to tell the server its IP address. If I'm right, they might be able to fix this on the client, though it may dependent on the OS promptly informing all network-using services of an IP change (the client unnecessarily spamming the OS for updates would be horribly inefficient). Or they might be able to fix this on the server, with a re-multicast after step 8's failure to pick up the new address. But, even in these days of devices often changing networks, I doubt the above crops up very often and probably isn't worth fixing (directly, at least). x509's "binding to a bogus address" is much more common, and if solving that solves other issues too -- bonus!
  9. DavidHertzberg

    Yet another -530 client not found error

    Nigel Smith, You are correct about my having defined the Piton protocol too narrowly; Instead of writing "multicast Piton Protocol", I should have used the term Piton Name Service—per page 227 of the Retrospect Windows 17 User's Guide. At last the -530 versus -519 difference is clarified. On page 221 the UG says: Page 228 says: Page 33 of the Appendices says: In fact, a closer examination of the log for my first test run illustrates the difference between the overall Piton protocol and Piton Name Service in a rather interesting way (it turns out I didn't need WireShark. 😁). The run actually "Finished scanning backup set data files to ... ", then issued the message "Can't access backup client ..., error -519 (network communications failed)". It seems my "backup server" managed to find my MacBook Pro "client" by name, when it couldn't do so by Direct Access because the IP address the "client" was using didn't match the one defined in Sources. Then, after successfully finishing scanning, the "backup server" said "Wait a minute, that's not the Source I'm supposed to back up" and issued the -519 error—not a -530 error. By contrast, the log for my second test run—where the IP address the "client" was using did match the one defined in Sources—says "Can't read state info, error -519 (network communications failed)" when I too-rapidly shut down the MBP after the "backup server" had successfully finished the backup stage. Thus it's the Piton Name Service that needs to be fixed. As I've predicted elsewhere, StorCentric will have to force this to be done for the forthcoming Drobo variant of the "backup server"—so hordes of new Retrospect users won't have to learn how to set up Direct access to avoid -530 errors.
  10. Nigel Smith

    Yet another -530 client not found error

    You're viewing the Piton protocol too narrowly. It's the protocol(s) by which server and client communicate and includes discovery, access and data transfer (amongst other things) and is used in the unicast (defined IP client, as above), broadcast and multicast "location" (using that since "discovery" usually means "first time ever finding a client" in RS) of a client on the network and all subsequent communication. You'll have to do a lot more digging with eg WireShark to know exactly why you saw what you saw -- I'd expect it to throw a -530 (because the client was still listening on x.x.x.202:497) or just work, not throw a -519 -- but I suspect that permanently binding the client to x.x.x.201 with "ipsave" might eliminate the issue. -530 is quite clear -- the client couldn't be found. That -519 is separate implies that the client could be found but then there was a problem, but I'm probably reading to much into it. All we really know is that "network communication failed", for whatever reason.
  11. DavidHertzberg

    Yet another -530 client not found error

    I am in fact doing what Nigel Smith calls "belt-and-brace" ("braces" are British English for what the rest of us call "suspenders") ; I have entries both in my router's MAC table and my MacBook Pro's System Preferences->Network->Locations for both my Moshi USB-C-to-Ethernet adapter port (X.Y.Z.201) and my CalDigit TS3 Plus Ethernet port (X.Y.Z.202)—X and Y and Z are "seekrit" numbers you couldn't 🤣 possibly guess.. My "Automatic" Location has the CalDigit port enabled, and my "Retrospect Priority" Location has the Moshi port enabled. On my Retrospect Mac 16.6 "backup server", the Source for the MBP is defined with Add Source Directly as X.Y.Z.201—and my MBP usually uses the "Retrospect Priority" Location although the "Automatic" Location would give me slightly-faster Ethernet via Thunderbolt 3. Yesterday afternoon I did a couple of tests, using my handy-dandy NoOpSun-FriBackup script with the No Files Rule (Selector in Retrospect Windows). I first switched my MBP to the "Automatic" location and ran the script, which immediately issued a -519 error for the MBP. (That error number is an argument for my side in the 6-months-back dispute with Nigel Smith over whether the "backup server" uses the multicast Piton Protocol in finding a Source defined with a correct MAC address using Add Source Directly. My "backup server" would have found the MBP by name if it had used the Piton Protocol, or it would have issued a -530 error.) I then switched my MBP's Location to "Retrospect Priority" and reran the script. It started to run fine, until I too-rapidly shut down the MBP while the script was still making its 4-minute run—eliciting a "backup server" -519 error. (Point for Nigel Smith in the 6-months-back dispute; "the client was found, then disappeared".) Getting back to Nigel Smith's final warning, x509 should certainly find out what range for fixed IPs his router allows. I believe I checked the manual for my ancient Verizon Quantum G1100 "gateway", but I simply set up fixed IP addresses starting with X.Y.Z.200.
  12. Nigel Smith

    Yet another -530 client not found error

    Would just warn that different routers' DHCP servers behave in different ways. Some treat the address blocks reserved for statics as inviolate, some will continue to offer those addresses when no MAC address has been set, etc. I always belt-and-brace, putting MAC addresses in the router's table and setting static IPs on the clients, when I need a definitely-fixed IP. Also, some routers force a certain (often limited) range for statics and others let you do as you will, so check your docs before planning.
  13. DavidHertzberg

    Yet another -530 client not found error

    x509, I did a little Googling, and—just below the heading "How to assign static IP address using Settings" [my emphasis] on this Pureinfotech article on "How to set a static IP address on Windows 10"—is a section "Assigning static IP address for Wi-Fi adapter". So you wouldn't have to do scripting or get into your router's assignments table, but—from what you and mbennett have said up-thread—a Windows update might silently reset any such settings. Everyone, I went searching for this because I couldn't believe that modern Windows doesn't have the equivalent of the System Preferences->Network->Location dialog in macOS, for x509 to use with his Wi-Fi. This facility was developed in OS X to provide for Mac laptops that might be moved to different locations (hence the name) having different LANs, and is available as far back as my ex-wife's ancient Digital Audio G4 booting 2003's "Panther" OS X 10.3. Although my MacBook Pro never leaves my study desk, I discovered Location after I bought a CalDigit Thunderbolt Station 3 Plus dock to connect it via a KVM switch to a an external monitor. When my Apple 27-inch LED Cinema Display loses the video signal, it goes into a "deep sleep" mode—and needs to be "goosed" to wake up. If my KVM switch is still set to take input from the CalDigit dock, it has lost the DisplayPort video because I shut down the MacBook Pro the input was indirectly coming from—so rebooting the MBP results in the dock "goosing" the monitor. If OTOH my KVM switch was formerly set to take input from the G4 via converted DVI, it has lost the DisplayPort video because I switched it to an awake MBP—and only rebooting the dock results in the dock "goosing" the monitor. In that second case I originally found that detaching and re-attaching either end of the Thunderbolt 3 cable between the MBP and the dock was sufficient to reboot the dock—as was unplugging and re-inserting the dock's power cord, but a woman at Apple Tech Support suggested that a method which wouldn't violate any mechanical port-insertion limits would be to plug the dock into a surge protector whose sturdy switch I could use to reboot the dock—so I'm doing it. This created a problem with using Retrospect to simultaneously Recycle backup my MBP—using version 16 and an Ethernet connection wired via MoCA (inter-room Wi-Fi is slow in my apartment) to a "backup server" in another room—and my G4—using version 6.1 and a DAT tape drive SCSI-cabled directly to the G4. Using the KVM switch to switch the Cinema Display from the MBP to the G4 works fine, because the G4 automatically "gooses" the monitor out of "deep sleep". However using the KVM switch to switch the Cinema Display from the G4 to the MBP was killing the MBP's backup, because power-cycling the CalDigit dock was interrupting its Ethernet connection. My solution was to create a Location named "Retrospect Priority" in addition to the "Automatic" one. In "Retrospect Priority" the MBP's Ethernet connection is via a Moshi USB-C-to-Ethernet adapter (used with iffy StarTech USB32DPPRO before CalDigit), and the Ethernet connection through the dock is disabled—so power-cycling the CalDigit won't interrupt the MBP's Ethernet connection. I took the trouble to explain this because, now that external docks are becoming popular, other administrators with DisplayPort or Thunderbolt 3 monitors in their installations may have similar problems. The "deep sleep" feature is common to many such monitors—not just Apple's, and represents monitor manufacturers taking advantage of a DisplayPort (and Thunderbolt 3, which merges DisplayPort + PCIe + DC power) characteristic to lengthen monitor life—ignoring DP cable swappers and KVM switchers. HDMI monitors also have a "deep sleep" feature, but it can be disabled in some models.
  14. DavidHertzberg

    Retrospect 17 and low-end users

    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. x509, The x.5 release of major version x is usually in late August or early September, and includes new Retrospect features. The fact that 17.0.2, consisting of bug fixes for big installations, was released in mid-May means IMHO there isn't going to be a release 17.1; I'd love to be proven wrong in this. My information is that engineers are hard at work on the variant of the "backup server" running on (beefed-up) Drobo hardware  (and possibly other Linux-based NASes), because it sounds as if that's the main reason StorCentric bought Retrospect Inc.. If OTOH you're looking for improvements in the Client programs that would overcome the -530 problem and difficulties with Windows 10, my feeling is that Retrospect "Inc." engineers won't be allowed to put in that effort until StorCentric management sees the Drobo variant of the "backup server" operating in 17.5 trying to backup Windows "clients"—and realizes that there are serious Client problems for some administrators. So my expectation is that we won't see the kind of upgrade you—and for that matter I personally—want until the release of Retrospect 18.0 in March 2021, or possibly a release 17.6 in December 2020. Sorry to be so pessimistic. 😒
  15. Since I personally don't have scripting skills beyond Windows CMD files, and not very good even at that a fixed IP for all clients (as David suggests) is probably the best approach for me. Right now, I'm busy with covid projects from my wife for fixing up things around the house, but I will get into my router's IP assignments table soon enough. To reprise an earlier comment, networking is the weakest part of Windows 10, since there is no one screen or set of screens to control all the entire TCP/IP stack or all the processes that can affect networking. Add to that the ways that a Windows update can silently reset some settings, and I spend way too much time on this issue. Retrospect client discovery is only one relatively small aspect of the overall issue. In my humble home LAN, all Retrospect clients and the server are wireless. One less issue.
  16. x509

    Retrospect 17 and low-end users

    If there were improvements in the UI of the client, as well as its performance, then I would have a solid reason to upgrade now. Otherwise I'll wait until 17.1 or 17.5, whatever its called. Any idea of when that upgrade might be released?
  17. DavidHertzberg

    Applicability of v17 fixes to earlier releases

    rfajman, It's first worth noting that two Engine improvements in Retrospect 17.0.0 are for "10x Faster ProactiveAI" and "Restore Preflight". Years ago you were talking about using Proactive, and administrators have been screaming for Restore Preflight for years. Three out of the four Engine improvements in 17.0.1 are for Remote Backup—which was a new feature in 2018 but has suddenly received administrator attention because of COVID-19 Work From Home, and the other Engine improvement is for Restore Preflight. Second, let us consider the 17.0.1 bug fixes that doubtless apply to earlier major versions of Retrospect Windows—as per the cumulative Release Notes. These are easy to identify, because bug #8547 is a "milestone" that was identified by Tech Support the same day 17.0.0 was released (it's debugging code that was erroneously left in on 3 March). There are 14 bug fixes in 17.0.1 with numbers lower than 8547; these must fix bugs in 16.6 and earlier. Other than #8547 itself, that leaves 16 bug fixes in 17.0.1 that may be for bugs introduced in 17.0.0; OTOH they may instead be for later-discovered bugs in earlier major versions. Of these, 7 bug fixes are for Storage Groups, a feature designed to work with Proactive that was not changed in 17.0.0. Of the remaining 9 bug fixes, 1 was for NAS Shares (3 "fixes" in 17.0.0) and 2 were for ProactiveAI and 1 was for Restore Preflight. That leaves 5 remaining bug fixes for Backup and Install and Configuration and Rebuild, which could have been for bugs introduced in the course of un-noted 17.0.0 changes. So the short answer is that at least 21 bug fixes out of 31 in 17.0.1 also apply to earlier versions of Retrospect, not bugs introduced in 17.0.0.
  18. Earlier
  19. DavidHertzberg

    Retrospect 17 and low-end users

    rfajman, I looked at your posting history, which you can get to by first clicking the green circular icon containing 'R' (in your case) to the left of any of your posts and then clicking "See their activity". You asked this question for both Retrospect Windows 15 and Retrospect Windows 16. Your were also at one time talking about using ProactiveAI scripts, which were substantially speeded-up for finding the next-available source computer in Retrospect Windows 17.0.0. BTW, cloud backup is a feature added in Retrospect Windows 12; that's 4 major releases ago.. For some of us, March 2016 isn't "relatively recently". 🤣 P.S.: If you're not using Proactive (and you're almost certainly not using Remote Backup), the new feature that would be useful to you might be added in 17.5. As I said in this post in another thread, it looks as if Product Management decided "there's no possibility certain new major features are going to be ready in another week, so let's 'quick-ship' a 17.0 release containing bug fixes plus the three new features that are ready—and then follow up ASAP with a 17.1 or 17.5 release with the other new features." You may not appreciate one future major new feature, which IMHO will likely be a rewrite of the 1990s-designed and klunky built-in GUI for the Retrospect Windows "backup server". But lots of other administrators have complained about that GUI, so they'll probably feel a new one—which ditches Auto Launching and ditches a separate GUI for Immediate operations—is an improvement. It would end the need for two greatly-different User's Guides for the Windows and Mac variants of Retrospect. The real reason IMHO: similar-look GUIs will aid a variant of the "backup server" running on (beefed-up) Drobo hardware (and possibly other Linux-based NASes)—which StorCentric's top management has said it wants, controlled by a GUI Console running similarly on Windows or Mac machines on the same LAN and connected to the "backup server" via a NAS webserver.
  20. Does anyone have any idea of how many of the numerous fixes listed for v17 also apply to earlier versions of Retrospect, rather than being for bugs introduced in v17?
  21. rfajman

    Retrospect 17 and low-end users

    Yes, of course. However, the reason that I asked the question is that new features can be added that would be useful to me. For example, I am using the cloud backup that was added relatively recently. It's also possible that important bugs could be fixed.
  22. Lennart_T

    Retrospect 17 and low-end users

    Don't try to fix what isn't broken. If Retrospect is doing everything you need it to do, there is no reason to upgrade.
  23. There are pros and cons to both approaches. But consider this first -- how will you restore your system disk if there's a disaster, have you tested it, and does splitting it into separate "Favourite" folders result in way more work than the benefits are worth?
  24. Nigel Smith

    Yet another -530 client not found error

    Of course -- would I offer anything simple? 😉 More seriously, if the client is "confused" by network interfaces when it starts up, can we guarantee it won't also be "confused" on a restart? While it should be better, since it is restarting when there is (presumably) an active interface, it might be safer to explicitly tell the client what to do rather than hoping it gets it right. And a batch script triggered by double-click is a lot easier for my users than sending them to the command prompt. As always, horses for courses -- what's best for me isn't best for a lot of people here, but might nudge someone to their own best solution.
  25. 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. denno, Storage Groups were previewed in the fall of 2018, and officially released in March 2019. I was given a feature justification shown in the third paragraph in this March 2019 post, but that justification left out a key element that is still IMHO inadequately documented in the Knowledge Base article—which has been recently copied into the User's Guides. That element, which was not documented in the Forums until this April post, is that "parallel backups" means a single Proactive script can be simultaneously backing up as many as 16 combinations of machine and drive to different Media Set components of its destination Storage Group. This is IMHO a clever riposte—using the multi-threading power of a modern "backup server" machine—to other more-complicated (and more-expensive) client-server backup applications, which require an installation needing equivalent multi-threaded random backup to interpose "appliances" backed up to on multiple "clients" own schedules—as if to an Airport Time Capsule (not necessarily using WiFi )—in between those "clients" and a "backup server" that backs up the "appliances" via periodically-run scripts . As shown especially in the Retrospect Windows cumulative Release Notes, the engineers have since been busy fixing Storage Groups bugs—most of them no doubt pointed out in administrators' Support Cases. The problem is that the engineers have not as yet provided any GUI for accessing the component Media Sets of an existing Storage Group, except for Restore in Retrospect Windows and for using custom Rules/Selectors in operations that can be scripted (i.e. not Rebuild). They may have planned to provide that GUI in the fall of 2019, but any such plans were upended by the StorCentric acquisition on 25 June 2019. Storcentric upper management has publicly announced it intends to build a Retrospect "backup server" that runs on at least a beefed-up Drobo version of a Linux-booting NAS, and my information is that Retrospect engineers are busily at work implementing that. Since NASes don't have their own monitors and keyboards and pointing devices, it seems obvious such a "backup server" would have to be accompanied by a Mac and Windows Console that connects to it over a LAN using (probably) a Web server on the NAS. And lo and behold, a Retrospect Console Preview was released on 3 December 2019—looking rather like a dumbed-down existing Mac LAN Console but also running on a Retrospect Windows "backup server" (where IMHO it'll be better when fully implemented than the 1990s-designed built-in GUI). It doesn't take great "tea leaf reading" skills to predict that it's unlikely further enhancements are going to be made this year to the existing Mac Console GUI. So—if you want to use Storage Groups—you'll for now have to live within the confines of the existing half-baked GUI. Until Retrospect 16 killed the Legacy Client, I was backing up 4 drives in two "client" machines plus two local drives and a Favorite Folder onto three rotated-weekly portable disk Media Sets. Now I'm instead backing up the 3 drives on my old G4 Digital Audio machine to 3 rotated-weekly DAT tape Backup Sets, using Retrospect Mac 6.1. I have a home installation, and I rotate a portable disk and a DAT tape off-site once a week; YMMV. Would describing your "problems with my existing media sets" get you better answers?
  26. It's not clear to me what's in Retrospect 17 for me, a simple user of the Desktop/Professional version with just two clients in my own office. I'm on 16.6 now. I think I asked the same question about 16.0 (maybe it was 15). I held off upgrading for quite a while. Eventually I did upgrade after some upgrades added things that I could use. Right now, though, I don't see it with 17.
  27. Another small item: it seems to me that how Retrospect flags errors and warnings in the log could be improved. For example: * File "C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Cache\2ac3ce7c582a3dab4663c700b7a6ee798b09349b\2a60267e790942dfdf2fe4407cee93ef8039457339704e44726bae6683da5335": didn't compare > Trouble reading files, error -519 (network communication failed) In the first message, "*" is really a yellow triangle with an exclamation point inside. In the second message, the ">" is red, but the yellow triangle stands out far more to me. Also, a warning that occurs a thousand (or whatever) times should be considered to be an error.
  28. Here's a trivial idea: sometimes I need to rerun a scheduled backup soon after Retrospect has been restarted. I don't want to enter the password, because it is very long and very random, so I schedule a one-time backup to run right away. It would be nice if it didn't take quite so many steps to do that. For example, after clicking on "Add a New Scheduler," one is given three things that can be checked, "Day of Week," "Repeating Interval," and "Single Date" and then buttons for "OK" and "Cancel." Instead of that, how about having these buttons: Day of Week Repeating Interval Single Date Cancel Thus an unnecessary step is eliminated. It would also be nice to have one more button, "Now," to schedule an immediate backup, so it wouldn't be necessary to adjust the starting time.
  1. Load more activity
×