Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by DavidHertzberg

  1. Nigel Smith,

    You're right on both counts; I didn't read Jan Löwe's second post in this thread anywhere nearly thoroughly enough 😢 , probably because he posted it while I was writing a post myself.  Please accept my apologies.

    However it appears that the analysis in the second point of my most-recent post isn't a total waste; the paragraph below the quote pinpoints what the bug is.  When the destination of a Proactive script is a Storage Group, the "backup server" should immediately generate all "child" Proactive scripts—placing them into the "Waiting" queue  in defiance of the second quoted Note.   That way each "child" script for which there is initially no available activity thread would start to execute as a preceding "child" script finished executing—making an activity thread available.

    Jan Löwe,

    Please ASAP do the test Nigel Smith suggests in his last paragraph of the post immediately above this one, and submit a Support Case.  It's now clear that it's really for a bug in an existing feature, so here's how to do that.  I'd submit it myself, except that my past experience has shown that Retrospect Tech Support will ask the person who submitted the Support Case to test at least possible bug fix—and I no longer have enough "client" machines in my installation to do that.  All you need to do for the Problem Statement is to copy the longest paragraph in your second post in this thread, and then append the result of that further test as an Additional Note.

  2. Nigel Smith,

    First, I don't know what you mean by "Mac script" and "PC script" in Jan Löwe's situation. He says all his scripts are running on a macOS Catalina "backup server", and there's nothing that says a single Retrospect script can't backup "clients" of both OS varieties.  In fact from 2001–2004 I used to include as a "client" the drive on my Windows 95 "grey box" PC, which my bosses' boss had forced on me for work-from-home use so I wouldn't infect the rest of the office with a recurrence of shingles (his mother was Native American, and although he was a graduate of New York University he had certain non-modern health concepts), in a weekly Recycle Backup script—running on my Mac "backup server"—that also included my wife's and my Mac "clients".  Although I don't use Proactive scripts, I'd expect that to apply to them as well.

    Second, I don't think anything in the Engine's handling of multiple activity threads—execution units in Retrospect Windows parlance—has changed with the introduction of Storage Groups.  Because Engine multi-threading was introduced in Retrospect Windows 7, here's a quote from page 161 of the Retrospect Windows 7.5 User's Guide (belatedly copyrighted in 2011)—whose explanation is simpler than in later editions:


    NOTE: The software allows up to 8 [16 since at least November 2012] concurrent executions, provided the computer has enough memory and backup devices to support such a configuration.

    When you're using multiple execution units [Retrospect Windows term for activity thread], you can run multiple operations at the same time. If you start more operations than there are available execution units, the additional operations are placed in a “Waiting” queue until an execution unit becomes available. See "Waiting Tab" on page 156. 

    NOTE: Proactive Backup scripts and User Initiated Restore operations do not go into the waiting queue. They only launch when an execution unit (and other required resources) is available.

    IMHO the Notes would apply to a Proactive script whose destination is a Storage Group.  Such a script simply attempts to launch a "child" Proactive script for each client-volume in the script's Sources; if there isn't an available activity thread, the corresponding "child" single-source Proactive script's launch goes into the "Waiting" queue—but only if the second Note doesn't apply).  When such a "child"  script has backed up its single Source, what's left for it to loop on?  One solution would be if a multi-Source "parent" Proactive script were also running—looping while monitoring completion of the single-Source "child" Proactive scripts, but I can see nothing in pages 37–45 of the Retrospect Mac 17 User's Guide that says that feature exists yet.  Don't expect it to be added soon.  It won't be needed if the second Note quoted doesn't apply to a "child" Proactive script; Jan Löwe should test this.

    Third, I agree with you about the aptness of the Retrospect term "grooming"—which appears in the Retrospect Windows 7.5 UG and thus can have originated no later than 2007.  However I think Jan Löwe's objection is similar to the reason the bossy Retrospect developer had for banning the use of the term "snapshot" in the Retrospect Mac 8 UI.  Both terms have acquired other more-popular connotations, in criminology for "grooming" and in Computer Science for "snapshot".  Welcome to the wacky world of English language development. 🤣

  3. Think nothing of it, Nigel Smith. 😄  My preceding post started out as a correction of your preceding post, but then I realized that Jan Löwe's fundamental problem seemed to be (he's just made a second post) that he didn't understand the use case for Proactive scripts—whether following the pre-2018 algorithm or the "AI" (I agree with him that "AI" is a bit of a naming stretch for what is really an "expert system") algorithm.  I'm running 16.6.

    Jan Löwe,

    Don't worry about posting in the wrong Forum; over the years many Retrospect Mac administrators have been confused by the "Professional" title for this Forum. 🤣   I'll change the User's Guide links in my previous posts to also reference the Retrospect Mac 17 UG page numbers.

    If your two Proactive scripts are each spawning multiple Activity Threads, then their destinations must be Storage Groups.  What you don't yet realize is that Storage Groups, with their current limitations, are basically a kludge intended to save administrators from the bookkeeping that would be required for creating multiple Proactive scripts with explicitly-separate (to avoid conflict) Media Set destinations.  AFAICT the use of a Storage Group currently doesn't create any "parent" Proactive thread that is looping while keeping tabs on the progress of the "child" Proactive activity threads; the looping is in each "child" thread—but that has AFAIK only one Source machine-volume so the looping is only theoretical.  It would be wonderful if there were such a "parent" thread, but that new feature—which your Support Case should suggest—would require inter-process communication that would AFAIK be different for Retrospect Mac vs. Retrospect Windows (challenging the common-code-since-2009 foundation of the Engine).  I've been told that the Retrospect "Inc." staff is now busy with meetings centered on StorCentric management's requirements, so don't expect that feature to be added soon.

    Therefore IMHO what you should do is to go through the bookkeeping of creating multiple scripts.  Some Proactive scripts can be for "client" machines that you know have been backed up before—possibly for "departmental" or "arrival-spread" subsets, and may use a Storage Group destination to enable parallel execution—which the Engine will keep track of but without looping.  OTOH each "new client" machine should have its own separate script with its own separate destination Media Set, and IMHO that should be a one-time-scheduled Backup script—with a Recycle media action—that can keep running over a daily boundary until it finishes.  After it finishes, you can run a Copy Media Set operation to copy the Media Set into the Storage Group; that run can overlap with other script runs using the same Storage Group for other "client" machines, and  can then re-use the same Media Set with a Recycle media action for your next "new client" Backup.  My warnings in my third post in this thread about Storage Group limitations continue to apply, especially for Retrospect Mac—where the GUI for accessing Storage Group component Media Sets doesn't exist yet.

    BTW, are you in real life the director of a laboratory in Cambridge UK?  (Or did you just pick his name as a Forums  "handle"?) Just asking because it's helpful to know something about an administrator's installation; I've been quite open about my own.  Nigel Smith's installation may resemble yours.

  4. Jan Löwe,

    This post will be the last of my thoughts on your problem, unless and until we get further information from you.  That information must include how many Proactive scripts you currently have scheduled, and what those schedules are.

    What you are asking in your OP is whether we agree that "that's poor behaviour of the scheduler that should make jobs active whenever required AND possible, and should prioritise those clients that have never been backup up to the current set."  I don't agree, because I think the use case for Proactive scripts described in the first paragraph of my second post in this thread has satisfied the needs of many administrators for over 20 years.  You OTOH have a different use case that prioritizes clients that have never been backed up to the current Backup Set.   I've explained in the remaining paragraphs of my second post how you can achieve that prioritization using separate scheduled Backup and Transfer scripts, and I've explained in my third post in this thread how you might be able to achieve that same prioritization using Storage Groups—despite their limitations. 

    What you may not fully appreciate, because the explanation on pages 197-198 of the Retrospect Windows 17 User's Guide is unclear (unlike page 108 of the Retrospect Mac 17 UG), is that the longest you can schedule a Proactive script is from midnight to midnight on a particular day.   A daily Proactive script starts again with a new "backup window" on its next scheduled day,  where—per "Algorithm" step 7 on page 191—"Sources with faster previous backups will be backed up sooner than sources with slower previous backups."  The "Algorithm" sub-section (which is a duplicate of the Knowledge Base article I have linked to in up-thread posts) doesn't explain what priority is given to a brand-new source on its first Proactive backup.  However the section lead on page 190 says "With ProactiveAI, backup scripts will optimize the backup window for the entire environment based on a decision tree algorithm and linear regression to ensure every source is protected as often as possible", which clearly means per step 7 that a new source that has been backed up at least once for several hours will get lower priority than an old source whose previous Normal incremental backup took a shorter time.

    That's why per your OP "it takes many days for all clients to be backed up for the first time (while others get incrementally backed up in the meantime)".  As I said in the third paragraph of my second post in this thread, you could file a Support Case asking for an option that would implement "Sources with faster previous backups will be backed up later than sources with slower previous backups."  But I doubt the feature request will be accepted, for the reason I've given in the second paragraph of this post.

  5. Jan Löwe,

    When I finished writing the first of my two up-thread posts, I still thought your problem was in not having enough "execution units" to provide sufficient parallelization of Proactive "client" backups.  That accounts for my next-to-last paragraph in the post.   However. as I started writing the second of my up-thread posts, I decided your fundamental problem is doing from-scratch backups of "client" machines via Proactive scripts that also do Normal backups of other "clients".  Let's consider this in terms of what Nigel Smith said up-thread:


    A Storage Group is, in essence, multiple Media Sets [Retrospect Mac term for Backup Sets] (one per client/volume) in a wrapper -- similar to above but with Retrospect doing the hard work and presenting you with a single UI element to use in your operations. So a single Proactive script can back up up to 16 clients in parallel to a Storage Group.

    The maximum—not just the default per mbennett—number of "execution units" that can run simultaneously on one Retrospect "backup server"—with 20GB RAM—is 16 , whether the "execution units" are from explicitly-separate scripts or in-parallel "execution units" implicitly generated by using a Storage Group as the destination for a Proactive script—as Nigel Smith suggests.  (Page 325 of the Retrospect Windows 17 User's Guide and page 166 of the Retrospect Mac 17 UG still say 8, but the fix for bug #1366 shown in the cumulative Retrospect Windows Release Notes shows that had been increased to 16—which I've confirmed in my Preferences ->General for Retrospect Mac 16.6—by November 2012.)  Your OP says you have to back up about 30 "clients", and when I attended primary school 30 was greater than 16—so there's no way you can back up all your "clients" at once.

    As I said in the third paragraph of my second up-thread post, a fundamental part of the ProactiveAI decision tree algorithm is that "Sources with faster previous backups will be backed up sooner than sources with slower previous backups."  I don't know whether a Proactive script that has completed one of its incremental "client" backups will release the "execution unit" for that backup while a from-scratch backup using the same Storage Group destination continues.  I suspect it will, but you're going to have to test that out with a couple of Proactive script runs that cover all 30 "clients" using the same Storage Group destination. 

    If it works, you can have one Storage Group for all 30-odd "clients", and not run—as I suggested in my second up-thread post—separate scripted Backup runs followed by Transfer Backup Sets operations for the from-scratch backups.  However be aware that, to avoid a confusing GUI mess, the Retrospect engineers required in 2018 that a Storage Group be defined with its first Member for all component Backup Sets on a single HDD or cloud equivalent.  At least one administrator posting on these Forums has reported a problem with the first Member for one component Backup Set apparently prematurely running out of space.  It's not yet clear whether one can define a second Member for an entire Storage Group, or whether one can do this for an individual component Backup Set (which isn't yet an option for a Retrospect Mac "backup server", because the engineers—before their new StorCentric masters diverted them to other tasks in Fall 2019—evidently didn't have time to enhance its GUI to enable accessing an individual Media Set—the Retrospect Mac term for Backup Set—component of a Storage Group).  If one can't,  you may have to Transfer Backup Sets off Storage Group component Backup Sets and re-initialize the components; that would be messier than what I suggested in my second post up-thread.

    Nigel Smith's quote also says that a Storage Group creates a separate component Backup Set for each volume attached to each "client" machine—I've verified that.  So if some "clients" have more than one volume attached, you'll have more than 30-odd component Backup Sets in your Storage Group.

  6. On 9/24/2020 at 11:48 AM, Jan Löwe said:


    .... The new ProactiveAI is great because it makes good use of the capabilities of the  backup server machine and its fast network connection by allowing parallel backups from much slower clients.

    Now, when looking at what is happening, the scheduler seems to make a number of jobs active and then waits until ALL those jobs are finished, before starting another batch. That wastes a lot of time and resource and has the effect that if one client takes days to finish, everything else is held back. If doing a complete backup once in a while, it takes many days for all clients to be backed up for the first time (while others get incrementally backed up in the meantime).

    To me that's poor behaviour of the scheduler that should make jobs active whenever required AND possible, and should prioritise those clients that have never been backup up to the current set.

    Many thanks for your thoughts!


    Jan Löwe,

    Proactive scripts were developed in the late 1990s for AFAIK the following use case: Sally SuperSalesperson visits the central office irregularly on a non-predictable schedule.  You as administrator want to do a Normal incremental backup of Sally's laptop whenever she cables it up (or connects via WiFi) at the central office, so that the organization won't lose her valuable data if her laptop is stolen or is destroyed in a car crash.  The organization has many female and male SuperSalespersons, each with his/her own schedule for central office visits—schedules which tend not to overlap.  It is assumed that Sally's laptop was given a New Backup Set backup via a Backup script after the initial organization software needed for her position was installed, before her boss first handed it to her.

    So why are you "doing a complete backup once in a while" via a Proactive script?  A Retrospect "backup server" can run a maximum of 16 scripts in parallel "execution units" (page 211 of the Retrospect Windows 17 User's Guide and page 166 of the Retrospect Mac 17 UG still say 8 because they haven't been updated as of November 2012), and that's on a machine that has 20GB or more of RAM.  Have each employee with a new "client" machine leave it at the central office overnight, so you can use it as a Source for a scheduled Backup script with the New Backup Set action to its own backup set—which you will then copy via a Transfer Backup Sets operation (pages 132-134 of the Retrospect Windows 17 UG, pages 118-120 of the Retrospect Mac 17 UG for Copy Media Set) to the backup set which will be the destination for its Proactive script with the incremental Normal action .

    If you read "Algorithm" step 7 in this Knowledge Base article, you'll see "Sources with faster previous backups will be backed up sooner than sources with slower previous backups."  That's a feature of the 2018 "ProactiveAI" decision tree, and it explains why you complain "it takes many days for all clients to be backed up for the first time (while others get incrementally backed up in the meantime)."  Here's what to do if you want to attempt to get this feature changed, but I can assure you that the Retrospect engineers went to a lot of trouble to change the late-1990s scheduler algorithm that did have the prioritizing you want.  You could try asking for an option to invert algorithm step 7, but who besides you would want it?

    BTW, in my simple home installation I use only Backup scripts; I just boot the "backup server" to backup my single "client" machine at or after 3 a.m..

  7. 21 hours ago, Jan Löwe said:


    Just went back to Retrospect after many years, to backup about 30 clients. The new ProactiveAI is great because it makes good use of the capabilities of the  backup server machine and its fast network connection by allowing parallel backups from much slower clients.

    Now, when looking at what is happening, the scheduler seems to make a number of jobs active and then waits until ALL those jobs are finished, before starting another batch.....




    Jan Löwe,

    First let's get some preliminary questions out of the way: 

    How long ago did you last use Retrospect?  Was it before 2009, when Retrospect Mac was resurrected with a different User Interface from Retrospect Windows after being end-of-lifed?

    Are you running Retrospect Windows on your "backup server" machine, or Retrospect Mac?  The "backup server" Engines have common code, but the User Interfaces have different terminology and look different.  (An old-timer in Sales says a key member of the team creating Retrospect Mac 8 was very bossy, and insisted that the old terminology and Graphic UI had to go.  Mostly because Retrospect Mac 8—having been developed in a management-imposed rush—was very buggy and incompatible with older machines and existing backups, it got such a bad industry reputation that the Retrospect team decided not to make the corresponding changes in the Retrospect Windows terminology and UI.)  Because you posted in the Windows—Professional ("Professional" as distinct from "Express"—a simplified Retrospect application for  Windows that is no longer sold) Forum, I'll assume your "backup server" runs Retrospect Windows and use that terminology—which is a slight problem for me since I use Retrospect Mac.

    Precisely what version of Retrospect Windows or Retrospect Mac are you running?  You should upgrade ASAP to 17.5.0.x.

    When you say "parallel backups", do you mean from different scripts?  "jobs" isn't a Retrospect term, and an individual Retrospect script cannot backup multiple "clients" in parallel—unless the script's destination is a Storage Group instead of a Backup Set.

    Are you using the Remote Backup feature?  It was developed in 2018 for use by a centralized organization with a few employees/contractors working in scattered far-away places, but has been recently hurriedly adopted by centralized organizations that have sent many employees off to Work From Home nearby.  The implementation of Remote Backup has a kludge that didn't matter much in 2018; IMHO you shouldn't use it if you don't have to.

  8. Thanks, Nigel Smith

    I did what you said in your second paragraph directly above, since I wanted to uninstall Retrospect from my "client" MacBook Pro—where I had installed it per my second paragraph in this up-thread post.  After I replaced my Mac Pro's PRAM battery, I had used System Preferences->Retrospect (not System Preferences->Retrospect Client) to stop the Engine on my MBP—so I didn't want to start the Engine (->run scheduled scripts) to Uninstall itself.

    So I did "Export server installer and uninstaller" to a thumb drive connected to my Mac Pro, then took the thumb drive over to to my MBP and ran the un-Zipped "Retrospect Support.app from there.  Before doing that I followed the procedure on pages 196-197 of the Retrospect Mac 17 User's Guide (which is on a different page in the Retrospect Mac 16 UG; I was uninstalling Retrospect Mac 16).  Note that what page 197 says is ~/Library/Preferences/com.Retrospect.plist has an extra "Retrospect" as part of the name.


  9. wanderlust,

    The head of North America Sales says someone was trying to do what you want to do, but was stymied because the Media Set was encrypted and the password wasn't available.  If that was you and you are a legitimate relative, I'm sorry.  If OTOH that was you and you are a hacker, you've provided a security lesson to us all.

    Now I'll reveal what I should have written in the second paragraph of this up-thread post:  You should first find out the name of the Media Set—I'll call it "Whatever" for this example— that was backed up onto your relative's hard drive, by looking at the name of the folder inside the "Retrospect" folder on it.  You should then start Retrospect and—clicking Media Sets in the sidebar—Add (not Rebuild) a Media Set with that same name "Whatever".   Add's default places the new Catalog File inside Library->Application Support->Retrospect->Catalogs on your own Mac.  When Retrospect asks to Add a New Member for "Whatever", you should select the Retrospect->"Whatever"->"1-Whatever" folder on your relative's hard drive.  Don't Add any more Members.

    I've previously done this (how did I navigate to Member?), but haven't newly Removed and re-Added an existing Media Set on my own "backup server".

  10. On 9/15/2020 at 3:23 PM, Nigel Smith said:

    Manual ipsave has been working for years, well before Remote Clients were even thought of. Particularly useful for dual-NIC machines where eg the primary interface (which RS Client will generally try to bind to) is the general network or "outside world" while the secondary (which you want RS Client to bind to) is connected to a backup or "internal" network. It's most useful for machines with static IPs since you just do it the once.

    As said before, it's also a good work-round for the "confused client" issue for those who don't allow their users to turn the Client off-and-on-again. But it is more involved since the user (or a script) has to determine the IP address to be used.

    Note that pretty much anything done server-side will not help because the "confused client" is rarely bound to an address that the server can reach.

    Nigel Smith,

    I'm sorry my last up-thread post consists of four lengthy paragraphs.   I felt I had to present my alternative proposals side-by-side in the same post, in order to avoid having the reader bounce back-and-forth between different posts.

    First, with regard to all my paragraphs except the third, let's go back to what "came out of the horse's mouth" on 5 SeptemberMrPete said:


    2) I have no comment on ipsave. Have not played with it as I have no reason to do so. (Yes, my perspective, even scripted: if I'm gonna write an effective script that waits around for a proper and stable dynamic IP, it is much easier in my context for the last two steps to be: (stop service // start service) than (discover the correct ip among possibly 4 or more available ip's // format correctly // issue a proper ipsave) ;) ) 

    The proposal in my fourth paragraph is to first automate what MrPete said—after the quoted word "than"—would be less easy to do manually.  The user (or a script) wouldn't have to do those things if the user's Client had stored within itself—by the "backup server" at Add time—a pre-formatted "ipsave address" for the "backup server".  As I said in that fourth paragraph, if the Client found that automation didn't work then it would know (based on the "hide-and-seek principle") it has to restart itself—because otherwise the "backup server" at that "ipsave address" won't be able to contact the Client at the address the Client is bound to.  This proposal would also get around the messy fact that an administrator who won't allow the user to stop and start his/her Client probably doesn't want that same user to be mucking about with a manual ipsave.

    The proposal in my third paragraph emerged from my memory after I drafted all my other paragraphs.  Despite what you said in the last paragraph I've quoted at the top of this post, the fact is that a Retrospect Mac Locate command did work when I was having trouble with "clients" Added via Use Multicast—precisely in the case that the "confused client's" Client was bound to an address that the server couldn't reach.  Since what's activated by a Retrospect Mac Locate command must be in the Engine's code—which is common to both Retrospect Mac and Retrospect Windows, there undoubtedly is a way of activating a Locate-equivalent that will work for Windows and Mac variants.  Figuring out what—if any (because the Retrospect Windows GUI has been intentionally "frozen in stone" since version 7.7)—command in Retrospect Window's GUI is equivalent to a Retrospect Mac Locate is "above my pay grade", but the engineers should be able to activate underlying common Engine code per the proposal in my third paragraph.

    P.S.: I have now, crediting you, added your post directly below as an Additional Note to Support Case #75559.

  11. d37fc1fe-a25d-4df0-9b52-cb21971f1fde,

    So are you now running Retrospect Mac Single Server Edition on a separate dedicated Mac? Release especially had a lot of bug fixes, as the cumulative Mac Release Notes  show.  Most of the bug fixes are for new Retrospect features, which you're probably not using.

    Unless you're using the new features, I suspect your "troubleshooting and bugs" are mostly because of recent versions of macOS.  For about a week I was running Retrospect Mac 16.6 Engine and Console just fine on my principal-machine MacBook Pro, because the 2010 "cheesegrater" Mac Pro I use as a Desktop Edition "backup server" wouldn't boot (which I eventually fixed with a replacement of its PRAM battery).  However my MBP is booting macOS 10.13 High Sierra, and my Mac Pro is booting macOS 10.12 Sierra; neither version is recent.  I suggest you phone Tech Support—which no longer reads the Forums—at (888) 376-1078‬ ext. 3; if you upgraded to Retrospect 17 in the last 30 days, you're entitled to free personalized support.

    If you don't have a dedicated Mac to use as a "backup server", you can buy an old one for a few hundred US$—although I inherited my 2010 Mac Pro.  OTOH if you can wait until the end of the year, I've read StorCentric management predictions backed up by titbits from Sales that Retrospect "Inc." is developing a variant of the Engine that will run on at least a beefed Drobo—which may turn out to be more expensive than an old Mac but can also be used as a NAS.  You might be able to use the NAS capabilities to replace macOS Server, saving several hundred US$ on your next release of Retrospect by allowing you to downgrade to Desktop Edition.

    When you talk to Tech Support, you can ask them how to uninstall the Retrospect Mac Engine—since its location is apparently intentionally not in the Applications folder.  In the mean time, you can just turn off the Engine in System Preferences->Retrospect.  I just Quit the Console each time I boot my MBP, but I could uninstall that with https://freemacsoft.net/appcleaner/ .

    If OTOH you've actually decided to scrap Retrospect, send me a Private Message and I'll reply with the name of a "push" backup application that—up to its latest version with problems akin to Retrospect Mac 8—is well thought of.  Naming competitor apps in Forums posts annoys the head of R. T. S..

  12. On 9/4/2020 at 1:15 PM, Nigel Smith said:

    His contention is that it's a lot easier for his users to simply turn RS off and on than it is to find the new IP address and use that (somehow!) in an ipsave command -- and I have total sympathy with his view! That would be my default fix too -- as long as (as you've also said) admins haven't disallowed turning off RS.

    Nigel Smith,

    This KB article says "The Retrospect Client uses the ip and ipsave commands to allow users to direct Retrospect backup traffic through a specific IP address if it is available to the machine the client is installed on."  IMHO that means the only way manual ipsave might be made to work is if [1] the "client"'s user knows the the IP address of the "backup server", and [2] the "client" machine—which has "wandered" by either being physically moved to another subnet or by having its IP adapter switched from from a cabled to to a WiFi connection (or vice versa)—can still connect to that "backup server" IP address.  However IMHO that would only work if the "client" is set up as a Remote Client and is backed up with a Proactive script, in which case the Client takes the initiative in contacting the "backup server".

    The -530 problem MrPete and x509 are dealing with is that—as diagnosed by MrPete in this up-thread post—the Retrospect Client for a particular "client" is getting confused,  either by getting assigned a virtual interface by  Windows APIPA or VMWare, or by a security system, or by a router.  That means the "backup server" can't contact the Client for a non-Remote backup.  MrPete's solution is to "unconfuse" a "client"'s Client by restarting the Client.  As for APIPA, this article says "The APIPA service also checks regularly for the presence of a DHCP server (every five minutes, according to Microsoft). If it detects a DHCP server on the network, APIPA stops, and the DHCP server replaces the APIPA networking addresses with dynamically assigned addresses."  So making the "backup server" wait 5 minutes before trying to back up a "wandering" client" might do the trick.

    However I just remembered this trick for "unconfusing" a "client"'s Client, which worked for my MacBook Pro "client" when I was still Adding it to my Retrospect Mac "backup server" with Use Multicast instead of Add Source Directly (using a fixed IP address)—which MrPete has said doesn't solve his -530 problem.  This suggests having the Retrospect Windows "backup server" automatically do the equivalent of Retrospect Mac's Locate (page 51 of the Retrospect Mac 17 User's Guide) 15 minutes before it starts to back up each particular Backup script "client".  If the "client"'s Client has been assigned a virtual interface by  Windows APIPA, the Locate-equivalent alone should "unconfuse" it.  If OTOH the "client"'s Client has been assigned a virtual interface by VMWare, or has gotten confused by a security system or a router, then the Locate-equivalent will fail—in which case the "backup server" should send an e-mail to the Retrospect administrator.  I suggest doing the Locate-equivalent 15 minutes in advance because the Retrospect administrator, upon receiving the e-mail, may have time to fix the "client"'s problem before the script begins to back it up.  Looking at a post in another thread later, I was reminded that the "backup server" already does "reaching out" to Proactive script "clients" per steps 3 and 4 of this KB article —so extending that "reaching out" as a Locate-equivalent for Backup scripts wouldn't be as "effortful" as the first sentence of the next paragraph says.

    But that at first seemed effortful, so here's another way or "unconfusing" a "client"—an extension to the suggestion I made in the second paragraph of this up-thread post:  Have the "backup server" store its own IP address, which I'll call the "ipsave address", in the Client of each "client" machine added to its Sources.  Then, when a "client"'s Client starts up, let it try to contact the "backup server" at the "ipsave address".  If it can't, then the "client"'s Client should restart itself—because it must have been "confused" by being re-assigned an address by APIPA or by VMWare or by a security system or by a router.  (This is based on the "if I can't see you, then you probably can't see me" principle we all learned as children playing hide-and-seek.)   A "client"'s Client successfully contacting the "backup server" for address verification would only be a slight variation of what is already done by a Remote Backup "client".  Possibly there should be a script run option to wait 5 minutes before backing up a "client" whose Client has not contacted the "backup server".

    P.S.: I have now created Support Case #75559, from this post preceded by links to appropriate preceding posts in the thread.


  13. 5 hours ago, wanderlust said:

    Honestly thanks for your help. But that accusation is offensive and ridiculous 


    I did use the word "may"—which I have now italicized—in the second and third sentences of the second paragraph of my latest up-thread post.  So IMHO you shouldn't find the accusation in the third sentence so offensive.

    As to it's being ridiculous, another Forums thread deals with a security threat that is extremely similar to the one I posited in that third sentence, described starting with this post in that other thread.  In fact the help you ask for in your OP in this thread is exactly the question a hacker who had generated an unencrypted Cloud backup of someone else's data per Malcolm McLeary's post would ask, namely the method by which he/she "simply Recreates the Catalogue for this exfiltrated Storage Set [an ancient Retrospect term for what is now termed Media/Backup Set] , on another machine running Retrospect and restores whatever they want." 

    We can Google "Malcolm McLeary" and "Australia", so we pretty much know what he is.  You, OTOH, have provided zero information about yourself in your three posts in this thread, so a little belated suspicion on my part seems perfectly justified.  I realize that many posters on these Forums don't use any variant of their real names as "handles" and conceal their occupation, mostly IMHO because they're consultants or employees who are expected to conceal for whom they're working or to already "know it all".  I fall into neither category, so my "handle" since registering in 2004 has been my real name and my Location is where I live.  You've "never used retrospect before", so why not tell us a bit about yourself to avoid suspicion from people like me?

    If you need further help from me, please post again in this thread after you've talked with the head of Retrospect North America Sales. I made a typo in my second up-thread post, which I've since corrected; I meant "Retrospect application registration".

    BTW when I wrote up-thread "If the RDB data on your backup HDD is encrypted, you won't be eventually be able to do a Restore", I assumed the password for any Media/Backup Set encryption had followed your alleged relatives and their machines to their graves.  We should all take to heart item 5 on page 11 of the Retrospect Mac 17 User's Guide:


    Retrospect supports many types of encryption, including AES-256, to ensure only you can read your backups, even if you store your backups in the cloud. Select "AES-256" and type in a password. Please write down your password. If you lose it, your data will not be recoverable by anyone.


  14. wanderlust,

    I'm sorry that I gave you the wrong Retrospect operation in my up-thread post. 

    However, when I started thinking about your latest post this afternoon, my suspicions were belatedly aroused.  You may in fact be what you said you are in the OP:  the descendant of a Retrospect-using family.  OTOH you may have illegitimately acquired someone's backup drive, and be trying to restore it for illegal purposes.  Please phone the head of Retrospect North America Sales at (925) 231-1313, so he can have the head of Tech Support cross-check your 24 August Forums registration with a prior Retrospect application registration.

    If the RDB data on your backup HDD is encrypted, you won't be eventually be able to do a Restore.  My backup HDDs aren't encrypted, because they're either in my apartment—behind a door with 2 locks—or in my bank safe deposit box.  Maybe I should think about encryption.

  15. wanderlust,

    I'll assume that your family's computer—as opposed to their HDD—is lost or inoperable.  You haven't said whether your family used a Macintosh or a Windows computer,, nor have you estimated how old it was, nor have you said whether you accessed the HDD containing the RDB files on a Macintosh or a Windows computer.  But—since you've posted in the Forum for Retrospect Macintosh versions since 2011—I'll further assume the answers to the questions in my preceding sentence are Macintosh, no more than 9 years old, and Macintosh.  But the answers to the first and last questions could just as well be Windows and Windows.

    Based on that, what you need to do is install the Retrospect "backup server" application on your own computer, Rebuild a Catalog File on it from the RDB files, and use the Catalog File to Restore the files onto another drive—possibly a USB thumb drive if the total size of the restored files is small enough.  I suggest you phone Retrospect Sales at (888) 376-1078 option 2, and ask about whether you can do this with the Retrospect Solo Edition—which I've never used (I have the Desktop Edition because I backup "client" computers as well).  If the Sales person says yes, ask if Solo Edition comes with 30 days of free Technical Support for the US$39.  If he says no, cagily ask about more expensive Editions—which come with a 45-day free trial that may be all you need.

    You may not need the Tech Support, because there are video tutorials here for Retrospect Mac, and here for Retrospect Windows.  The tutorial for Restore using Retrospect Mac is under the "Legacy" heading, and the tutorial for Rebuild is under "Tools", because nobody in Product Management got the over-worked head of Retrospect Tech Support—who makes the best videos at Retrospect "Inc."—to make more recent ones.  No matter; the GUI for Retrospect Mac basic operations hasn't changed since Retrospect Mac 9.

    You probably want to just Restore the files and folders for Users, or the Windows equivalent, because the applications on your family's computer may not still run on your computer.  However you should be able to find applications that will open the restored files on your computer, given that the "lots of memories" are probably in formats that newer applications can still read.

    Good luck! 😀

  16. On 5/29/2020 at 6:24 PM, MrPete said:

    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.)

    Oh it's a long long way, from October [2019] to May [2020].

    Nigel Smith,

    You said directly above:


    We can nudge things with stop/start, ipsave, or your suggested automation, but these are just workarounds until the engineers (from whichever company) fix the problem.

    My impression—subject to correction—is that MrPete is saying ipsave doesn't work in his circumstances, which include a "client"'s network connection changing.  However Retrospect Mac has for years had an option preventing a "client"'s user starting or stopping the Client (pp. 85-86 in the Retrospect Mac 17 User's Guide), and Retrospect Windows has the same option (pp. 236-237 in the Retrospect Windows 17 UG).  AFAIK Product Management had the engineers add this option, years ago, because some ordinary users were suppressing Retrospect backups to avoid slowing down their "client" machines.  My suggested automation would simply enable the Client to do its own stop/start, without allowing or requiring the machine's user to do it.

    I recommend that you avoid holding your breath waiting for either Retrospect "Inc." or Microsoft to come up with a permanent fix to the underlying problem.  Retrospect engineers seem too busy implementing StorCentric's priorities (2nd long prgf.) to do a deep analysis required for a permanent fix.   Microsoft may consider the problem too unimportant for most Windows users to have its own engineers do the analysis and fix.  That's why I suggest the stop/start automation, which may be simple enough for a Retrospect engineer to do while waiting for Drobo hardware to become available again.

    P.S.: What I wrote in the preceding paragraph may have been too pessimistic. 😁  I just talked to someone in Retrospect Sales about another matter, and a fix for bug #8512 is supposed to be in a Retrospect 17.X release scheduled for September–October 2020.  So you can start holding your breath.

  17. pjreagan,

    How about the comparative number of files backed up, vs. the total bytes?  Lots of smaller files means a slower backup and compare than fewer larger files.

    If there's a significant difference in the processor speeds between "AG-04" and "DD-13", that will also affect the Retrospect "client" backup speeds. 

    This post in a 2017 thread, especially the first two paragraphs (the P.S. mostly rules out speed of the "backup server" for "client" files), covers the first part of experiments I ended up doing that have a bearing on this.  This post in that same thread,  and the one following, covers the rest.   This post near the end of the same thread discusses my hypothesis on slowness of "client" backups.

    P.S.: This ArsTechnica Mac forum post says "My 2012 Era iMac with 1Tb Fusion Drive is starting to really slow down. It seems like when the drive is nearly full, the physical drive doesn't like to spin up anymore. ugh."

    • Like 1
    • Thanks 1

  18. MrPete and Nigel Smith,

    I see MrPete diagnosed the Windows Client problem—under "Here are anomalies ..."—in an up-thread post last October.  It's that Windows is assigning an APIPA address, possibly because DHCP services are not available in the "wandered-to" subnet.  This krypted article gives a brief explanation, and also outlines (one can Google "APIPA Windows" for detailed—and possibly obsolete—instructions) a way of disabling APIPA for the laptop.  Of course one should also investigate why DHCP services aren't available in the "wandered-to" subnet; maybe there's a problem with that subnet's router.

    Now let's consider how the Retrospect engineers might fix the APIPA problem entirely in the Windows Client, without allowing and requiring the laptop user to manually stop and restart the Client (see pg. 237 of the Retrospect Windows 17 User's Guide).  This would be an automated version of running a stop/start script to do it.  The Client would have to detect that it had been assigned an APIPA address, and then to stop and restart itself.  Based on my obsolete and cursory Computer Science knowledge, that would require the Client to be multi-threaded—with the stopping and restarting of the main thread embodied in an auxiliary thread.  Based on my observation of the history of Retrospect, combined with my complete lack of knowledge of the Client source code, I doubt that the Windows Client is now multi-threaded.  So IMHO fixing bug #8512 would demand a significant engineering effort.

    I had a phone conversation with someone in Sales this afternoon, and there's a 17.1 release planned for September that may include a fix for bug #8512.  An alternative "motivating" approach would be to send an e-mail to the new StorCentric boss of the head of Retrospect Tech Support, who may have influence with Retrospect engineers.  He's David Bartizal, and his e-mail address is dbartizal@storcentric.com.  That address was supplied by the VP Service & Support himself, in the e-mail conveying his request to fill out a SurveyMonkey survey on handling of an unrelated Support Case.

    P.S.: The automated-stop-restart solution I suggested in the second paragraph would be inappropriate for an installation set up per Nigel Smith's last paragraph directly above,  and for one that isn't supposed to have a router—because the krypted article says "APIPA is a dhpc mechanism that provides dhcp clients with self-assigned IP addresses when DHCP servers are not available."  How would you disable the automated-stop-restart solution in such cases?  Possibly the Retrospect "backup server" could be enhanced to automatically create and test a 192.168 ... Subnet if there are no Subnets defined, and set a flag in every Client installed using that "backup server" if the 192.168 Subnet fails the test.  Would disabling per that flag do the trick?

  19. Nigel Smith, and MrPete,

    Getting back to what Gilbert and Sullivan might have termed the "poor wandering laptop", I have two suggestions for that -530 problem.

    My first suggestion is based on henry-in-florida's suggestion, which I tried in late 2018 and which worked.  That is to define the laptop as a Source using Subnet Broadcast, and to define all possible Subnets on which the laptop might appear (see pages 228–9 of the Retrospect Windows 17 User's Guide).  If you do so, the "backup server" uses Piton Name Service in turn on each defined Subnet to find the "client" by its Computer Name (or the Windows equivalent).  This, of course, assumes that the "client"'s Computer Name is not used for different machines in different Subnets; if e.g. Martha in Meteorology takes her laptop from the Science Building when she goes over to the Engineering Building to work with Martha in Materials Engineering on designing a sturdy mast for measuring wind speeds inside tornadoes, and each woman has a different machine named "Martha's Machine", the "backup server" will get confused.  Subnet Broadcast actually solved my -530 problem for a month starting in 2018 even though IIRC I had no defined Subnets, but I then switched over to using Direct Access with fixed DHCP IPs defined in my router.

    The second suggestion is based on an approach I came up with in early 2017, when I started getting -530 errors after upgrading an Ethernet switch.  That is to add a preliminary "sacrificial" Backup script  backing up each "wandering laptop", as described most clearly in the second paragraph of this June 2019 post.  You don't care whether or not the "sacrificial" script gets -530 errors, because using the No Files Rule (No Files Selector for Retrospect Windows) means it's not going to back up any files regardless.  The cost is 4 minutes or so of run time.

    The voodoo idea behind both of these suggestions is that a "client" needs time to "straighten up and fly right", rather than being backed up immediately by a "backup server" Engine that is in the process of initializing itself.



  20. On 6/1/2020 at 5:26 PM, rfajman said:

    I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.


    Thank you for,  3 months later, confirming my point in the post you quote in the post directly above this one.  As I'd guessed, the WHATSIS is hardware.

    My "backup server" doesn't have more than one NIC, so I never knew Interfaces—described on page 297 of the Retrospect Windows 16 User's Guide—are a Retrospect feature (which is why I'm now initial-upper-casing "Interface").  But I don't know how you'd run within Retrospect "a command file that runs in the background", much less one that "periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary."  It sounds as if you actually run a Windows command file that checks and reestablishes a proper Windows configuration of hardware and/or software—one that is reflected within a Retrospect Interface.

    Since you mention "pretty high speed wireless Internet access provided by the place where we live", it also sounds as if your Gigabit Ethernet switch is used only for Retrospect backups.  That would imply you are having a periodic hardware or Windows problem with your switch, which your Retrospect Interface "sniffs out".  I suggest you temporarily modify your command file  to not reestablish the proper configuration, but instead to send you an e-mail or other message.  When you get that message, you should then test communication over the switch using programs other than Retrospect.

    As x509 wrote in response to your 1 June post, "Can you post this [command file] script.  Thanks."  Please post the un-modified reestablishing version.

  21. MrPete,—and maybe x509,

    With my simple-minded experience, I'm having trouble understanding why for you "an endpoint changes its IP address".  I remembered something about a problem Nigel Smith had in the past, but couldn't find the thread for most of an evening.  Here it is, starting—for your purposes—with this post describing a procedure that worked for him.  The remainder of that thread explains his situation, ending with a post that explains why his procedure is the only one that solved his problem—which may or may not be similar to yours.

    (My simple-minded experience consists of an home installation with a "client" in the study and a "backup server" in the bedroom.  In 1998 I replaced my previous PhoneNet network with a re-purposed piece of in-the-wall coaxial cable running between the two rooms, now attached at each end to a MoCA adapter in turn cabled to an Ethernet switch.  I did a test two years ago, and discovered that 802.11g WiFi between the two rooms only ran at 20% of the cable speed—because of multiple Sheetrock walls and a refrigerator in the signal path.  Thus WiFi on all my computers is turned off, so I never have any endpoint address change—unless I alter my "client"'s static DHCP IP in my router that's specified in its Sources definition's Direct Access address.)

    You might consider his 10-step procedure, because it handles a 2-subnet-with-Fortigate-switching problem that's IMHO at least as generalized as yours.

  22. MrPete and x509,

    It sounds as if both of you could use the "ipsave" command described in this Knowledge Base articleThis 2019 post in another thread and its follow-ons describes the command's successful use on Windows "client" machines.  Other posts you can find by doing a Forums search for "ipsave" describe its successful use on Mac "client" machines, but as a Mac user I didn't want to scare you.

    The facility was added in Retrospect Windows 10.0, but—starting with that release in 2015—Retrospect Inc. adapted a policy of having the "What's New" chapter in the User's Guides be written by marketing-oriented Product Management people—and having the information in that chapter overwritten in the next UG release.  In this case, the astonishingly-specific 🤣 information was:


    Retrospect is more resilient to network hiccups and address changes that affect client connectivity and stability.


    Here's an Ars Technica post by a Drobo user (I'm not one), written in response to my announcing that Retrospect Inc. had been acquired by StorCentric—which also owns Drobo.  I saw somewhere in the last year or so that disks used in a Drobo NAS, which can be of different sizes—a formerly-touted feature, can only be read by another Drobo NAS because of proprietary formatting.  IME the head of R. T. S. will hit the roof if we say anything too critical.

  23. Nigel Smith,

    I wrote in this up-thread post "I was proceeding to your next issue while writing this post, but I had to take an hour off and you've meanwhile beaten me to it."  But IMHO your subsequent posts have not so far really "beaten me to it".

    That "next issue"—really three "ifs" in one long sentence, covered in your more-upthread post, was:


    I didn't notice this last night, but it appears that the client was added with the interface "Default/Direct IP", in contrast to the clients automatically added from the server's network which were "Default/Subnet". I don't know what this means if my home router's IP changes or I take the laptop to a different location (will the server consider it to now be on the "wrong" IP and refuse to back it up?) or if I know take it into work and plug in to the network (will the server not subnet-scan for the client, since it is "DirectIP"?).

    My opinion on the first two "ifs" is based on what I wrote in the last two sentences of the first paragraph and entire second paragraph of this even-more-upthread post.  It is that Remote Backup, designed for machines that don't have predictable Internet addresses, will backup any machine having the exact "backup server" Tag "Remote Backup Clients" that "reaches out" to the "backup server" with a public key that is in the "backup server"'s Remote Clients table.  So long as such a "client" machine remains truly Remote, a Proactive AI script specifying "Remote Backup Clients" will back up any machine having that Tag—even if your home router's IP changes or you take the laptop to a different location.

    My opinion on the third "if" is based on my personal experience that Retrospect Mac 16.6's Piton Name Service will override Add Source Directly, so long as the Computer Name matches what is defined for that Source on the "backup server".  So if you now (the word I'm sure you meant) take the laptop in to work and plug in to the non-subnetted portion of your LAN, Retrospect will back it up—assuming its Computer Name is unique in the non-subnetted portion of your LAN and has not changed from when a Proactive script added it to Sources.

    If you've done further testing on these "ifs", please post your results.

    P.S.: Two days after writing the "third 'if'" paragraph, while disabling access by my Retrospect Management Console to my "backup server" for security reasons (see P. S. and P.P.S. of this post in another thread), I looked at the definition of my MacBook Pro in Sources.  I noticed there an interesting Ignore Client Discovery option.  The cumulative Retrospect Mac 17 Release Notes have, under "Network" for Retrospect Mac  12.0:


    NEW "Ignore client discovery" checkbox for preserving Client's address in certain firewall and NAT environments

    That sounded applicable to your "third 'if'" paragraph, so I searched the Forums and found this 2018 threadlstone19, in his OP there,  seems to confirm my own experience of what happens if that option is not checked.  Which means if you now take the laptop in to work and plug in to the non-subnetted portion of your LAN, Retrospect will back it up—assuming its Computer Name is unique in the non-subnetted portion of your LAN and has not changed from when a Proactive script added it to Sources.  The reason I say "non-subnetted portion of your LAN" is because I assume that— when it can't access the Sources-specified IP address for that Computer Name—Retrospect Mac 12+ interprets the access method Direct IP as if it were Multicast, but if you have subnets defined it might interpret the interface as Subnet Broadcast.  Try it and let us know. 😃

  24. svennd,

    You don't say which variant of Retrospect you are using, but since you use the term "snapshot"—which has been banned for the Retrospect Mac GUI since version 8 (Engine messages still use the term, since the Engine is common code underneath the variant GUIs)—I'll assume it's Retrospect Windows.

    Pages 8–9 of the Retrospect Windows 17 User's Guide are a minimal description of how to generate the new Restore Preflight report for a snapshot.  What it generates is a CSV, which presumably you have to import into a spreadsheet program (whatever that is; I assume one candidate is Microsoft Excel) in order to read.

    The front screenshot on page 8 of the Retrospect Mac 17 UG shows how to tell that variant of Retrospect 17 where to save the CSV using a macOS GUI dialog.  I assume the corresponding Windows GUI dialog would be similar, but whoever in Retrospect Product Management wrote the "What's New" chapter of the Retrospect Windows 17 UG seems to have felt it was more important to show a  screenshot of how to generate the CSV—owing to the crufty old GUI of Retrospect Windows (guess which variant I use 🤣 ).