Limits on Time Machine

So I have my three macs backing up to my UnRAID via Time Machine (by the way - very happy with UnRaid 5beta 3) - but I can see that Time Machine will carry on making backups until my drive is full. I would like to limit the size of my Time Machine share, but I can't see how to do this. Is it possible to set quotas on the shares so that I don't use all my space with Time Machine backups?

Jon

Set the min free space for your time machine share to limit its size on the disk. This may confuse TM because the reported free space will show that space is available but writes will fail. Although, this may work without issue.

I don't recommend the above....

If you really want to limit time machine, I would suggest using a full dedicated disk for your backups. The new 5.0b3 option allows you to set a disk to not take part in the user shares. This is perfect for Time Machine.

If you have spare slots, put a 500gb (or whatever space you want to dedicate for your backups) in that slot and set time machine to backup there. That way you won't be fudging with how it works. Time Machine is very picky about how it does it's backups and I'd hate for you to corrupt your sparseimage files because of unexpected write failures.

Thank you - makes sense - use a separate disk. Will try that.

Jon

netatalk should support a fake volume limit since version 2.1 (http://www.netafp.com/tn004-10-6-3-and-timemachine-over-afp-image-size-limitation-102/#more-102).

maybe this can be included. (maybe it already is, but it's not yet in the webui?)

as far as I understand it, it should be a sinple additional setting when setting up the share.

volsizelimit:size in MiB

Useful for TimeMachine: limits the reported volume size, thus preventing TM from using the whole real disk space for backup. Example: "volsizelimit:1000" would limit the reported disk space to 1 GB.

I believe the version of AFP included in unRAID 5.0 beta series will be 2.0.5. Once basic support is ironed out and stabilized then it could/would be updated to the newer versions, such as 2.1 or 2.1.5.

you're right. i just checked the version, it's 2.0.5.

I thought, Tom would use the most recent version. But hopefully this will come in a later build.

you're right. i just checked the version, it's 2.0.5.

I thought, Tom would use the most recent version. But hopefully this will come in a later build.

Slackware "current" only supports 2.0.5, so that means I have to build it from source and create my own package - which I can do, and  have done, e.g., with Samba.  It just takes some time to get it right.  Newest netatalk also requires newer 'db' library than available in slack, so I have to build that too.  But I thought I'd get the support in there to get some experience with using AFP and learning how it works, even if a couple rev's back - hey if Apple can get away with using an old version of Samba I should be able to get away with using an old version of netatak 

The free space issue with Time Machine is something I can definitely look at though.  If someone can provide a good description of what the issue is, or point me to a source, I can think about a solution.

I had a look at Slackware's build process "netatalk.SlackBuild" and it might be reusable for you. So if you're extra fortunate, grabbing the source/n/netatalk/ directory from a Slackware mirror, removing netatalk-2.0.5.tar.xz, grabbing netatalk-2.1.5.tar.gz, then invoking ./netatalk.Slackbuild. Their build script seems to dynamically determine the version number.

As always there's gotchas... One possible gotcha is they apply 3 patches to the source code before compiling. Another possible gotcha are changes required for the newer version to the rc.atalk or afppasswd or some other file involved.

If nothing else, is should provide a decent starting point.

I had a look at Slackware's build process "netatalk.SlackBuild" and it might be reusable for you. So if you're extra fortunate, grabbing the source/n/netatalk/ directory from a Slackware mirror, removing netatalk-2.0.5.tar.xz, grabbing netatalk-2.1.5.tar.gz, then invoking ./netatalk.Slackbuild. Their build script seems to dynamically determine the version number.

 

As always there's gotchas... One possible gotcha is they apply 3 patches to the source code before compiling. Another possible gotcha are changes required for the newer version to the rc.atalk or afppasswd or some other file involved.

 

If nothing else, is should provide a decent starting point.

 

Right, that's how I already do it, unfortunately there are quite a few configure changes.  Also need to build a newer berkeley db than what's available in slack current using same technique (also many configure changes).  I want to get current netatalk working as expected so when 2.1 gets built, if something wrong it's probably with 2.1 and not a general config issue like it looks like I'm seeing now.