Making Time Machine work with the ReadyNAS

Never really thought about it. Why would I want my users to have access to the TM share?

A good view times I have wanted to browse a backup for an older version of a file or for something I've "lost". By being able to access the TM backup via Finder it is possible to quickly view & compare multiple versions of files, or perform searches, and then simply drag & drop to another location the data I find/need. Far easier than dealing with the full screen TM interface in my opinion - which looks nice, but is not as flexible. Having to now disconnect from the NAS and reconnect to do this is a bit of a pain.

Second, while not a big deal for my needs, having all the backups on a share with a shared username/password gives all users access to all backups does it not?. Would not seem to be a good idea in a business scenario. Perhaps it would have been better to support an option to allow users to store their TM backups in, for instance, their home folders or limited somehow via permissions so that 1) they can access more conveniently as I describe and 2) users cannot access other peoples backups. (Note: I realise a common share is how Timecapsule typically works)

<Beware - rant mode on>

My 'feeling' is that the Netgear team has solved the basic technical problem of enabling the NAS to be used as a TM storage device without resorting to manual hacks (ie sparsebundle creation), which is to be commended. But there seems to be an opportunity here to provide even better support for TM and Mac users than can be achieved through the likes of TimeCapsule which would be a significant capability the Netgear team could promote and I would certainly like to see.

But to offer that I think how the TM backups are stored and accessed needs to be better thought through - Other examples in addition to what I have already described: why, when the TM service is enabled, do I get a 'timecapsule' icon in Finder that doesn't do anything? (A bug in the beta yet to be fixed?) Why is the TM service advertised over Bonjour as <hostname> such that it will prevent the CIFS service appearing in Finder if also enabled? (some users do use both and may unnecessarily hit issues because of the changes which are not documented). Less significant but further illustrates: Why has the naming convention for advertising the AFP service been arbitrarily changed? Changing naming like this without good justification surely is not good practice and for those who say this won't cause issues: Anyone who upgrades to 4.1.5 but continues to run with the manual TM hack will get failures if then ever disable & re-enable AFP support. Then there is the issue you raise of managing the TM backups - it's incredibly slow to delete a backup.

There needs to be more thought put into the practical usage scenarios to realise full TM support and to not cause existing NAS users potential problems, however remote, rather than just solving the technical issues. But do that, and the ReadyNAS products could be a superior solution for Mac data storage.

<rant off>

sphardy wrote:
<Beware - rant mode on>

It seems like you've done a good job enumerating the limitations of Time Machine / Time Capsule. Certainly most of the issues you note with the ReadyNAS are directly because of the way Time Capsule was designed. If there's a way to make something better than TC, I do think that would be cool, but given the closed nature of the solution, I believe it will be difficult to do that, while still using TM. (i.e., I think the improved solution would look something more like Retrospect or Synchronize Pro X.

The incredibly slow deleting isn't the fault of the ReadyNAS directly, but due to the huge number of files that Apple sparse bundles create, and certain limitations of the ext2/3 filesystem (very slow deleting large files.) Even if you were to ssh into the NAS and delete the bundle directly, it would take quite a while.

I still keep thinking that time machine support should be a "per user" thing, instead of a huge generic pool. The following "solution" has a major hole in that it only support user level security (not domain level), but I think it could be extended...

In frontview, in the 'user accounts' page, have an additional checkbox and quota field for each user. The checkbox enables or disables time machine for that user, and the additional quota field is to limit the size of the TM backup for that user. (As an alternative, the TM could support a group quota for TM backups.) If a user has TM enabled, an additional user account has to be created for the TM backup space. TM_username. The password would be the same as the user's normal password. Having a separate username allows the unique quota, as well as deals with other possible technical issues... The TM backups would no longer be stored in /c/.tmbackups (or whatever that directory is), but instead of stored in the user's home directory... .../username/.tmbackup/.

Doing this solves several gripes people (myself included) have about the current TM support:

1. security: I would no longer have to worry about other NAS users seeing the contents of my TM backups. In addition, I could enable/disable TM support for specific users...

2. Deletion of backups: By simply unchecking the TM support for a user in Frontview, the NAS would handle deleting the .tmbackup directory for that user without me having to deal with technical details.

3. Deletion SPEED: because deleting the sparse bundles is now something done on the NAS itself (instead of something done over ethernet) deletion of the sparse bundles can be faster. In theory, this can even be done with no apparent delay if the NAS were to have the deletion occur in the background. (turn off the share, and then "rm -rf username/.tmbackup &". There's also a linux trick for deleting large files faster that the NAS could use: truncate each file to a 0 byte size, and then delete the remaining file. For that, a custom "rm" utility would have to be written...

I've been able to get my MacBook Pro to work using instructions (thanks :D ), but had some minor problems with my MacMini. For some reason, I couldn't create a sparsebundle greater than the current avail local disk capacity. I kept getting the error:

hdiutil: create falied - No space left on device.

I initially created 30g for MacMini, but this wasn't the case with my laptop where I created 200g. Is there a way to increase capacity lator on?

False alarm...I found out that I had missed the file extension "sparsebundle" in the hdiutil create command. I had printed out the instructions and my printer truncated the instructions. I'm now able to back-up 2 Mac's to my ReadyNAS.

Please ignore my previous post.

So I've followed the guide have have set up a couple of Time-machines on our ReadyNas 1100. When setting this up I was constantly testing with 1 Mac, and pretty happy that I got it to work and the performance.

However I've set up 8 Mac's to perform Time-machine backups on the Readynas 1100 at this point, and the performance is really extroadinary slow. When 2 or more Mac's are performing a backup, the speed is around 50MB per minute. Anyone experiencing this as well?

I am connecting over 100Mbit through AFP.

Just a quick question, when I created the sparseundle i purposely left out a size determinate in the terminal command because I wanted to have the ability to have it grow exponentially without having to start over.

Time machine is working as expected (aside from a permissions error on the share after updating to latest firmware which I figured out) but by me creating a sparse bundle with no size requirements will it work in the way that I described? Or will at some random point the sparsebunle nuke itself and my backups into oblivion?

Thanks in advance.

dtambre wrote:
Time machine is working as expected (aside from a permissions error on the share after updating to latest firmware which I figured out) but by me creating a sparse bundle with no size requirements will it work in the way that I described? Or will at some random point the sparsebunle nuke itself and my backups into oblivion?

In theory (ie I don't knwo of anyone who has tested this) the sparsebundle will only be restricted by the available space on your NAS - I'm not aware of any size limitations of sparsebundles.

One thing to note however: If your TM backup does become too large for any reason, deleting files/backups from a sparsebundle will NOT reduce its size. It will grow as you add data but space is not 'recovered' when data is removed. The utility 'hdiutil' does have the capability to manipulate sparsebundles, but I have not seen this work successfully when the sparsebundle is on the NAS (which is why the TM hack requires you to create the starting sparsebundle locally first)

///P

That's interesting, I have no problem being the ginnie pig for this. I doubt the size is going to be a problem, since I'm currently working with a 160gb HDD in the macbook, theoretically(on the mac side) old back ups get deleted anywhere between 2-3 months depending on space on the external and are then replaced with fresh ones to keep down on mold.

I'll have to give some info further down the line on if backups are indeed being removed after some time. I also realize that deleting files from the sparsebundle that I made would be irrelevant (been checking to see if anything was added to it on my share) however other then when the system is backing up does anyone know of a way to get into the external drive that shows up? Because I know I can defiantly root through the backups.db folder and get rid of old dates manually should the need arise. And if I remove files from there does anyone know if it effects the sparsebundle size in return? Or does the sparsebundle stay bloated?

dtambre wrote:
other then when the system is backing up does anyone know of a way to get into the external drive that shows up?

If you setup TM with the NAS manually (ie do not use the service in the newest 4.1.5 beta) then you can simply mount the TM backup by double-clicking on the sparsebundle in finder

dtambre wrote:
Because I know I can defiantly root through the backups.db folder and get rid of old dates manually should the need arise. And if I remove files from there does anyone know if it effects the sparsebundle size in return? Or does the sparsebundle stay bloated?

It stays bloated - this I can confirm from practical experience