Jump to content

Backup client extremely slow after upgrade to MacOS 11.0.1


Recommended Posts

Following recent upgrade on machine that hosts Retrospect (Desktop for MacOS 17.5.1) 
server to MacOS 11.0.1 (Big Sur), backups of (MacOS 11.0.1) machines connected to this 
server by ethernet LAN, are running extremely slow - about 1/4 of normal (pre-os upgrade) 
speed. The log shows performance less than 500MB per minute versus ~ 2GB per minute prior. 
The performance degradation is obviously due to the OS upgrade and the issue might be 
corrected by next MacOS incremental release - however, asking if anyone has suggestion(s) for 
settings I could change or something else that could fix this problem? 
I appreciate any help you can provide on this issue. 

Thank you.
Link to comment
Share on other sites

tbrauer01,

Whatever Web browser you used  to post the OP in this thread put the entire post on a single line, which has to be scrolled sidewise to be read.  Please fix it and re-post.  Also please include what version of Retrospect you are using in that re-post, as well as your previous macOS version.

Link to comment
Share on other sites

tbrauer01,

Now that I can read your re-formatted OP, I can offer some volunteer help.  In case you weren't aware of it, Retrospect "Inc." personnel haven't been following these Forums for a couple of years.  Here's why and how to file a Support Case for a bug.

In creating that Support Case, you'll have to provide complete information on precisely what changed in your installation.  If I believed your OP was accurate, the only thing that changed was that your Retrospect Mac 17.5.1 "clients" already upgraded to macOS 11.0.1—that continue to be connected via Ethernet to your Retrospect Mac 17.5.1 "backup server"—are now connected to the same "backup server" upgraded to macOS 11.0.1.

But I don't believe your OP told the whole story, because of several years of experience summarized in this post in a 2017 thread—and my later posts in that same thread.  Supplementing that is the Recycle backup of all my drives that I do every Saturday morning.  Yesterday morning it backed up my 2016 MacBook Pro "client" SSD drive over a LAN that includes a room-to-room MoCA 1.1 segment at just under 370MB per minute, but backed up two more drives—one HDD and one SSD—directly mounted inside my 2010 Mac Pro "backup server at about 2300MB per minute and 2400MB per minute respectively.  That experience corresponds with that of kevinpoole in the OP of this 2010 thread, which I linked to in a later post in the 2017 thread.  It also corresponds with what you reported in this thread's OP—"client" vs. local-mount (my "normal" term) backup speeds resembling mine.

That's why I suspect your OP in this thread concealed the fact that, prior to the macOS upgrades, your "client" drives were backed up to your "backup server" as local shares—rather than via "client" machines—or copied (non-Retrospect cloning app?).  In my delayed last post in that later thread I said:

Quote

My proposed explanation is that, when the Engine backs up a disk via a Retrospect Client, it sends a "send me the next file" message over the LAN to the client machine.  The Client software receives that message, traverses the directory structure, and then sends the file block-by-block over the LAN to the Engine.  When it has finished, it sends a "that's the end of that file" message over the LAN to the Engine, after which the Engine begins the process again for the next file.  The processing of messages by the Client software seems to require significant amounts of CPU work by the client machine.

By contrast, when the Engine is backing up a shared disk no exchange of messages is necessary—since the Engine software automatically keeps track of what it is doing.  The directory traversal and reading of the file blocks still has to be done, but that seems to require less CPU work. 

I should note that MoCA 1.1 is half-duplex, which might slow down the exchange of messages over the MoCA portion of my LAN.  If I had a spare 40-foot Ethernet cable, I'd bypass my inter-room MoCA LAN segment (drat!) to do a test.  However kevinpoole gives no indication that he was using MoCA—rather than straight LAN Ethernet—in 2010.  I should also note that my "client" machine is booting macOS 10.13 High Sierra, my "backup server" machine is booting macOS 10.12 Sierra, and I'm still running Retrospect Mac 16.6.  However the Retrospect Mac cumulative Release Notes don't announce a dramatic speedup☹️ (vs. pgf.3 here) in  Retrospect Mac 17 "client" backup, which maybe later decreased in macOS 11.0.1 Big Sur.

P.S.:  Regardless of whether your OP in this thread was complete, consider using Retrospect's block level incremental backup feature—described on pages 233–237 of the Retrospect Mac 17 User's Guide—in your No Media Action incremental backups.  I had not used it from 2015 until June 2020, because I have only one set of small FileMaker Pro databases.  However I then realized that the reason my Sunday–Friday morning incremental Backup script runs had recently crept up from from 8 minutes to 35 minutes is because Apple Mail stores all saved e-mails in a single file, and I've saved a lot of e-mails.  I found that I also need to enable block level incremental backup on my Saturday morning Recycle script, even though Recycle runs are not incremental.  Although page 237 says "After you enable block level incremental backup for a backup script, the next backup will be a full backup of new or modified files", it appears that the feature actually applies to a Media Set—even though it is specified for a script.   Therefore, until I specified block level incremental backup for my Saturday morning Recycle script in early September, my Sunday morning incremental script runs were still taking 35 minutes—even though my Monday–Friday incremental script runs were now taking only 8 minutes.

P.P.S: The OP in that 2017 thread said my posted speed figures agreed with his for 1Gbps Ethernet.  However his installation was considering upgrading to 10Gbps Ethernet, and already had shared drives connected to the "backup server" with 10Gbps Fiber Channel that backed up at FCoE speeds.  So if you're using 10Gbps Ethernet to connect your "clients" to your "backup server", your "normal" speed may be correct even if you are using the Retrospect Client.  My installation is in my apartment, and for architectural reasons I couldn't upgrade to 10Gbps even if I wanted to—which I don't.  I did at one point buy a pair of relatively-cheap MoCA 2.0 adapters, but downgraded to MoCA 1.1 because they seemed to have reliability problems.  However I intend to upgrade the adapters again for test purposes before my next Saturday morning Recycle backup.

Edited by DavidHertzberg
P.S.: Consider Retrospect block level incremental feature in your No Media Action backups. 2nd prgf.: "Clients" were already upgraded to macOS 11.0.1 before "backup server" upgraded. P.P.S.: If you're using 10Gbps Ethernet, "normal" speed may be legit
Link to comment
Share on other sites

On 11/20/2020 at 1:15 AM, tbrauer01 said:

I appreciate any help you can provide on this issue.

To clarify:

Catalina server with Big Sur clients = 2GB/min
Big Sur server with Big Sur clients = 500MB/min

Correct? What are you backing up to (local disk, tape, NAS, etc)? Have you a similar slowdown with eg Finder network copying using the server? What kind of speeds are you getting with an RS "Copy" rather "Backup" operation?

It'll help Support if we can nail down where the slowdown is happening -- network transfer, writing to disk, or somewhere else. I might have a Mac Mini turning up later this week that I could, perhaps, "borrow" and try and replicate the problem.

Link to comment
Share on other sites

Hello .. thank you for responses to my query regarding long back-up time for LAN connected clients following upgrade to MacOS 11.0.1.  

Here is some additional info: I have three MacOS machines: iMacPro, MacPro, and MacBookPro 16.  All 3 of these machines are now running on MacOS 11.0.1. The Retrospect Desktop edition 17.5.1 is on the iMacPro and the other two machines have Retrospect Client 17.5.1.  In addition, I have one Windows10 installation as a Parallels VM (on the iMacPro) which also has a Retrospect client connection.  So there is essentially 4 sources to backup.  These machines are connected by ethernet in my home office: the iMacPro and MacPro connect through 10G ethernet and the MacBook Pro is 1G.  I backed up all these machines before the MacOS 11.0.1 upgrade.  The backup media sets are all on an external hard-disk array (RAID 0) connected to the iMacPro by Thunderbolt 3 cable.

I did full backup of all the sources prior to the MacOS Big Sur upgrade.  The local iMacPro backup was of course very fast .. about 8GB/minute.  The client connected backup performance was around 2GB/minute  (ranging from 1.5 to 2.5 hours for each source)  Following the MacOS upgrade, performance for the same full backups of the client connected machines is about 500MB/minute = 6 hours or more for each source.

I am basically living with this slow backup performance for now .. hoping the next incremental upgrade to MacOS will fix this issue.

thank you.

Link to comment
Share on other sites

tbrauer01,

Thanks for now providing complete information on precisely what changed in your installation, which was in fact just the upgrade to macOS 11.0.1 on your iMac Pro "backup server". 😃  Based on that post, I'd now agree you have grounds for a Support Case; again, here's why and how to file a Support Case for a bug.  Getting a fix may IMHO be tricky, because it's not clear whether the slowdown in Client backups is due to macOS 11.0.1 having a unexpected deficiency affecting Retrospect Mac 17.5.1 or macOS 11.0.1 having an announced-to-developers change for which Retrospect Mac 17.5.1 hasn't been updated.  Always assuming that Retrospect Tech Support can reproduce the slowdown you found, the Retrospect and/or Apple engineers are going to have a "fun time" ☹️ with this.

I'm still trying to understand why, prior to the macOS upgrade of your iMac Pro, your Client backups were running four times as fast as mine—which explains my initial skepticism..   Two times as fast might well be explained by your hard-disk-array destination being connected via Thunderbolt 3. My backup destinations are 5-year-old portable HDDs connected via USB3, and I had to add a card to my 2010 Mac Pro to enable that connection.  The other two-times-as-fast might be explained for your Mac Pro by the 10Gbps Ethernet connection, except that the feasibility test recounted in the P.S. of this 2017 post indicated a slower-than-1Gbps Ethernet connection—I'm pretty sure I was still using a 100Mbps Ethernet hub (!) to connect the "client" with the "backup server" in early 2015—didn't result in a backup that was much slower.  In any case, you're also saying that the backup of your 1Mbps-connected MacBook Pro also ran at four times the speed of the backup of my 15-inch 2016 MBP, which (because of Intel's well-known recent inability to introduce significantly faster processor chips, which has led to the introduction of Apple Silicon processor chips) isn't very much slower.

As promised, yesterday evening I replaced my MoCA 1.1 adapters with my MoCA 2.0 adapters.  I then ran an extra No Media Action backup of my MBP; for the same amount of incrementally-changed data, it ran in almost exactly the same amount of time as my usual Tuesday morning backup.

 

Link to comment
Share on other sites

tbrauer01,

My mighty brain continued to work on your problem as I was going to bed.  🤣  The first thing that occurred to me is that both your LAN-connected "clients" are running at 25% of their normal speed, so the problem is more likely to be with your destination drive's speed.  Then I remembered your saying something about RAID-0 as well as Thunderbolt 3 in connection with the destination, so I booted my MBP up again and took a look. 

The first thing I looked at was the Wikipedia article covering RAID-0, to make sure it didn't require a NAS.  Then I did a series of Google searches, which eventually led me to this SoftRaid Forum thread.  There's an 11 November 2020 post there that summarizes the problem with SoftRaid and Big Sur nicely, and it's written by Henry-in-Florida—which happens to be a knowledgeable occasional poster's "handle" on this Retrospect Forum.

It's just a thought; you might be using different RAID-0 software, such as Disk Utility—which could also be having a problem in Big Sur.

P.S.: As Nigel Smith implicitly suggests below, local backup of your iMacPro should also have slowed if my RAID-0 problem hypothesis is correct.

Edited by DavidHertzberg
P.S.: _Local_ backup of your iMacPro should also have slowed if my RAID-0 problem hypothesis is correct.
Link to comment
Share on other sites

10 hours ago, tbrauer01 said:

 I backed up all these machines before the MacOS 11.0.1 upgrade...

I did full backup of all the sources prior to the MacOS Big Sur upgrade...

Following the MacOS upgrade...

OK, so it sounds like

  • Server and clients all on 10.15.7 -- fast backups
  • Server and clients all upgraded to 11.0.1 -- slow backups

So it could be clients, or server, or both. Try a test backup of a folder on the iMac Pro to the RAID, to take network ops out of the equation. Try a straight Finder copy from the iMac to the RAID, to take Retrospect out of the equation. And as David asks -- is this a hardware or software RAID?

The good news is that you've now got full backups of everything and can now use incrementals, which will take a lot less time even with those slower speeds. So you'll be OK, even if it takes a while to find a fix.

Link to comment
Share on other sites

tbrauer01,

Let's consider the alternate possibility that the slowdowns occur only when backing up your "client" machines, which would rule out my RAID-0 hypothesis above.

derek500 reported a couple of weeks ago in the OP of this Server, SBS, and Multi Server thread that restores to "client" machines don't work under Retrospect Windows 17.5.1.102, but that the same restores work if you restore to the "backup server"'s local hard drive.  mrogerson reported today in that thread that the same is true for a Copy script (mrogerson used the Retrospect Windows term Duplicate, which is the same as a Retrospect Mac Copy when it isn't Copy Backup or Copy Media Set).  That thread's OP went on to say that the head of Retrospect T. S. "replied quickly [to derek500's Support Case] to let me know that they were aware of this issue and it was a high priority for them to fix."  Thus there's an acknowledged bug in Retrospect Windows 17.5.1.102 that exists either in the Engine or in the Client program, but it only affects operations involving "clients".  (There's no indication that the bug is Server-related, though that's the Forum where the thread is posted; IMHO it's due to derek500's Edition license.)

My first conclusion is that there may be a similar bug in Retrospect Mac 17.5.1, but slowing down "client" Backups instead of totally ruining Restores or Copies.  I strongly urge you to get in your Support Case ASAP, so that the engineers can fix your bug in the equivalent Retrospect Mac release.

My second conclusion is that Retrospect Engineering's alpha-testing, always weak over the past 20 years, has totally gone to sh*t since the StorCentric acquisition.  How could the engineers fail to confirm that routine Restore and Copy operations still work for a release candidate? 😖 

 

Link to comment
Share on other sites

On 11/29/2020 at 11:39 PM, DavidHertzberg said:

My first conclusion is that there may be a similar bug in Retrospect Mac 17.5.1, but slowing down "client" Backups instead of totally ruining Restores or Copies.

Except, from the descriptions, it's a bug in 17.5.1 on Big Sur but not in 17.5.1 on Catalina. And Big Sur itself seems to be rather variable, with eg reports of general big slowdowns on recent Fusion-drive iMacs while being really nippy on old SSD MacBook Airs.

I'd promised a test on my Big Sur Mini -- the wrinkle is that that's an M1 machine, throwing yet another confounding factor into the mix. So I'll try and find something else to test on, which'll let me speed trial the same setup on both Cat and Sur. The problem will be finding a spare bit of kit that isn't so old that backups are dog-slow in both tests!

  • Thanks 1
Link to comment
Share on other sites

On 12/1/2020 at 5:26 AM, Nigel Smith said:

Except, from the descriptions, it's a bug in 17.5.1 on Big Sur but not in 17.5.1 on Catalina. And Big Sur itself seems to be rather variable, with eg reports of general big slowdowns on recent Fusion-drive iMacs while being really nippy on old SSD MacBook Airs.

I'd promised a test on my Big Sur Mini -- the wrinkle is that that's an M1 machine, throwing yet another confounding factor into the mix. So I'll try and find something else to test on, which'll let me speed trial the same setup on both Cat and Sur. The problem will be finding a spare bit of kit that isn't so old that backups are dog-slow in both tests!

tbrauer01,

It looks like Nigel Smith may well have zeroed-in on the problem 😀 , which is with Big Sur on iMacs 🙄not with Retrospect 17.5.1 on Big Sur.  

Here's an Apple Developer Forums thread titled "iMac slows down after Big Sur installing".  A post once on that thread's page 2 by ttelmah (I can't link to slide-down posts on that forum) says "On a 2017 i7 Fusion [my emphasis—not an iMac] machine, Big Sur for me runs fine, On my 2019 iMac Pro using an SSD, it does not", so the problem appears to be with iMacs (including iMac Pros also cited in some other posts there)—not with Fusion Drivettelmah's second post shortly after says "After a long session this morning with Apple support, they have suggested I switch back to Catalina. The rep said that they were having a lot of problems with Big Sur, and it'd probably be several months before it was working properly."

Presumably Nigel Smith doesn't have an M1 iMac, unless he has access to as-yet-unreleased Apple hardware.  But if he did, I'll bet it would work fine as a Retrospect "backup server"—because I get the feeling that Apple devoted the bulk of its Big Sur alpha-testing to Apple Silicon M1 Macs rather than to crummy old Intel Macs.  Apple may have been taking alpha-testing lessons from Retrospect "Inc." personnel 🤣 ,  who to be fair probably don't own iMacs corporately or individually.

My excuse for not being aware of this problem is that my Mac-related reading is exclusively of the Ars Technica Mac forum.  A few posters who upgraded their iMacs reported slowness in the "Big Sur pludging thread" there, but they associated it with installer problems.

So you don't have to feel guilty if you haven't filed a Retrospect Support Case.  You should instead file an equivalent case with Apple, especially if your iMac Pro has slowed down in other ways than as a "backup server".  Phone 800.APL.CARE to find out how, and to find out how to downgrade.

P.S.: Replies on that Apple Developer Forums thread are sorted most-recent-first, so ttelmah's posts—including the one from which I added a quote at the end of the second paragraph here—are sliding downward from page 2—where I found them.

 

Edited by DavidHertzberg
P.S.: Replies on that Apple Developer Forums thread are sorted most-recent-first, so ttelmah's posts—including the one from which I added a quote at the end of the second paragraph here—are sliding downward from page 2—where I found them.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...