No more instant scan on MacOS?

[CherylB]

On 1/22/2019 at 9:35 PM, cgtyoder said:

No, you're not the only one. Came here, searching for info on this problem. It is very frustrating! The first scan on my MBP (10.13.6), accessed from Retrospect Desktop 15.6.1.104 (W10), took 14 hours. I will have to try turning ISA off. Looking forward to a real solution...

Martin is definitely not the only one experiencing over-lengthy backups. We use incremental backups and the instant scanning often takes multiple hours and sometimes overnight. I will discuss this with our team and try turning off ISA but am hoping the release of v.16 repairs this.

[DavidHertzberg]

insont and cgtyoder and CherylB,

I haven't been denying that long scans are a real problem for Retrospect administrators backing up Mac drives formatted with APFS.  I'm really sorry you folks have this problem.

It's not a problem for me, because my two modern Macs are running macOS 10.13 High Sierra (just upgraded last week at the urging of Apple Support—keeping the machine's only drive still formatted with HFS+) and macOS 10.12 Sierra.  One reason for my OS backwardness is that I had a deep-seated mistrust of APFS; I felt—and still feel—that a brand-new filesystem was a big challenge for Apple.  That feeling was later confirmed by my reading here (along with other places) that Apple didn't publish full documentation on APFS until sometime in 2018.  As I said 8 months ago in this thread, the developers of another backup application turned out to be also having problems with their equivalent of Instant Scan not working for APFS.   But, as I tried to make clear in my latest previous post, the reason Retrospect has slowness of non-Instant scanning is probably because it has been using 32-bit Mac APIs for the last 30 years.

Now here's something "positive" I can contribute.  A couple of hours ago I phoned Retrospect Inc. Sales.  A senior salesperson there told me the engineers are working on this problem, and that it's likely to be fixed in version 16.

If you feel it's necessary to put additional pressure on Retrospect Inc., my advice is for each of you to submit a separate Support Case.  Here's why and how to do that.  Just copy your individual post(s) in this thread into the Description of Your Issue, which IMHO should be categorized as a Problem rather than as a Backup Error.

[DavidHertzberg]

insont and cgtyoder and CherylB,

I just discovered, while writing a post discussing this problem (among others) in my authorized Retrospect thread on the Ars Technica Mac forum, that this Knowledge Base article has been temporarily hidden from view (I found it again through my link in a prior post in this thread) while having been updated to refer to Retrospect 16 as of 5 March 2019. I take this as confirmation that the engineers have now completed what must have been a substantial effort in changing a lot of 30-year-old code, which the developer(s) of younger backup applications such as the one insont mentioned have not had to go through.

OK, IMHO you've now got a definite date (probably 6 March) when the non-Instant lengthy APFS scan problem will be—at least preliminarily—fixed.  If you still want to vent, feel free to do so.  If you want instead to file Support Cases, those would provide retroactive justification for Retrospect engineers having made the effort.  But IMHO it's time to make good on "I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this."

[CherylB]

DavidHertzberg, thank you for the detailed information. I have filed a support case and hope the March 6 upgrade to v. 16 (or v.16.1) will be helpful in speeding up Instant Scan and other backups.  

[DavidHertzberg]

On 2/18/2019 at 10:43 AM, CherylB said:

DavidHertzberg, thank you for the detailed information. I have filed a support case and hope the March 6 upgrade to v. 16 (or v.16.1) will be helpful in speeding up Instant Scan and other backups.  

CherylB,

I think you misunderstand what I've been saying in this thread.  Instant Scan was not supported for APFS volumes as of May 2018, and I don't think that's going to change with Retrospect 16—because the macOS facility it depends on (called FSEvents) wasn't implemented in the same way for APFS as it was for HFS+. 

But, according to what Retrospect Tech Support told insont per this October 2018 post, "In our next full release of Retrospect the client scan APIs will be completely overhauled .... For local backups you can help speed things up by changing your current api settings .... Client API changes are being worked on and preliminary testing shows them being upwards of 10 times faster than they are currently."  IMHO that means non-Instant Scan will be speeded up so much we won't miss Instant Scan.

P.S.: I even have hopes that the speed of actual Mac Client data backup will increase with Retrospect 16, because of the changeover to 64-bit APIs.  This February 2018 post by dittberner@dbr3.de says he got much faster backup of his Windows server files when he switched from Retrospect Mac to another application; he says further down the thread "The other product is not comparable (much more expensive and other functions)."  dittberner@dbr3.de later PM'd me (signing it with his male first name) the name of the other client-server backup application; its developer was founded 18 years after Dantz Development Corp., and its 64-bit application—meaning it won't back up sources booted with anything earlier than OS X 10.8—"is ideal for businesses in the Media and Entertainment industry".  IOW, my hypothesis in this February 2018 post in the dittberner@dbr3.de thread seems to be true only if you assume that the client-server application stays with the same set of APIs—rather than change its APIs from 32-bit to 64-bit.

P.P.S.: What I predicted seems to have come to pass with the release of Retrospect Mac 16.0 on 5 March 2019.  First, the cumulative Release Notes say for Engine "Improved: Scanning faster on APFS volumes" and for Client "Improved Mac: Client scanning faster on APFS volumes".  Second, the cumulative Release Notes also say for Client "Alert Mac: EOL notice for Apple Mac OS X 10.3. 10.4, and 10.5 - See details"—where the details are the temporarily-hidden updated version of the Knowledge base article I linked to up-thread which says "Now that the transition to 64-bit macOS file system data structures is complete, Retrospect can no longer support 10.3, 10.4, and 10.5 with the Retrospect 6.3 Client and Retrospect 9.0 Client."

Edited March 5, 2019 by DavidHertzberg
Added links to other posts; added P.S. expressing hope that actual data backup speed will be increased; added extra sentence to P.S.; dittberner@dbr3.de is male; added P.P.S. showing released version 16.0 has implemented what I predicted

[insont]

I installed 16.0 yesterday and am test running it now on my 2013 MacBook Air with MacOS 10.14.3, APFS. There is a process "Retrospectinstantscan" running so that's good news. Retrospect did a full scan of almost 2,200,000 files, over 300 GB, in 20 minutes. No indication that it was using any index from instant scan, but I don't think you can expect that so early after installing it. Will have to see over the next few days if it starts using an index. The preference pane for the Retrospect client does say that Instant Scan is enabled. (But so it did for the 15.6 as well, even when it wasn't.)

After 23 minutes, it started copying files. The total running time, including copying of almost 8 GB of files, was an hour and 17 minutes, as compared to over three hours in my September post (see above). The scanning phase went down from about 2.5 hours to 20 minutes. Yay!

The client clearly uses less CPU now. It also backs off if something else uses significant CPU, so the machine is running much cooler, without the usual jet engine sounds. Nice.

I'll be back in a couple of days to see if Retrospect actually catches up to the performance of competing-product-that-shall-not-be-named-here. It still has a way to go, but it's entirely possible that a few days of indexing can fix that. 

/Martin

+  Normal backup using After8 at 2019-03-06, 11:52:18  (Activity Thread 2)
    2019-03-06 11:52:19 : Finished scanning backup set data files
    To Backup Set After8 Martin...
    -  2019-03-06 11:52:18 : Copying Macintosh HD on after8 (2)
    2019-03-06 12:10:57 : Found: 2414406 files, 532724 folders, 337,8 GB
    2019-03-06 12:11:14 : Finished matching
    2019-03-06 12:12:16 : Selector "Martin's machines" was used to select 2 344 893 files out of 2 414 406.
    2019-03-06 12:15:24 : Copying: 4216 files (7,9 GB) and 2 hard links
    2019-03-06 12:32:42 : Building Snapshot...
    2019-03-06 12:32:44 : Checking 532 724 folders for ACLs or extended attributes
    2019-03-06 13:04:33 : Finished copying 359 066 folders with ACLs or extended attributes
    2019-03-06 13:04:38 : Copying Snapshot: 2 files (255,4 MB)
    2019-03-06 13:04:47 : Snapshot stored, 255,4 MB
    2019-03-06 13:04:47 : Comparing Macintosh HD on after8 (2)
    *File "Macintosh HD/Applications/Junos Pulse.app/Contents/Plugins/JUNS/accessRecovery.ini": didn't compare
    *File "Macintosh HD/usr/local/var/postgres/server.log": different data size (set: 121 455 000, vol: 121 471 000)
    2019-03-06 13:09:21 : Execution completed successfully
    Completed: 4 217 files, 7,9 GB, with 25% compression
    Performance: 762,5 MB/minute (483,3 copy, 1 811,4 compare)
    Duration: 01:17:03 (00:55:45 idle/loading/preparing)

[insont]

Just ran a backup on a 2014 iMac with wired Gb network (the Macbook Air is on wifi), and things are decidedly looking more useable than before Retrospect 16. The scanning took just 2 minutes 11 minutes or so and the entire process 20 minutes. Retrospect is back in the race now. I still can't make out if it's using instant scan or not, but with this speed it must be.

/Martin

    +  Normal backup using Razr at 2019-03-06, 18:19:20 (Activity Thread 1)
    2019-03-06 18:19:20: Finished scanning backup set data files
    To Backup Set Razr...
    -  2019-03-06 18:19:20: Copying Macintosh HD on razr
    2019-03-06 18:30:18: Found: 3796060 files, 863974 folders, 596.4 GB
    2019-03-06 18:30:50: Finished matching
    2019-03-06 18:32:18: Selector "Martin's machines" was used to select 3 681 740 files out of 3 796 060.
    2019-03-06 18:32:30: Copying: 2330 files (3.9 GB) and 0 hard links
    2019-03-06 18:35:25: Building Snapshot...
    2019-03-06 18:35:25: Checking 863 974 folders for ACLs or extended attributes
    2019-03-06 18:36:42: Finished copying 83 900 folders with ACLs or extended attributes
    2019-03-06 18:36:55: Copying Snapshot: 2 files (1.2 GB)
    2019-03-06 18:37:28: Snapshot stored, 1.2 GB
    2019-03-06 18:37:28: Comparing Macintosh HD on razr
    *File "Macintosh HD/Users/mw/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm": didn't compare
    *File "Macintosh HD/Users/mw/Pictures/Photos Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-wal": different data size (set: 32 992, vol: 45 352)
    *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.2019-03-05T19-37-16Z-00000": different data size (set: 360 448, vol: 368 640)
    *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.interim": different data size (set: 3 457, vol: 2 913)
    2019-03-06 18:39:34: Execution completed successfully
    Completed: 2 330 files, 3.9 GB
    Performance: 1 595 MB/minute (1 332.2 copy, 2 003.9 compare)
    Duration: 00:20:13 (00:15:14 idle/loading/preparing)

Edited March 6, 2019 by insont
Changed the estimate of scanning time. Bad arithmetic.

[CherylB]

That is good news. We are in the process of upgrading to v.16. 

[DavidHertzberg]

insont/martin,

My guess is still what I said in this up-thread post, including the P.S..  From what I remember when I was using Retrospect Mac 14.6, the log used to say "Using Instant Scan" on the second or third line for each drive backed up—except for the 3 drives on my Digital Audio G4 which boots under OS X 10.3.9 (the Legacy Client doesn't do Instant Scan because FSEvents hadn't yet been implemented in OS X).  When I upgraded to Retrospect Mac 15.6.1.105 in January 2019, the log stopped showing that line.  Maybe the Retrospect Inc. engineers accidentally disabled the code that generates that log line, or maybe they intentionally disabled it so administrators backing up drives formatted with APFS wouldn't feel so disadvantaged.

Because this Knowledge Base article says [the bolding is Retrospect Inc.'s] "Mac Customers: Please note that Instant Scan is not supported with APFS", and that article hasn't been updated since 15 May 2018.  Are your Macintosh HD drives on both "after8" and "razr" both formatted with APFS?  If they are, I see two possible explanations for the good news about the scan phase running so much faster: [1] The Retrospect Inc. engineers—likely with some help from Apple—got Instant Scan to work in Retrospect 16 for APFS-formatted drives, but the engineers have thus far not gotten around to updating the KB article.  [2]  What I quoted in my up-thread post has come to pass, and the ordinary scan phase as implemented with 64-bit APIs has turned out to be so much faster that the engineers have simply abolished Instant Scan for Macs—while keeping the "Retrospectinstantscan" process for sentimental reasons .  Maybe Instant Scan on Mac  HFS+ drives had to continually update its own indexes using FSEvents to access the filesystem logs, which would explain why your "Retrospectinstantscan" process is no longer using as much of the CPU; that would argue for explanation [1].  I still prefer explanation [2], including keeping "Retrospectinstantscan" for sentimental reasons.

Please let us know about the scan phase timing of your subsequent Backup runs, and the CPU use of "Retrospectinstantscan" on your APFS-drive-formatted Macs.  Meanwhile I'll try booting my "backup server" from the drive that still has Retrospect Mac 14.6 on it, so I can check my old logs for the "Using Instant Scan" line.

P.S.: The reason I still favor explanation [2] in the second paragraph is that, since I upgraded to Retrospect Mac 15.6.1.105 in January 2019, my scan times have gone up from less than 5 minutes to nearly 10 minutes.  I know this because I have for over two years been scheduling a "sacrificial" Backup script to run 5 minutes before each "real" Backup script, as a workaround for -530 Bug 1 occurrences for my MacBook Pro "client".  Because the "sacrificial" scripts use the No Files Rule, they are basically just doing a scan and then building a Snapshot.  The "sacrificial" scripts used to take around 5 minutes to run; they now take around 10 minutes.  IMHO the time increase means that Instant Scan is no longer being used, even though it is specified for the MBP "client" and the MBP's boot drive—the only one backed up—is still formatted with HFS+ and booting macOS 10.13 High Sierra.

 

 

[insont]

More news after some more testing and waiting for instant scan to catch up.

The CPU usage of RetrospectInstantScan seems to be in the low single digits percentage every time I look at them. That's amazing. It used to be above a 100% of a core when it didn't actually work. I have a backup running right now on this machine (iMac 2014 i7) and while copying files, RetrospectClient uses less than 10% CPU in Activity monitor (up to 30% in iStat Menus, though). I've seen it peak to around 60-70% before, but maybe that was before the index was properly built (even though I suspect the index has nothing to do with speed during upload, but who knows). If, in fact, there is an index (see below).

The scanning period has not gotten faster than in the tests I did earlier, so I'm unsure if there's actually an index from instant scan. I suspect there isn't one. When looking in /Library/Application Support/Retrospect/RtrISAExec.dir, there's nothing there and I think that's where the index data is supposed to be. There is, however, a retroISA_log.utx file modified at the latest two days ago, with a size of 9.6 MB. Inside, the last entries are from March 5, so I think it stopped updating when I installed the 16.0 client. This leads me to think instant scan is no more, but that full scan has been made so much more effective that it doesn't matter much. Or, maybe the instant scan is saving data elsewhere. Why there's still an instant scan daemon mystifies me, though. Unless it's the old daemon they forgot to stop and delete.

Another great bonus: there's a new feature in "sources", namely "automatic update" of the client, which seems to work, at least it updated one of the machines for me. That will be a huge relief, since it means we won't have to run around updating machines, or fiddle with the remote update thing, which I always found obnoxious. It seems to just do it on its own.

Latest logs for the two machines, "after8" is a 2013 Macbook Air over wifi (with around 150 Mb/s) and "razr" is the 2014 i7 iMac on wired Gb. All backups to a Synology 1517+. Backup server is a 2019 Mac Mini i7.

When looking at the log for the Macbook Air, you'll see it slower than the iMac, but a bit faster than it was before. It's not as fast as I'd like it to be, but it's within the range of acceptable. Arq runs for 13-15 minutes on the same machine, but that's without validation. Arq is also set to only backup the home folder, while Retrospect is set to backup the entire disk (with some exceptions).

Now, interestingly, on the iMac, Arq is really slow at times, taking more than two hours to do a backup of the home folder in some cases and 20 minutes in other cases. I really don't know why. So right now, Retrospect rules on the fast machine, while Arq rules on the slower laptop.

In conclusion: I think, for the first time, I can set MacOS machines to hourly proactive backups without completely hogging the machines (maybe 2 hour intervals would be more reasonable). The performance now is on par with Arq, and probably close to what can be done on the platform. Arq is still somewhat quicker, but that is maybe at least in part because it defers validation to a separate and more infrequent session, while Retrospect does it every time (if set to verify). But Arq also has slowdowns that I don't know the reason for.

Remains the question why "Instant Scan" is still a setting in the client. Weird.

Another side note: it looks as if backups have started working for sleeping machines, albeit very slowly. But I haven't looked into that systematically.

+  Normal backup using Razr at 2019-03-09, 12:52:07 (Activity Thread 1)
    2019-03-09 12:52:08: Finished scanning backup set data files
    To Backup Set Razr...
    -  2019-03-09 12:52:07: Copying Macintosh HD on razr
    2019-03-09 13:04:02: Found: 3797143 files, 864033 folders, 596.3 GB
    2019-03-09 13:04:52: Finished matching
    2019-03-09 13:08:23: Selector "Martin's machines" was used to select 3 681 955 files out of 3 797 143.
    2019-03-09 13:08:46: Copying: 2406 files (2.5 GB) and 0 hard links
    2019-03-09 13:11:20: Building Snapshot...
    2019-03-09 13:11:20: Checking 864 033 folders for ACLs or extended attributes
    2019-03-09 13:14:22: Finished copying 84 113 folders with ACLs or extended attributes
    2019-03-09 13:14:35: Copying Snapshot: 2 files (1.2 GB)
    2019-03-09 13:15:14: Snapshot stored, 1.2 GB
    2019-03-09 13:15:14: Comparing Macintosh HD on razr
    *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.2019-03-05T19-37-16Z-00000": different data size (set: 991 232, vol: 995 328)
    *File "Macintosh HD/usr/local/var/mongodb/diagnostic.data/metrics.interim": different data size (set: 2 948, vol: 3 345)
    2019-03-09 13:17:14: Execution completed successfully
    Completed: 2 406 files, 2.5 GB
    Performance: 1 108.6 MB/minute (943.9 copy, 1 354.4 compare)
    Duration: 00:25:06 (00:20:24 idle/loading/preparing)

+  Normal backup using After8 at 2019-03-09, 14:04:31 (Activity Thread 1)
    2019-03-09 14:04:31: Finished scanning backup set data files
    To Backup Set After8 Martin...
    -  2019-03-09 14:04:31: Copying Macintosh HD on after8 (2)
    2019-03-09 14:20:40: Found: 2412938 files, 532691 folders, 340.7 GB
    2019-03-09 14:20:59: Finished matching
    2019-03-09 14:22:12: Selector "Martin's machines" was used to select 2 344 605 files out of 2 412 938.
    2019-03-09 14:25:48: Copying: 322 files (715.7 MB) and 0 hard links
    2019-03-09 14:27:49: Building Snapshot...
    2019-03-09 14:27:49: Checking 532 691 folders for ACLs or extended attributes
    2019-03-09 15:01:46: Finished copying 358 898 folders with ACLs or extended attributes
    2019-03-09 15:01:54: Copying Snapshot: 2 files (255.3 MB)
    2019-03-09 15:02:04: Snapshot stored, 255.3 MB
    2019-03-09 15:02:04: Comparing Macintosh HD on after8 (2)
    *File "Macintosh HD/Applications/Junos Pulse.app/Contents/Plugins/JUNS/accessRecovery.ini": didn't compare
    *File "Macintosh HD/usr/local/var/postgres/server.log": different data size (set: 123 352 400, vol: 123 367 500)
    2019-03-09 15:02:34: Execution completed successfully
    Completed: 320 files, 712.1 MB, with 52% compression
    Performance: 662.4 MB/minute (431.5 copy, 1 473.2 compare)
    Duration: 00:58:03 (00:55:54 idle/loading/preparing)

[DavidHertzberg]

insont/Martin,

Thank you for taking the time to investigate and write your immediately-above post, which is very informative.

I will assume for the purposes of this post that both your "aftr8" and "razr" client Macs have their disks formatted with APFS.

It seems that you are now leaning toward my explanation [2] in the second paragraph of this up-thread post.  I propose to sub-divide that into two further possible explanations: [2a] Instant Scan can still be effective in version 16.0 for Mac disks formatted with HFS+, so the Retrospect Inc. engineers had to leave the "Instant Scan" option and the daemon in the Client—especially since a particular Mac "client" machine could have one disk formatted with HFS+ and another disk formatted with APFS.  [2b] Instant Scan has been determined to no longer be useful for any Mac "client" disks, so it has been disabled in the Client code—but the engineers didn't have time to eliminate the daemon and/or the option.

If you look at the succession of public announcements since the release of Retrospect 15.0 and "read between the lines", it seems that getting out version 16.0—with whatever deficiencies it still has—required a tremendous effort on the part of all employees of Retrospect Inc..  I suspect that a lot of those employees are catching up on their sleep this weekend; I hope the engineers are not waking up screaming.   Niceties such as eliminating un-needed options and/or daemons will have to wait for a later "point release", especially since explanation [2a] would require that the daemon would have to be launched whenever the Mac Client finds itself backing up a disk formatted with HFS+.

[insont]

Yes, APFS on both (it's well-neigh impossible to not have APFS on 10.14).

About Instant Scan in settings: I don't agree. It's easy as can be to not show that label and button if it's not relevant. So your theory of how they'd be so exhausted after all these months not to be able to add like ten lines of code (at most, probably more like three) for that seems a bit fanciful. I can't believe it's not on purpose. Your whole idea that it took almost a year because it was so difficult is based on absolutely nothing. They might as well have been doing something else entirely. We don't know their priorities.

OTOH, they had the same problem, i.e. a pointless label and button, in 15.6 when instant scan didn't do anything. Except then it actually consumed a lot of CPU doing nothing. So something's not right.

No matter why, it seems to work now. And even though I think it took them way too long, I'm willing to forgive and forget since the result seems pretty good. So let's cut the whole discussion of why they did what they did, since we can't know. Unless you have some real insider information outside of guesswork.

[DavidHertzberg]

On 3/9/2019 at 4:48 PM, insont said:

....

About Instant Scan in settings: I don't agree. It's easy as can be to not show that label and button if it's not relevant. So your theory of how they'd be so exhausted after all these months not to be able to add like ten lines of code (at most, probably more like three) for that seems a bit fanciful. I can't believe it's not on purpose. Your whole idea that it took almost a year because it was so difficult is based on absolutely nothing. They might as well have been doing something else entirely. We don't know their priorities.

....

No matter why, it seems to work now. And even though I think it took them way too long, I'm willing to forgive and forget since the result seems pretty good. So let's cut the whole discussion of why they did what they did, since we can't know. Unless you have some real insider information outside of guesswork.

insont/Martin,

Those of us with long memories do know what Retrospect Inc.'s priorities were for Retrospect 16.0 as of March 2018.  I could make you work by telling you to read the blue-tagged "New" items for the various Retrospect 15 releases in the cumulative Release Notes, but I'll try to make it easy for you—even though Product Management has done a pretty good job of hiding the 2018 historical record.

The Retrospect Inc. developers announced that they intended to release these new features—some in beta form—in May 2018 for Retrospect 15.1.  However their priorities were changed by the urgent need to provide "Data Retention Policies: file selector support for grooming for GDPR compliance", so those non-e-mail new features were not released until early September 2018 for Retrospect 15.5—as you can see.

The apparent rush in which the engineers did that seems to have led to their inadvertently disabling several Retrospect capabilities that had previously worked.  That led to two more bug-fix releases, and it wasn't until 29 November 2018  in the 15.6.1 release that the engineers fixed "Backup: Fixed issue where scripts hung due to Management Console integration (#7753)"—a havoc-causing  bug that appears to have originated in the 15.6.0 release on 16 October 2018.

Now we reach the 16.0 release on 5 March 2019.  Look at the "Feature Set" section of this Knowledge Base article, and tell me with a straight face that the Shared Scripts feature isn't still in beta.  As the last sentence of the next-to-last paragraph of the "History" section of the Wikipedia article—as well as several threads in the Windows Forums on this website—will tell you, a fully-functioning two-way Management Console is a feature that Retrospect Windows administrators have been pleading for for many years—a plea to which Retrospect Inc. planned to respond.  Nevertheless the Management Console Add-On (referred to in the right-most listed item) which is a requirement for Shared Scripts, hasn't as of tonight made it into the Product Configurator so that administrators can purchase it online (here's my one piece of "inside information": the head of North American Retrospect Sales told me on the phone the day before yesterday that someone is working to add that Add-On to the Configurator).

BTW, insont, have you noticed that my predictions up-thread, made without any "inside information", turned out to be pretty accurate?

P.S.: You failed to consider the possibility of explanation [2a] per this up-thread post.  You may not have them, but other users have external drives cabled to Macs of your vintages.  macOS 10.14 Mojave does not force conversion of an HFS+ drive to APFS unless that drive is an SSD.  Also, you had not previously said that your "razr" iMac had been upgraded to Mojave.  Lastly, you failed to consider the difficulty (which I think the Retrospect Inc. engineers also failed to consider) of the API conversion documented in this KB article—a conversion that was partly forced on them by Apple's development of APFS.

P.P.S.: Retrospect Inc. Product Management's "hiding the 2018 historical record", mentioned in my first paragraph, was done by overwriting Web pages written in 2018 with 2019 announcements.

Edited September 19, 2019 by DavidHertzberg
In my second prgf., added historical links, noted only non-e-mail features were postponed until September 2018; P.S. insont didn't consider possibility that Instant Scan still works for HFS+ drives or difficulty of API conversion; P.P.S. "hiding the 2018"

[DavidHertzberg]

For reasons, described in this Ars Technica Mac Forum thread, last week I was forced to convert my MacBook Pro's  SSD to APFS.  I therefore, for reasons stated above in this thread, had to upgrade to Retrospect Mac 16.0.1.105.

Obviously I Removed and re-Added my MBP with Use Instant Scan un-checked.  I now find my SSD scans taking 4 minutes, whereas using Retrospect Mac 15.6.1.105—with the SSD formatted with HFS+ and using Instant Scan—they took 7 minutes.  I also find the total time for an incremental backup of 5GB, including scan, is 14 minutes; using Retrospect Mac 15.6.1.105—with the SSD formatted with HFS+ and using Instant Scan—it took 17 minutes.

 

Edited April 9, 2019 by DavidHertzberg
Yesterday's incremental backup was a bit over 5GB, as was the one the week before last, so revised the comparative times; used Instant Scan with HFS+