Jump to content

DavidHertzberg

Members
  • Content count

    1,055
  • Joined

  • Last visited

  • Days Won

    38

DavidHertzberg last won the day on November 8

DavidHertzberg had the most liked content!

Community Reputation

62 Excellent

About DavidHertzberg

  • Rank
    Occasional Forum Poster

Profile Information

  • Gender
    Male
  • Location
    New York, NY
  • Interests
    Retired applications programmer, with a few Macs at home.

Recent Profile Visitors

1,722 profile views
  1. DavidHertzberg

    Several Issues with mac Clients

    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.
  2. DavidHertzberg

    Drop the Dashboard

    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 hang a new GUI parasite onto 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 full 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.
  3. 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".🤣
  4. 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 adapters (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".
  5. 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.
  6. 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."
  7. redleader, This Forum is a sub-Forum of Windows Products—Retrospect. Why are you posting here about a problem with what is obviously Retrospect Mac?
  8. 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 backs up to tape". 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".
  9. DavidHertzberg

    Grooming Policy Too Simplistic

    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.
  10. DavidHertzberg

    Windows clients no longer accessible

    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.
  11. 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."
  12. DavidHertzberg

    Windows clients no longer accessible

    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.
  13. DavidHertzberg

    Remote client issue with Catalina

    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)?
  14. DavidHertzberg

    Windows clients no longer accessible

    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?
  15. DavidHertzberg

    Grooming Policy Too Simplistic

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