Shed light on warning on AFP add form about multiple Time Machine volumes?

[hartzell]

When you add an AFP share there's a pull-down menu for the 'Disk discovery mode'. The info tool tip warns that "Selecting 'Time Machine' on multiple shares may cause unpredictable behaviour in Mac OS".

Can anyone shed any light on what that unpredictable behavior might be, what causes it, and what (if anything) might be done about it?

I'd like to publish volumes for each of several macs to use for their time machine backups and the vague warning is unsettling.

Thanks,

g.

 

[hartzell]

Bump.

Is there anyone who knows the netatalk suite and can explain what advertising as a time machine volume does and what's dangerous about advertising multiple volumes?

g.

 

[bollar]

I don't have any direct experience with FreeNAS and Time Machine, but given that Mountain Lion now supports multiple Time Machine targets, I don't think you should have an issue.

 

[vbonline]

I don't have any direct experience with FreeNAS and Time Machine, but given that Mountain Lion now supports multiple Time Machine targets, I don't think you should have an issue.

There are still problems (like not finding the TM volume, while I can mount is without problems over AFP)..

So don't assume... ;-)

 

[vbonline]

Bump.

Is there anyone who knows the netatalk suite and can explain what advertising as a time machine volume does and what's dangerous about advertising multiple volumes?

g.

I can explain the symptoms I see with my box (Freenas 8.3-Release).

Situation: I created three datasets with quotas for the three Macs I plan to backup. Next I exported all three datasets via AFP in TM mode.

Result: All three machines can see and backup on those datasets... sometimes... Most of the time local TM reports: "Backup postponed, can't find volume".

Restarting AFPD on the NAS fixes this (if only for a couple of minutes), so you'll get at least one backup through. Surprisingly booting the Client fixes it as well for at least one backup....

Sometimes it fixes itself.. I've seen the last backup as 19:00, than it stopped, next morning I see one backup from 04:00 and no more...

In short: Intermittent connectivity problems... :-( Which is a real pity, because I don't want to meddle with the sparse files TM creates, but I still want to restrict the size on my TM backups individually per machine. Datasets, Quotas and dedicated shares per machine would be the best solution... If only it would work...

 

[James]

The answer may be here: http://www.readynas.com/forum/viewtopic.php?f=71&t=55166#p312945

The separate TM volumes, one per Mac, is necessary because Apple does not deal properly with low-diskspace issues when multiple Mac's share the same TM volume (nothing breaks, it's just that one Mac can hog the whole drive and there is no Mac-to-Mac TM communication to ask it to nicely remove some old backups on behalf of another Mac trying to use the TM volume).

 

[vbonline]

That's EXACTLY the reason to use datasets and quotas on a freenas volume... Let's say you have a 2 TB freenas volume and you need to backup two 500GB Mac's on it. You'd like to create two different datasets with a 750 GB quota on each (one for each Mac).

So you end up with two time-machine shares and some free space left on the volume.....

Sadly it is NOT working (I'd guess that avahi is getting into problems announcing multiple tm volumes)...

Someone from freenas should look into it and fix it... It IS a major annoyance...

On the other side I get roughly one tm backup done per machine per day (instead of one per hour as it should be).... That should be enough security for now... So right now it is not a deal breaker for me, just an annoyance.

 

[JaimieV]

Although multiple Macs won't evenly share a single TM target, they do react appropriately when the TM target runs out of space: each starts trimming their own backups, encapsulated inside its own sparsebundle. I've observed this on a FreeNAS8 quota'd TM share, with four Macs sharing 1Tb of TM destination. Works fine.

If you feel strongly about enforcing more even shares, you can use hdiutil to set a max size on one or more of the sparsebundles, or more easily you can 'pre-bloat' the sparsebundles by creating then deleting large files on them. The sparsebundles will not be shrunk when TM trims the backups within them.

 

[vbonline]

As I said: I don't want to meddle with the sparsebundles (with hdiutil) which I'd have to because my main volume is raid-z1 out of 6 * 2TB... and that is too much space for backups to grap...

Look, I work as a admin in the storage industry and creating a dataset/qtree, applying a quota and share it to the user is standard. That this is NOT working with AFP/TM/Avahi on Freenas is just disappointing...

... and I really don't want a workaround ('cos it is somehow working for me, as I stated before), I want to have it working the way it is supposed to work. Too much asked?

and that would be by fixing the current AFP/TM/Avahi blunder in Freenas...

and I think this has been ignored long enough by now...

Anyone of the developers around?

 

[bollar]

FWIW, it's not a FreeNAS issue as much as it is a Netatalk issue. Netatalk 3.0.1 is supposed to handle this better -- you could update Netatalk and see if that resolves the issues for you -- but be aware that the configuration files have completely changed in Netatalk 3 and it will probably break the FreeNAS GUI.

Alternatively, I would expect FreeNAS to include the Netatalk update in their next major release.

 

[JaimieV]

Too much asked?

Yes, for the current software. Feel free not to take advantage of workarounds. I have two more that I won't bother to type up due to your attitude.

Also, go raise a bug rather than rant at people trying to help.

 

[JaimieV]

Heh. To knock that little strawman over, the 'hdiutil' I reference above is a command line process running in a certified Unix environment based on BSD (why yes, Apples *do* run an open-source Unix). And vbonline doesn't want to mess with it, he/she wants to solely use the point'n'click interface and not the Apple supplied methods of getting under the shiny GUI and doing complex things.

But all that's irrelevant, since the issue here is with netatalk 2 being a bit rubbish, not with Apple at all.

 

[vbonline]

1.) Creating a dataset, applying a quota on it and share it out is a standard, even with multiple datasets.
2.) Trying to do so with FreeNas, AFP and Time Machine volumes doesn't work as it should.
3.) This is NOT mentioned in the FreeNas documentation (at least I couldn't find it in the users guide or in the release notes).
4.) Only AFTER installation you get a dialog box when you try to configure this mentioning this "may cause unpredictable behaviour in Mac OS"
5.) Someone was asking about this warning and I'm explaining the results I've seen (see the start of this thread).
6.) I'm getting some workarounds on how to avoid the configuration, while the underlying problem isn't fixed and isn't properly documented. (again see the start of the thread)...

I'm trying to point this out and as a result I'm getting insulted as someone wanting to "solely use the point'n'click interface" and being a person "that can barely breathe on their own".

...and I'm the one with the attitude?

Thanks for the offered service, but I think I'm better off by unsubscribing from this thread...

 

[cyberjock]

Actually.. I was trying to give you a compliment...

 

[hartzell]

Yes, for the current software. Feel free not to take advantage of workarounds. I have two more that I won't bother to type up due to your attitude.

Also, go raise a bug rather than rant at people trying to help.

For what it's worth, I filed a bug a couple of months ago asking for clarification about what the warning was about. It's here:

http://support.freenas.org/ticket/1884

and there has been no response. Seems like *someone* put that code there and could explain what they were worried about (even if it's just a cargo-culted warning).

I have a setup that is similar to the person you're accusing of ranting, (for the record I think he's being useful) Current version of FreeNAS, multiple zfs filesystems (one per machine on which I'm running TimeMachine), all exported via AFP with the TimeMachine option set.

It usually works, I see occasional times when it can't find the volume but it always seems to recover spontaneously.

My main problem with my setup is that that why my Mountain Lion based laptop periodically verifies the Time Machine backup it often declares it FUBAR and needs to start over. There are various hacks for trying to recover a backup but they're not guaranteed to work. I *think* that the problem is associated with my laptop disappearing in the middle of a backup (e.g. I grab it and leave the house) but I haven't come up with anything repeatable. The first release of Mountain Lion seemed to foul the backup up every time it went to sleep, but that was appears to have been fixed in .1 or .2. I think it's an inherent problem with remote TimeMachine backups, not a FreeNAS or netatalk issue.

 

[JaimieV]

My main problem with my setup is that that why my Mountain Lion based laptop periodically verifies the Time Machine backup it often declares it FUBAR and needs to start over. There are various hacks for trying to recover a backup but they're not guaranteed to work. I *think* that the problem is associated with my laptop disappearing in the middle of a backup (e.g. I grab it and leave the house) but I haven't come up with anything repeatable. The first release of Mountain Lion seemed to foul the backup up every time it went to sleep, but that was appears to have been fixed in .1 or .2. I think it's an inherent problem with remote TimeMachine backups, not a FreeNAS or netatalk issue.

Yes, closing the laptop to sleep is the most common reason for TM archive failure by my count, by a long way - and that happens using wifi or ethernet direct to an Apple Time Capsule as well, so you're right about it being inherent. The new ML feature of dual round-robin TM destinations papers over the cracks, as when one archive gets invalidated you can copy the other one to where it was and continue with two good archives.

More anecdote than data, mind - this is domestic usage. "A long way" translates to five events on one laptop that gets manually closed and sleep'ed a lot, while the other laptop is in an office setup with external screen and only goes to sleep on its own 15 minute timer, once event. A wired iMac twice, a wired Mini never.

Thanks for filing the bug, btw. vbonline does indeed have good points, but also shoots the messenger which is rarely helpful.

 

[Xcapee]

I've been back to this thread numerous times over the last year, to see if there was any update. Given that 9.2.x uses netatalk 3, I'm wondering if this is still an issue. The 9.2.1 documentation still contains the warning "due to a limitation in how Mac deals with low-diskspace issues when multiple Mac's share the same volume, checking Time Machine on multiple shares is discouraged as it may result in intermittent failed backups".

I was hoping for more definitive traceability on the "issue". There are some helpful anecdotes but nothing definitive that sheds light.

I'm wondering how the devs and doc developers will know when to remove the warning if no-one can definitively point to the actual (rather than imagined?) issue.

 

[dlavigne]

I can't find it at the moment, but there was a forum thread that had several URLs pointing to external resources that explained the issue...

In order to change the message/docs, we'll need verification from users that multiple Time Machine shares no longer seem to have a problem.

 

[Xcapee]

Thanks @dlavigne. Most of the external links I have seen referred to haven't been a "smoking gun". If you do come across it again, please post the link to that thread here.

 

[fracai]

I've been using two datasets (for a bit it was three) as TimeMachine shares without any issue that I can attribute to the share. (There have been a few issues that I attribute to TimeMachine and OS X.)