No more instant scan on MacOS?

[insont]

I'm backing up a couple of Macs and Retrospect seems to place an inordinate load on them. My Macbook Pro 17", for instance, is hyperventilating several hours per day even though I hardly use it. I had Crashplan until they cancelled the service, and even though they backed up every 15 minutes, it was totally inconspicious and effective. Retrospect is a steamroller compared to that. Admittedly, Retrospect backs up more files, but still.

Every now and then backups went smoother, and that was when Instant Scan did its work (as verified in the logs), but most of the time Instant Scan simply bogs down the machines but doesn't actually work.

I had a week-long exchange with Retrospect support about this, trying to figure out why Instant Scan is totally ineffective, but once they escalated, I was told Instant Scan is no more. Not that it's having problems, no, that it has been abandoned. Does that mean my Mac backups will continue to be so grossly overloading the machines? I'll quote verbatim the last message I did get from Retrospect below. To me it sounds like Retrospect on MacOS will forever remain a dog.

(I should mention that Instant Scan already didn't work before I upgraded to 10.13 and APFS. I also assume Retrospect support meant to say "APFS" and not "AFP", which makes no sense in relation to 10.13. And makes no sense in any case on the local machine where Instant Scan works. Or maybe they actually did mean AFP and then I understand even less.)

"Dear Martin, 
Retrospect Engineering Reply can be found below. 
Instant scan doesn't work on AFP, and most likely customer is using AFP if they are on OSX 10.13.
We recommend disabling instant scan in ALL cases, we are disabling instant scan by default in future versions of Retrospect.
Thank you for using Retrospect,
The Retrospect Support Team "

[DavidHertzberg]

insont,

The only 2018 information I could find about this is this thread on the Apple Developer Forums.

Forgive me for asking this, but I notice your profile contains no information about you,  that you joined the Forums on 30 June, and that your profile says "The recent visitors block is disabled and is not being shown to other users."  Is what you are saying you heard from Retrospect Engineering true, or is it "fake news".

[insont]

David,

I copied verbatim what Retrospect support sent me. How can I prove that to you?

And yes, I created this login specifically to post about this, since the reply from Retrospect upset me. I didn't expect, however, to be accused of lying in the process. About "recent visitors block is disabled" I know nothing. I haven't touched my profile from the default. I'm sorry if I broke some kind of rule by not doing that.

BTW, since you doubt my veracity, I'd suggest you ask Retrospect support if this is true. Either they confirm what I just said, making me somewhat happy, or they backtrack and say they are going to support Instant Scan in the future or that I misunderstood, and I'm even happier. To me their reply seems not quite thought through and not good for the product, so you asking could make them think again.

Oh, and the case is nb 00061949 that contains this exchange, including the message I quoted. You're welcome to reference that.

Martin

Edited July 14, 2018 by insont
wrote "forum" instead of "support"

[DavidHertzberg]

6 hours ago, insont said:

David,

....

....

BTW, since you doubt my veracity, I'd suggest you ask Retrospect support if this is true. Either they confirm what I just said, making me somewhat happy, or they backtrack and say they are going to support Instant Scan in the future or that I misunderstood, and I'm even happier. To me their reply seems not quite thought through and not good for the product, so you asking could make them think again.

Oh, and the case is nb 00061949 that contains this exchange, including the message I quoted. You're welcome to reference that.

Martin

insont/martin,

I doubt your veracity because:  [1] No other threads, other than the ones you have posted in, have reported a problem with APFS and Instant Scan for Retrospect Mac except for this one back in October 2017.  [2] Retrospect Engineering has lately given fair warning about planned feature changes that would affect some administrators adversely; they put yellow-flagged Notes about two such changes (once of which has already been expanded into a Knowledge Base article) in the cumulative Release Notes for Retrospect Mac 15.1 (and one of those was already in there for Retrospect Mac 15.0)—so I find it a bit difficult to believe that Retrospect Engineering (which IME communicates with customers only through a Support Engineer) would announce such an adverse change directly to you.

[2] is not impossible to believe; the next-to-last substantive paragraph in this post suggests that IMHO the "real" engineers are being given unprecedented freedom in documentation.  Also, the Apple Developer Forums thread linked to in my preceding  post indicates there is a problem with the APFS change in "normalization" of file names.  Finally, this would be such a massively adverse change that Retrospect Product Management may have "chickened out" on announcing it, which would explain why you "had a week-long exchange with Retrospect support" and why this Knowledge Base article has not  been updated.

As a mere customer, I am not allowed to view Support Cases other than my own.  However I will file a Support Case, referencing this thread and Support Case 61949—which Retrospect Support has the capability of viewing.

 

[insont]

David,

Retrospect Engineering didn't reply directly to me; it was forwarded by the support engineer. I thought that was obvious from the quote where they mention me in third person. I just picked up the whole support thread from Retrospect Support and copy/paste it below. It's completely unedited, I left all references in. Start reading from the bottom.

BTW, I have the problem on several machines, but I concentrated on one for the support case.

 

Quote

June 28, 2018 09:24

Dear Martin, 

Retrospect Engineering Reply can be found below. 

Instant scan doesn't work on AFP, and most likely customer is using AFP if they are on OSX 10.13.

We recommend disabling instant scan in ALL cases, we are disabling instant scan by default in future versions of Retrospect.


Thank you for using Retrospect,
The Retrospect Support Team 

---------------------------

Click the link below to update your support case. Note, the case is automatically closed if no response is received within 5 days). 

* Case # 00061949 - http://retrospect.com/support/case/5000P00000iaXqm
ref:_00DU0Kyj8._5000PiaXqm:ref

June 25, 2018 19:41

Attached 608 KB file: RetroISA.zip

June 25, 2018 19:41

Including the requested files.

June 25, 2018 07:26

Dear Martin, 

Retrospect Agent Reply can be found below. 


Agent Response: 

Please send us your  retroISA_log.utx

This files can be found in: Library/Application Support/Retrospect/ and provide the Mac System Report – https://support.apple.com/en-us/HT203001

Thank you for using Retrospect,
The Retrospect Support Team 

---------------------------

Click the link below to update your support case. Note, the case is automatically closed if no response is received within 5 days). 

* Case # 00061949 - http://retrospect.com/support/case/5000P00000iaXqm
ref:_00DU0Kyj8._5000PiaXqm:ref

June 22, 2018 15:58

Hi,

I did as you suggested, removed the ISA Scan files, updated server and client and restarted Instant Scan. I verified it runs by using launchctl load. Now nothing happens. I waited a couple of days but the database isn't recreated. Yesterday I removed even the folder RetroISAScans, but even the folder does not recreate. The Instant Scan process consumes very little CPU. I'm used to it consuming more than one core, but now it's down under 1%. It looks as if it is doing hardly anything.
Backups work, but scan the whole file system, taking forever (three hours or more). I would have thought the Instant scan database would recreate in a day or two, but it doesn't look like it.

Any more tips?

Regards,

Martin

June 19, 2018 08:32

Dear Martin, 

Retrospect Agent Reply can be found below. 


Agent Response: 

stops Instant Scan, it might be an issue with Instant Scan’s internal data files.

Locate Instant Scan’s folder in /Library/Application Support/Retrospect/RetroISAScans and remove the files starting with RetroISAScan.
 
Start Instant Scan and wait for the first initial scan to finish.

Update Retrospect Server to 15.1.2.101 https://s3.amazonaws.com/download.retrospect.com/software/mac/v1512/Retrospect_15_1_2_101.dmg and all your clients to 15.1.0.x

Thank you for using Retrospect,
The Retrospect Support Team 

---------------------------

Click the link below to update your support case. Note, the case is automatically closed if no response is received within 5 days). 

* Case # 00061949 - http://retrospect.com/support/case/5000P00000iaXqm
ref:_00DU0Kyj8._5000PiaXqm:ref

June 18, 2018 16:11

Attached 1.03 MB file: Archive.zip

June 18, 2018 16:11

Hi,

I'm uploading the files. The launchctl command told me the daemon was already running.

June 18, 2018 09:51

Dear Martin, 

Thank you for contacting Retrospect support.  Retrospect Agent Reply can be found below.

We understand you have the following question:

Instant Scan seems not work on one client

Agent Response: 

Please send me your Operations_log.utx file  located in  Library/Application Support/Retrospect/

On the Client computer send me the files retroclient.log and retropds.log

and Library/Application Support/Retrospect/retroisa.utx

Also on the client check Instant Scan is well started: sudo launchctl load /Library/LaunchDaemons/com.retrospect.retroisa.plist

Thank you for using Retrospect.

The Retrospect Support Team 

Additional Resources: 
Have you tried our online self-service tools? 
* Knowledgebase - http://retrospect.com/kb
* Forum - http://forums.retrospect.com
* Training Videos - http://www.youtube.com/user/RetrospectInc/featured?hl=en


-----------------------------------------
Click the link below to update your support case. (Note, the case is automatically closed if no response is received within 5 days). 

* Case # 00061949 - http://retrospect.com/support/case/5000P00000iaXqm 

------------------------------------------

Your Problem Description.: 
Instand scan doesn't seem to work. On one machine, a MacBook Pro 17", the entire proactive backup takes hours, I've had days it's been six or nine hours, to complete, even though this machine sees very light use, mostly emailing. As far as I can see, Retrospect always scans the entire drive, never using Instant Scan results. Instant Scan is on in preferences.
I've had this problem even before v15, but had hoped v15 would have cleared it up, but it didn't. Client is also updated.
I have no idea where to start troubleshooting this.
ref:_00DU0Kyj8._5000PiaXqm:ref

June 17, 2018 09:57

Instand scan doesn't seem to work. On one machine, a MacBook Pro 17", the entire proactive backup takes hours, I've had days it's been six or nine hours, to complete, even though this machine sees very light use, mostly emailing. As far as I can see, Retrospect always scans the entire drive, never using Instant Scan results. Instant Scan is on in preferences.
I've had this problem even before v15, but had hoped v15 would have cleared it up, but it didn't. Client is also updated.
I have no idea where to start troubleshooting this.

 

[DavidHertzberg]

The OP in the 21 May Apple Developer Forums thread I linked to in this previous post used the "handle" "suyashdruva", so I just did a little Googling for "suyash druva".  It appears that his name is Suyash Singh, and he works for a company named Druva.  And a look at an overview video on Druva.com confirms they have product(s) that do AWS cloud backups including for  "endpoints".  Reading some of the references in this section of the Wikipedia "Backup" article has made me aware that "endpoint" is industry slang for end user devices such as PCs, laptops and mobile phones.  And that would include Macs, so the APFS problem insont/martin reports sounds as if it's Mac-backup-industry-wide and not just limited to Retrospect.

So "Walnut Creek, we have a problem"; sorry for my initial skepticism, Martin.

BTW, even the newest of my 3 Macs is on macOS 10.12.6, and they use good old HFS+.  So I'll let Instant Scan continue to shorten my daily incremental backups of one Mac by 8-10 minutes.

[insont]

David,

Nice detective work. Yes, what you found seems very likely to be the explanation. As long as that API problem persists, Retrospect can't do all that much about it. (Except if it's only a problem of identifying file deletions I would expect it not to be that disastrous. If the agent tries to back up a deleted file that is still in the scan index, it could just skip it. At least that's what I would assume. The inserts and updates seem to work right, so... but there could be more to it than that, of course.)

Let's hope Apple gets its act together, though, and get this fixed.

[DavidHertzberg]

suyashdruva says in the last 21 May 2018 post in that Apple Developer Forums thread "I observe case and normalization are preserved for operation other than delete. So why behavior is different for file/folder delete event? It seems while accumulating events, paths are getting normalized except this case."

CrashPlan had (and evidently still has) a File System Scan that was scheduled to run by default at 3 a.m., because it "Requires more resources".  CrashPlan used to use Spotlight instead of FSEvents—which Retrospect uses, so that section of the page used to say "Spotlight does not report deleted files in real-time, so CrashPlan only detects deleted files during the scheduled scan".  Maybe Retrospect will have to adopt the same approach.

P.S.: insont got in his immediately-preceding post while I was researching the second paragraph for this one.  I think what I've just said still is applicable.

P.P.S.: For the masochists and/or frustrated systems programmers among you, here's an applicable blog post—with comments—on APFS filename normalization.

[insont]

The latest Retrospect doesn't seem to implement Instant Scan either. I can't even enable it anymore. I have to leave laptops on for hours just to get anything backed up at all. See this log from today, from a Macbook Air where the scanning and snapshot took three hours, then the actual copy around two minutes. Tomorrow, it's going to scan for three hours again... unless I forget and close it, which will make the whole thing repeat. It's not reasonable to consume three hours just for file scanning for every backup on a relatively small computer. (And to think Crashplan used to run backups every 15 minutes, each one taking seconds. Without significantly loading the CPU.)

 

 +  Normal backup using After8 at 2018-09-20, 17:36:11  (Activity Thread 2)
    2018-09-20 17:36:12 : Finished scanning backup set data files
    To Backup Set After8 Martin...
    -  2018-09-20 17:36:11 : Copying Macintosh HD on after8 (2)
    2018-09-20 19:59:26 : Found: 2268745 files, 497287 folders, 316,4 GB
    2018-09-20 20:00:04 : Finished matching
    2018-09-20 20:01:50 : Selector "Martin's machines" was used to select 2 225 329 files out of 2 268 745.
    2018-09-20 20:07:04 : Copying: 935 files (709,7 MB) and 0 hard links
    2018-09-20 20:09:20 : Building Snapshot...
    2018-09-20 20:09:21 : Checking 497 287 folders for ACLs or extended attributes
    2018-09-20 20:40:57 : Finished copying 336 384 folders with ACLs or extended attributes
    2018-09-20 20:41:11 : Copying Snapshot: 2 files (239,6 MB)
    2018-09-20 20:41:26 : Snapshot stored, 239,6 MB
    2018-09-20 20:41:26 : Comparing Macintosh HD on after8 (2)
...
    2018-09-20 20:42:07 : Execution completed successfully
    Completed: 935 files, 705,2 MB, with 52% compression
    Performance: 549,5 MB/minute (371,1 copy, 1 057,8 compare)
    Duration: 03:05:55 (03:03:21 idle/loading/preparing)

 

/Martin

[insont]

Well, I did write support to ask if they had plans to fix Instant Scan in the future or if they'd given up on MacOS, and got some encouraging news:

Quote

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 by following the instructions in this article: https://www.retrospect.com/en/support/kb/macos_api_request_impossible This is only for LOCAL BACKUPS for the time being. Client API changes are being worked on and preliminary testing shows them being upwards of 10 times faster than they are currently. Thank you for using Retrospect.

/Martin

[DavidHertzberg]

On 10/6/2018 at 6:03 AM, insont said:

Well, I did write support to ask if they had plans to fix Instant Scan in the future or if they'd given up on MacOS, and got some encouraging news:

/Martin

insont,

That's good, because I just found a 15 May 2018 Knowledge Base article change confirming what you've been saying.  The  paragraph

"Mac Customers: Please note that Instant Scan is not supported with APFS."

has been added below the first paragraph in the KB article "Instant Scan Frequently Asked Questions". which is under the catch-all heading "Resources" in the KB .  That first paragraph  begins with the sentence "Retrospect 10 for Macintosh and Retrospect 8 for Windows introduced a new feature called Instant Scan."  This section of the permalinked old version of the Wikipedia article says those versions were introduced in 2012, so the original KB article almost certainly dates from sometime shortly after that year up through April 2015—when the companion article "Instant Scan Advanced Options" was published.

Sorry to have previously expressed doubt, Martin.  Pretty sneaky announcement there, Retrospect Inc. ; you didn't even point Martin to it in your final reply to his Support Case.

[henry-in-florida]

I got that feedback from support recently as well and reported it in another post here.

Frankly, when using SSD's in clients, I don't see a huge advantage to ISA. Whether in incremental or full backup. It is a CPU hog and space hog. Maybe also duplicates processes already in place (in the case of APFS). I will compare again in 15.6 with ISA disabled to confirm this. Once turned off, intend to leave it that way. Locally, on HFS+ formatted (HDD) drives, maybe some advantage, but since the server does its thing quicker locally and is essentially unattended, I don't care too much. 

My 2¢...

 

Henry

[insont]

Henry,

Well, I'm certainly seeing a difference. Going from 2 minutes on a Windows machine to 2 hours or more on a Mac with a built-in SSD, with comparable backup sizes. That's two hours spent in "preparing for backup". So let's hope that is due to (the lack of) Instant Scan, else it's beyond useless, if it never gets fixed.

Possibly this only happens to some people, of course, but it's happening on all my Macs on APFS (four of them), and not on virtual and real Windows machines (three of them). Am I really the only one seeing this?

/Martin

[DavidHertzberg]

insont,

I agree with your general conclusion. This post in another thread, especially the P.S., discusses what the probable effect of eliminating Instant Scan would be.

[cgtyoder]

On 10/16/2018 at 11:59 AM, insont said:

Henry,

Well, I'm certainly seeing a difference. Going from 2 minutes on a Windows machine to 2 hours or more on a Mac with a built-in SSD, with comparable backup sizes. That's two hours spent in "preparing for backup". So let's hope that is due to (the lack of) Instant Scan, else it's beyond useless, if it never gets fixed.

Possibly this only happens to some people, of course, but it's happening on all my Macs on APFS (four of them), and not on virtual and real Windows machines (three of them). Am I really the only one seeing this? 

/Martin

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

[DavidHertzberg]

1.5 weeks ago I switched to running Retrospect Mac 15.6.1.105 in production on my Mac Pro "backup server".  My Saturday Recycle backups of 6 drives plus a Favorite Folder are running about 0.5 hours faster then they used to. That is probably because Retrospect 15.6.1.105 is running on an SSD, whereas Retrospect Mac 14.6.0 was running on an HDD (my Mac Pro has 2 HDDs, including the one belonging to my late friend, and 1 SSD).

Instant Scan is still working for the SSD in my MacBook Pro "client" and the 2-drives-plus-a-Favorite-Folder in my Mac Pro.  However both my MacBook Pro and my Mac Pro are still booting under MacOS 10.12, and all my drives use HFS+ instead of APFS.  In addition my MacBook Pro is still using the Retrospect Mac 14.1 Client, because I have long suspected that a later version of the Client was contributing to my temporarily-vanished -530 errors.  The half-hour speedup in my Saturday backup script may simply be due to the fact that the current Mac Pro boot drive, that I am backing up in its entirety, is an SSD rather than a HDD (I've kept my Catalog Files on the former HDD boot drive, so I'm backing them up as a Favorite Folder).

[insont]

Backing up my MacOS machines is still taking 3-5 hours every time, always with a heavy CPU load. And any interruption makes it start all over again, so in practice I have to leave the machines on all day just for Retrospect. I've reduced the backups to one day a week simply because I can't stand feeling (and hearing) all that hot air.

Meanwhile I tried ArqBackup and it has none of these problems on the same machines. It blows through the backups in no time. It runs every hour with no noticeable CPU load. If a one man product like Arq can do this on APFS, why can't Retrospect? The performance difference is completely surreal. Arq seems to be very similar to Crashplan in this respect. Or rather, similar to practically anything except Retrospect.

I'm starting to wonder if all that money I spent on three years of support on Retrospect wasn't wasted. It sure looks like they don't really care. No solution of any kind has appeared yet and this has been going on for quite a while now. If it wasn't for that investment, I'd have thrown out Retrospect by now.

Sorry about that. I needed to vent.

/Martin

[DavidHertzberg]

insont,

What you are saying about a competing "push" backup application is actually good news, because IMHO it means that Stefan Reitshamer has been able to speed up APFS backup.  The reason for the speed difference is that, since Reitshamer's application was developed much more recently than Retrospect, it undoubtedly uses 64-bit structures rather than the 32-bit ones that Retrospect still uses as of Mac version 15.  Retrospect is apparently going to switch to 64-bit structures as of Mac version 16, which is why the engineers created this KB article.

As I've pointed out here, especially in the P.S., the consequent tradeoff loss of Instant Scan will probably—by itself—add 10% to the duration of backing up a modern Mac.  However that 10% may well be more than overcome by the increased speed of backing up made possible by the switch to 64-bit data structures.  I'd wait until the release of 16.0, probably in March, to see what the results are.  Even better, I'd wait until the release of 16.1 later this spring—to give the engineers time to fix the inevitable early-discovery bugs.

P.S.: A reason for Retrospect Inc. to have stuck with the 32-bit structures is that it enables Retrospect Mac to do backups and restores of PowerPC Macs that can't boot from anything past OS X 10.5.  This has been a critical requirement for administrators (including me) who have old files that can only be read by programs that can't be run on an Intel Mac.  That explains why the KB article linked-to in the last sentence of the first paragraph of this post says "If you would like to protect those versions of Mac OS X with Retrospect 15, please contact our Support team for a production build that continues to include support for those."

Edited February 12, 2019 by DavidHertzberg
Added P.S. explaining why Retrospect Inc. stuck with the 32-bit structures for so long; revised that P.S.

[insont]

I did a cursory comparison between Retrospect and Arq on my iMac just now. Retrospect is set to backup the whole disk, with some exceptions, and usually is in the scanning phase ("Preparing for backup") for hours, then doing the actual backup for a couple of minutes or longer, depending. This while running a CPU at above 100% (right now, for some reason, it's down at 10% during scanning). If I sleep the machine, the scanning is restarted from the beginning when I wake it up again. So if I don't use the machine for more than an hour at a time, Retrospect in effect never gets anything done. Except heating the room, that is. 

Note that this is a 1 TB Apple SSD with APFS, 4-core i7, a GBit net with copper and fiber, and the destination is a Synology 1517+ on the local net. Both Retrospect and Arq, in this comparison, back up to the same Synology. MacOS 10.14.3. Retrospect 15.6.1. Arq 5.15.2. (I also run several laptops, which I've mentioned before, but this time I'm on this iMac.)

Arq, on the other hand, doesn't have a separate scanning phase; it scans and uploads at the same time. So it always gets something done right away. I have it set to only backup the home directory, but that is about 85% of the total size of data on the drive. While it was running, it took about 35% of a CPU, with no noticeable warming up. The whole scan and upload took 21 minutes, scanning 586 GB and uploading 890 MB. And, as I said, totally unobtrusive. By default it backs up hourly.

Now, that's what Retrospect should do, as well. The separate scanning phase seems to be the fundamentally bad idea here. And it's excruciatingly slow to boot.

Something else they should copy: Arq can use SFTP to the backup store. So even if you have a local NAS, you can backup without mapping the drive, which makes it way less likely that crypto malware destroys your backups as well. Yes, I know you can unmap network drives in Finder once you've set the credentials in Retrospect, but I've had that fail a couple of times. I don't like it. I figure it will be a lot less likely malware will see and be able to connect to an SFTP destination. Arq also has S3, so I can use both Retrospect and Arq with Wasabi.

In summary: Arq is painless where Retrospect is painful. And Arq is safer, having SFTP. (I may have missed something in Retrospect, though.) Do note, however, that I'm currently anti-Retrospect biased, so I'm probably blind to the advantages of Retrospect over Arq right now. But that's humanity for you.

/Martin

[insont]

Meanwhile, Retrospect finished on the same machine. "Preparing to backup" took 2 hours and 54 minutes, and the actual backup of 5.5 GB took another 6 minutes for a grand total of exactly three hours. Arq did the same job in 21 minutes.

The reason Retrospect found 5.5 GB to backup while Arq only backed up 890 MB is because Arq runs successfully every hour, while it can take days for my machine to be on long enough for Retrospect to get past the "Preparing to backup" to actually do a backup. 

But, as I already said, the huge difference is in the scanning, and both products scan about the same volume of data.

[DavidHertzberg]

insont,

Allright, allready, Retrospect doesn't implement Instant Scan for APFS volumes—as I pointed out in this post in the thread.  The "push" backup application you mention no longer implements Instant Scan using Mac fsevents at all, as someone who is pretty obviously Stefan Reitshamer said on Twitter in 2016 (which is before Apple introduced APFS).  I've already pointed out Retrospect Inc.'s expressed intention to speed up overall backup—probably in Retrospect 16—in this post just above your latest two posts in the thread.

IIRC the "push" backup application you mention by default doesn't back up all the files that Retrospect does.  But I'm too busy to Google for that now.

I have now confirmed that Retrospect used to be able to backup to an SFTP/FTP destination, but abandoned that in Retrospect Mac 8 in favor of a WebDAV destination and an AFP/SMB destination—announced in the UG for Retrospect Mac 10.   In a 2012 blog post Retrospect Inc.'s then-Director of Marketing said  "SFTP/FTP is just not a good protocol for backups .... doesn't support mid-point file access—so Retrospect would need to download the entire container file just to restore a single file from the backup .... As a result, Retrospect 6 needs to write much smaller container files, which generates additional overhead and complexity, and reduces performance."  Remember that Retrospect is an enterprise client-server backup application, which gives it different requirements from a "personal push" backup application.  However this Knowledge Base article says, as of 2017, that FTP/SFTP can be a R.V.  backup destination—so maybe you should switch to that product if your "backup server" runs Windows and you're willing to do without "client" backup.

P.S.: Corrected first sentence of 3rd paragraph to say that FTP destinations were dropped in Retrospect Mac 8 and AFP/SMB destinations were added in Retrospect Mac 10, with WebDAV destinations added in Retrospect Mac 9 (for which there is no UG—only an Addendum).

P.P.S.: Replaced second sentence of 3rd paragraph, because I found Kristin Goedert's 2012 Retrospect Blog post.

Edited October 15, 2020 by DavidHertzberg
3rd ¶ corrected for timeline of dropping FTP and adding AFP/SMB destinations, changed because blog post explains why SFTP/FTP dropped, changed links to to go to pre-massacre versions of Wikipedia articles

[insont]

David,

Yes, I know that Retrospect doesn't implement instant scan anymore, but they sure do scan. Not so instant, though. And yes, Arq doesn't do fsevent monitoring, but where the full scan on Retrospect is comparable to the full scan in Arq, there's a nine-fold difference in scanning speed. Nine. At least.

And yes, Retrospect has said they're going to fix it, but after seeing no sign of that for eight months now, can I not be excused for getting really irritated? Especially since Arq (and other products) show that this problem is clearly solvable? And considering that Retrospect cost me around ten times the price of Arq, the price-performance ratio between the two is 1:100. 

I promise to stop complaining once Retrospect shows any sign of at least trying to do something about this. And so far, nothing.

/Martin

PS: my name really is "Martin". "Insont" is only a handle. I thought that was obvious by now.

[DavidHertzberg]

insont,

You are evidently not a programmer, at least not one who has worked on complicated applications that keep several programmers busy.  Although I have never worked for Retrospect Inc. or its predecessor organizations, I'm reasonably sure that changing every single Mac-related API structure and call in both the Engine and Client programs is a big job.  That's why this Knowledge Base article is dated 23 May 2018.  Therefore it's not surprising that the changes will be introduced with the release of Retrospect 16, which—if past years are a guide for major releases—will be in early March 2019.

Your complaining about the amount of time the change is taking won't make it happen any faster.  I'm curious; do you practice this technique with your fellow workers and friends?  Does it produce results, or does it just give you the reputation of being a pain in the a**e?  As I've pointed out in my "boilerplate" posts on filing a Support Case, Retrospect Inc. people don't normally read these Forums.

I seriously suggest that you consider switching to the "push" backup application you have mentioned in this thread,  so you can try this method of interaction on Stefan Reitshamer.  And, since its a "personal" backup application, good luck in on getting your "backup server" device to not overload when 7 different "client" machines try to backup to one destination at the same time.

 

 

[cgtyoder]

David, your condescending comments aren't needed here. Martin (and others, myself included) are frustrated at this slowness, and a little venting is not out of order. I don't understand why you feel the need to carry water for Dantz - if you don't have anything positive to contribute, you aren't required to post.

[insont]

David,

That was truly horrible. 

/Martin