4 hours ago, phenomeus said:

ONLY when I stop the array and restart the array immediately it finds the share and is working flawlessly and as expected.

So you have it working now?

Yes but it will not stay this way. The next backup will fail again until I stop and restart the array 

Did you enable enhanced macOS interoperability in Settings>SMB?

yes

Anything configured in SMB Extras?

#unassigned_devices_start
#Unassigned devices share includes
   include = /tmp/unassigned.devices/smb-settings.conf
#unassigned_devices_end

 

I have the exact same problem as phenomeus and running OSX Catalina. 

 

Tried everything. Nothing works. 

When it's working please type:

testparm -sv  >working.txt

then when it's failing type:

testparm -sv >failing.txt

Then we can see if there are any differences:

diff working failing

I don't know what changed, but now suddenly it works... I haven't changed anything except purging old stuff with Onyx on the Mac. Maybe your divine intervention? 😅

 

Will monitor this (Have taken the testparm working) now. Will make the failing if it fails again.

20 hours ago, Gromit83 said:

I don't know what changed, but now suddenly it works... I haven't changed anything except purging old stuff with Onyx on the Mac. Maybe your divine intervention? 😅

 

Will monitor this (Have taken the testparm working) now. Will make the failing if it fails again.

I saw this on one of my machines and seen multiple reports of this on the internet. TM will finally see the backup destination after it has been mounted for a while (~24 hours in most of the reports I saw).

 

I haven’t been able to find an explanation for this, just reports of the issue.

 

Mounting the destination volume on the client machine and waiting a day seems to be a very common recommendation.

On 10/28/2019 at 6:38 PM, limetech said:

When it's working please type:

testparm -sv  >working.txt

then when it's failing type:

testparm -sv >failing.txt

Then we can see if there are any differences:

diff working failing

I did that right now. it wasn't working, I created the failing.txt.

than I stopped the array, restarted the array (no reboot) and TM started by clicking/ forcing it to do a backup. so I created a working.txt.

but diff don't show any differences. 

 

further ideas? 

I did the same again. 

 

following steps:

1. macOS Catalina 10.15.1, working since hours, forcing TM Backup on Server > failed cant find the share

2. creating failing.txt

3. stopping the unraid array

4. creating offline.txt

5. starting the unraid array

6. forcing TM Backup on Server > working, its preparing the backup, scanning files, all good what it should do everytime

7. creating working.txt

8. diff working.txt failing.txt > no results

9. diff working.txt offline.txt > some results of course

 

still no solution to this damn problem. I don't understand what is the difference to a freshly started array? is something differently broadcasted? 

 

hope you can help me guys. keeping the .txt files for further inspection

Does this work with older OS, such as el capitan? I have an old computer I want backed up, however every AFP back up becomes corrupt and it wants me to restart.

No. Official SMB backup support started with Sierra. You could use something like Carbon Copy Cloner. It’s not quite as well integrated as TM but I’ve never had any corruption issues with it.

Has anyone got TimeMachine working consistently with large backups.  I'm trying to get our Mac (3TB) backing up to unraid over SMB.  It has been running for days and still under a 100GB backed up and still in progress.  I keep seeing references to it being slow but it can't be that slow can it?

 

(Running Unraid newest 6.8, tried both SMB and AFP, same issues)

Edited January 2, 20206 yr by jfrancais

On 1/1/2020 at 6:38 PM, jfrancais said:

Has anyone got TimeMachine working consistently with large backups.  I'm trying to get our Mac (3TB) backing up to unraid over SMB.  It has been running for days and still under a 100GB backed up and still in progress.  I keep seeing references to it being slow but it can't be that slow can it?

 

(Running Unraid newest 6.8, tried both SMB and AFP, same issues)

Yes, working fine for me on Catalina with a 3.06TB backup (unraid 6.8.0 over SMB)

On 1/1/2020 at 6:38 PM, jfrancais said:

Has anyone got TimeMachine working consistently with large backups.  I'm trying to get our Mac (3TB) backing up to unraid over SMB.  It has been running for days and still under a 100GB backed up and still in progress.  I keep seeing references to it being slow but it can't be that slow can it?

 

(Running Unraid newest 6.8, tried both SMB and AFP, same issues)

Also working fine for me on 6.8.0, no difference in performance or behavior from 6.7.2 that I was on before. I have a 2.5TB SMB share set to fill-up Disk 1 in my array (so it doesn't split across disks), Export set to Yes/Time Machine and security set to Private (to force a user/password). It's been working without issue for a couple years. 

On 1/4/2020 at 7:07 PM, Shawn_ said:

Yes, working fine for me on Catalina with a 3.06TB backup (unraid 6.8.0 over SMB)

How long did your initial backup take?  I'm over a week and it still isn't close to complete.  gigabit network.   TimeMachine share is one disk, no cache.

6 minutes ago, jfrancais said:

How long did your initial backup take?  I'm over a week and it still isn't close to complete.  gigabit network.   TimeMachine share is one disk, no cache.

I back up a 512GB drive with maybe 300GB used, the initial backup usually takes a couple days to complete the first one. Time machine uses a ton of small files from what I've seen (all those bands folders/files) and I think network protocols like AFP/SMB/NFS don't typically handle it in a performant manner. For unRAID over a wired network mounted on a Windows computer, I often times can only transfer or delete files at a rate of 7-10/second. 

 

One disk no cache is my setup too. I'm using a WD 10TB white label for the parity and destination drive with two other 6TB WD Purples in the array for 4 disks total. 

 

How is your array set up? I can't remember for sure but I think writing to the array requires reads from all drives in the array, meaning that reads or writes to say Disk 3 could slow down writes to disk 2. 

26 minutes ago, kubed_zero said:

I back up a 512GB drive with maybe 300GB used, the initial backup usually takes a couple days to complete the first one. Time machine uses a ton of small files from what I've seen (all those bands folders/files) and I think network protocols like AFP/SMB/NFS don't typically handle it in a performant manner. For unRAID over a wired network mounted on a Windows computer, I often times can only transfer or delete files at a rate of 7-10/second. 

 

One disk no cache is my setup too. I'm using a WD 10TB white label for the parity and destination drive with two other 6TB WD Purples in the array for 4 disks total. 

 

How is your array set up? I can't remember for sure but I think writing to the array requires reads from all drives in the array, meaning that reads or writes to say Disk 3 could slow down writes to disk 2. 

Single parity drive + 5 array drives and dual cache drives.    Nothing out of the ordinary.  I don't have have a high volume of read/writes on the array happening.  Most of the time the drives are spun down with the exception of the Time Machine share which is currently always spun up.

 

Don't think you are correct on the write/read thing.  Disks not in use are spun down.  If a write to the array caused a read from other drives then all disks would be spun up during writes.  Unless the gui is incorrect, that is not the case.

2 hours ago, jfrancais said:

Don't think you are correct on the write/read thing.  Disks not in use are spun down.  If a write to the array caused a read from other drives then all disks would be spun up during writes.  Unless the gui is incorrect, that is not the case.

Depends on the write mode selected in settings. Turbo (reconstruct) does exactly that, spins up all drives for writes.

3 hours ago, jfrancais said:

Single parity drive + 5 array drives and dual cache drives.    Nothing out of the ordinary.  I don't have have a high volume of read/writes on the array happening.  Most of the time the drives are spun down with the exception of the Time Machine share which is currently always spun up.

 

Don't think you are correct on the write/read thing.  Disks not in use are spun down.  If a write to the array caused a read from other drives then all disks would be spun up during writes.  Unless the gui is incorrect, that is not the case.

Yes sorry! As @jonathanm said I was using reconstruct writes. But as you said the default mode as defined by the wiki https://wiki.unraid.net/Parity#Performance only does parity + destination disk reads and writes. Thanks for the correction!  

30 minutes ago, jonathanm said:

Depends on the write mode selected in settings. Turbo (reconstruct) does exactly that, spins up all drives for writes.

Ah that's what I was thinking of, thanks! I use that mode because I think it grants better performance, but I'm not positive.