Issue with second source not matching or backing up

[boomcha]

I'm still using version 14.6.2 on my old Mac Pro because it's been pretty reliable with LTO drives, however I do have an issue which I have been lazy to fix in the last couple of years. It's just getting really annoying now and I worry I'm going to miss it one day and mess up my back ups.

I'm backing up to a media set and I choose two sources, one local (the 8TB RED drive) and then the second source in this case is a networked machine called "jorge".

The first source to scan will backup fine and verify but the second drive source won't at all as you can see from the log. BUT if I then rescan the "jorge" again by itself then it will find the files it needs and back it up normally. Basically the matching doesn't work for the second source.

This phenomenon will also happen on other sources with two drives attached. Does anyone have any ideas why?

The log below is what it says:

Normal backup using Backup Assistant - 2021-02-04, 5:43 PM at 2021-02-04, 5:44:29 PM
    To Backup Set JORGE SPRING 2019 BU...
    -  2021-02-04 5:44:29 PM: Copying jorge on MacBook Pro
    2021-02-04 5:51:16 PM: Found: 328161 files, 100732 folders, 621.5 GB
    2021-02-04 5:51:21 PM: Finished matching
    2021-02-04 5:51:27 PM: Copying: 0 files (0 B) and 0 hard links
    2021-02-04 5:52:35 PM: Building Snapshot...
    2021-02-04 5:52:35 PM: Checking 100,732 folders for ACLs or extended attributes
    2021-02-04 5:54:41 PM: Finished copying 70,124 folders with ACLs or extended attributes
    2021-02-04 5:54:42 PM: Copying Snapshot: 2 files (122.1 MB)
    2021-02-04 5:54:48 PM: Snapshot stored, 122.1 MB
    2021-02-04 5:54:48 PM: Comparing jorge on MacBook Pro
    2021-02-04 5:54:53 PM: Execution completed successfully
    Duration: 00:10:23 (00:09:12 idle/loading/preparing)

    -  2021-02-04 5:54:53 PM: Copying 8TB RED
    2021-02-04 5:55:02 PM: Found: 55577 files, 20599 folders, 3.3 TB
    2021-02-04 5:55:03 PM: Finished matching
    2021-02-04 5:55:04 PM: Copying: 818 files (89.7 GB) and 0 hard links
    2021-02-04 6:07:00 PM: Building Snapshot...
    2021-02-04 6:07:00 PM: Checking 20,599 folders for ACLs or extended attributes
    2021-02-04 6:07:01 PM: Finished copying 890 folders with ACLs or extended attributes
    2021-02-04 6:07:01 PM: Copying Snapshot: 2 files (20.9 MB)
    2021-02-04 6:07:05 PM: Snapshot stored, 20.9 MB
    2021-02-04 6:07:05 PM: Comparing 8TB RED
    2021-02-04 6:22:49 PM: Execution completed successfully
    Completed: 818 files, 89.7 GB
    Performance: 7,701.4 MB/minute (7,712.2 copy, 7,690.6 compare)
    Duration: 00:27:55 (00:04:02 idle/loading/preparing)

    2021-02-04 6:22:49 PM: Execution completed successfully
    Total performance: 7,332.7 MB/minute
    Total duration: 00:38:18 (00:13:15 idle/loading/preparing)

 

 

[Nigel Smith]

The logs are saying something different -- that the remote client is contacted/scanned just fine but no files are found that need to be backed up, while the local volume does have files to be backed up and they are.

So it's a problem with the remote source, and you need to include OS version, RS client version, and disk format of that. Also whether "jorge" is the system volume, a Favourite Folder you've defined in RS, or another volume (icons may not have pasted into your post). It doesn't look like you are using any Rules, but check just in case.

I would have guessed at an issue with Instant Scan but, on my system at least, use of that is included in the logs...

[boomcha]

Hey Nigel, I did not have Instant Scan turned on because of how much of resource hog it is usually but I will test it with it turned on. I'm not using any rules and initiating the backup myself (not through scripts).

OS Server machine: High Sierra latest  RS.14.6.2 (8TB RED drive is a regular HFS+ volume)
OS Client machine: Mojave  using RS 14.6 Client (APFS format)

"jorge" is my user on the client machine FYI.

The same thing happens on other machines that both external drives were HFS+ volumes and mounted on the same client machine too FYI so I don't think it's something to do with volume format.

Just after that log, I did initiate a scan of just the "jorge" user and it found everything it needed and backed up normally as it does. But I will test it over the next little bit with Instant Scan On for sure.

 

[Nigel Smith]

1 hour ago, boomcha said:

Hey Nigel, I did not have Instant Scan turned on because of how much of resource hog it is usually but I will test it with it turned on

I leave it off myself, for that very reason. I asked because it may have resulted in the client mistakenly using an "old" file listing from the last backup (so nothing needs to be backed up because you already have). If not on, that's probably not the issue. Also, Instant Scan isn't compatible with APFS.

1 hour ago, boomcha said:

"jorge" is my user on the client machine FYI.

So "jorge" is your user folder and you've defined that as a Favourite in RS? What state is the client machine at when the backup fails -- logged out, logged in but asleep, logged in but on screen lock, logged in and in use? -- and when it succeeds?

But...

1 hour ago, boomcha said:

OS Client machine: Mojave  using RS 14.6 Client (APFS format)

Certification for Mojave only arrived with RS v15.5. If you've a Mojave test system handy you could try downloading the 15.5 client, installing it, and seeing if your v14 server can still back it up and, if so, if there's any improvement. Otherwise, it's worth noting that even if your server is limited to High Sierra, you can still upgrade to RS v17.

[boomcha]

1 hour ago, Nigel Smith said:

I leave it off myself, for that very reason. I asked because it may have resulted in the client mistakenly using an "old" file listing from the last backup (so nothing needs to be backed up because you already have). If not on, that's probably not the issue. Also, Instant Scan isn't compatible with APFS.
 

Not sure it doesn't matter if its an APFS drive or not. This also happens on external HFS+ drives on another client as well consistently as well. That one is running Sierra but same version

1 hour ago, Nigel Smith said:

So "jorge" is your user folder and you've defined that as a Favourite in RS? What state is the client machine at when the backup fails -- logged out, logged in but asleep, logged in but on screen lock, logged in and in use? -- and when it succeeds?

Yes on both counts about "jorge". The machines are usually logged in and screen locked.

1 hour ago, Nigel Smith said:

But...

Certification for Mojave only arrived with RS v15.5. If you've a Mojave test system handy you could try downloading the 15.5 client, installing it, and seeing if your v14 server can still back it up and, if so, if there's any improvement. Otherwise, it's worth noting that even if your server is limited to High Sierra, you can still upgrade to RS v17.

Upgrading might be the option, but didn't want to throw money away if nothing gets resolved. I'm given RS a call to see what they say, and they are recommending upgrading to 17. So I'll try that.

It's also recommended to Disable Instant Scan.

[Nigel Smith]

1 hour ago, boomcha said:

I'm given RS a call to see what they say, and they are recommending upgrading to 17.

That isn't exactly a surprise 🙂 But there's a few more things you can try first (I'd still recommend upgrading to v17 eventually, for better compatibility).

1 hour ago, boomcha said:

This also happens on external HFS+ drives on another client as well consistently as well. That one is running Sierra but same version

So that is completely different -- an external drive rather than a system disk, HFS+ rather than APFS, Sierra rather than Mojave? Sounds like the only constants are the server and the client version, yet it isn't happening with every client...

What are the commonalities/differences between the clients for which this happens and the ones that don't? Don't just look at software versions, but also what's installed and what is or isn't enabled eg FileVault, sleep options.

Give the v15.5 client a go, even if you haven't a spare test machine. If it doesn't work you can simply uninstall it, re-install the v14 version, and re-register the machine with your server.

And ultimately -- if it is always "first attempt fails, second attempt works" as you describe... Simply schedule a "primer" script to hit the troublesome systems before your real script 😉 You could even do it with a rule that excluded everything -- all files would be scanned, priming the target for the real script, but little or no space would be needed on your backup target.

[boomcha]

Thanks, I just bought the 17 upgrade and installed, updated the clients and all that.

Seems to be working correctly as I can see it go throught 1 of, 2 of 3, 3 of 3 and I've tried a few machines and looks to be ok now.