NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Making Time Machine work with the ReadyNAS
The step-by-step how-to can be found here.
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 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...
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
