Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by DavidHertzberg

  1. jhg,

    You probably know this, but here's how and why to submit a Support Case for a feature request.

    However IMHO Retrospect Launcher—which you refer to by its ancient name of retrorun—is going to disappear from Retrospect Windows 17 (you're surely not really still running Retrospect Windows 7.5 as your Profile says?), as it did from Retrospect Mac 8.0 in 2009, in March or August 2020.  I've discussed that prediction starting with this post in another thread.  If I'm correct, there's no way your feature request will be implemented by Retrospect engineering.

    Later on in that thread, Nigel Smith suggested using Windows Task Scheduler—for which a basic guide can be found in this Digital Citizen article.  Disclaimer: I'm a Retrospect Mac administrator, and I haven't used Windows since I chose to retire from my last job—where I was using Windows 95 for all but the last 5 months—in mid-2004.  So I don't know how you would schedule a kill of Retrospect.exe after it has sent the daily backup report, say at 7:05 a.m..  Maybe someone else on the Forums has a suggestion, or maybe you'll have to research that yourself.


  2. 22 hours ago, Nigel Smith said:

    Or, since he knows the the time the script needs to run, he could use Windows Task Scheduler to launch RS when appropriate.

    Or even, if his BIOS supports it and he doesn't mind the security implications: set the PC to boot at a certain time and auto-login, set Windows Task Scheduler to fire up RS, use script hooks to to monitor and shut down both PCs when complete!

    These are computers -- we should be getting them to do things, instead of having to remember to do them ourselves! 😉 

    I briefly considered Windows Task Scheduler, but thought rbratton might not be knowledgeable enough about it—which was stupid of me since he/she is a software developer.  In a prior thread NoelC wondered why the Retrospect developers hadn't included "easy integration with Windows Task Scheduler just by setting the right options in the Retrospect UI"; my answer in a post in that thread—whose first paragraph links to an article describing how to use that modern Windows facility—was that doing so would have seemed a bit premature in 2013.  Maybe rbratton should write a Support Case for such a product enhancement—per this boilerplate post, for Retrospect engineering to implement assuming Retrospect Launcher will disappear in Retrospect Windows 17.

    If rbratton chooses to setup a Windows Task Scheduler task that launches Retrospect early Sunday or Monday mornings, he/she should simply pre-write unscheduled Retrospect Backup scripts —so that he/she can Run them in my predicted Retrospect Windows 17 R.-Mac-like GUI after having worked on a Saturday or Sunday.  That would ensure that there are no Retrospect tasks to cancel later on Mondays.  He/she can test this currently with run documents.

    Here's a Knowledge Base article on writing Retrospect script hooks, in case rbratton chooses to follow the suggestion in Nigel Smith's second paragraph.

  3. Nigel Smith,

    You're correct in the immediately-above post, but to "schedule Proactive to run only for certain hours of the day" requires that the "backup server" be already running to act on that schedule.  For the next few months,  that can be done via the Retrospect Launcher.  But, as I said in the second paragraph of the same post you quote, "Retrospect 'Inc.' AFAICT intends getting rid of Retrospect Launcher in Retrospect Windows 17".  That would mean that as of March or August of 2020 rbratton's "backup server" machine would  have to either be constantly running the GUI-less Retrospect Engine whenever it is booted, or rbratton would have to remember to start the Engine each midnight—a reversion from what he is going to do.  I think the second alternative might be more burdensome than the only-on-most-Mondays cancellation procedure I described in the second paragraph of this post, which is applicable to regular Backup scripts.  The first alternative would, of course, also work with Backup scripts individually scheduled to run only at certain hours.  We'll see in a few months—but see the next two posts.


  4. 19 hours ago, rbratton said:

    Thanks for the info!  I'll keep an eye on future Retrospect plans.


    Cheer up; even if my informed guess about Retrospect engineering plans to switch Retrospect Windows 17 to a Launcher-less Retrospect-Mac-like interface proves correct, you will have the following two options:

    The first option is the equivalent of your current solution.  First, change your Sat.-Sun. backup scripts to both use the same execution unit (see page 272 of the Retrospect Windows 16 User's Guide), and change the scheduled time of those Sat.-Sun. scripts that backup your "backup server" machine to 5 minutes after those Sat.-Sun. scripts that backup your "client" machine.  Then, on every Monday following a weekend on which you have not worked both Saturday and Sunday, boot your "backup server" machine first.  Immediately, before you boot your "client" machine, start the Retrospect Engine and the Retrospect Console on your "backup server" and cancel every Backup activity awaiting execution.  The Backup activity that has already started should be trying to back up your "client" machine; it will fail by itself because your "client" machine—not having yet been booted—is not yet visible on your LAN.  After you have done the necessary cancellations, you can boot your "client" machine,  By then no Sat.-Sun. Backup activities should be executing or awaiting execution, so you can leave the Retrospect Engine running  on your "backup server" machine—where it will be using mostly virtual memory until the scheduled time for your midnight-Tuesday-morning Backups of your Monday work ( you can quit the Retrospect Console, restarting it to monitor those Tuesday-morning Backups).

    The second option is the equivalent of the one I said in a post above I personally would prefer.  First, create scripts for Sat.-Sun. backups of your "backup server" and "client" machines, but do not schedule them.  Then, on every Saturday or Sunday you work, when you have finished work simply start the Retrospect Console and Run those scripts using the appropriate Backup Set destination.  When the Console shows those scripts have finished execution, you can shut down both machines.  If you want, you can instead create a single two-Source script that does a Backup of both machines.

    I predict you'll like the new Retrospect Windows GUI after you get used to it.  Based on the current Retrospect Mac 16 User's Guide, the Retrospect Windows 17.x User's Guide will be half—less than 300 pages—the length of the Retrospect Windows 16 User's Guide.

  5. rbratton,

    I had thought about what Nigel Smith says in the first paragraph of his post directly above.  However I assume that you are bothered by the additional scanning time for regular backups  that follow "catchup" backups, even if the backups are incremental.  Moreover I'm not sure his second-paragraph suggestion of Proactive is applicable, because Proactive (which I don't use) assumes a dedicated "backup server" machine that is "always here" whenever the "client" machine is "sometimes here"—which (as Nigel Smith recognizes in his third paragraph) is not the situation described in your OP.

    Unfortunately your current solution will IMHO become impossible as of March or August 2020 (maybe with a month's delay if Retrospect engineering gets overwhelmed by other StorCentric-dictated enhancements).  That is because, per this post in another thread (second sentence in P.P.S.),  Retrospect "Inc." AFAICT intends getting rid of Retrospect Launcher in Retrospect Windows 17—as they did with retrorun (its old name) in Retrospect Mac 8.0 in early 2009. 

    The Retrospect Mac 16 User's Guide describes no general Schedule Preferences equivalent to what is on pages 397-399 of the Retrospect Windows 16 User's GuideThose Schedule Preferences are dependent on the Startup Preferences described on page 401, which affect the behavior of Retrospect Launcher—if the first checkbox in Startup Preferences is checked to enable Retrospect LauncherThis post is part of another thread that discusses the woes of using Retrospect Launcher in Retrospect Windows; and the post's P.S. says "And now that my [Retrospect Mac] backup script has finished running, the combination of Retrospect Engine and Retrospect Console has dropped to 250MB real memory.    IMHO derek500's [Retrospect Windows] installation ought to be able to afford reserving that continuously."  And in Retrospect Mac one can stop and start the GUI Console while the Engine continues to run.


    On 1/15/2020 at 1:09 PM, rbratton said:

    .... Retrospect did not automatically start "catchup" backups when the computers booted which is good -- it honored my backup time window.  But it did schedule "catchup" backups of both computers starting tonight at 00:00 -- the earliest allowed backup time.  I think I can live with that; I'll just have to remember to delete these redundant backups (as the scheduled ones will occur a few hours later).


    rbratton,Page 398 of the Retrospect Windows 16 User's Guide says "Schedule lets you define a window during which scripts are allowed to execute."  So the result of your experiment is exactly what I would have predicted, if I had had time to post.  If you prefer to remember on most Monday mornings to delete the "catchup" backups that have been scheduled but not yet executed, that's up to you.  If I were you,  I'd prefer to remember on a few Sunday or Monday mornings to execute a pre-prepared run document.  Different strokes for different folks.

  7. rbratton,

    Sorry, but I read "the other runs MTWTF at 2AM" in your previous post as meaning you normally run what you call your "MTWTF" script at 2 a.m. on Monday through Friday.  I now think you mean "MTWTF" as referring to the days you did the work that is backed up, not the days the script is actually run.  Thus you actually run the "MTWTF" script at 2 a.m. on Tuesday through Saturday, even though it is backing up work you did Monday through Friday.

    Assuming that what I wrote in the first paragraph is correct, I hereby absolve you from the charge of not backing up your Friday work until the following Monday.  So you are indeed professional enough to use Retrospect; you're just not always the most professional tech writer.  It's good to hear you're using a version control system promptly.

    Making that same assumption,  your "Weekend" script is actually scheduled for Sunday and Monday at 2 a.m..  But maybe your "Weekday" script is also scheduled for 2 a.m. on Monday, not just Tuesday through Saturday.  If so it ran yesterday—Monday—right after the "Weekend" script ran when it was unable to run on Sunday or Monday at 2 a.m..  Or something along those lines.

  8. rbratton,

    You work in remote software development, but you don't normally back up work you do on Friday until the following Monday (assuming you're not working  a Transylvanian schedule)?  😮  Please PM me your employer's company name, so that I can short-sell the stock. 🤣  My 7-days-a-week backups are scheduled for 3:05 a.m., but I boot my MacBook Pro "client" and then my "backup server" whenever my BPH wakes me up after that time—and let the backup run while I do my teeth. 

    IMHO you're not professional enough to be using Retrospect; you should instead be using a Windows backup program that does near-continuous backup.  That's why Retrospect doesn't have the feature you want.  However, if you persist, I suggest creating one or more run documents (pages 236-238 of the Retrospect Windows 16 User's Guide).  Then, if you work on a Saturday or Sunday, just use a run document to start the appropriate Backup script after you've finishing working.

  9. On 1/11/2020 at 3:06 PM, rbratton said:

    @mbennett, @DavidHertzberg

    Thanks for the replies.  I'll give those suggestions a try and report back.

    Great idea on the "sacrificial" script to let the remote computer completely boot!



    I originally got the idea for the "sacrificial" script from this 2016 post by hgv.  He/she wrote "This suggests there's an issue with Retrospect daemon being initiated too soon at startup. This is particularly annoying to me because my backup computer is restarted daily. As a workaround I created a launchd script to do a 60 seconds delayed stop/restart of both daemons at startup. The problem seems to have disappeared."   I don't know enough about macOS to write a launchd script, so I came up with the "sacrificial" Retrospect script instead.

    I noticed, in re-reading that thread, that I originally scheduled my "sacrificial" script 10 minutes before the real script.  That was sufficient to nullify the effect of the -530 error for the "sacrificial" script then.  I still schedule "sacrificial" scripts 5 minutes before my real Backup scripts, but—since I changed to using Add Source Directly (the Retrospect Windows equivalent is Direct Access Method)—I'm no longer getting any -530 errors on the "sacrificial" scripts even when I boot my "backup server" machine (with my MacBook Pro "client" machine already booted) several hours after their scheduled 3 a.m. start time.

    Wikipedia says launchd is "an init and operating system service management daemon created by Apple Inc. as part of macOS to replace its BSD-style init and SystemStarter".  If, instead of a "sacrificial" Retrospect script, you want to write the equivalent of a launchd script for Windows, I have no idea how to do that—but it would probably have to do a delayed stop/restart lasting more than 60 seconds.

  10. rbratton,

    To solve the first problem in your OP, just duplicate your 2 a.m.-scheduled script.  Have one script scheduled only for Mon.-Fri., and the other script scheduled only for Sat.-Sun..  If your computers are shut down on Sat.-Sun., the second script won't run that week—but the first script will run Mon.-Fri..

    To solve the second problem in your OP—if the above paragraph doesn't eliminate it, precede your "real" Monday execution of the first copy of the script with a "sacrificial" script scheduled for 1:55 a.m. Monday.  This will be an exact duplicate of the "real" script, but with the No Files Selector;  Selectors, including Built-In ones, are documented on pages 435-437 of the Retrospect Windows 16 User's Guide.  I've used a "sacrificial" script for years to bypass Retrospect Mac Engine startup delays; if the "sacrificial" script runs before the LAN is active, as x509 says, the "sacrificial" script fails at 1:59 but the "real" script" runs.


  11. oleksiak,

    This sounds like a problem I had in July 2017 (note to self: see Support Case #56419) when I experimentally upgraded my MacBook Pro from the Mac 14.0 Client to the Mac 14.1 Client.  When I re-Added the MBP as a "client" on Retrospect Mac 14, it began doing scripted Backup activities having the MBP as a Source so as to automatically include what I will call 3 Apple-created "hidden duplicate volumes" on the MBP—for which it got -1101 errors because the Engine couldn't see the "hidden duplicate volumes" on Backup script runs.  I discovered that there is now a Volumes dropdown in Sources->Options that specifies which volumes on a "client" should be backed up.  The dropdown defaults to All Volumes; I found I had to change the dropdown to Startup Volume to eliminate the "hidden duplicate volumes" (which are not shown with a disclosure triangle).  The Volumes dropdown is documented on page 40 of the Retrospect Mac 16 User's Guide,. 

    Try changing the Options->Volumes dropdown in your Sources definition of your Linux "client" machine to Startup Volume—you may need to do a Sources Remove and re-Add and then re-checkmark in scripts.  I have a hunch that doing so may eliminate Retrospect Mac's trying to back up the Docker container.


  12. oleksiak,

    Read the second post in this Windows Linux, Unix and Netware Clients thread.  If the CentOS 7—but with FreeBSD kernel (... 11.2 and 12.0 kernels)—is applicable to you, it looks like there was—at least experimentally—some kind of fix for the Retrospect Windows Engine that may not have made it into the Retrospect Mac Engine.  OTOH maybe that fix never made it into a later production release of the Retrospect Windows Engine.  I'd suggest PM'ing Xenomorph to find out if it did, and then contacting Retrospect Tech Support on that basis.  You may also (or instead—in case your OP-described bug was fixed in Engine 16.5 or 16.6) have to get your "it crashes our Linux client on connect" bug fixed for the Retrospect Mac Engine 16.6, though, unless you can get your OP-described bug fixed in an experimental version of instead for 16.6.

  13. x509,

    I've expressed myself as far as I dare to on what's going on vis-a-vis the new StorCentric top management; I have had Forums posts deleted in the past because they were deemed too critical of Retrospect or Forums-participant personnel.

    However IMHO the problem in this case is that NoelC "poisoned the waterhole" with his Support Case, which was submitted prior to yours—much less mine.  I don't know what he said in it, but it seems he complained about "transient" files generated by Windows—particularly ones generated by VSS.  That explains why Retrospect Tech Support responded to your Support Case with "Unfortunately, there is no way to groom these kind of files as with every windows update, we do not know what windows will change exactly. There is no way to modify or to groom windows files."

    In an Additional Note to my Support Case, I suggested that the proposed "transient" Groom feature could have the capability of grooming out previous versions of VSS-generated "snapshot"  files.  These are always created in a specific directory, and have names that differ from VSS "snapshot" to "snapshot" only in a numeric prefix in front of a leading open-curly-bracket character.  I suggested that my 3-file-merge procedure for VSS "snapshots" could sort those files by numeric-prefix-eliminated name so that they merged together, and then "groom"-out the older versions of the same file.  I didn't yet say so in my Support Case (I will), but an alternative would be to do what AOMEI Backerupper (see P.S. in this up-thread post) apparently does—which is to access some kind of an index that Microsoft maintains for VSS "snapshot" files.

  14. Greg,

    Disclaimer: I'm a Retrospect Mac administrator of a home installation that doesn't include any NAS, much less a Synology.  But I'm reasonably good at searching the Retrospect Forums.

    Starting with this post, here's a 2014 thread in which someone managed to install a Linux Client on a Synology, rather than simply mounting as a NAS share.  I'm not sure if it provides enough detail in the longer posts with script listings.

    Here's an alternate—and perhaps unpalatable-to-management—suggestion: Why not pay your previous Linux specialist to provide instructions on how to do this?  Another possibility is to contact Retrospect Tech Support and ask them how to do this, even if you don't have ASM and have to pay a one-time fee.

  15. x509 and everybody else,

    My new Support Case, described as a "precise re-statement of the last two sentences of the Problem Description" in x509's Support Case (he PM'ed me his Support Case number, so I could point to it in my Support Case—I can't look at his Support Case) is #71425.  To show the multi-user interest in this enhancement, I even mentioned NoelC although—from his last post in this thread—he has quit using Retrospect because of lack of this enhancement.

    My Support Case is basically a cut-down copy of three posts in this thread: this post, this post (which I had to split into two Additional Notes—one of which split itself because the last sentence made it exceed the Support Case software length limit), and the third substantive paragraph of this post as another Additional Note.

    IMHO x509's failure to get Tech Support to "recognize a problem or issue as something that they should submit as a feature request" illustrates the pitfalls of a lack of dialogue between the application user and the systems analyst that is inherent in Retrospect "Inc"'s Support Case system of enhancement requests.  IME the systems analyst must understand 3 separate items: what the user says he/she wants, what the user really wants, and what the user really needs.  That understanding can only be gained by a back-and-forth process, which is what we've had to some extent in this thread.  The second sentence of my Support Case specifically links to the OP of this thread, so that T.S. can see that back-and-forth process at second hand.



  16. x509,

    Thank you for both submitting your Support Case and for posting the Problem Description here.

    However I don't think you were quite precise enough in the last two sentences of your Problem Description.  "The problem you need to have solved" is specifically grooming out of older copies of "transient" files, defined above in this thread as files that are backed up each time a backup is run.  However we want this grooming done only in designated directories, so that e.g. we don't consider the FileMaker Pro database for my little home business (the Almighty grant that it be backed up each day because of new orders—which I regret is unlikely to happen) to be a group of such  "transient" files.

    Therefore I'd like to file a Support Case supporting your Support Case, into which I would basically copy several of my posts in this thread.  I think those posts together would constitute a sufficiently precise problem description (which would have to extend into at least one Additional Note because of the size limit in the Support Case software), but would not really "tell them how to do it".

    An example of how this up-thread post would not really "tell them how to do it":  The first substantive paragraph of that post implicitly assumes that Retrospect, as it back up a file, can "look up" that file in in the latest  Snapshot stored in the Catalog File for the Backup Set.  That in turn assumes that the Catalog File has an index associated with that latest Snapshot.  If it doesn't—which I suspect may be the case—then the "transient flag bits" handling description only describes the desired logical result.  If the index doesn't exist, that result might have to be implemented by doing a "3-way merge" (ah, sequential processing as in the old days 😂)  of the last three Snapshots, as a pre-processing step in a "Transient" Grooming operation.  The implementation would have to be left to the engineers, and they might decide that grooming out of older copies of "transient" files is infeasible.

    To save my having to refer to your Support Case indirectly, as "the Support Case filed by the Retrospect administrator who goes by the Forums nickname x509 and created the post with the URL ...", I'd like to be able in my Support Case to refer to your Support Case by its Support Case number.  All I would need is the number, not any identifying information about you.

    If that's OK with you, could you either post the number of your  Support Case here, or PM it to me?

  17. tlemons,

    If you're worried about not backing up the System Volume Information folder, you could do what I suggested to x509 in this post in another thread.  That means you'd have to create a separate Backup Set purely for the System Volume Information folder, because Retrospect currently allows specifying a Grooming Policy only for an entire Backup Set.  (If Retrospect "Inc." adopted the feature suggestion in the second substantive paragraph in this post in that same thread, you'd be able to specify "transient " Grooming for individual Subvolumes in the same Backup Set; x509 hasn't said that he added the Additional Note for the suggestion to his "transient " Grooming enhancement Support Case, but a special provision would be needed to ignore VSS file name's lead # .)

    BTW, here's a 2009 thread OP saying what System Volume Information did for Windows Server 2008.  And here's a Wayback Machine link to that How-To Geek article that doesn't grab you by the throat and insist that you register, and a link to another 2016 How-To Geek article that it links to—with the same Wayback Machine virtue.

  18. amkassir,

    For a number of years Retrospect Inc. has had what I call the "august Documentation Committee", which writes most Knowledge Base articles and does the (shoddy) updating of the User's Guides.  The head of Retrospect Tech Support stated a couple of years ago that he is not permitted to be a member of that committee, which IMHO should be taught in business schools as a classic example of mis-organization (probably resulting from his not being able to buy a share of ownership when the privately-owned Retrospect Inc. was set up in 2011). 

    In any case the core of that committee is Retrospect engineers, and from everything I can see as an outsider the engineers are up to their eyeballs in work—both the pre-merger-initiated Web-based Management Console and the long-planned but post-merger-initiated non-Web non-Management Console that will replace the Retrospect Windows and Retrospect Mac GUIs.  IMHO that second project is Mihir Shah's top priority, because it will be necessary to provide an over-the-LAN GUI for his announced effort (fourth paragraph) to produce a "backup server" that will run on a Drobo device —where it can't have a local GUI because a NAS device doesn't have its own monitor and keyboard and mouse.

    My suggestion is that Retrospect Mac 17 should add the capability of creating its own Disaster Recovery "Disk", similar to the capability discussed on pages 316-328 of the Retrospect Windows 16 User's Guide.  To get that started, I recommend sending a snail-mail to the StorCentric Chief Technology Officer:


        Attn.: Mr. Rod Harrison, CTO

    1289 Anvilwood Ave.

    Sunnyvale, CA 94089


    Rod Harrison may not have any idea what macOS Catalina is and what new challenges it poses for the Retrospect Mac product, so your letter will have to include an explanation.  You can also include a request for the "detailed document", but—for reasons explained in the second paragraph of this post—IMHO you won't be able to get it written.

    P.S.: You're "preaching to the choir" in your post directly below this; as a customer Retrospect administrator I totally agree with you.  However StorCentric didn't bail Retrospect Inc. out of an apparent financial crisis (resulting—I assume—from their inability to charge customers using Linux-based NASes the price for beyond-Desktop Editions as if they were still using Server versions of macOS or Windows ) out of the goodness of Mihir Shah's heart.  Shah has said he wants a Retrospect "backup server" running on Drobo devices, and "he who pays the piper calls the tune".  IMHO it would take an engineer more than a day to do experiments for the restore document.  Request the document in your snail-mail letter to Harrison; I'm still on High Sierra, or I'd write one myself.

  19. tlemons,

    For 4.5 years—ever since I updated my Macs at home and re-started using Retrospect—it has been backing up a "phantom" multi-GB file from my MacBook Pro every morning.  The file has a very long name, but it begins with "imap".  Using my mighty brain, honed to perfection by my (non-PhD track) MS in Computer Science, 🤣 I soon concluded the file is my accumulated undeleted IMAP e-mails.  Because the file name is so long, I have never tried searching for it using Mac Spotlight.  Retrospect 15 added explicit protection for several common e-mail systems in March 2018—you can migrate messages between e-mail accounts, but IMAP messages get backed up anyway because the Mac Mail program downloads them.  Help, my download file's growing! 🙄

    I don't know what e-mail program you're using, but—unless you're backing up another file that you know is your e-mails—I suggest a similar conclusion for your problem.  If I'm correct, you probably don't want to stop backing up that file, unless you want to explicitly back up e-mail. 

    Happy New Year.😀

    P.S.: Forget what I said above about e-mail.  The OP in the thread that x509 links to in the post below this shows file names that are the same as the one in your OP, except that they have different numbers before the left curly bracket.  So the big file is in your System Volume Information folder; read that thread.

  20. If kolohe280 had been reading the Forums regularly since they signed up 7 years ago, they would have noticed that I frequently post a link to this.  Surprisingly, its fifth paragraph reads:


    Note that, despite the new dialogs in the Retrospect Inc. Support Case system urging you to sign up for Annual Support and Maintenance, Mayoff has verbally assured me that you don't need to be signed up for ASM to report a bug—only to get personal assistance with coping with it.

    Its sixth paragraph suggests that the head of Retrospect Tech Support post a version of what I link to as a "sticky thread".  IMHO he hasn't done this because he wants people to sign up for ASM, which funds his department's budget.  I think such discouragement of administrators from filing Support Cases has been unwise, and that the StorCentric acquisition is partly a result of Retrospect's reputation for bugs not getting fixed—sometimes for years.

    They also would have noticed that a fair percentage of reported bugs involve Retrospect incompatibilities with various OS features.  There are several volunteers who are experts in that area, but who can't help administrators who don't say what OS version they are using.  OTOH I am fairly familiar with where to find information on various Retrospect features and updates, but I can't help administrators who don't say what Retrospect version they are using.

    Finally they would have noticed that a fair percentage of OPs on these Forums are from non-Americans.  I try to spot these (foreign-sounding user names are one of the clues), so that I can explain any American slang I might use and try to simplify the English I use to respond to such administrators.  Moreover, some of the most knowledgeable volunteer responders on these Forums are British or Scandinavian—and are proud of it.

  21. kolohe280,

    I deduce from the genesis of your "handle" and your times of posting that you may be located in Hawaii.  Please update your Profile with at least the U. S. state of your Location, so that we may know when to expect posts from you.  Also please add your Gender, so I don't either have to address you in the second person or refer to you as "he/she" (not knowing the Hawaiian language, I have no idea what the gender of a kolohe is presumed to be).

    With that housekeeping detail out of the way, were you able to do similar things with NASes successfully in earlier major versions of Retrospect Windows?  I ask because the Retrospect Windows cumulative Release Notes show the engineers added several Engine fixes and improvements to NAS support in the 16.5 releases and and the 16.6.0 release.  In the last two major releases of Retrospect, there is abundant evidence that improvements and fixes to existing features were botched—especially in x.5 and x.6 "minor" releases.  As a lowly paying user with 40 years experience as an applications programmer, I think these botches resulted because the engineers have been really rushing to add major new features—Storage Groups and the Management and (demo) non-Management Consoles.  I therefore suggest, given that Storage Groups IMHO basically eliminate a lot of Backup Set bookkeeping—mostly for Proactive scripts (which I've never used)—that experienced administrators were able to do before with more effort, you consider downgrading to and asking Retrospect Sales for a refund on version 16.

    Even if you're not actually willing to go through with that downgrading, IME it will be an excellent bargaining tactic in getting a free upgrade to Retrospect Windows 17.  About two years ago, I stayed on Retrospect Mac 14.1 until Retrospect 15 had been out for over half a year—because of a trio of -530 bugs that Retrospect Mac 14.6 seemed to make worse and for which I filed Support Cases.  Then, after running some inconclusive beta tests with an augmented-logging test version that Tech Support sent me, I paid for Retrospect Mac 15 with the proviso that I get a free upgrade to Retrospect Mac 16 even though I was upgrading a couple of months earlier than the free-upgrade cutoff.  Considering that you report that you have been substantially helpful in diagnosing bugs in the hot new Storage Groups feature, I speculate that you can bargain from Sales (who have access to everybody's Support Cases) the same kind of free update to Retrospect Windows 17—especially if you only license the Desktop Edition as I do.




  22. kolohe280,

    I see you joined the Forums in November 2012, although this is your first post.  Is it possible you are still running Retrospect Windows 8, or even Retrospect Mac 10—in which case you should have posted to the Retrospect Mac 9+ Forum?  Please post what version of Retrospect you are running, and under what version of your "backup server" machine's OS.  Nobody on these Forums works for Retrospect "Inc.", so we're not going to push you to upgrade to the latest version unless it turns out you need it.  Also please state any error message number you get with "The disk is not accessible".

    The reason I ask that is there have been several fixes to the "backup server" Engine for NAS shares since 2014.  If you do a browser Find for "share" (without the quote-marks) on the Retrospect Windows cumulative Release Notes, you'll see them one by one in reverse chronological order.

    Have you added the second share on your other RAID array to My Network Places per page 421 of the Retrospect Windows 16 User's Guide (don't worry, the contents of the UGs—other than the "What's New" chapter—hasn't been updated for about the last 5 years)?  Also, did you select the first and second volume using Control-Click per page 419 of  the UG?  Full disclosure: I'm a Retrospect Mac administrator without a Windows machine, so I'm "going from the book" in this paragraph.  Also, try the Repair Catalog procedure as described on pages 451-453 of the UG.

  23. 🙄x509,

    Reading this gave me a strong feeling of déja vu.  And sure enough, I found this thread from last August, with your final post in that thread urging jhg to submit a feature request Support Case.  I guess either he/she didn't submit it, or it got turned down.😕

    On this question, my position is still exactly as I expressed it in the second paragraph of the post above yours in that thread.  "However I suspect that Retrospect Tech Support's answer will be along the lines of 'it's already the way we'd like it to be'.  Their explanation would be that anyone who submits two Immediate operations whose destination is the same Backup Set is more likely than not to have made an error."  The rest of that paragraph can be read as a testimonial to how much easier it is to get Retrospect Mac to do what you want, because in early 2009 the still-EMC Iomega engineers made a momentous decision to do away with Immediate operations and instead have a Run button for a Script—if necessary a New script created a second ago via the GUI—generate an operation using it that is scheduled immediately.  In the personal example I cited in that paragraph, "I added  a Repeat Never schedule of the same script 2 minutes later"—which took 15 seconds in Retrospect Mac.  Maybe you can sneakily achieve the same result in Retrospect Windows by creating the script equivalent of your Immediate operation, and then creating for that script two run documents with different names per pages 237-238 of the Retrospect Windows 16 User's Guide.  The indented paragraph under item 5 on UG page 238 says "When you open several run documents at once, the scripts associated with them will run in alphabetical order by script name, regardless of the run document file names."  (If you want non-identical operations—with different Sources but the same Destination, create one run document for each operation but be sure they have different script names.) 😁

    The fact that doing this in Retrospect Windows requires at best a sneaky workaround illustrates a fact that the EMC engineers rethought in 2008: The old Retrospect GUI targets a 1990s scripting-virgin user.  The fact that they decided to retain this old GUI in Retrospect Windows must IMHO have been at least partially a reaction to the administrator consternation produced by the new GUI in Retrospect Mac 8—but that consternation also was caused by bugs and limitations in the Mac 8.0 release.  It's abundantly clear that Retrospect Inc. management and staff has regretted this decision ever since; I got confirmation of this in a Support Case response 2.5 years ago that said Retrospect Inc. was delaying updating the non-"What's New" chapters of the UGs pending "a UI overhaul in the works".   That they are now hell-bent on that UI overhaul is evident in my two posts responding to kidziti's suggestion 1 in his OP in a recent Product Suggestions—Windows thread.  Remember that StorCentric top management has publicly promised (4th paragraph herea Retrospect "backup server" version that will run on a Drobo device, and you can bet your bippy that the GUI for that will not be like the current GUI for Retrospect Windows. 🤔

    Therefore I suggest you not bother to submit a feature request Support Case. 🙄  Clearly the next non-bug-fix release will be Retrospect 17.0 in March 2020; expect it to contain a  greatly-enhanced version of the non-Web non-Management Retrospect Console that will look much like the Retrospect Mac GUI ( this KB article shows the more-enhanced 16.5 Web Console).  Thus, if it includes script scheduling—which the 16.6 Preview doesn't, IMHO the separate class of Immediate operations will be a thing of the past.  In the meantime, try what I suggested in the last three sentences of the second paragraph in this post. 😁