Jump to content

DavidHertzberg

Members
  • Content count

    1,089
  • Joined

  • Last visited

  • Days Won

    39

Posts posted by DavidHertzberg


  1. 🙄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 alreadï»ży 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 here)  a 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. 😁


  2. x509 and everybody else,

    I think I've figured out two substantial improvements to the enhancement proposed in this previous post in the thread. 

    The first improvement is to have at least 3 bits of "transient flags" in the Catalog entry for a file:  If the file is not being updated in this Backup run, set all its "transient flags" to zero.  If the file is being updated in this Backup run and its "transient flags" are all zero, set its "transient flag 1" bit to one.  If the file is being updated in this Backup run and only its "transient flag 1" bit is one, set its "transient flag 2" bit to one.  If the file is being updated in this Backup run and only its "transient flag 1 and 2" bits are one, set its "transient flag 3" bit to one.   If the file is being updated in this Backup run and all its "transient flag" bits are one, keep its "transient flag" bits at one.Then in the Groom script doing "transient Grooming", exclude only non-latest copies of those files whose "transient flag 1 and 2 and 3" bits are all one.  That way "transient Grooming" can exclude only non-latest copies of files which have been backed up in at least the last 3 consecutive Backup runs, thus making the "transient flag" bits the equivalent of a binary counter of the minimum number of immediately-consecutive Backups of the file (which might be the way Retrospect engineers would want to implement them to save a bit; a binary number with values 0 to 3 can be represented in 2 bits).  That should take care of what I characterized—in the third substantive paragraph of the post linked to in the first sentence of this post—as "situations in which the source volume has been backed up and 'transient'-Groomed since undetected ransomware encrypted it, or in which the latest versions of some applications files turn out to have been erroneously updated by the user".  It could obviously be extended with additional "transient flag" bits—or a longer binary counter as an equivalent— to cope with sneaky ransomware which might delay revealing itself in order to defeat the preceding scheme—although ransomware that encrypted all source files at once would in any case reveal itself by causing—to poison the backup—a noticeably-more-lengthy Backup of all source files.

    The second improvement simplifies the "additional checkbox for each Backup Set's Grooming Options , with a subsidiary checkbox specifying whether 'transient' flagging is to be done on a daily or weekly basis" proposed in the first substantive paragraph of the post linked to in the first sentence of this post.  The improvement adds a checkbox indicating "Groom this for transients" to the definition of a Subvolume (Favorite Folder in Retrospect Mac).  If a script is doing "transient" Grooming for a Backup Set whose Grooming Options has the additional checkbox checked, it would look at the Subvolume checkbox for the Subvolume to which a file belongs in order to determine whether that file should actually be "transient" Groomed.  Thus the improvement would make it unnecessary to segregate Backups of files for  which "transient" Grooming should be done into separate destination Backup Sets, because the checking/non-checking of a checkbox in a Subvolume would be sufficient to enable/inhibit "transient" Grooming of files in that Subvolume.  In fact having a checkbox in the Backup Set Options would be unnecessary except as an error-check, or to simplify the operation of Grooming for a particular Subvolume.  This would also probably eliminate the need for the subsidiary daily/weekly checkbox in the Backup Set's Grooming Options, because script scheduling would handle it.

    X509, please add these proposed improvements to the Support Case which this preceding post in this thread says you have submitted.  You'll have to add each substantial paragraph as a separate Additional Note—blamed on me, due to the 2000-character Additional Notes software limit for Support Cases.

     


  3. x509,

    Thinking further about my suggestion in this previous post in the thread, I now think that it wouldn't be such a good idea because of limitations in the way the Grooming options work for Backup Sets.  Per pages 380-381 of the Retrospect Windows 16 User's Guide, "Keep only the last n backups: specify the number of backups you want to preserve for each source [my emphasis].  I now realize that doesn't mean for the particular file.  Therefore n = 10 under that policy might result in keeping no backups for a file that doesn't change very often.  I therefore suggest that, as of the beginning of 2020, you switch to "Keep according to Retrospect's defined policy" specifying Months to Keep = 12; the months specification is too recent (2015) to have been updated into the UG.  That grooming wouldn't save as much space, but at least you'd have at least one copy of every file. (Note that the verb used on the UG screenshot is "Keep", but the verb used in the Retrospect Windows Tutorial screenshots is "Groom"; as a Mac administrator, I don't have a copy of Retrospect Windows to read.)


  4. On 12/9/2019 at 10:11 AM, Mayoff said:

    If Retrospect is having trouble seeing Macintosh Client volumes, make sure you are running the 16.6 version and not 16.5.1. 

    The explanation for the head of Retrospect Tech Support's comment, which turns out to not be applicable to the OP's problem, is in the P.P.S. of this post in the corresponding Mac 9+ Forum thread which the OP subsequently created.  A subsequent post in that thread shows that the OP solved his/her problem, which appears to have been caused by administrator error—possibly resulting from confusion shown by the misleading use of the red-markup terms "Server" and "Client" in the OP's screenshots—which I attempted to explain in a later post in that thread.


  5. robr,

    You don't say what version of the Retrospect Windows "backup server" you are running, nor do you say whether this particular Windows "client" is being backed up with a Backup script or a Proactive script.  In addition, you don't supply any information about what makes the other Windows "client" different from this Windows "client".

    This 2012 post says, for Retrospect Windows 7.7, "If the computer is already asleep, then retrospect will not run. There are 2 places to enable 'Wake on Lan' in retrospect, but I have found that it does not actually work (and yes, WOL works on my machine from other apps and is enabled in the bios)."  Presumably that is why you are waking your "clients" with a Python script.  Moreover, in spite of the fact that the Retrospect Mac Sources category has a checkbox under Client ->Options for enabling Wake-on-LAN, Retrospect Tech Support in 2016 verified my report that it wasn't working for Retrospect Mac 12 (equivalent to Retrospect Windows 10).

    However the cumulative Retrospect Windows Release Notes say, for 15.1.0, "Windows Client: Fixed Wake-On-Lan (WOL) for upgraded Windows client (#7358)".  I suggest that you Remove that particular  "client" machine's Retrospect Client from the "backup server", uninstall and re-install its Client program, and then re-Add the "client on the "backup server" (pages 277-293 in the Retrospect Windows 16 User's Guide)—after which you will have to re-Add it in each script that backs it up and drag its name into the appropriate sequential position (page 178 in the UG) .  However it may be sufficient to do what this recent post in another thread says, which is that the Remove and re-Add etc. in the "backup server wasn't needed—only a clean Client delete and re-install.


  6. redleader,

    To avoid confusing simpleminded people like me with your naming scheme, I'm going to insist that you follow certain terminology rules in this thread:  Your machine names shall be listed inside quotes (inverted commas), e.g. "JRP SERVER" and "FS SERVER".  Your volume names shall also be listed inside quotes (inverted commas), e.g. "JRP DATA" and "JRP DATA BU" and  "FS SERVER DATA" and  "FS SERVER BU" and "FS SERVER TM".  Where the same name is used for both a machine name and a volume name, e.g. "FS SERVER and "JRP SERVER", every use of that name shall be prefixed or suffixed with the word "machine" or "volume"—so we know whether you are talking about the machine "FS SERVER" or the volume "FS SERVER".  Lastly every Retrospect Inc. program shall be referred to with a name beginning with an upper-case letter, e.g. Server and Client, and followed by the word "program".

    Now that we've established those rules, I'll ask you two sets of questions:  (1) Why are you running both the Server program and the Client program on the machine "FS SERVER"?  (2) When you wrote ""I 'got around' the issue but ["but" presumably intended to be  "by"] turning off all the retrospect active tasks with activity manager and starting the client First", did you mean Retrospect active tasks on the machine "JRP SERVER" or the machine "FS SERVER", and—if it was the machine "FS SERVER"—did you mean you started the Server program on that machine or the Client program on that machine (I presume that when you say "turning off all the retrospect active tasks" you are referring to tasks in the Server program)?

    Let me now point out that, if you were backing up the volume "FS SERVER" on the machine "FS SERVER"  using the Server program running on the machine "JRP SERVER", of course you had to first start the Client program running on the machine "FS SERVER"!đŸ€ŁÂ  Do you ever turn that Client program off on the machine "FS SERVER", and if so why?  See the P.S. of this post for possible circumstances—local backups using machine "FS SERVER"—you might do that.

    P.S.: I now realize that this up-thread post probably means that you are running the Server program on the machine "FS SERVER" to locally backup its connected—possibly external—drives to one or more Media Sets connected to machine "FS SERVER"', and also running the Server program on the machine "JRP SERVER" to do Remote Backup—over the public Internet—instead of over machine "JRP SERVER"'s LAN—of one or more drives on the machine "FS SERVER" to one or more Media Sets connected to machine "JRP SERVER"'.  Is this correct, and—if so—do you need to turn the Client program running on the machine "FS SERVER" off when you are not doing the Remote Backup?  As for macOS Catalina's "poor current state", I hear 10.15.2 fixed a number of bugs.


  7. redleader and everyone,

    To redleader's Windows Products—Retrospect -> Server, SBS and Multi Server Forum essentially-OP-only version of this thread, the head of Retrospect Tech Support posted a reply that reads in its entirety "If Retrospect is having trouble seeing Macintosh Client volumes, make sure you are running the 16.6 versï»żion and not 16.5.1."  Since there is as yet no release of a 16.6 Client, I assume that refers to the Retrospect for Mac 16.6.104 "backup server" download.

    I saw this around 9 hours ago New York City time, but did not have time to phone Retrospect Tech Support until 5 minutes before their closing time this evening.  I'll phone again late tomorrow morning NYC time.  I'm still on 16.1, because I feared bugs in the 16.5 versions, but have no external drives.  Recently it has been extremely rare for anyone from Tech Support to post to these forums, so I'd take this as admission of a bug in the Mac 16.5 Engine.

    P.S.: I phoned T.S. Tuesday 10 December (after phoning Sales because I mistakenly remembered  extension 2 instead of 3), but I couldn't get them to pick up the phone.  I sent an e-mail to support@retrospect.com asking if there's a 16.5 bug; they set up a Support Case.

    P.P.S.: Tech Support replied Wednesday morning: "The fix for the client volumes not showing up with names longer than 27 characters was applied to the Retrospect engine v16.6.0.114, so suggestion from Robin followed to see if it fixes customers issue in this situation.  Retrospect client did remain unchanged with version 16.5.1.104."  From the screenshots I don't think the suggestion applies to redleader's problem—but the rest of you be warned if you have long volume names.  Rather IMHO the head of R. T. S. was harried as usual, felt impelled to respond with a suggestion, but was as confused by the OP's marked-up screenshots as I was—which is what led me to establish the terminology rules in the first paragraph of this post below.


  8. x509,

    Disclaimer: I'm a Retrospect Mac administrator, and my only Retrospect experience with Windows was backing up a job-mandated Windows 95 "client" from 2001-2004.  Please tell me where to mail you a bag of guinea-pig treats—whatever those are—for upgrading to 16.6.  😃

    Look at the thread containing this post, and another one containing this post.   The first thread pointed to OneDrive as the problem, and the second thread pointed to the Hyper V shadow copy service as the problem.  Did you do any Windows upgrading at the time you upgraded Retrospect Windows?  If not—and even if you did, I suggest you file a Support Case; the Retrospect "Inc." engineers may have messed up or missed a Windows change in the new version.

    BTW eppinizer, who made posts in the first thread, is IRL the actual Retrospect Tech Support person Jeff. M..  Ah, those were the days.😱


  9. On 12/6/2019 at 2:30 PM, Pesetus said:

    Hi everyone, from the start we had many different client problems, from double volume listing, to several "mac specific" filters and options that wouldn't work, On Demand Restore won't work, basically all conf lost due to upgrading from 15x to 16x while using certificates to authenticate clients and so.... most of them i managed to fix by myself... 
    Now, after Catalina OS, no client will work, i've done every step in the upgrading guide, verified security configs, even tried to uninstall the client (using the uninstall script) and re installed it with no effect.

     ....


    Our setup is the following
    We have a Win server running Retrospect 16.5 and around 40 mac clients, all of them laptops with only one network interface. Server and Clients are on the same subnet, all clients running 16.5. 
    All clients with Catalina show problems  
     

    ....

    screenshot3.png

     

    Pesetus,

    You need to read this Knowledge Base article, and also this one.  Note that the first KB article, in its last multi-sentence paragraph, erroneously links to the Mojave version of the second KB article rather than the Catalina version—which it should have (except that somebody on Retrospect "Inc."'s. august Documentation Committee didn't coordinate what he wrote in the first article with somebody else who was rewriting the second article for Catalina).

    Also, on general principles, I suggest you upgrade your Retrospect Windows "backup server" to version 16.6.0.133—which was just released 4 days ago.


  10. kidziti and everyone else,

    I had another telephone chat with the head of North America Sales for Retrospect "Inc."  this morning (his time), in which I asked about the Retrospect Console Preview which was released yesterday as part of Retrospect 16.6.0.  He had just come back from an all-hands meeting on the subject, and he agreed with me that this new Knowledge Base article is uninformative—verging on misleading regarding the article's Web (versus top-of-the-article) title. 

    "Desktop" in the title doesn't mean that this Console only runs on the Desktop Edition; it is apparently meant to contrast it with the Web-based Management Console.  What it does mean is that it runs only on the particular "backup server" machine it is monitoring, with the currently very-limited-beyond-monitoring capability of creating Proactive scripts on that particular "backup server".  The Retrospect Console Preview does not use Heroku or any other Web server, and requires no Add-On.  IMHO the engineers have contrived a way to attach a new GUI parasite to the Engine using the existing internal mechanisms for the Retrospect Windows integrated Dashboard plus—for Proactive script creation—some additional existing or new-in-16.6 GUI internal mechanisms, only now without some of the interfering properties of the existing integrated Dashboard you Retrospect Windows administrators have long complained about. 

    For those Retrospect Windows administrators who have physical access to their "backup server" machine, the Retrospect Console Preview may enable them to avoid using the existing integrated Dashboard—and even to leave their Retrospect Engine running constantly without using Auto Launching.  The Sales guy says that the reason the engineers released the Retrospect Console Preview at this time is to get people to beta-test the first version of a future Retrospect Windows GUI.  My cynical guess is that another reason for them releasing now it was to check off one or more boxes on their managers' lists. 

    P.S.: Upon taking a second—careful—look at the KB article linked to in the first paragraph, I realized that this version of the Retrospect Console Preview will not easily enable Retrospect Windows administrators who have physical access to their "backup server" machine to avoid using the existing integrated Dashboard.  I phoned the head of North America Sales for Retrospect "Inc." again this afternoon, and it turns out he still hasn't tried using it.  The way I would describe this version is a "funhouse hall of mirrors", similar to the one in the first few minutes of the movie "Us".  Once you start using it, it appears you can't get to its Dashboard substitute without first setting up a new Proactive script that starts to run immediately.  I think J. G. Heithcock, and possibly also his boss at StorCentric, ought to be embarrassed for thus trying to force Retrospect administrators to run a beta test of the script interface.😩  IMHO a less-sneaky way of getting beta testers for essentially a superset of the same interface (even if the Heroku Web-based code is JavaScript, not C++) would be to put the Management Console Add-On into the Configurator, especially if it were priced at no more than US$49 even for fancier-than-Desktop Editions.

    P.P.S.: Upon thinking still further, I realized that this version of the Retrospect Console Preview  has only one primary purpose—as a Sales demo for administrators either considering buying Retrospect Windows or considering switching to a competing Windows backup application because they are sick and tired of its current GUI.  For the rest of us, IMHO the key sentence in the KB article is  "We plan to steadily build Retrospect Console into a replacement for the current user interface for Windows and Mac."  But I'm happy with the Retrospect Mac GUI, even though its Console can at most be used over a LAN.


  11. x509,

    The screenshot in your OP is simply a copy of the only one on page 303 of the Retrospect Windows 16 User's Guide, and says it is of the Mac Client.  The Windows Client screenshot you probably should have included is on page 304 of the UG;  it has a Protected by Retrospect checkbox line instead of an On / Off button line.  Mac windows have three round buttons at the topmost left, whereas Windows windows have three square buttons at the topmost right.😀

    Do what Nigel Smith suggests above, except that I'd suggest Forgetting the "client" machine from your "backup server" beforehand (page 290 of the UG) and re-Adding afterwards (pages 281-299 of the UG).  Unfortunately you'll then have to re-enter and re-arrange the "client"'s list order  (pages 177-178 of the UG) in all Scripts that use it.  I used this procedure the other day, as recounted in the P.S. of this post in a Retrospect Mac 9+ thread.  Also consider updating your "backup server" to Retrospect Windows 16.6.0.114; it was released yesterday, but the Retrospect Windows and Mac Clients are still for 16.5.1.

    As far as the updating of  the UGs is concerned, that hasn't happened—except for the "What's New" chapter that is over-written with every major release without previously being copied into later UG chapters—since Retrospect Windows 9 was released in 2014. A couple of years ago Tech Support, replying to my Support Request, told me that the august Documentation Committee intended to get around to updating the UG.  In order to get StorCentric management to approve the one person-week that I estimate would be required to do that, I suggest sending a snail-mail to the Chief Technology Officer:

    Drobo

        Attn.: Mr. Rod Harrison, CTO

    1289 Anvilwood Ave.

    Sunnyvale, CA 94089

    USA

    Please include in the envelope a round piece of paper with "TUIT" written on it, as a suggestion that Retrospect "Inc." should "get around to it".đŸ€Ł


  12. cgtyoder,

    Nigel Smith, who has experience administrating an extensive LAN—which I don't have, is assuming the Client on your Macintosh machine has "gone bad" in a one-shot occurrence.  OTOH I, based on my prior experience, am assuming there is something making it systematically and repetitively generate -505 errors.  Try what Nigel Smith suggests; then, if that doesn't permanently solve the problem, investigate along the lines of what I have suggested.  Please let us know in a post here what you found.

    P.S.: This morning I'm a lot more receptive to the idea of Retrospect Mac Clients "going bad" in a one-shot occurrence than I was 24 hours ago.  The OP in this thread describes my experiences starting last summer getting -559 (network connection timeout) errors up to 2 hours into the 3-hour Saturday-morning Recycle backup of my MacBook Pro.  The last post in that thread describes my October 28th conclusion that, based on my having acted on Nigel Smith's suggestion that I change the System Preferences -> Energy Saver settings, the problem had been caused by a change in macOS 10.13.  But yesterday morning I got a network connection timeout for my  MBP (without any -559 error) about an hour into my Saturday morning backup.  I switched back to my slower 4-year-old Actiontec MoCAï»ż 1.1 adaï»żpters (see the second paragraph in the linked-to OP), and tried running No Media Action (Retrospect Mac name for Normal) backup scripts—all of which failed with -530 errors even though my MBP was running because the Client kept switching itself off despite reboots.  What I finally did was to Remove the MBP from my "backup server"'s Sources, re-run the Uninstall and Installer apps for Retrospect Client 16.1 on my MBP, and re-Add the MBP to the "backup server"'s Sources and Scripts.  I have been re-running the Recycle backup since 1:44 a.m.; it finished backing up and comparing the MBP at 5:57 a.m., and has nearly finished backing up the second of two local disks on my "backup server".  Conclusion: something made the Client on my MBP "go bad"—and "stay bad"—in a one-shot occurrence.  I'm still on 16.1, because it appears 16.5 is a "bad release".


  13. cgtyoder.

    First, possibly you should have posted this in the Retrospect 9+ Mac Forum, since it has to do with a problem with a Macintosh "client" machine—even though your "backup server" is a Windows machine.  Based on my past experience, you're likely to find that the -505 error is caused by something else running on the "client" machine that is interfering with the Retrospect Client software.  I predict that when you dig into "not sure what has changed in the meantime", you'll have to talk to whoever maintains your Mac "client"'s software.

    Here is my initial post, from 2017, in a thread on jweisbin's -505 error.   The short version is that, in 2016, I had discovered my own problem was because Adobe Flash Player Install Manager.appï»ż was repeatedly trying to update my MBP even though the latest version of Adobe Flash Player was already installed.  However in the remaining posts in the 2017 thread, I speculated that the ChronoSync "backup server" equivalent was— scheduling ChronoAgent's synchronization of an individual Mac for which the OP in that thread was responsible—interfering with its Retrospect Client.  We never got a jweisbin reply.


  14. redleader,

    Have you read the "Catalina" sub-section under the "Technical  details" section in this Knowledge Base article?  Although it's termed a "folder"—which I think is sloppy editing by the engineer who copied the article for Mojave and updated it for Catalina, it sounds as if your external drives  must be given "Full Disk Access" in System Preferences->Security & Privacy->Privacy.  And the last sentence under "Version 16.5 Required" in this KB article requires Full Disk Access for "...  removable volumes and network volumes."


  15. billbobdole,

    In case the Retrospect trick you're trying to use doesn't work anymore even with solutions in the P.P.P.S. or P.P.P.P.S. of my preceding post, here is how to replace it with facilities from 21st-Century ( 😀  ) Retrospect—as introduced with Retrospect Windows 7.5 in 2006 and added to Retrospect Mac 8 in 2009:

    This post by you in a January 2010 thread starts out  "Every friday at 9pm, I have retro do a full backup of about 30 dept computers, which will finish sunday afternoon.  This full backup appends to an already existing backup set as a new member [meaning a new File Media Set per my post above]. The data file from the full backup is about 700 GB".  You can  replace this with a Recycle weekly Backup of the departmental computers onto a single "first-stage destination" Disk Media Set, which you will re-use each week.

    Then during the week you can use a Copy Backup script—per pages 137-139 of the Retrospect Mac 16 User's Guide—to "ï»żï»żcopy this toï»ż a remote filestoreï»ż which from there bï»żacks uï»żp ï»żto ï»żtapï»że".  Because you are re-using the "first-stage" Media Set, that script can have the same source each week—so you won't have to do anything to it "manually".  Moreover, because Copy Backup by default copies only "active" backups to the "second-stage destination",  you don't have to Recycle the "first-stage destination" Media Set each week—so long as you don't set up a Grooming Option for it.

    You can then use a Copy Media Set script—per pages 135-137 of the UG—to copy from that "second-stage destination" Disk Media Set to a "third-stage destination" Tape Media Set. If you checkmark the Match Source Media Set to Destination Media Set and Don't Add Duplicate Files to the Media Set options, you won't have to worry about duplication onto the "third-stage destination".

     


  16. On 11/24/2019 at 12:36 AM, x509 said:

    It's about 12 hours after I wrote the last post, just above, and I think I left out an important point.

    I don't keep any user data on my PROGRAMS drive.  There is the Windows ProgramData and the \usere\phil set of subdirectories, which keep program config and status data. And some of that data does change frequently.  However, these data files are pretty small, usually well under 1 MB.

    Right now, as I write this post, a script is backing up the PROGRAMS drive.  

    
     On one system, there is 13, 262 files and 4.6 GB of backup.  On another system, 10, 533 files and 6.6 GB. Again, this isn't real user data.   I think all these files represent true "transient data,"  where I would need only the latest version or maybe 2 versions for restore purposes.
    This is the kind of datathat needs better grooming capabilities.

    x509,

    Due to your file hygiene—which might serve as a shining example to the rest of us, IMHO you don't need a new feature. 😀  All you need is a separate Backup Set for the PROGRAMS drive.  You would define the "Grooming Options" for that Backup Set, per pages 380-381 of the Retrospect Windows 16 User's Guide, as Keep Only the Last 2 Backups.  Then, after every one of those Backups, you'd schedule a Groom script per pages 221-223 of the UG.  If you're worried about disasters or ransomware, you could schedule a Transfer Backup Sets script per pages 209-213 of the UG—whose destination Backup Set would go off-site ASAP, before or after that Groom script.  Alternatively you could make every Backup of the PROGRAMS drive a Recycle, but that wouldn't be as good protection against disasters or ransomware—even with a Transfer Backups script—unless you scheduled a Recycle of the PROGRAMS drive periodically.  After using your Disaster Recovery Disk, you'd restore from your PROGRAMS  backup first before restoring from your DATA backup.


  17. twickland,

    First, nice problem solving. 😄  Please file a Support Case; maybe the engineers can fix this in the point-release of Retrospect  Mac 16 which I was told would come this week.  Now I know why it was wise for me to stay on Retrospect Mac 16.1. instead of upgrading to 16.5.1. 😌

    In related news, I now have a possible explanation for my -530 error—instead of -519—recounted in the P.S. of this post above.  The short version is that my "backup server" seems to have acted as if my MacBook Pro "client" was defined with Multicast, even though it was and is defined with Add Source Directly.

    The longer version is that on 19 November I received a fairly-recent model of CalDigit Thunderbolt 3 dock, with which I replaced the not-too-satisfactory two-year-old StarTech USB32DPPRO adapter connecting  my MBP via an ATEN KVM switch to my inherited DisplayPort Apple LED Cinema Display.  Since the CalDigit dock has a variety of outputs, I also used it to replace my Moshi USB3 to Ethernet adapter.  On 22 November, in the course of re-arranging my surge protector plugs to work around a limitation in the CalDigit dock, I tripped and fell (my balance is no longer good after two spinal operations) while working behind one of my study desks.   The fall caused my rear end to come down hard on the HP JetDirect EX Plus adapter that connects my 24-year-old HP LaserJet 5MP's parallel port to my Ethernet LAN. 

    The replacement JetDirect EX Plus arrived this afternoon, and I created a replacement static IP 192.168.1.200 entry for it (because the MAC address of the new EX Plus is different) in my Verizon FiOS "gateway" router.  In the process I noticed that my MBP was now showing up in the router at the non-static address 192.168.1.154 instead of at the static 192.168.1.202.  I figured out via System Preferences -> Network that this was because my MBP's Ethernet connection is now via Thunderbolt Ethernet Slot 1 instead of USB 3 (same port, different channel).  I gave the MBP the static 192.168.1.202 address in the router, and before going to dinner ran a "sacrificial" (Rule = No Files) Backup script  to make sure everything would be OK for my weekly Recycle script tomorrow.  It got a -530 error, so I Removed and re-Added the MBP "client" in Sources again using Add Source Direct—after specifying in System Preferences -> Network on my MBP that its Thunderbolt Slot 1 is  to Configure IPv4 Using DHCP with manual address; the "sacrificial" script then ran OK.

    The interesting thing is that I had had absolutely no errors—except in the stupid situation linked to in the second paragraph of this post—running Backup scripts for the last week and a half.  IMHO the only reasonable explanation is that the Retrospect Engine on the "backup server" had automatically re-tried finding the MBP via Multicast because the MBP wasn't at its Add Source Direct address—and succeeded.  That would explain why I got a -530 error, rather than a -519, on the one morning when I stupidly let the "backup server" run a Backup script when the MBP "client" really wasn't on the LAN yet.  So what you said typically happens still seems correct.


  18. billbobdole,

    IMHO you are not being candid with us about what you are trying to do.  According to this PCMatic page, .rbf—shown in your first screenshot—is an extension that was used for File Backup Sets—which per page 34 of the Retrospect Mac 16 User's Guide "combine the Catalog File and backed-up files into a single file stored on a volume."  This old Knowledge Base article says, under "File Backup Sets", "Because a file’s resource fork is limited to 16 MB, the file will eventually grow too large for the file system. When this happens, Retrospect 5.0 or later will separate the catalog file from the data file to allow the file backup set to expand. The split catalog file will be named 'Backup Set Name.cat.'"  Moreover, because your .rbf file is referred to as "Backup Set" in your seventh screenshot, it appears you are trying to backup onto a File Media Set using Retrospect Mac 16—which may no longer work.

    It sounds as if you will have to convert your old data to Disk Media Sets, which may or may not be possible.  If you recently upgraded to Retrospect Mac 16, you are entitled to 45 days free personalized help from Retrospect Tech Support—which isn't anyone on these Forums (we're volunteers).  You should phone (888) 376 -1078 extension 3.  However, you'll undoubtedly have to file a _candid_ Support Case, with your screen shots as attachments.

    P.S.: This 2010 thread, in which you are the OP, confirms that my first-paragraph deduction is absolutely correct—you're still using File Media Sets.  You've been using a Retrospect trick described by twickland in this post in that same thread: New Media backups have enabled you to automatically create multiple File Media Sets whose name differs only in an appended square-bracket-surrounded "subnumber"—meaning those File Media Sets which you referred to in the next post in that thread as "new members"—on the same HDD.  My search of these Forums has disclosed no other mention of this  trick—especially a more-recent one.  The head of Retrospect T.S. has been around since 1994, so he may know whether the trick still works in Retrospect Mac 16.  Alternatively you could Private Message twickland, and see if he knows.  When I started using Retrospect again in 2015—after stopping backing up to tape 5 years before, a Tech Support person (named Alan; he left 2 or more  years ago) advised me not to use File Media Sets; so I have no knowledge of them.

    P.P.S.: A reason what you're trying to do may not work is mentioned in this Knowledge Base article under "Details".  What you're trying to do may involve 32-bit data structures, and Retrospect Mac 16 eliminated their use—which may mean for File Media Sets as well as old OS X versions.  Ask Tech Support.

    P.P.P.S.: By doing a Google Search (of history for my next post in this thread) using the ancient Retrospect term "storage set", I found a 2011 post that may solve your problem using your old trick! 😀   The OP for that thread (by an administrator who used the "handle" AshMan3 before the Forums messed it up) begins " I'm attempting to perform an incremental backup to the Storage Set and it fails with the error message 'Can't access Media Set iMac 2010-04-03, error -1101 (file/directory not found)'."  The solution post I've linked to quotes an administrator who went (no posts since 2013) by the "handle" CallMeDave.

    P.P.P.P.S.: Have you read the "Catalina" sub-section under the "Technical  details" section in this Knowledge Base article?  Although it's termed a "folder", it sounds as if your SMB share must be given "Full Disk Access" in System Preferences->Security & Privacy->Privacy—as Nigel Smith alludes to  two posts below this one.  And the last sentence under "Version 16.5 Required" in this KB article requires FDA for "...  removable volumes and network volumes."


  19. Nigel Smith and twickland,

    According to the Retrospect Windows 16 User's Guide pages 491-492 (the same information was in the Retrospect Mac 6 UG, but was deleted in the glorious Retrospect Mac 8 upgrade), -515 and -530 errors have to do with connecting via the Piton Protocol (pages 293-294)—while -519 errors have to do IME with loss of an IP address connection during backup (e.g. when I forget my Add-Source-Directly MacBook Pro is being backed up and shut it down). 

    The Piton Protocol is Retrospect's 18-year-old method of allowing administrators  to add "clients" via Multicast, which means backup administrators—who are often non-IT key office functionaries with knowledge of what data has to be backed from what machines— don't have to know anything about IP addressing.  It definitely requires use of the 224.1.0.38 multicast address as well as TCP and UDP on port 497; "clients" added with Add Source Directly may not even need port 497—but from what twickland says in his last paragraph directly above I might be wrong about this.

    It still sounds to me as if your installations'  PIGs or Microsoft Windows Defender have now installed an anti-intrusion "improvement" that disables either 224.1.0.38 multicast and/or port 497 by default.  I consider this to be a menace to Retrospect's continued viability, and I urge both of you to file Support Cases as soon as you can pin this down for your installations—and please post in this thread what you pinned down.  Be sure to make the point that all the StorCentric-prioritized development (for which I have both official and informal sources) of a version of the "backup server" running on Drobo isn't going to sell many Drobos, if administrators can't back up their Windows "client" machines.  Maybe all that is needed is a prominent mention in the supposedly-forthcoming UG rewrites, plus a Knowledge Base article.

    P.S.: What twickland said typically happens didn't apply to me this early this morning.  Waking up after the scheduled time for my No Media Action script that backs up my MacBook Pro every day except Saturday , I stupidly booted the "backup server" in my bedroom before booting the MBP "client" in my study.  According to twickland's experience I should have gotten a -519 error, since my MBP was Added with Add Source Directly.  Instead I got a -530 error.

     


  20. bookcent/Steve,

    First of all, "backup client not found" is error -530, not -503.  I presume you have taken steps 1-5 in this ancient Knowledge Base article.

    Second, I solved a 2-year-long problem with -530 errors by Removing my MacBook Pro client from Sources and re-adding it using Add Source Directly—after having assigned the MBP a fixed IP on my router using its MAC address (stands for Media Access Control and has nothing to do with Macintosh, obtained from System Preferences -> Network -> Advanced for active Ethernet connection -> Hardware tab), per pages 66 and 79-80 in the Retrospect Mac 16 User's Guide.  You speak of "remote Macs"; are these "clients" possibly on a different subnet from your "backup server"?  If so, Subnet Broadcast, per page 79 in the UG, may work for you instead of Add Source Directly; it worked for me when I briefly tried it in late 2018 per henry-in-florida's suggestion.

    Third, once you have eliminated the -530 error, upgrading your remote Mac to Catalina means you'll have to comply with this KB article to fully access it with Retrospect.  This KB article is also applicable, but you have complied with its current contents by upgrading your "backup server" to Retrospect Mac 16.5.1.(104); Retrospect "inc." promised new contents several weeks ago, but so far there's been no update of the article.

    P.S.: As Nigel Smith has pointed out below, while I was writing this you started another thread.  In that one you mentioned a ï»ż"multicast port unavailable" message; have you simultaneously made changes to either your "remote Mac" hardware or how you operate it (i.e. use of wireless)?


  21. Nigel Smith,

    Is it possible that your "client" machines are defined to your Retrospect Windows "backup server" by the Direct Access Method (see pages 296-297 of the Retrospect Windows 16 User's Guide), but defined to your Retrospect Mac "backup server" with Use Multicast?  If so, IMHO that would mean that the latest version of Microsoft Windows Defender has added something that blocks multicast on 224.1.0.38, and that your "rather old Mac RS software" still defines "clients" by a method that used to work.  Alternatively your "clients" are also defined to Retrospect Windows by the default Multicast, but the latest version has some code for working around Windows Defender that isn't in your "rather old" version of Retrospect Mac.  FYI, the -515 error is defined on page 491 of the Retrospect Windows 16 UG. 

    BTW, could you tell us why you are backing up the same "clients" with two "backup servers—and what version of Retrospect Mac you are using?

    twickland,

    I ask again: When you say "They are all connected via direct IP", do you mean "clients" are all defined with Direct Access Method?


  22. x509,

    Actually you may be smoking more-powerful stuff than you think you are.😄 

    How about having a one-bit flag in the Catalog for a Backup Set that marks a file as "transient" if it has been backed up N times in the last N days/weeks—which it would have been because its file size or contents kept changing while its name and directory stayed the same?  It would be safe (but see the next-to-last paragraph for when it wouldn't be) to keep only the latest backup of such "transient" files—regardless of legal requirements—so long as they aren't in certain directories known to possibly contain business-critical files.  It would probably be safest to have the Windows/Mac variant of Retrospect automatically avoid doing "transient" flagging in such directories.   There would no doubt have to be an additional checkbox for each Backup Set's Grooming Options , with a subsidiary checkbox specifying whether "transient" flagging is to be done on a daily or weekly basis.

    There could then be a Built-In Selector (see page 437 of the Retrospect Windows 16 User's Guide; the Retrospect Mac term is Rule), usable only in a Groom script (a Retrospect 15 feature)—as opposed to a Backup or Proactive script, that would be used to Exclude all files marked as "transient" unless they have the date of the latest backup per the Backup Set Catalog.  Such a Groom script could be run after the last of the daily/weekly backups to a Backup Set.

    On second thought, for Backup Sets whose Grooming Options have the additional box for "transient" flagging and which has been Groomed for "transients", a Restore would have to use the Catalog File—rather than a Snapshot—for any files flagged as "transient" regardless of whether a previous Snapshot was chosen, in order to restore an entire source volume.  This would not be good for situations in which the source volume has been backed up and "transient"-Groomed since undetected ransomware encrypted it, or in which the latest versions of some applications files turn out to have been erroneously updated by the user—a situation which has happened to me.  That makes this enhancement sound considerably less attractive.

    Here is why and how to submit a Support Case for an enhancement.


  23. twickland,

    Here's the Knowledge Base article on the -519 error.  "Error 519 means Retrospect had established a network connection with another computer and was communicating through that connection when something caused the connection to be severed." 

    "This error is one of Retrospect’s most challenging errors to troubleshoot because networks involve a large number of variables. Causes of error 519 range from a simple software conflict on an individual workstation to a faulty network component that does not cause trouble during normal (non-backup, less intensive) use. Weak links can exist in the software or hardware level, on the backup computer or the client computer, or in the infrastructure of your network. This document aims to help you narrow down what might at first seem like an unwieldy problem to solve."

    When you say "They are all connected via direct IP", do you mean "clients" are all defined with Direct Access Method—known in Retrospect Mac as Add Source Directly?  I've had to do that to avoid -530 errors that seem to be somewhat related to changes in networking hardware.

    Yes, Retrospect still uses TCP and UDP port 497; it multicasts 224.1.0.38.  Here's MrPete's post on comprehensive Windows trouble-shooting procedures.

    Here are some very cynical WildA**edGuesses:

    • Your Professional IT Guys (sexist term,  and naughty acronym when 't' is lower-cased, entirely intentional) installed an anti-virus product that interferes with Retrospect Windows Clients, one not yet fixed in this 2013 post. I'd add Windows Defender Firewall to the list of anti-virus products, except that "a newly-added Windows 10 client was able to be backed up once before going incognito"—which sounds like somebody did something to that machine's software after it arrived in the organization with a presumably-latest version of Windows 10 ( ask PIGs: What was arrival version?) .
    • Your Professional IT Guys did something to the networking hardware/software with which your organization's Windows "client" machines are connected.  Your organization's Mac "client" machines are unaffected because Mac users are isolated in one or more "leper colony" departments .đŸ€Ł
    • The Retrospect "Inc." engineers messed up something in the Retrospect Windows 16.5.1 Engine.  They've been doing that in the last two X.5.Y releases, IMHO because management is trying desperately to fully implement major features that were previewed in the corresponding X.0.0 releases.  A known example (which unfortunately probably has nothing to do with your problem) from a recent thread in  this Forum is connected with "Improved NAS support with auto-adding existing NAS share mounts" in 16.5.0.  I happened to mention it in a short phone conversation with the head of North American Sales last week, and he said that is a known problem that will be fixed with a new release "within about a week".  My candidate for the Engine "improvement" that caused your problem is "Networking: Retrospect now honors service priority when choosing a default interface (#7058)"—whatever "service priority " means—in the cumulative Retrospect Windows Release Notes (assuming carryover to Mac Engine).

    P.S.: The head of Retrospect Tech Support replied in my Support Case 3 weeks ago "You can try going to Network in the Retrospect Preferences and click Advanced. Change the network timeout from 300 seconds to 9,000 seconds and see if Retrospect is able to complete the backup".  That Support Case was about my getting -559 errors after precisely two hours when running a Recycle backup of my MacBook Pro.  He had also suggested "Inside your energy saver control panel, you may need to set the screen to never sleep (and use a screen saver) and check 'prevent computer from sleeping automatically when display is off'. Or try a combination of those options. In some cases Uncheck Put hard disk to sleep when possible can also help."  Those latter suggestions are obviously for a Mac "client", but possibly Windows 10 has—as Nigel Smith said of macOS in my thread about the -559 problem—"tied computer-sleep and display-sleep together -- the default is that, when your display sleeps your computer does too."  The combination of suggestions fixed my -559 problem.


  24. kidziti,

    I'm concerned about the speed of large-scale recovery, not "seeding".  Amazon started offering Snowball for "seeding" in October 2015, which was almost 6 months after I formulated my modern Retrospect off-site strategy and 5 months before Retrospect Windows 11—with cloud Backup Sets and a nifty facility for changing paths for a Backup Set between cloud and shipped disk (unfortunately only shown in this Retrospect Mac video Tutorial)—was introduced. 

    Microsoft offers Azure Data Box and Backblaze B2 offers Fireball, but renting these devices or Snowball run US$200-300 minimum.  All 3 of these services include encryption of your data.  As far as affordability is concerned, the reason Retrospect Inc. offered Backblaze B2 as a cloud backup service in Retrospect Windows 12 is because it "is a business-class cloud storage provider with extremely low costs, at $0.005/GB a month."

    Overnight FedExing of a recovery physical device back to your installation would add more to the cost.  That's why "Some applications offer seeding and large-scale recovery via third-party services, which may use a high-speed Internet channel to/from cloud storage rather than a shippable physical device."

×