Why does using AFP for TimeMachine backups cause all disks to spin up?

[guitarlp]

I had this issue on 4.7, and I thought with AFP and Time Machine being supported in the latest 5.0 that things would work correctly, but it looks like enabling AFP causes every disk to spin up and stay spun up.

 

I initially created a user share, designated it to one disk, and only enabled the AFP protocol for TimeMachine. I've been using that most of the day today and my entire unraid system (all 16 disks) have stayed spun up the entire time.

 

I then tried removing the user share, and instead backing up directly to one of my disks by using AFP. That however, appears to also cause the entire array to spin up.

 

I can spin down all of my disks, but as soon as I tell Time Machine to create a backup, one by one I heard each of my disks spin up in unRAID. While that happens Time Machine is showing "Looking for backup disk..."

 

Is everyone that uses Time Machine experiencing this? I've seen others report it, but I haven't found a fix for the issue.

[dgaschk]

Is the TM share allowed to use all disks?

[snowboardjoe]

Your TM client is already designated to just connect to one of these right?  I could see this happening when you select a different "disk" for TM, but I would not expect it once it's already selected.  Weird.

[guitarlp]

Is the TM share allowed to use all disks?

 

No. When I used a user share, I assigned that share to 1 disk. But this also happens when I go direct to disk (no AFP users shares at all in my setup). In both cases, AFP was only enabled for use on disk14.

[guitarlp]

Your TM client is already designated to just connect to one of these right?  I could see this happening when you select a different "disk" for TM, but I would not expect it once it's already selected.  Weird.

 

Yep... I configured Time Machine to connect directly to disk14. I stopped the backup, spun down all in unRAID, and told Time Machine to start a backup again.Once I clicked that button to start another backup, all disks, starting from parity up to disk14 spun up sequentially.

[dgaschk]

I may have not had this issue because I use disk1 for my TM share.

[guitarlp]

I may have not had this issue because I use disk1 for my TM share.

 

Interesting thought (that unRAID may spin up each disk until it finds the Time Machine share).

 

I decided to test it by swapping disk14 and disk2 positions. However, after doing so and spinning down all of the disks, unRAID spun up all disks, 1-14 in sequential order when I told Time Machine to create a backup.

[dgaschk]

Are spin-up groups disabled?

[guitarlp]

Yes, they're disabled.

[Joe L.]

I may have not had this issue because I use disk1 for my TM share.

 

Interesting thought (that unRAID may spin up each disk until it finds the Time Machine share).

 

I decided to test it by swapping disk14 and disk2 positions. However, after doing so and spinning down all of the disks, unRAID spun up all disks, 1-14 in sequential order when I told Time Machine to create a backup.

If it is pointing to a specific disk share, and not using a "user share" then the mac is scanning those disks for some reason.

 

Joe L.

[guitarlp]

I may have not had this issue because I use disk1 for my TM share.

 

Interesting thought (that unRAID may spin up each disk until it finds the Time Machine share).

 

I decided to test it by swapping disk14 and disk2 positions. However, after doing so and spinning down all of the disks, unRAID spun up all disks, 1-14 in sequential order when I told Time Machine to create a backup.

If it is pointing to a specific disk share, and not using a "user share" then the mac is scanning those disks for some reason.

 

Joe L.

 

How so? if AFP is disabled on all user shares, and only enabled on 1 disk share, how could my mac be accessing those disks to cause them to spin up? My Mac would query the server, see the one disk share, and then connect that that share right? My Mac see's no other disk or user shares using AFP, so it wouldn't even know there are other disks to spin up.

 

Edit: I may be wrong here, but it would seem like my Mac is sending a signal to unRAID asking for all of the available shares over AFP, and unRAID is then spinning up each disk to see if there's anything being shared on them. I'm not running any add-on's, just bone stock unRAID. Maybe those of you that don't have this issue are running that cache_dir's script so unRAID already knows what's on each disk and doesn't cause the disks to spin up?

[dgaschk]

No cache-dirs here and I don't have this issue. Only my TM disk spins. It is a User share restricted to a single disk.

[guitarlp]

No cache-dirs here and I don't have this issue. Only my TM disk spins. It is a User share restricted to a single disk.

 

Do you have any other shares over SMB or NFS, or are you only using AFP? For the disk using TM, is that the only share you're using on that disk?

[dgaschk]

No cache-dirs here and I don't have this issue. Only my TM disk spins. It is a User share restricted to a single disk.

 

Do you have any other shares over SMB or NFS, or are you only using AFP? For the disk using TM, is that the only share you're using on that disk?

 

2 smb-only user shares are also restricted to disk 1. No NFS. The other disks are rsync targets. They hold a single share that is not exported by unRAID.

[guitarlp]

I'm at a loss at why my machine seems to be spinning up all the disks during each TM backup. I've tried rebooting unRAID, as well as my Macbook, but it didn't make a difference. I have TM pointing at a single disk (none user share) and I'm only using AFP on that disk. Yet every time I run a Time Machine backup, all the disks spin up one by one, and Time Machine doesn't start the backup until all of the disks have spun up.

 

I'm running rc 16c, and it's completely stock. I was running 4.7 previously, but I wiped my flash drive, and re-configured all the settings from scratch on rc 16c so that I didn't have any left over configuration or garbage from my old unRAID. I checked the sys logs, and all I see is this:

 

Jul 28 01:06:24 NAS emhttp: Spinning down all drives...
Jul 28 01:06:24 NAS kernel: mdcmd (94): spindown 0
Jul 28 01:06:25 NAS kernel: mdcmd (95): spindown 1
Jul 28 01:06:25 NAS kernel: mdcmd (96): spindown 2
Jul 28 01:06:26 NAS kernel: mdcmd (97): spindown 3
Jul 28 01:06:26 NAS kernel: mdcmd (98): spindown 4
Jul 28 01:06:26 NAS kernel: mdcmd (99): spindown 5
Jul 28 01:06:27 NAS kernel: mdcmd (100): spindown 6
Jul 28 01:06:27 NAS kernel: mdcmd (101): spindown 7
Jul 28 01:06:28 NAS kernel: mdcmd (102): spindown 8
Jul 28 01:06:28 NAS kernel: mdcmd (103): spindown 9
Jul 28 01:06:28 NAS kernel: mdcmd (104): spindown 10
Jul 28 01:06:29 NAS kernel: mdcmd (105): spindown 11
Jul 28 01:06:29 NAS kernel: mdcmd (106): spindown 12
Jul 28 01:06:30 NAS emhttp: shcmd (112): /usr/sbin/hdparm -y /dev/sde &> /dev/null

 

That's me manually spinning down all the drives. Once that completes I tell Time Machine to make a backup and all the disks start to spin up. But nothing posts to the log after that point. Any other thoughts on what could be the problem?

[dgaschk]

Install the inotify package. It's available via the unMenu package manager.

[guitarlp]

That would tell me what files/folders are being accessed or modified to help me troubleshoot?

 

I don't have unMenu installed because I like to keep unRAID stock and use separate Linux machines for all the app/front end stuff. I can install it to help troubleshoot, but I'm wondering how inotify would help me out.

[guitarlp]

Did a bunch more testing, including booting into unRAID directly instead of through ESXi. However, I've narrowed down the issue to my Macbook. If I connect to the share from another Macbook, it only spins up the parity and disk1. On my Mac however, everything spins up.

 

I tried disabling TotalFinder, as well as telling Spotlight not to search that network location, but I'm still running into this issue. I guess it's time to un-install each potential problem program one by one until I find the culprit.

[guitarlp]

I can't figure it out. So far I have:

 

• Repaired permissions
  
• Cleared Spotlight data and forced a refresh
  
• Cleared Keychain of all logins related to this server via AFP
  
• Deleted Finder preferences
  
• Uninstalled TotalFinder
  
• Uninstalled Alfred
  
• Uninstalled Pacifist
  
• Uninstalled OSXfuse
  
• Uninstalled BlueHarvest
  
• Uninstalled NFSManager
  
• Rebooted and tested after every change to try and find the culprit
  

 

Unless anyone else has any ideas, I'm just going to turn off AFP for now since it's a headache (and always has been). I would have ideally liked to have unRAID manage my TM backups, but I'll just let napp-it manage that for now. For some reason my machine has something on it that forces a complete scan of the unRAID server when it tries to mount a share (only when mounting with AFP), and I'm out of ideas on what it could be at this point.

[snowboardjoe]

AFP and TM has been a pain in the butt for me too.  I was trying to mix things up by having one share for all TM clients, but that failed miserably.  I ended up having to keep them as separate shares.  Otherwise, when one AFP client touched a TM share that was touched by another AFP client, AFP seized.  Once is separated them all into their own shares things are good again (and I also adjust TM client to only run once/day (hourly is just silly).

 

I will check my logs when I get home this evening to see if I'm seeing the same thing as you're seeing.  I'm curious now.

 

I may even just dump one of my 3TB drives onto my AirPort and let TM backups happen that way.