Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


DavidHertzberg last won the day on March 18

DavidHertzberg had the most liked content!

Community Reputation

57 Excellent

About DavidHertzberg

  • Rank
    Occasional Forum Poster

Profile Information

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

Recent Profile Visitors

1,434 profile views
  1. AntonRang, You don't say what version of Retrospect you are running, and under what version of macOS you're running it. The latest version of Retrospect Mac, released on 28 May, has the following fix in the cumulative Release Notes: If that doesn't help, here's why and how to file a Support Case for this bug.
  2. DavidHertzberg

    PSA: Wikipedia article on Retrospect going away in current form

    After 3 tries, DovidBenAvraham has created a sufficiently neutral-sounding Request for Comment section on the "Backup" article's Talk page that several other Wikipedia editors have commented. All of them so far, plus DBA, have reluctantly voted to split off the "Enterprise client-server backup" section into a separate article. DBA's justification is that only doing the split-off will allow him to file an Administrators' Noticeboard request to ban Pi314m from editing the new separate article. Pi314m promised in his own voting statement to act as if such a ban is in effect, but DBA pointed out that the promise is worded so as to likely expire within a day. Anybody who is already a Wikipedia editor can come over to the Request for Comment section on the "Backup" article's Talk page, in order to vote on and/or discuss DBA's request. Actually you don't already need to be a WP editor, but by the time you learn to use the idiosyncratic WP editing system DBA will have already filed his Administrators' Noticeboard request—so your input may not count for much.
  3. DavidHertzberg

    multicast on wrong interface

    zz-pdb, Both possible versions of your problem have been discussed in a Mac 9+ Forums thread. Here's my post that distinguishes both versions; you can look forward or backward in that thread to find a possible solution for your particular version. However if it is indeed your "client" machine that has two network interfaces, this Knowledge Base article doesn't say how to specify the "ipsave" command for the Linux Client software. Page 554 of the Retrospect Windows 16 User's Guide says: If that doesn't help, here's why and how to submit a Support Request for a bug. P.S.: I had forgotten to suggest that you Add Source Directly, specifying its fixed IP address on your LAN. I see that this option in adding "client" machines, which solved a two-year-old problem I had with -530 errors, is called Direct Access Method on pages 294 and 296-297 of the Retrospect Windows UG. Since Subnet Broadcast—which also to some extent bypasses Multicast—may solve your problem if it is your "backup server" that has two network interfaces, you probably should read pages 294-299 in the UG. Either way you'll need to Remove and re-Add your "client" machine.
  4. Thank you, CherylB. Would you believe that same article, titled "macOS Mojave – Application Data Privacy", has been in the Knowledge Base under "Top Articles" since 16 October 2018? Great article titling, Retrospect engineers! P.S.: CherylB, how about your creating a Support Case suggesting that Retrospect Inc. change the KB article's title to something like "macOS Mojave – Application Data Privacy and Error -1101"? Here's why and how to do that.
  5. I stopped the "sacrificial" script early 8 June morning after 19 minutes when it issued "!Error reading snapshot record ...", which it shouldn't have been doing because the script specified Recycle. I did a Rebuild of "Media Set White" from portable HDD "G-DRIVE White" , and the "real script started to run OK—until it failed with a -519 (network communication failed) error after 4 minutes when I absent-mindedly shut down my MacBook Pro "client" preparatory to going back to bed.
  6. After I downloaded Retrospect Mac, both the Recycle backup scripts—the "sacrificial" one and the "real" one—started to run OK early 1 June morning to "Media Set Red". However, after the "sacrificial" script ran OK, two things happened while the "real" script was running: The backup of my MacBook Pro "client" failed after 1.5 hours with -559 (network connection timeout). The script continued with my local drives. After the script backed up and compared my late friend's local "Macintosh HD" and backed up my local "Macintosh HD SSD", it failed with -116 (volume doesn't exist) when I gently (I thought) picked up "G-DRIVE Blue" to look at its bottom masking-tape label one minute into the compare.
  7. I originally posted this on 25 May (as shown in the right-most column of the thread listing), but it was deleted by Retrospect Inc.—evidently sometime after 6 June 2019 03:35 when I copied it as an Additional Note to Support Case #67777—because they considered a final paragraph I've now omitted to be overly critical of Retrospect Inc. engineers. This happens, as I warned you in the third paragraph here! Both the Recycle backup scripts—the "sacrificial" one and the "real" one—ran OK early 25 May morning to "Media Set Blue". Of the possibilities discussed here up-thread: I simply pushed the USB3 cable firmly into "G-DRIVE Blue" late 24 May morning; I didn't take special precautions. This wasn't the week for my cleaning lady, but last week—when the scripts also all ran successfully—was. The USB3 cable I used was the same one that was used when I had problems two Saturdays ago. I had upgraded my "backup server" to Retrospect Mac 16.1.0 before last Saturday's run, and I upgraded it to 16.1.1 on Thursday. So possibility 3 is the winner. The Retrospect Inc. engineers must have fixed the Recycle bug in 16.1.0, even though there's no mention of that in the cumulative Release Notes. I can't believe they released 16.0 without having tested Recycle for APFS-built Media Sets; I too would be ashamed!
  8. zz-pdb, I sincerely doubt that it wouldn't work on AMD processors, but I'm a Retrospect Mac administrator—and all Macs manufactured since 2006 have Intel processors (before that they had IBM PowerPC or Motorola processors).. Here's why and how to file a documentation request. P.S.: Here's the most recent post (from 2014) I could find where the OP says he is running Retrospect on an AMD CPU. Here's an 8-month-old post where the OP is having the same problem as jgaiche reported in 2014 but is running Retrospect Windows 15.6 on an Intel CPU. FYI, here's a post from farther down x509's 2018 thread where he recounts Retrospect Tech Support's response to that same problem, which AFAICT will only be resolved for Retrospect Windows administrators by the introduction of the glorious Web-based Management Console.
  9. DavidHertzberg

    PSA: Wikipedia article on Retrospect going away in current form

    I've noticed a recent rapid uptick in the number of views of this thread. I'm guessing that's because a number of you have noticed drastic changes to the ""Backup"" article, including deletion or total-dumbing-down of two paragraphs in the "Performance" sub-section of its "Enterprise client-server backup" section (described here). DovidBenAvraham is now trying to remove the article from the clutches of what he and I would describe as a "neatnik near-nut-case". If any of you are Wikipedia editors, please don't interfere at this stage—which consists of getting a Third Opinion from a WP outside volunteer. To quote DBA [edited slightly]:
  10. DavidHertzberg

    repetitive SIGSEGV error

    Thank you, Nigel Smith, for suggesting a problem explanation—launchd—I didn't know anything about. minidomo, did you inherit and/or upgrade this Retrospect installation? minidomo, read all pages 198-204 in the Retrospect Mac 15 User's Guide. "launchctl on the Mac" on pages 203-204 discusses what Nigel has diagnosed, with a slightly different (but possibly out-of-date, because the chapters after "What's New" in the UG haven't been updated in years) solution.
  11. DavidHertzberg

    File properties changed - Did Retrospect

    x509, Look at pages 362-367 in the Retrospect Windows 16 User's Guide, and see if you can figure that out. You might have to check-mark the Set Archive Attributes option per page 364, Restore those photo files, and change the Windows date values for them again to cause the files to be backed up again. Then again, I might not know what I'm talking about. P.S.: Wait a second, aren't those file date values stored in the Snapshot entry for a file? If so, then Retrospect would have updated all of the entries on the next Backup run. I know that because, as a holdover from when I was having a problem with -530 errors, I schedule a "sacrificial" script run before each "real" Backup script run. The "sacrificial" scripts specify the No Files Selector (Rule for Retrospect Mac)—meaning no files are actually backed up, but they spend about 3 minutes "creating snapshot" and "copying snapshot"—evidently for each file on my MacBook Pro's SSD. And yes, "Windows Selector Conditions" on page 440 of the UG says: P.P.S: For Retrospect Mac administrators who may be reading this, Snapshots are the "crazy Mrs. Rochester in the attic we're not supposed to talk about". Back around 2000, first Unix-based OSes and then Windows developed this capability which the industry has termed a "snapshot". Thus when Retrospect Mac 8 was developed in 2008, EMC documentors decided to drop the use of the term "Snapshot" for a different capability that had been in Retrospect since the late 1980s; however the terminology in Retrospect Windows has never been changed due to "unfortunate events" in 2009-2010. DovidBenAvraham used to have this described in the Wikipedia article, but other meanie WP editors made him remove this as Original Research. So you'll have to sneak over and read about Retrospect Snapshots on page 31 of the Retrospect Windows 16 User's Guide. But don't talk about them, even though you can hear "Mrs. Rochester screaming" every day in messages issued by the Retrospect common underlying code. "Mrs. Rochester" doesn't "burn the house down" as in Jane Eyre; in fact Snapshots are a vital part of Retrospect Mac as well as Retrospect Windows operations. Pages 229-230 of the Retrospect Mac 16 UG say "Retrospect now uses the term backup to include both session and Snapshot data." BTW, APFS offers "snapshots" in the industry-standard sense, so the EMC documentors were prescient.
  12. DavidHertzberg

    repetitive SIGSEGV error

    minidomo, Am I correct in thinking that the messages you refer to in your third paragraph immediately above are in the macOS Console log, not the Retrospect log? [assumes Indian accent] You should PM me your credit card information, so that our technical specialist can remove a very serious virus infection from your Mac! [ drops Indian accent] Seriously, maybe you should stop looking at your macOS Console log. I assume you've checked your Retrospect scripts to make sure that "Fridge" and/or its folders are not check-marked as Sources or used as Destinations in any of them. My guess is that you're getting those messages either because you're still running Time Machine, or at because at one time you specified a Time Machine Backup Disk. If it's the latter, you should go to System Preferences->Time Machine, click Select Backup Disk, click the "Fridge" disk that's shown there, and then click the Remove button to remove it. If it's the former, then you should know that Time Machine doesn't work with an APFS-formatted Backup Disk (which is what the messages are telling you)—so reformat "Fridge" with HFS+ (which you may not be able to do if it's an SSD). If you're not running macOS Server or Windows Server on any of your machines, then Desktop Edition is all you need. As I've delicately alluded to in this post and the following one in another thread, Retrospect Inc. is worried about reduced Edition license revenue because many installations have substituted Linux-based file servers for macOS Server—which doesn't provide much anymore beyond what you get for free with macOS 10.14. An upgrade to Retrospect Mac 16 Desktop Edition will cost you US$70-75.
  13. DavidHertzberg

    repetitive SIGSEGV error

    minidomo, I don't know know what the cause of this specific error is, but I'm pretty sure that "retroisa" is Retrospect's separate Instant Scan process. If you un-check the Enable Instant Scan box per page 200 in the Retrospect Mac 15 User's Guide, that should eliminate the repetitive Console error message. The cost will be some slowness in your backups. BTW, is this message in the Retrospect Console log, or in the macOS Console log? Another thought that occurs to me is that your Mac Mini may have a drive formatted with APFS, especially if it's running macOS 10.14 and the drive is an SSD. Several administrators found that Retrospect Mac 15 was taking hours to scan APFS-formatted source drives, and a Knowledge Base article was updated in May 2018—when Retrospect 15 was the latest major version—to state that Retrospect Instant Scan doesn't work for APFS. As stated in this final post in that same thread, after my MacBook Pro "client" SSD was forcibly converted to APFS I upgraded to Retrospect Mac 16; I found that the MBP scan is taking less time without Instant Scan than it did under Retrospect Mac 15—when the SSD was still formatted with HFS+ and I was using Instant Scan. (I should point out that Retrospect Inc. and its predecessor corporations have never paid me a cent, so I won't get a commission if you upgrade to Retrospect Mac 16—and you may be able to get away with upgrading to the Desktop Edition because I don't think Retrospect can identify recent editions of macOS Server .)
  14. DavidHertzberg

    Duplicate-Copy has stopped working in 15.6

    Fredspon, After rereading this, I question whether you should set your Scheduled Executions as Recycle. You say "I want the original backups to remain intact as they are recycled by their own scripts after 3 months". However page 226 of the Retrospect Windows 15 User's Guide says: If I understand what you probably want to do, it is to Recycle your primary Backup Set disk Members after 3 months to prevent their running out of space, but to keep accumulating forever the backups on your secondary disks in case you need those backups for disaster recovery. This is the user-demanded feature that the EMC predecessor of Retrospect Inc. built with Transfer in the early 2000s; many enterprise users wanted—and still want—their secondary Backup Set Members to be on tape (beats chest, shouts "Real enterprises use tape!" ) because buying an additional high-capacity blank tape every so often is cheaper (once they've shelled out upwards of US$1500 for a tape drive) than buying an additional hard disk drive every so often. If this is what you want to do, then—besides changing Scheduled Executions to Normal—you should tick Match Source Volumes to Catalog File and tick Don’t Add Duplicates to Backup Set and tick Transfer Any Needed Intermediate Database Snapshots (I've initially-upper-cased some more words in these option names to make the names easier to read). Although those options will slightly increase the running time for your Transfer Backup Set scripts, it will allow you to Transfer incremental backups while preventing any multiple transfer of the same backup. You won't have any unpleasant surprises after 3 months, and I doubt you tested for that long. I should point out that I am a lowly home user of Retrospect Macintosh, who does a Recycle backup every Saturday onto a brought-back-from-bank-safety-deposit-box portable HDD and does incremental backups onto it Sundays through Fridays. So an administrator with real enterprise experience should correct me if I'm wrong. However I just found my applicable three-year-old post, and the options in it are the same ones I said to tick in my third paragraph (second below the quote) of this post. I'm not providing a link, because the thread it's in is about doing Cloud backups using Retrospect Mac and involves initial "seeding". However three years ago I changed the options ticked in the post after the head of Retrospect Tech Support posted a Tutorial, to which I also won't link because I see the Transfer options in Retrospect Windows have changed since the Tutorial was posted. P.S.: If what I suggested in the paragraph below the quote is not what you want to do, at least have your Transfer Backups Sets script(s) be scheduled to do a Recycle at least one run after your Backup script(s) are scheduled to do a Recycle. That way you don't run into the following bad situation, which Murphy's Law says will happen: One or more data folders on your source drive go bad. Your Backup script runs with a scheduled Recycle immediately after that happens, so your primary Backup Set no longer contains data from the now-bad folder(s) . You don't notice the error message(s) from your Backup script, so you allow your Transfer Backups Sets script to run with a scheduled Recycle. Result is that you no longer have that data on either your source drive or your primary Backup disk Member or your secondary Transfer Backups Sets disk Member. Back in the early 2000s your Transfer Backup Sets script(s) would have had tape Members as their destinations, so (provided you hadn't re-used your existing tapes for the Transfer Backups Sets run that did the Recycle) you could have done a Recreate of your secondary Backup Set's Catalog file from the tape Members and done a Restore using that secondary Backup Set; however you're probably not using tape.
  15. DavidHertzberg

    Event Handlers

    cmgsupport and PaulMikeC, This Knowledge Base article says: My eventually-achieved understanding of the first sentence in that quoted passage is that you have to rename your script file to "RetroEventHandler" (without the quotes). It is not sufficient to put the script file in the proper folder per the KB article. Did you do the renaming? Sorry it took me so long to spot that; I looked at the KB article several times. I haven't messed with script files myself, but you could PM saskia. P.S.: In view of what PaulMikeC has written directly below, my apology to him—and presumably to cmgsupport—for suggesting that he missed the KB article statement that the script must be named "RetroEventHandler" . However I strongly recommend that he file a Support Case suggesting that either the KB article or the sample event-handler script(s)—or both—be revised to deal with the fact that the log file isn't generated in a directory where the script creator would expect to find it. Here's why and how to do this.